【.com快译】众所周知，在软件开发项目开始之前，项目经理的工作往往是确定在项目生命周期中应该采用哪种开发方法。目前业界流行的开发方式有两种，分别是：瀑布模型，一种传统的开发模式和方法。敏捷方法论，一种比瀑布模型更新更快的应用程序开发模型，通常由使用Scrum的开发人员实施。如今，随着全球各大软件开发公司采用敏捷方法开发产品，瀑布模型逐渐失去了原有的适用性。让我们深入探讨为什么敏捷如此受欢迎以及它与瀑布有何不同。它们是如何工作的瀑布模型为软件开发提供了一种更连续的方法。它按以下顺序进行：收集软件开发的需求文档。需求确定后，应用程序的设计就开始了。开始并行开发和执行单元测试。通过增加负载或压力，进行性能测试和用户验收测试，以保证系统的整体稳定性和健壮性。测试团队将检测到的缺陷提交给开发人员开始修复缺陷。将应用程序部署到生产环境。然而，敏捷方法不遵循任何一种线性路径。它遵循迭代开发方法。它不为项目的全过程创建各种任务，而是划分为多个迭代周期阶段（Sprint）。因此，敏捷方法通常关注四个基本价值：团队成员之间的互动，而不是纯粹的工具之间的互动。更多的重点放在正在进行的工作流程上，而不是包罗万象的文档。客户在每个冲刺中的合作和参与。快速响应变化，不遵守规则。RequirementsGatheringPhase如果使用瀑布模型开发应用程序，客户和组织都需要事先对需求规范有一个清晰的了解。而一旦接受了要求，任何一方都不能轻易改变既定的范围。然而，在敏捷方法中，项目并不是从固定的需求文档开始的。客户可以在每个Sprint中提出不同的用户故事（userstories），开发人员的任务是完成程序编码并提交一个demo版本。如果客户对产品不满意并需要添加更多组件，那么他可以请求更改应用程序。可见敏捷方法在处理客户需求上比瀑布模型更加灵活。适合的项目根据以上特点，如果客户对要开发的软件有非常明确的需求，那么瀑布模型显然是最好的方法，因为它遵循的是线性方法，可以将需求明确化。但是，如果你开发的是一个在每个阶段都需要进化的应用，并且你可以预见到项目中各种频繁的变化，那么敏捷方法适合满足客户需求和技术实现。产品对客户的可见性在瀑布模型完成并将应用程序部署到生产环境后，客户只能在项目结束后才能看到完整的产品。在敏捷方法中，由于持续时间分为多个Sprint，客户可以有频繁的机会查看产品，然后决定是接受当前标准还是实施变更。团队合作瀑布模型的最大缺点是它不允许开发人员和测试人员之间进行集成协作。测试人员只有在开发阶段结束后才开始接触代码并开始各种测试任务。而在敏捷方法中，测试人员和开发人员能够一起工作。每个冲刺都有一个测试阶段，在开发人员每次发布新功能特性后，测试人员会立即进行回归测试。将大任务分成小任务在瀑布模型中，整个软件开发变得更加复杂，因为整个应用程序是作为一个项目完成的。尤其是当一个大型应用进入测试阶段时，不仅开发人员会有等待“审判”的感觉，就连测试人员也会感到奇怪和慌乱。而在敏捷方法中，一个项目被分成多个用户故事。在每个阶段，开发人员和测试人员一起工作以了解需求，并由客户得出是否一切都已正确完成的结论。这些使各方的工作变得更容易、更快捷。StandishGroup（译者注：专门跟踪IT项目成功的权威机构）2010年的一份CHAOS报告使用统计数据清楚地表明，采用敏捷方法的项目面临的挑战更少。与遵循瀑布方法的项目相比，它们失败的可能性更小。敏捷与瀑布的优缺点作为传统的瀑布模型，瀑布法在很多方面都积累了自己的优势：通过可预测的静态工作流，确保团队可以计算出合适的成本和期限的概念进行合理的估算.由于该过程需要各种文档，因此各种文档线程贯穿于开发的每个阶段。对于项目组来说，只要按照过去项目的逻辑走，就可以为以后的项目打下坚实的基础。由于流程模型相对固定，项目团队可以按照既定的瀑布模型进行工作，无需事先储备和积累知识。但是，这种模式的缺点是：由于模式是固化的，任何大的改动，无论是客户还是项目组，都会带来很高的成本。毕竟整个项目可能会推倒重来。每个开发阶段，如需求收集、开发和测试，都占用了大量时间，因此项目利益相关者，尤其是客户，直到最后才能看到真正的应用效果。由于敏捷开发方法遵循迭代开发路径，因此敏捷方法具有以下优点：更短的开发阶段可以使项目更具适应性，项目团队可以随时响应客户提出的任何重大或次要的变更。客户可以在每个冲刺期间看到项目的当前状态，并能够通过定期反馈生产出更高质量的产品。开发人员、测试人员和客户可以一起工作。这种协作项目团队有助于个人发展和组织改进。当然，客观来说，凡事有利有弊。我们来看看这种方法的缺点：与文档化相比，敏捷方法更强调持续的工作过程。因此，清晰明确的项目仍然可以接受文档不足；对于复杂的大型项目，我们仍然需要平衡文档和程序代码之间的联系和完整性。这种方法主要是为中小型团队设计的。因此，团队的每个成员都应该准确地认识自己的角色和工作的独立性。总结长期从事软件开发的项目人员往往认为，只有提前明确客户的需求，采取合适的方案，才能保证成功交付。但在我们实际的工作和开发任务中，只有实现快速交付，才能提高组织的盈利能力。因此，希望通过以上对两种开发方式的对比分析，能够帮助项目利益相关者根据手头项目的具体性质和特点，选择更合适的软件开发方式。原标题：Head-to-Head:TheAgileandWaterfallMethodologies，作者：ArnabRoy
