引言：本文通过对两种流行的开发方法进行比较，协助项目干系人根据手头项目的具体特点，做出恰当的选择。
众所周知，在一个软件开发项目开始之前，项目经理的工作往往是要确定在该项目的生命周期中应该采用哪种开发方法。目前，业界比较流行的开发方法有两种，它们分别是：
- 瀑布模型，一种传统的开发模型与方法。
- 敏捷方法，一种较瀑布模型更新的、快速的应用程序开发模型，开发人员经常使用Scrum来实现。
如今，随着全球各大软件开发公司纷纷采用了敏捷方法来开发其产品，瀑布模型正在逐渐失去其原有的适用性。下面让我们来深入探讨敏捷方法盛行的原因、以及它与瀑布模型的区别。
各自的工作原理
瀑布模型为软件开发提供了更为连续的方法。它会按如下顺序进行推进：
- 收集软件开发的需求文档。
- 在需求确定完成后，开始对应用程序进行设计。
- 着手开发，并执行并行式的单元测试。
- 通过增加负载或压力，开展性能测试、以及用户验收测试，以确保系统整体的稳定性和健壮性。
- 测试团队将检测到的缺陷提交给开发人员，以着手进行缺陷的修复。
- 将应用程序部署到生产环境中。
然而，敏捷方法却并不遵循任何一种线性的路径。它遵循的是迭代式的开发方法。它不会为项目的全程创建各种任务，而是分为多个迭代周期阶段（Sprint）。因此，敏捷方法通常关注的是四个方面的基本价值：
- 团队成员之间的交互，而不是单纯的工具之间。
- 更强调持续的工作过程，而不是包罗万象的文档。
- 客户在每一次sprint中的合作与参与度。
- 快速响应变更，而不是循规蹈矩。
需求收集阶段
- 如果采用了瀑布模型来开发应用程序，那么无论是客户还是组织都需要事先对需求规范拥有一个清晰的理解。而一旦需求被接受了，任何一方都不可以轻易改变既定的范围。
- 然而，在敏捷方法中，项目在开始时并没有固定的需求文档。客户可以在每一次Sprint中提出不同的用户故事（user stories），而开发者的任务是完成程序编码、并提交演示版本。如果客户对该产品并不满意，需要附加更多组件的话，那么他就可以要求对应用程序进行变更。可见，在处理客户需求上，敏捷方法比瀑布模型更为灵活。
适合的项目
- 根据上述特点，如果客户对于即将开发的软件有着非常明确的需求，那么瀑布模型显然是最好的方法，因为它遵循的是一种线性的方法，并且能够在第一个阶段就将需求明确了下来。
- 然而，如果您筹备开发的应用程序，需要在每个阶段进行演进，并且您在项目中可以预见到各种频繁的变更，那么敏捷方法则是满足客户需求和技术实现的最佳方法。
产品对于客户的可视性
- 在瀑布模型完成之后，应用程序被部署到了生产环境中，客户只能在项目结束后看到完整的产品。
- 而在敏捷方法中，由于持续的时间被分成了多个Sprint，客户可以有频繁的机会来查看产品，进而做出是要接受当前的标准、还是要执行变更的决定。
团队合作
- 瀑布模型最大的缺点是：它不允许开发人员和测试人员之间进行集成式的协作。测试员只有在开发阶段结束后才开始接触代码，并着手各项测试工作。
- 而在敏捷方法中，测试人员和开发人员能够协同工作。每个Sprint都有一个测试阶段，而且在开发人员每次发布新的函数功能之后，测试人员都会立即进行回归测试。
把大任务分成小任务
- 在瀑布模型中，由于整个应用程序是作为一个单独的项目被完成的，因此整个软件开发会变得较为复杂。特别是当大型应用程序进入测试阶段时，不但开发人员会产生等待“审判”的感觉，就连测试人员也会觉得陌生且慌乱。
- 而在敏捷方法中，一个项目被分成了多个用户故事。在每个阶段，开发人员和测试员通过协同工作以了解需求，并且由客户最后给出是否正确地完成了所有工作的结论。这些都使得各方的工作更为容易和更加快捷。
