瀑布与敏捷开发方法大比拼

【51CTO.com快译】众所周知，在一个软件开发项目开始之前，项目经理的工作往往是要确定在该项目的生命周期中应该采用哪种开发方法。目前，业界比较流行的开发方法有两种，它们分别是：

瀑布模型，一种传统的开发模型与方法。

敏捷方法，一种较瀑布模型更新的、快速的应用程序开发模型，开发人员经常使用Scrum来实现。

如今，随着全球各大软件开发公司纷纷采用了敏捷方法来开发其产品，瀑布模型正在逐渐失去其原有的适用性。下面让我们来深入探讨敏捷方法盛行的原因、以及它与瀑布模型的区别。

各自的工作原理

瀑布模型为软件开发提供了更为连续的方法。它会按如下顺序进行推进：

收集软件开发的需求文档。

在需求确定完成后，开始对应用程序进行设计。

着手开发，并执行并行式的单元测试。

通过增加负载或压力，开展性能测试、以及用户验收测试，以确保系统整体的稳定性和健壮性。

测试团队将检测到的缺陷提交给开发人员，以着手进行缺陷的修复。

将应用程序部署到生产环境中。

然而，敏捷方法却并不遵循任何一种线性的路径。它遵循的是迭代式的开发方法。它不会为项目的全程创建各种任务，而是分为多个迭代周期阶段(Sprint)。因此，敏捷方法通常关注的是四个方面的基本价值：

团队成员之间的交互，而不是单纯的工具之间。

更强调持续的工作过程，而不是包罗万象的文档。

客户在每一次sprint中的合作与参与度。

快速响应变更，而不是循规蹈矩。

需求收集阶段

如果采用了瀑布模型来开发应用程序，那么无论是客户还是组织都需要事先对需求规范拥有一个清晰的理解。而一旦需求被接受了，任何一方都不可以轻易改变既定的范围。

然而，在敏捷方法中，项目在开始时并没有固定的需求文档。客户可以在每一次Sprint中提出不同的用户故事(user stories)，而开发者的任务是完成程序编码、并提交演示版本。如果客户对该产品并不满意，需要附加更多组件的话，那么他就可以要求对应用程序进行变更。可见，在处理客户需求上，敏捷方法比瀑布模型更为灵活。

适合的项目

根据上述特点，如果客户对于即将开发的软件有着非常明确的需求，那么瀑布模型显然是最好的方法，因为它遵循的是一种线性的方法，并且能够在第一个阶段就将需求明确了下来。

然而，如果您筹备开发的应用程序，需要在每个阶段进行演进，并且您在项目中可以预见到各种频繁的变更，那么敏捷方法则是满足客户需求和技术实现的适合方法。

产品对于客户的可视性

在瀑布模型完成之后，应用程序被部署到了生产环境中，客户只能在项目结束后看到完整的产品。

而在敏捷方法中，由于持续的时间被分成了多个Sprint，客户可以有频繁的机会来查看产品，进而做出是要接受当前的标准、还是要执行变更的决定。

团队合作

瀑布模型最大的缺点是：它不允许开发人员和测试人员之间进行集成式的协作。测试员只有在开发阶段结束后才开始接触代码，并着手各项测试工作。

而在敏捷方法中，测试人员和开发人员能够协同工作。每个Sprint都有一个测试阶段，而且在开发人员每次发布新的函数功能之后，测试人员都会立即进行回归测试。

把大任务分成小任务

在瀑布模型中，由于整个应用程序是作为一个单独的项目被完成的，因此整个软件开发会变得较为复杂。特别是当大型应用程序进入测试阶段时，不但开发人员会产生等待“审判”的感觉，就连测试人员也会觉得陌生且慌乱。

而在敏捷方法中，一个项目被分成了多个用户故事。在每个阶段，开发人员和测试人员通过协同工作以了解需求，并且由客户最后给出是否正确地完成了所有工作的结论。这些都使得各方的工作更为容易和更加快捷。

使用统计

一份由Standish集团(译者注：美国一家专门从事跟踪IT项目成败的权威机构)于2010年发布的CHAOS报告曾明确地表明：那些采用了敏捷方法的项目会面临更少的挑战。与遵循瀑布模型方法的项目相比，它们失败的可能性会更小。

敏捷与瀑布的利与弊

瀑布式方法

作为传统的瀑布模型，它在许多方面都积累了自身的优势：

通过一个可预测的、静态的工作流，确保了团队能够计算出适当的成本、以及根据截止日期的概念进行合理的估算。

由于该过程需要各种文档，因此各类文件线索会贯穿每个开发阶段。对于项目团队而言，只要遵循过去项目的逻辑，就能为未来的项目奠定扎实的基础。

由于流程模型较为固定，项目团队无需事先储备与积累知识，便可根据既定的瀑布模型开展工作。

然而，该模型的缺点在于：

由于该模型是固化的，因此无论是客户、还是项目团队，任何重大的变更都会带来高昂的成本，毕竟整个项目可能会被推倒重来。

需求收集、开发、测试等每个开发阶段都占用了大量的时间，因此项目干系人，特别是客户，直到最终才能看到真正应用效果。

敏捷开发方法

由于遵循了迭代式的开发路径，因此敏捷方法具有如下方面的优势：

较短的开发阶段，能够使得项目的适应性较强，项目组随时应对客户所提出的任何重大或微小的变更。

客户可以在每一次sprint期间查看到项目的当前状态，并能够通过定期的反馈产生更高质量的产品。

开发人员、测试人员、客户三者能够协同工作。这样的协作式项目团队有助于个人的发展和组织的改进。

当然客观地说，凡事有利必有弊，我们来看看该方法所具有的缺陷：

相对于文档，敏捷方法更强调的是持续的工作过程。因此清晰明确的项目尚可接受文档的不到位;而对于复杂的大型项目而言，我们仍需要平衡好文档和程序代码之间的联系和完整度。

该方法主要是针对中小型团队设计的。因此，团队中的每个成员应当准确地明白自己的角色、以及工作的独立性。

总结

长期从事软件开发的项目人员时常会认为：只有事先明确了客户的需求，并采用了适当的计划，才能保障成功的交付。但是在我们现实的工作与开发任务中，只有实现了快速的交付，才能提高组织的盈利能力。因此，希望上述针对两种开发方法的比较与分析，能够帮助项目干系人根据手头项目的具体性质与特点，选择出更为恰当的软件开发方法。

原文标题：Head-to-Head: The Agile and Waterfall Methodologies，作者：Arnab Roy

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】