瀑布式开发和敏捷开发的区别

在软件开发时，经常面对的第一个项目实现决策是“我们应该使用哪种开发方法?”这是一个引起很多讨论(和激烈辩论)的话题。如果您以前没有使用过这种方法，那么适当了解开发方法和理论是必要的；简单地说，这是一种组织软件开发工作的方法。这与项目管理的风格或特定的技术方法无关，尽管您经常会听到这些术语混在一起或互换使用。最流行的两种基本方法是:瀑布开发和敏捷开发。这两种方法都是可用的、成熟的方法。

现在，说起敏捷开发（Agile Model）和瀑布开发（Waterfall Model）模式，很多人认为敏捷开发是未来的项目实施的趋势，瀑布实施太老土已经过时了。另外确实一些跨国企业如索尼，联想也在使用敏捷的方式实施一些项目。但实际上我们看到绝大多数公司还是依然在采用瀑布的方式实施项目。本文主要简单介绍敏捷和瀑布的区别和优劣。

敏捷开发和瀑布开发

1、瀑布模型

瀑布模型是一种项目分解为有限的阶段来开发软件的方法。只有在审查并验证其前一阶段时，开发才应进入下一阶段。在瀑布模型中，阶段不重叠。在这种方法中，事件的顺序是这样的：

收集和记录需求
设计
代码和单元测试
执行系统测试
执行用户验收测试(UAT)
解决任何问题
交付成品

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

SDLC瀑布模型一般用于这些情况：要求稳定且不经常更改；应用程序很小；没有不明白或不明确的要求；环境稳定；使用的工具和技术是稳定的；不是动态的；资源可用。

2、敏捷模型

敏捷是一种迭代的、基于团队的开发方法。这种方法强调以完整的功能组件快速交付应用程序。所有的时间都被“固定时间盒”划分为“冲刺（通常称迭代）”阶段。而不是创建任务和时间表。每个迭代周期都有一个定义的持续时间(通常以周为单位)，其中包含在迭代开始时计划的可交付成果的运行列表。交付物根据客户确定的业务价值进行优先级排序。如果迭代中所有计划的工作都不能完成，那么工作将被重新排序，这些信息将用于未来的迭代计划。当工作完成时，项目团队和客户可以通过每日构建和迭代演示对其进行审查和评估。敏捷依赖于整个项目中非常高水平的客户参与，特别是在这些评审期间。

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

很多支持敏捷的同学会说，与瀑布方法相比，敏捷风险的风险要小得多。因为其专注于交付经过充分测试的独立、有价值的小功能。因此分散了风险——如果一个功能出错了，它不应该影响另一个功能。在这一方面，我们仍然在迭代中计划我们的工作，并且我们仍然会在每次迭代的末尾发布。而瀑布缺乏与业务的沟通和迭代次数，所以如果在项目的后期才发现要更改需求的话，则项目可能会失败或需要重新启动。这张图好像也解释了瀑布开发经常所面临的困境。

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

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

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

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

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

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

焦点碰撞

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

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

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

敏捷开发的优势：

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

敏捷开发的劣势：

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

瀑布开发的优势：

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

瀑布开发的劣势：

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

结论：

敏捷和瀑布的实施方法差别还是很大的。现在，瀑布几乎可以应用于任何类型的项目，尤其是大型的项目。敏捷方法在这两年来越来越受欢迎，我们开始看到企业(甚至国防部和联邦机构)中大量采用各种敏捷方法，尤其是当前SaaS软件当道，如Salesforce、SAP等这样自带开发平台的SaaS产品可以非常容易的搭建初始原型并进行快速迭代。但总的来说敏捷并不能完全替代瀑布，它只是给了我们另外一种好的选择。

现在，对于组织来说，将敏捷和瀑布方法结合在一起的混合敏捷方法也很常见。一旦我们决定了使用哪一种基本方法，我们就可以进一步细化过程以最适合我们的项目目标。最后，尽管我们工作的方式很重要，但是交付一个可靠的、可维护的、满足客户需求的产品才是最重要的。