瀑布模型是一种按固定顺序推进的开发方法：需求、设计、实现、测试、交付依次进行，上一阶段完成并确认后才进入下一阶段，成果以文档等形式固化。它适合需求相对稳定、变更代价高或需要明确阶段验收的项目；需求频繁变化时，需要评估返工成本，或改用迭代方式。
要点总览（TL;DR）
- 瀑布模型按需求、设计、实现、测试、交付/维护的顺序推进，上一阶段确认后才进入下一阶段，阶段成果以文档等形式固化。
- 判断一个项目是否属于瀑布，关键看阶段之间是否允许回退、不同阶段工作是否允许并行，有阶段划分本身并不构成瀑布。
- 需求相对稳定、变更代价较高、验收标准清晰的项目适合瀑布；需求频繁变化时应评估迭代或混合方式。
- 瀑布项目中的变更需要经过影响评估、决策和记录，接受后同步更新受影响的文档与计划。
- 阶段门评审、角色与交付物管理、变更控制是瀑布运转的三套机制，回退到上一阶段代价较高，需评审确认。
瀑布模型的核心定义与阶段顺序
瀑布模型（Waterfall Model）是一种线性推进的项目开发方法。项目被划分为若干前后衔接的阶段，每个阶段有明确的输入、活动和产出；只有当前阶段的成果经过确认，项目才进入下一阶段。这种“完成一段、确认一段、再走下一段”的推进方式，是瀑布模型区别于其他方法的核心特征。
理解瀑布模型，需要抓住三个要素。第一是阶段顺序：阶段之间存在先后依赖，后一阶段的工作以前一阶段的成果为基础。第二是阶段门（Stage Gate，也称阶段关口）：每个阶段结束时设置一次确认动作，由相关角色检查交付物是否达到进入下一阶段的条件。第三是成果固化：阶段产出以需求规格说明、设计文档、测试报告等形式记录下来，作为后续工作和验收的依据。
典型的阶段顺序如下表所示。不同组织会在此基础上增删阶段或调整名称，但“顺序推进、逐段确认”的结构保持一致。
| 阶段 | 主要工作 | 典型产出 | 阶段门关注点 |
|---|---|---|---|
| 需求 | 收集、梳理并确认业务与功能需求 | 需求规格说明、需求确认记录 | 需求是否完整、清晰，相关方是否确认 |
| 设计 | 完成总体架构与详细设计 | 架构设计、详细设计文档 | 设计是否覆盖全部需求，技术方案是否可行 |
| 实现 | 编码与单元测试 | 可运行的程序、单元测试记录 | 功能是否按设计完成，代码质量是否达标 |
| 测试 | 系统测试、集成测试与缺陷修复 | 测试用例、测试报告、缺陷清单 | 缺陷是否收敛，是否满足上线标准 |
| 交付/维护 | 上线部署、验收移交与后续维护 | 上线记录、验收报告、维护文档 | 验收是否通过，移交材料是否齐全 |
需要说明的是，阶段门并非形式上的签字环节。它的实质是一次有输入、有判断标准的检查：输入是本阶段的交付物和遗留问题清单，输出是“通过”“有条件通过”或“退回”的结论。阶段门的存在，使瀑布项目在早期就能暴露需求遗漏或设计缺陷，避免问题积累到测试阶段才集中爆发。
瀑布模型的边界：哪些做法不算瀑布
有阶段划分的项目很多，但并非都采用瀑布模型。判断一个项目是否属于瀑布，关键看两点：阶段之间是否允许回退，以及不同阶段的工作是否允许并行。瀑布模型要求上一阶段确认后才进入下一阶段，阶段内的成果作为下一阶段的基线；如果项目允许设计与开发并行、测试与开发交替推进，或者需求可以在任意时点插入并立即排期，那么它更接近迭代或增量方式。
瀑布与迭代开发的区别在于推进逻辑。迭代开发把项目切成若干短周期，每个周期都经历需求、设计、开发、测试的完整循环，通过多轮循环逐步逼近最终产品；瀑布则把整个项目作为一个大循环，每个阶段只走一次。增量交付的区别在于交付节奏：增量方式按功能模块分批交付可用成果，瀑布通常在项目末期一次性交付完整成果。混合项目管理则是把瀑布的阶段计划与迭代的执行方式组合使用，例如整体按阶段规划、阶段内部按迭代推进，它属于方法组合，不能简单归入瀑布。
| 对比维度 | 瀑布模型 | 迭代开发 | 增量交付 | 混合项目管理 |
|---|---|---|---|---|
| 推进方式 | 阶段顺序推进，每阶段一次 | 短周期循环，多轮迭代 | 按功能模块分批构建 | 整体阶段规划，局部迭代执行 |
| 需求处理 | 前期尽量确认，变更走评估 | 每轮迭代可调整优先级 | 按批次细化需求 | 按阶段或模块区分处理方式 |
| 交付节奏 | 项目末期集中交付 | 每轮迭代产出可评审成果 | 分批交付可用功能 | 视模块安排而定 |
| 适用条件 | 需求稳定、验收标准明确 | 需求不完全明确、需要快速反馈 | 功能可拆分、可分批上线 | 项目不同部分特征差异明显 |
需求变更在瀑布中的处理方式，也是判断边界的重要依据。瀑布模型并不禁止变更，而是要求变更经过评估：提出变更请求后，分析它对已完成阶段成果、后续阶段计划和交付时间的影响，再由相关角色决定是否接受、推迟或拒绝。变更被接受后，需要更新受影响的文档和计划，并记录变更原因与决策过程。如果团队对任何需求变化都直接排期、不做影响分析，这种做法已经偏离瀑布的控制逻辑。
瀑布模型如何运转：阶段门、评审与变更控制
瀑布项目的运转依赖三套机制：阶段门评审、角色分工与交付物管理、变更控制。三者共同保证阶段之间的交接有依据、有判断、有记录。
阶段门评审的输入包括本阶段交付物、未关闭问题清单和下一阶段的启动条件说明；输出是评审结论和待办事项。评审通常由项目经理组织，需求、设计、开发、测试等角色的负责人参加。评审结论为“通过”时，交付物进入基线状态，下一阶段可以启动；“有条件通过”需要明确遗留问题的责任人和关闭时间；“退回”则要求本阶段补充或返工后再次评审。
各阶段的主要角色与交付物可以按下表分工。角色名称因组织而异，但职责边界大体一致。
| 阶段 | 主要责任角色 | 核心交付物 | 交接对象 |
|---|---|---|---|
| 需求 | 业务负责人、需求分析人员 | 需求规格说明、验收标准 | 设计人员、测试人员 |
| 设计 | 架构师、设计人员 | 架构与详细设计文档 | 开发人员、测试人员 |
| 实现 | 开发人员 | 程序代码、单元测试记录 | 测试人员 |
| 测试 | 测试人员、开发人员 | 测试报告、缺陷修复记录 | 项目经理、业务负责人 |
| 交付/维护 | 项目经理、运维人员 | 上线记录、验收报告 | 业务方、维护团队 |
变更控制的流程通常包括四步：登记变更请求，说明变更内容、提出人和期望时间；评估影响，分析变更对需求基线、设计、已完成的开发和测试工作以及整体进度的影响；做出决策，由项目经理与相关角色共同确定接受、推迟或拒绝；更新与记录，变更被接受后同步修改受影响的文档和计划，并保留变更记录以便追溯。
回退到上一阶段是瀑布项目中代价较高的动作。回退意味着已确认的基线被打破，后续阶段基于旧基线完成的工作可能需要部分返工。因此，回退通常只在两种条件下发生：一是发现上一阶段成果存在影响后续工作的重大缺陷，二是外部条件发生实质性变化导致原基线不再成立。回退需要经过评审确认，并重新评估进度和资源。
在工具层面，阶段计划、里程碑和基线对比可以帮助团队把上述机制落到日常协作中。例如，ONES 支持用项目计划创建工作分解结构，按阶段或交付物分解工作，为任务设置前后置依赖，并用里程碑标记关键决策点；设置计划和里程碑基线后，可以对比计划与执行的偏差，并通过版本对比追溯变更细节。这类承载方式适合需要保留阶段评审记录和变更痕迹的瀑布项目，具体配置以实际产品为准。
一个具体例子：需求稳定的系统上线项目怎么走瀑布
以下为演示情景，用于说明瀑布项目在各阶段的具体动作，不代表真实客户案例。
某企业需要上线一套内部报销系统，业务规则由财务制度明确规定，监管要求上线时间固定，验收标准在合同中有清晰约定。项目周期为四个月，团队包括项目经理、需求分析人员、两名开发人员、一名测试人员和一名运维人员。需求相对稳定、变更代价较高，是选择瀑布方式的典型条件。
需求阶段（第1—3周）。需求分析人员与财务部门逐条确认报销类型、审批层级、额度规则和报表要求，形成需求规格说明和验收标准。阶段门评审由项目经理组织，财务负责人确认需求完整、无重大遗漏，评审通过，需求进入基线。
设计阶段（第4—6周）。架构师完成系统架构设计和数据库设计，明确与现有财务系统的接口方式。评审重点关注设计是否覆盖全部需求条目、接口方案是否可行。评审中发现一处审批层级的设计与需求不一致，设计人员修改后再次评审通过。
实现阶段（第7—11周）。开发人员按设计文档编码并完成单元测试，项目经理每周检查任务状态和阶段进展。阶段门检查功能完成度和单元测试通过率，确认达到进入系统测试的条件。
测试阶段（第12—14周）。测试人员依据需求规格说明编写并执行测试用例，缺陷按严重程度分级修复。阶段门以缺陷收敛情况和上线标准为判断依据，确认无阻断性缺陷后通过。
交付与维护阶段（第15—16周）。系统上线，财务部门按验收标准逐项验收，运维团队接收维护文档。上线后进入维护期，后续调整按变更流程处理。
项目进行到第9周时，财务制度调整，新增一类报销场景。团队登记变更请求后评估影响：需求文档需要补充，设计中的审批规则需要修改，已完成的开发工作约有三天返工量，测试用例需要增加。项目经理与财务负责人确认该变更必须在本期上线，于是接受变更，更新需求与设计文档，调整后续计划并记录变更决策。这个例子说明，瀑布项目中的变更并非不可发生，关键在于变更被评估、被记录、被同步到受影响的成果中。
常见误解：瀑布等于慢、等于不能改需求
围绕瀑布模型存在几类典型误解，澄清这些误解有助于判断它是否适合当前项目。
误解一：瀑布就是不能变更需求。瀑布模型要求变更经过影响评估和记录，而非一律拒绝。需求稳定是它发挥优势的条件，不是使用前提。当变更确实必要且代价可接受时，按变更控制流程处理即可；真正需要警惕的是未经评估就插入变更，导致阶段基线失效、进度失控。
误解二：瀑布等于文档越多越好。瀑布强调阶段成果固化，目的是让交接和验收有据可查，而非追求文档数量。文档应覆盖需求、设计、测试和验收的关键信息，篇幅和形式服从项目规模与风险。为每个细节编写冗余文档，只会增加维护负担，拖慢阶段推进。
误解三：瀑布一定比迭代慢。瀑布的交付节奏集中在项目末期，前期投入较多时间确认需求和设计。对于需求清晰、验收标准明确的项目，这种前期投入可以减少后期返工，整体周期未必更长；对于需求模糊、需要快速验证的项目，瀑布的返工风险确实更高，这时迭代方式更合适。
误解四：所有项目都该用同一种方法。项目类型、需求稳定程度和团队特点不同，方法选择也应不同。需求不稳定、需要频繁反馈的项目适合迭代；功能可拆分、可分批上线的项目适合增量交付；整体计划性强但局部需要灵活调整的项目，可以采用混合方式。企业可以在统一的管理平台中按项目类型选择适合的方式，而不必所有项目套用同一流程。
判断是否采用瀑布，可以看三个条件：需求能否在前期相对完整地确认；变更的代价是否较高、是否值得用前期确认来换取后期稳定；验收标准是否清晰、能否按阶段检查。三个条件大多满足时，瀑布是合理选择；需求频繁变化、验收标准难以提前确定时，应评估迭代或混合方式，把返工风险控制在更小的周期内。
常见问题
瀑布模型和迭代开发可以同时用在一个项目里吗？
可以，这正是混合项目管理的常见做法。整体项目按瀑布方式划分阶段、设置阶段门和里程碑，阶段内部再按短周期迭代推进，例如设计阶段内分几轮细化方案，实现阶段内按迭代交付可测试的功能增量。采用这种组合时，需要明确哪些节点走阶段门评审、哪些工作按迭代节奏验收，避免两套节奏互相冲突。
瀑布项目进行到测试阶段才发现需求遗漏，应该回退还是走变更？
先判断遗漏的性质。如果遗漏属于上一阶段成果的重大缺陷，导致后续工作建立在错误基线上，应启动回退评审，补充需求并评估对设计和开发工作的返工影响。如果遗漏是新增或细化的需求，按变更流程处理：登记请求、评估对已完成工作和进度的影响、由项目经理与相关角色决策、更新文档与计划并记录。两种路径都需要留下评审或决策记录，便于后续追溯。
阶段门评审需要哪些人参加，结论怎么算通过？
评审通常由项目经理组织，本阶段责任角色的负责人和下一阶段的主要接收方参加，例如需求阶段门需要业务负责人确认需求、设计和测试人员确认可据此开展工作。结论一般分为通过、有条件通过和退回：通过表示交付物进入基线、下一阶段可启动；有条件通过需明确遗留问题的责任人和关闭时间；退回则要求补充或返工后再次评审。参会角色和判定标准建议在项目启动时约定，避免每次评审临时确定。
需求不太稳定但又必须按固定节点验收，该怎么选方法？
可以按项目不同部分的特征分别处理。对验收标准清晰、变更代价高的部分采用瀑布方式，前期确认基线、按阶段门推进；对需求尚不明确的部分采用迭代方式，在短周期内验证并调整。整体上用里程碑对齐固定验收节点，局部用迭代吸收变化。这样既满足外部节点要求，也把返工控制在较小范围内。是否采用这种组合，取决于团队能否同时维护阶段计划和迭代节奏。
瀑布项目一定要写很多文档吗？
瀑布强调阶段成果固化，目的是让交接和验收有据可查。文档应覆盖需求、设计、测试和验收的关键信息，形式和篇幅服从项目规模与风险。小型、低风险项目可以用精简的需求说明和测试记录完成交接；大型或合规要求高的项目则需要更完整的规格说明和评审记录。判断标准是下一阶段能否据此开展工作、验收时能否据此核对，文档数量本身并不构成质量指标。
