传统瀑布式模型的四大缺点

自2001年敏捷宣言诞生至今有近20年的时间，敏捷已经在全球范围内应用非常广泛。在很多企业里，敏捷成为必须的工作方式。

VersionOne[1]2016的敏捷开发状态报告中，上千人参与了反馈，98%的受访者在敏捷项目中获得了收益(如下图)。其中占比最大的三个收益是：

1. 增强了应对（需求）变更的能力
2. 提高了团队交付效率
3. 提升了项目的可视化程度

这三项收益在连续五年的调研结果中一直排名靠前。除此之外，调研报告中敏捷带来其他的收益还有：

1. 提升团队士气
2. 交付更加可预测
3. 缩短上市时间
4. 提高产品质量
5. 降低项目风险
6. 增进业务与IT部门的协作
7. 加强软件工程纪律
8. 改善软件的可维护性
9. 更容易管理跨地域团队

 

VersionOne 2016年敏捷对组织的收益的调研统计

虽然很多企业通过实施敏捷在以上多个方面获得了收益，但是，企业为什么一定要进行敏捷转型?敏捷转型是必须要走的路吗？

90年代后，随着互联网时代的到来，人们越来越认识到传统研发方式的缺点。

缺点1：花了很长时间但是最终交付的产品与客户的期望偏差很大。人们不得不接受这样两个现实：

1. 需求不是一次性或者一段时间内就可以完全定义清楚的。需求定义是个不断发现的过程。需求必须在整个研发过程中与客户不断沟通，反复澄清，甚至需要结合业务流程图、产品原型等工具，才能明确客户想要的需求是什么。需求的本质特性决定了即使瀑布模型存在一个专门的需求分析阶段，然而在设计、开发甚至测试阶段中仍旧会出现新的需求。
2. 需求本身具备不确定性，客户也经常不完全清楚自己想要的是什么，只有看到了产品原型或者使用了产品之后，才有可能厘清自己的需求。因此需要持续获得客户对产品的反馈，才能明确产品下一步该做什么需求、不该做什么需求。

因此，瀑布模型试图在第一步就定义好完整的产品需求，这其实是在试图实现一个无法实现的梦想。

缺点2：无法根据市场的变化动态地调整产品。

市场不是静态的。尤其是互联网产品，市场的变化非常迅速。而瀑布模型在需求分析阶段结束后冻结需求，之后任何需求的变化都需要走严格的变更流程。因为怕影响交付时间，一般都会抑制需求的变化。但是市场已经有了变化，抑制需求的变化反而不能交付真正适配市场的产品，即便最终按时交付，但是交付的是几个月甚至几年前冻结的需求文档里定义的那个产品，而不是现在市场上真正需要的那一个，反而贻误了新的商业机会。

缺点3：质量反馈严重滞后。

瀑布模型里严格区分了需求分析→设计→开发→测试等阶段，每个阶段通常都会耗时几周甚至几个月的时间，导致质量问题的反馈周期过长。例如：在开发阶段发现需求存在问题的时候，通常需求分析阶段结束已经过了好几个月了，对需求问题的修正除了需要走严格的变更评审流程之外，还需要对需求分析和设计阶段的产出物进行相应的调整，最终才能体现在开发阶段的产出物上。更为糟糕的是，测试阶段发现的Bug，有的是开发阶段引入的，有的是设计阶段引入的，有的甚至是需求分析阶段就出现了纰漏和错误。因此，从一个Bug引入的时候到发现它，已经过了至少几个月的时间。通常情况下，采用瀑布模型的项目，在交付前都会有长达几个月的集中修改Bug的阶段。

根据Scott W. Ambler做的瀑布研发方式的软件变更成本曲线(见下图)，可以看到采用瀑布模型的项目，软件变更的成本随着变更引入的阶段呈指数型上涨，越到软件研制的后期，变更的成本越高。

                                                      资料来源：Scott W. Ambler的博客

缺点4：价值交付周期长。

在瀑布模式里，一个产品从立项到发布给客户一般需要经过几个月、一年甚至几年的时间。在研发的中间过程中，没有任何可以给客户使用的产品。虽然在客户的要求下，也许有一些文件和报告会提供给客户，但产品的实际进展对客户还是一个黑盒。

于是在这样的背景下，软件工程迎来了第二次浪潮：敏捷软件开发。XP(极限编程)、Scrum等各种敏捷方法出现，在2001年的时候诞生了敏捷宣言。2003年，精益软件大师Mary Poppendieck将精益思想融入到软件工程中，诞生了精益软件开发原则(参考文献2)。

随着近几年移动互联网的快速发展，为了抓住市场上稍瞬即逝的商机，满足不断增长的业务需求和用户体验，促使服务提供商对软件产品有了更高的期望和要求：不仅仅是能够短周期内迭代交付，而是持续不断地按需部署到生产环境。由此，DevOps概念和技术在这个背景下诞生。

下表列出了世界互联网的几只领头羊企业的交付效率与一般企业的对比。部署效率以月或季度为单位的企业，与部署时间以分钟或小时为单位的企业相比，完全不具备竞争实力。

世界TOP互联网企业的交付效率

公司	部署频率	部署效率单位	可靠性	客户响应高
亚马逊	23000次/天	分钟	高	高
谷歌	5500次/天	分钟	高	高
网飞	500次/天	分钟	高	高
Facebook	1次/天	小时	高	高
Twitter	3次/周	小时	高	高
一般企业	9个月1次	月或季度	低/中	低/ 中

资料来源： 《凤凰项目，一个IT运维的传奇故事》（The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ），2015年9月

从以上历史可以看出，软件工程方法的演进是个自然的过程，其背后是技术的驱动和时代的演进。当我们从大型主机一步一步发展到移动互联网的时代，必然会演进新的工程方法和技术来适配时代的进步，以期更加快速、灵活地响应客户和用户的需求，使其在竞争极其惨烈的时代占得先机。

 

---