软件开发模式：瀑布与敏捷对比

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

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

敏捷开发和瀑布开发

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

• 收集和记录需求
• 设计
• 代码和单元测试
• 执行系统测试
• 执行用户验收测试(UAT)
• 解决任何问题
• 交付成品
  
  对于瀑布的开发模型来看，彷佛依然具有很可靠的工做逻辑，一个工程或项目分为多个阶段，每个阶段都投入相应的资源，来完成本阶段的工做。每个阶段到下一个阶段，都有明确的输入输出产物，不一样的阶段根据本身所需的输入，进行工做活动以后，产生本身阶段的产出，投入到下一个阶段的工做中。若是不放心的话，每个阶段还能够增长一个审批环节，让每个环节均可以通过可靠的审批以后，再投入到下一个环节当中。
  
  SDLC瀑布模型通常用于这些状况：要求稳定且不常常更改；应用程序很小；没有不明白或不明确的要求；环境稳定；使用的工具和技术是稳定的；不是动态的；资源可用。

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

在敏捷看来，不少状况下面，咱们都没法去了解到所有的内容，或者即便是了解到，咱们也不能保证这些内容是不会变化的。因此先根据主路径，完成主要功能后，咱们再经过不断地迭代，去完善咱们的工做，这样当咱们产生变化的时候，咱们推翻的工做量也是少许的，能够很快的去完成新的需求变动。经过这样的不断地变动、重构，咱们能够得到一个相对客户满意的产品。

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

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

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

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

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

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

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

焦点碰撞

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

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

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

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

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

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

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

结论：

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

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

转载请注明出处：怡海软件（http://www.frensworkz.com/）