瀑布和敏捷都不是什么新概念，关于敏捷开发与瀑布开发的优势与缺点都已经比较明确，这里根据一些平台的资料给大家做一些整理和总结。
一、瀑布开发
瀑布模型 式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档， 测试计划 和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
有论文统计他是造成70%软件开发失败的原因。
瀑布开发大体分为这几个阶段： 需求分析 、设计、编码、测试、维护。 目前来说2B的传统企业，包括ERP，MES，WMS，CRM，OA，IBMS等系统当中可以经常见到他们的影子。现在这种模式仍然流行在一些大的项目或者是外包的一些项目当中。
瀑布模型作为最典型的预见性方法，其优点主要在于：
- 阶段清晰：从计划到开发最后到上线运行，三个阶段非常清晰。
- 时间顺序：每个阶段顺序必须是从上到下，严格按照时间先后进行。
- 环环相扣：在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。
- 黑盒模式：每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注。
而其特点也突出：
- 需求隔离：由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
- 变更代价大：既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。
- 束缚创造性：由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。
- 周期漫长：整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。
二、敏捷软件开发
敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。敏捷开发以用户的需求进化为核心，采用 迭代 、循序渐进的方法进行软件开发。
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发借助互联网浪潮开始流行起来，相比瀑布模式，敏捷无疑更加贴近互联网时代背景下快速发展变化的市场环境以及业务需求。
简单总结，敏捷开发的优缺点在于：
优点：
- 更快交付价值
- 更低的风险
- 拥抱变化
- 更好的质量
- 持续改进
- 更高的客户满意度
- 更高的团队满意度
- ……
缺点：
- 很难进行准确的资源规划
- 很难准确的定义“轻量的“或必要的文档
- 很难把握整体产品的一致性
- 很难预测有限的终点
- 很难有效地进行度量
- …….
从上文来看，敏捷开发似乎要优于瀑布开发，但本质并非如此。两者都有自己适用的范围，而当下这个VUCA的时代，多变的项目是很多科技公司的常态，所以越来越多的人关注到敏捷开发的优点。但仍旧有一部分确定性很强的项目会适合适用瀑布开发。
本文来自投稿，不代表Worktile社区立场，如若转载，请注明出处：https://worktile.com/kb/p/5209
微信扫一扫 
支付宝扫一扫 
