”瀑布“和”敏捷“之争

最近和朋友谈起敏捷开发和瀑布开发模式，很多人认为敏捷开发是未来的项目实施的趋势，瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼，联想也在使用敏捷的方式实施一些项目。但实际上我们看到绝大多数公司还是依然在采用瀑布的方式实施项目。我之前参与过敏捷开发的项目，但当时比较“年轻”，认识不是很深刻，于是最近又补习了下和大家一起分享下我对敏捷和瀑布的感悟。

I ”敏捷”的理由

在敏捷看来，很多情况下面，我们都无法去了解到全部的内容，或者即使是了解到，我们也不能保证这些内容是不会变化的。所以先根据主路径，完成主要功能后，我们再通过不断地迭代，去完善我们的工作，这样当我们产生变化的时候，我们推翻的工作量也是少量的，可以很快的去完成新的需求变更。通过这样的不断地变更、重构，我们可以获得一个相对客户满意的产品。

对于瀑布的开发模型来看，似乎依然具备很可靠的工作逻辑，一个工程或项目分为多个阶段，每一个阶段都投入相应的资源，来完成本阶段的工作。每一个阶段到下一个阶段，都有明确的输入输出产物，不同的阶段根据自己所需的输入，进行工作活动之后，产生自己阶段的产出，投入到下一个阶段的工作中。如果不放心的话，每一个阶段还可以增加一个审批环节，让每一个环节都可以经过可靠的审批之后，再投入到下一个环节当中。

很多支持敏捷的同学会说瀑布缺乏与业务的沟通和迭代次数，所以如果在项目的后期才发现要更改需求的话，则项目可能会失败或需要重新启动。这张图好像也解释了瀑布开发经常所面临的困境。

在高举效率与拥抱变化的大旗之下，似乎敏捷模式，就是最好的开发模式。与之相比的是瀑布模式，在这样的呼喊之中，显得有些无法跟得上步伐，体现的是陈旧、死板的。

I “瀑布”对“敏捷”的驳斥

敏捷本身不是项目管理框架，也不是“方法论”。它是一套与产品开发相关的原则和价值，特别是互联网产品经常会采用敏捷的方法来进行开发。但是，有一些基于敏捷原则的方法，这些方法是产品开发方法，而不是项目管理框架。

说到需求变更，瀑布也可以走需求变更，提变更申请，按照环节一步一步走，去规划工作量。虽然比敏捷是要慢一些，但是我整个流程是可靠的！为什么就说瀑布是死板的，不符合时代的呢？

似乎瀑布的做法也没有错误，我们何不按照这样的步骤，来完成我们的工作呢？这样的过程听起来是如此的可靠。看，我有明确的阶段；看，我有明确的审批；看，我有明确的变更流程。以瀑布模式进行开发的项目有这么多，已经证明了这是一个有效的实施方法，难道不是么？

另外被敏捷所诟病的瀑布项目经常失败通常是发生了非常严重的错误情况下才会产生。实际上只有在对项目的控制很差的情况下才会发生这种情况。瀑布型项目没有迭代和用户的多次反馈也是不正确的 - 很多项目可以通过产品原型图的方式和业务部门确认操作的流程，只是很多项目中并没有使用这种方法。

I 焦点碰撞

敏捷模式，两周一个迭代，每个迭代都能进行一定功能模块的交付，让用户更早的看到交付物，虽然只有部分，也可以让用户来提出自己的看法，产生变更的时候，开发人员也可以在下个迭代中进行修改，让用户进行再次的确认。

从这样看来，两者的碰撞就是在交付的及时性上与面对变更的成本上，所看到有极大的变化。瀑布在交付阶段比较靠后，交付的模块比较完整，在面对变更的时候，变更影响范围就比较大，变更的成本就极大。问题发现的阶段越靠后，解决问题所需要付出的成本就更高。这样，就体现出来了敏捷对瀑布在这样的情景下面的优势。

时间和成本，看起来就是敏捷和瀑布在选择时主要考虑的两个方面。未来能更好的指导未来的选择，下面还列出了更详细的敏捷和开发的优劣势。

敏捷的优势：

• 开发的阶段性成果会在开发过程中尽早的进行审查，项目的风险会降低；
• 适用于需求不明确情况，因为需求不明确，所以需要在不断迭代的过程中来逐步理清需求。
• 灵活性较高，几乎可以在任何时间进行需求变更；
• 敏捷鼓励开发人员与业务用户之间进行多频次的沟通，业务用户的不合理需求以及开发人员的错误理解都会在这些频繁的沟通中进行不断审查和更新，
• 敏捷的协作通常要高得多，通常能开发出更高质量的产品；
• 适用于快速变化的项目，特别是面向前端业务人员的CRM项目更容易根据业务的变化而变化

敏捷的劣势：

• 敏捷的概念接受度还不算太高，初次尝试可能不会非常成功；
• 最终交付的内容无法预测，预期和实际完成的内容经常会有很大差异；
• 敏捷需要高水平的协作以及开发人员和用户之间的定期沟通。 业务和IT人员在沟通前需要做大量的准备工作，但很多情况下业务的沟通时间无法保证；
• 当存在乙方供应商的情况，敏捷会面临更大的挑战性。 客户通常希望尽早了解他们的项目投入。 预估项目时间和成本难度较高；
• 在敏捷项目中，最大的问题可能是业务部门永远不希望有最终的截止时间；

瀑布的优势：

• 在管理良好的项目中，瀑布可以在早期提供交付的信心；
• 项目团队成员不需要在同一地点频繁沟通；
• 在需要大量的设计或分析的情况下瀑布是一种更合适的方法；
• 如果在基本产品开发之外存在许多接口和依赖关系，瀑布式项目会使用工具来建模和管理这些接口和依赖关系；

瀑布的劣势：

• 许多企业和业务人员确实不容易在前期定义清楚需求，早期计划中所依据的假设需求可能存在很大风险；
• 沟通的风险要高得多 - 特别是很多项目都是前期单向的沟通，后期项目和业务人员的预期差别很大；
• 瀑布项目的风险一般都很高，因为基于无效假设基础上的需求可能会让项目无限度扩大。 所以你会看到很多瀑布项目都出现成本超出预算或延迟的情况；

I 结论：

敏捷和瀑布的实施方法差别还是很大的，瀑布几乎可以应用于任何类型的项目，尤其是大型的项目。

敏捷方法今年来越来越受欢迎，尤其是当前SaaS软件当道，特别像Salesforce这样自带开发平台的SaaS产品可以非常容易的搭建初始原型并进行快速迭代，所以我们才会看到有越来越多的企业采用敏捷的方式来进行项目实施。总的来说敏捷并不能完全替代瀑布，它只是给了我们另外一种好的选择。