瀑布式方法是一种线性、顺序的项目管理方法，项目通过不同的、预定的阶段稳步向下推进。每个阶段都必须100%完成，然后才能开始下一个阶段，并且团队在不重新开始流程的情况下，无法轻易回到上一个阶段。
与敏捷灵活和迭代的特性不同，瀑布式方法严重依赖广泛的前期规划、严格的文档和固定的时间表。
瀑布模型的6个经典阶段
一个传统的瀑布项目严格按照以下连续阶段进行： [11]
- 需求： 在项目开始时收集并记录项目的每一个细节、功能和约束。
- 系统设计： 架构师根据固定需求规划技术解决方案、选择编程语言或创建蓝图。
- 实施（开发）： 团队成员编写软件代码或构建物理产品的实际构建阶段。
- 集成与测试： 将完成的产品整合在一起，并进行严格测试以发现并修复缺陷。
- 部署： 最终完成的产品正式发布到市场、客户或最终用户。
- 维护： 产品上线后的持续支持、修补错误和小型更新。
瀑布模型的主要特征
- 顺序流程： 进度通过从一个受控阶段到下一个受控阶段来衡量。
- 大量文档： 在生产开始前，对每个步骤、需求和设计选择都进行细致的记录。
- 灵活性低： 在项目中期更改需求需要一个正式的、通常代价高昂的变更管理流程。
- 价值延迟： 在整个项目完成之前，用户无法看到或接触到产品的工作版本。
瀑布模型的优缺点
优点：
- 清晰的期望： 成本、时间表和最终交付物从一开始就明确定义。
- 易于跟踪： 里程碑非常可见且易于跟踪，因为截止日期是固定的。
- 严格的结构： 阶段的清晰分离使得不同团队（例如，设计师到开发人员）之间的交接易于管理。
缺点：
- 难以变更： 如果市场需求或客户目标在项目进行到一半时发生变化，适应起来极其困难。
- 后期测试： 在项目接近尾声的测试阶段发现关键的架构缺陷，修复成本极高。
- 高风险： 如果最初的需求存在缺陷，团队可能会冒着花费数月时间构建错误产品的风险。
何时使用瀑布模型而非敏捷模型
尽管现代软件开发偏爱敏捷方法，但对于以下项目，瀑布模型仍然是行业标准：
- 固定、不可更改的预算和截止日期。
- 严格的法规和合规要求（例如，医疗设备、航空航天工程）。
- 物理依赖，迭代是不可能的（例如，建造桥梁或摩天大楼）。
- 技术理解透彻，团队之前多次构建过完全相同的产品。