敏捷项目管理︱传统瀑布式模型的四大缺点

敏捷的三大收益
自2001年敏捷宣言诞生至今有近20年的时间，敏捷已经在全球范围内应用非常广泛。在很多企业里，敏捷成为必须的工作方式。
 
VersionOne[1]2016的敏捷开发状态报告中，上千人参与了反馈，98%的受访者在敏捷项目中获得了收益(如下图)。其中占比最大的三个收益是：
 
增强了应对（需求）变更的能力
提高了团队交付效率
提升了项目的可视化程度
 
敏捷的其他收益
这三项收益在连续五年的调研结果中一直排名靠前。除此之外，调研报告中敏捷带来其他的收益还有：
 
提升团队士气
交付更加可预测
缩短上市时间
提高产品质量
降低项目风险
增进业务与IT部门的协作
加强软件工程纪律
改善软件的可维护性
更容易管理跨地域团队  
传统瀑布式敏捷的四大缺点
虽然很多企业通过实施敏捷在以上多个方面获得了收益，但是，企业为什么一定要进行敏捷转型?敏捷转型是必须要走的路吗？
90年代后，随着互联网时代的到来，人们越来越认识到传统研发方式的缺点。
 
缺点1
缺花了很长时间但是最终交付的产品与客户的期望偏差很大。人们不得不接受这样两个现实：
需求不是一次性或者一段时间内就可以完全定义清楚的。需求定义是个不断发现的过程。需求必须在整个研发过程中与客户不断沟通，反复澄清，甚至需要结合业务流程图、产品原型等工具，才能明确客户想要的需求是什么。需求的本质特性决定了即使瀑布模型存在一个专门的需求分析阶段，然而在设计、开发甚至测试阶段中仍旧会出现新的需求。
需求本身具备不确定性，客户也经常不完全清楚自己想要的是什么，只有看到了产品原型或者使用了产品之后，才有可能厘清自己的需求。因此需要持续获得客户对产品的反馈，才能明确产品下一步该做什么需求、不该做什么需求。
因此，瀑布模型试图在第一步就定义好完整的产品需求，这其实是在试图实现一个无法实现的梦想。
 
缺点2
无法根据市场的变化动态地调整产品。
市场不是静态的。尤其是互联网产品，市场的变化非常迅速。而瀑布模型在需求分析阶段结束后冻结需求，之后任何需求的变化都需要走严格的变更流程。因为怕影响交付时间，一般都会抑制需求的变化。但是市场已经有了变化，抑制需求的变化反而不能交付真正适配市场的产品，即便最终按时交付，但是交付的是几个月甚至几年前冻结的需求文档里定义的那个产品，而不是现在市场上真正需要的那一个，反而贻误了新的商业机会。
 
缺点3
质量反馈严重滞后。
瀑布模型里严格区分了需求分析→设计→开发→测试等阶段，每个阶段通常都会耗时几周甚至几个月的时间，导致质量问题的反馈周期过长。例如：在开发阶段发现需求存在问题的时候，通常需求分析阶段结束已经过了好几个月了，对需求问题的修正除了需要走严格的变更评审流程之外，还需要对需求分析和设计阶段的产出物进行相应的调整，最终才能体现在开发阶段的产出物上。更为糟糕的是，测试阶段发现的Bug，有的是开发阶段引入的，有的是设计阶段引入的，有的甚至是需求分析阶段就出现了纰漏和错误。因此，从一个Bug引入的时候到发现它，已经过了至少几个月的时间。通常情况下，采用瀑布模型的项目，在交付前都会有长达几个月的集中修改Bug的阶段。
根据Scott W. Ambler做的瀑布研发方式的软件变更成本曲线(见下图 ）