瀑布与敏捷开发模式之抉择

前言

敏捷开发，是一种应对快速变化的需求的一种软件开发能力。瀑布模型是一种老旧的计算机软件开发方法，采用最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。对此我们将在文章中给大家进行详细解读。

优缺比对

开发模式	定义描述	优点	缺点
瀑布开发模式	瀑布模型是由W.W.Royce在1970年最初提出的软件开发模型，瀑布式开发是一种老旧的计算机软件开发方法。 瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。 步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。 瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。 瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。	瀑布模型作为最典型的预见性方法，其优点主要在于： 阶段清晰：从计划到开发最后到上线运行，三个阶段非常清晰 时间顺序：每个阶段顺序必须是从上到下，严格按照时间先后进行。 环环相扣：在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。 黑盒模式：每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注。	需求隔离：由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。 变更代价大：既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。 束缚创造性：由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。 周期漫长：整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。
敏捷开发模式	敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。 人和交互重于过程和工具。 可以工作的软件重于求全而完备的文档。 客户协作重于合同谈判。 随时应对变化重于循规蹈矩。 敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。 在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发借助互联网浪潮开始流行起来，相比瀑布模式，敏捷无疑更加贴近互联网时代背景下快速发展变化的市场环境以及业务需求。	更快交付价值； 更低的风险拥抱变化； 更好的质量持续改进； 更高的客户满意度； 更高的团队满意度。	很难进行准确的资源规划； 很难准确的定义“轻量的“或必要的文档； 很难把握整体产品的一致性； 很难预测有限的终点； 很难有效地进行度量。

如何选择

哪一个适合您的组织？答案可能取决于您的产品或服务的性质，以及看您的业务或组织使命。但即使完全敏捷的方法不适合您，在产品开发中加入它的方方面面也可能产生有效的改进。

步骤说明	瀑布模式	敏捷模式
开展工作的方法	瀑布式为软件开发提供了更顺序的方法。它遵照以下线性顺序工作。 收集软件需求文档； 该应用程序是在需求最终确定后设计的； 开始开发且并行执行单元测试； 执行性能测试以确保系统在负载或压力用户验收测试下表现良好； 缺陷修复，开发人员开始处理测试团队检测到的错误； 将应用程序部署在生产环境中。	敏捷并不遵循任何线性路径。它遵循迭代的开发方法。项目的整个持续时间分为称为sprint的阶段，而不是创建任务。敏捷通常关注四个基本价值观： 团队成员之间的互动而不是工具。 正确运行的软件而不是包含所有内容的文档。 客户在每个sprint中的协作。 快速响应变更而不是遵循计划。
需求收集阶段	如果客户明确了要开发的软件需求，瀑布模型是最好的方法，因为它遵循线性方法，并且在第一阶段已经明确需求。	在敏捷方法中，一开始就没有固定的需求文档。客户在每个sprint中提供用户故事，开发人员的工作是完成编码并演示。如果客户对产品不满意并需要更多附件，他会要求更改需求。因此，敏捷在需求方面比瀑布更有灵活性。
产品对客户的可见性	当遵循瀑布模型开发时，用户或客户只能在项目结束后才能看到完整的产品，之后才能将应用部署到生产环境中。	在敏捷中，由于持续时间被分成多个冲刺，因此客户经常有机会查看产品，从而做出有关接受标准和要执行更改的决策。
作为一个团队工作	瀑布模型的最大缺点是它不允许开发人员和测试人员之间的集成协作。测试人员只有在开发阶段结束后才开始，他们才能单独工作。	在敏捷中，测试人员和开发人员一起工作。每个sprint都有一个测试阶段，每次发布新功能时，都会立即进行回归测试。
任务拆解与交付	在瀑布模型中，软件开发变得有点复杂，因为整个应用程序将作为一个单独的项目完成。对于开发人员来说，这对于测试人员来说，当他们开始测试大型应用程序时，它会变得非常繁忙。	在敏捷模型中，该项目分为多个用户故事。开发人员和测试人员在每个阶段一起工作以了解需求，客户最终会回顾一切是否正确完成，它使工作更轻松，更快捷。
选择适合的项目		如果你计划开发的应用程序需要随着每个阶段而发展，并且项目中可能需要经常进行修改，那么敏捷方法是满足客户需求和技术前景的最佳方法。

总结

长期从事软件开发行业的人士建议，事先明确要求的规划，能够确保软件成功交付。但我们生活在一个快速交付、提高盈利能力的世界。因此，根据项目的性质，由团队和利益相关者共同决定哪种方法最适合使用。

参考资料

敏捷开发流程之Scrum：3个角色、5个会议、12原则 - 腾讯云开发者社区-腾讯云

瀑布与敏捷的区别

敏捷开发与瀑布开发方法论之对比_51CTO博客_敏捷开发 瀑布开发