我也来聊聊传说中的敏捷和小瀑布

敏捷与小瀑布：相爱相杀还是迷茫中前行？

敏捷和小瀑布模型在软件开发的过程中有着各自的特点与问题。传统的大瀑布模型因固定的时间和范围常常导致质量牺牲或延期上线，而且集中的测试阶段往往增加了Bug修改的时间和成本。相比之下，小瀑布模型虽然更加灵活，但在迭代过程中仍未能彻底解决瀑布模型固有的缺陷。

大瀑布与小瀑布的困境

大瀑布模型中，上线前的范围固定，所有功能开发完毕后才进行测试。由于开发经常延期，而上线时间不变，测试时间被压缩，质量因此受损。尽管加入缓冲时间，但由于“学生综合征”，开发人员往往浪费缓冲时间，导致最终结果仍然不尽如人意。此外，长时间后的Bug修改使得开发周期延长。

小瀑布则是大瀑布的一种迭代形态，虽然通过优先级分配和频繁上线提高了敏捷性，但在短迭代周期内，瀑布模型的问题仍然存在。

敏捷的解决之道

敏捷模型通过允许范围的变化，在不牺牲质量的前提下解决了这些问题。敏捷的关键在于需求的细致拆分和优先级排序，以及每个小块的独立上线能力。即便部分功能未完全实现，也能交付用户最在乎的部分。

在敏捷实践中，需求拆分至关重要。理想的目标是将迭代中的任务拆分到3天内完成，包括开发、测试和验收。敏捷不是一个具体的目标，而是不断迈向工作方式更加敏捷的方向。

作者简介

徐东伟，资深敏捷教练，拥有丰富的行业经验。自2008年起践行敏捷，并深入研究敏捷、精益、SAFe、DevOps等方法论。他致力于为中国企业的敏捷转型做出贡献，并期望结交更多志同道合的朋友。

代码覆盖率：质量的黄金标准，你的软件有多可靠？

了解更多

想要了解更多内容？

查看原文：我也来聊聊传说中的敏捷和小瀑布

文章来源：

徐东伟Jack

扫码关注公众号