瀑布模型是一种按需求、设计、开发、测试、交付等阶段顺序推进的项目方法：上一阶段完成并通过评审确认后，才进入下一阶段。它适合需求相对稳定、变更成本较高、需要阶段性确认的项目；需求频繁变化时，需要配合变更控制和阶段回溯机制。本文解释瀑布模型的阶段组成、适用边界、评审与变更机制，并澄清“瀑布就是不能回头”等常见误解。
要点总览（TL;DR）
- 瀑布模型把项目划分为需求、设计、开发、测试、交付等阶段，上一阶段完成并通过评审确认后进入下一阶段，每个阶段都有明确产出物。
- 它适合需求相对稳定、验收标准清晰、变更代价较高、需要阶段性确认的项目；需求频繁变化时，更适合迭代或敏捷方式。
- 阶段评审负责把关质量，需求基线固定承诺范围，变更需经过申请、影响评估、审批、实施和验证的受控路径。
- 瀑布模型允许受控回溯，也可以与迭代元素组合成混合模式，把瀑布等同于“不能回头”或“一次性交付”都是误解。
- ONES 瀑布项目管理解决方案覆盖从立项到收尾的全过程，支持项目计划、任务依赖、里程碑以及计划与里程碑基线，便于追踪变更影响。
瀑布模型的核心定义
瀑布模型是一种把项目工作划分为若干顺序阶段、逐阶段推进并逐阶段确认的开发方法。它的名称来自阶段像水流一样自上而下依次落下：需求阶段完成后进入设计阶段，设计确认后进入开发阶段，开发完成后进入测试，测试通过后交付上线。每个阶段都有明确的产出物，并在阶段结束时安排评审或确认动作，作为进入下一阶段的前提。
理解这个定义，可以抓住三个关键要素：
- 阶段顺序推进：阶段之间有先后关系，前一阶段的主要工作没有完成，后一阶段通常不全面展开。这种顺序让计划、资源和责任边界相对清晰。
- 阶段产出明确：每个阶段都留下可检查的成果，例如需求规格说明、设计文档、可运行的软件版本、测试报告、交付清单。产出物既是本阶段的工作结果，也是下一阶段的输入。
- 评审确认把关：阶段结束时由相关角色对产出物进行评审或确认，确认通过才进入下一阶段。评审的作用是把问题拦在阶段边界上，避免缺陷沿阶段链条向后放大。
需要说明的是，瀑布模型描述的是阶段推进的基本逻辑，并不规定每个阶段必须持续多久，也不规定项目只能做一次交付。阶段的数量、名称和颗粒度可以按项目规模和行业惯例调整，但“顺序推进、产出明确、阶段确认”这三个特征构成它的基本骨架。
瀑布模型包括哪些阶段
典型的瀑布项目包括需求分析、设计、开发实现、测试验证和交付上线几个阶段，部分项目还会在前后增加立项启动和运维收尾。阶段之间的衔接依靠进入条件与退出条件：退出条件通常是一组产出物通过评审，进入条件则是上一阶段产出物已确认并完成交接。
| 阶段 | 主要工作 | 典型产出物 | 进入下一阶段的条件 |
|---|---|---|---|
| 需求分析 | 收集业务需求，明确范围、优先级和验收标准 | 需求规格说明、需求清单、验收标准 | 需求评审通过，需求基线确认 |
| 设计 | 完成架构设计、模块设计、接口与数据设计 | 架构方案、详细设计文档、接口说明 | 设计评审通过，关键技术方案确认 |
| 开发实现 | 按设计编码，完成单元测试和集成准备 | 代码、构建版本、单元测试记录 | 开发完成，版本可进入系统测试 |
| 测试验证 | 执行系统测试、回归测试，记录并跟踪缺陷 | 测试用例、测试报告、缺陷清单 | 测试通过率达到约定标准，遗留问题有处理结论 |
| 交付上线 | 部署、验收、培训与移交 | 上线记录、验收报告、移交文档 | 验收确认，移交完成 |
阶段产出物在衔接中承担两种作用：一是作为下一阶段的工作依据，例如设计文档约束开发实现的范围；二是作为评审和追溯的对象，当后续阶段发现问题时，可以回到对应产出物定位原因。阶段划分越清晰，交接时的责任越容易界定，但阶段之间的等待和返工成本也越需要管理。
瀑布模型的边界：哪些情况不属于它
瀑布模型适合需求相对明确、范围可预先界定、变更代价较高的项目。例如合同约束强、验收标准在启动前已确定、涉及硬件或外部系统联调、需要按阶段向客户或监管方提交确认材料的项目，顺序推进有助于把计划和责任固定下来。这类项目的共同点是：前期把需求谈清楚带来的收益，大于后期频繁调整带来的灵活性损失。
需求频繁变化、市场验证周期短、用户反馈需要快速进入产品的项目，通常不适合以纯瀑布方式推进。原因在于瀑布模型的评审点和基线设置在阶段边界上，需求在开发或测试阶段发生较大变化时，已完成的設計和代码可能需要成片返工，变更成本随阶段后移而上升。这类项目更适合迭代开发或敏捷开发：把工作拆成短周期增量，每个周期都包含需求、开发、测试和评审，用频繁的小反馈替代一次性的大确认。
可以用下面的清单判断一个项目更接近哪一侧：
- 偏瀑布的条件：需求可以在启动阶段基本确定；验收标准清晰；变更需要走正式审批；阶段成果需要向外部干系人确认；项目周期和预算需要提前锁定。
- 偏迭代或敏捷的条件：需求只能边做边明确；需要尽早看到可用版本；用户反馈会实质影响下一批功能；团队具备短周期交付和持续评审的能力。
- 需要混合模式的条件：整体范围和合同节点固定，但部分模块需要探索；或者外部交付按阶段验收，内部研发按迭代推进。
边界的关键在于变更的频率和代价，而非项目大小或行业标签。一个大型项目如果需求稳定，可以按瀑布推进；一个小型项目如果需求高度不确定，也可能更适合迭代方式。
阶段评审与变更控制如何运转
瀑布模型依靠两类机制维持秩序：阶段评审负责把关质量，变更控制负责处理偏离。阶段评审在阶段结束时进行，参与角色通常包括业务方、技术负责人、测试负责人和项目经理。评审的对象是阶段产出物，结论可以是通过、有条件通过或不通过；有条件通过需要记录待办事项和完成时限，不通过则留在本阶段整改。评审的价值在于把需求歧义、设计缺陷和测试遗漏拦在阶段边界，减少后续返工。
需求基线是变更控制的参照点。需求评审通过后，需求规格说明形成基线，后续开发、测试和验收都以基线版本为依据。基线的作用是让“当前承诺的范围”有唯一版本可查，避免口头变更分散在不同文档和聊天记录里。基线形成后，变更需要走申请、评估、审批、实施和验证的路径：提出变更申请，说明变更内容和原因；评估对设计、开发、测试、进度和成本的影响；由有权角色审批；批准后更新需求和相关产出物，必要时回溯到受影响阶段；最后验证变更结果并记录。
在工具层面，阶段评审和变更控制需要落到可追踪的工作项与文档状态上。ONES 瀑布项目管理解决方案基于 PMI、CMMI 理论，覆盖从立项到收尾的瀑布项目管理全过程，将需求管理、研发管理、测试管理和资源管理流程连接起来。团队可以用「项目计划」创建工作分解结构，按项目阶段分解计划和工作，为任务设置前后置依赖，并用里程碑标记重要时间点、事件或决策点。对于基线与变更，ONES 支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，并通过版本对比追溯变更细节。这些能力承接的是评审后的计划确认和变更后的影响追踪，具体评审节点和审批流程仍需团队按自身制度配置。
一个具体例子：从需求到上线的顺序推进
以下为一个演示情景，用于说明瀑布模型的运转方式，不代表真实客户案例。某企业需要建设一套内部报销系统，合同约定三个月内上线，验收标准在启动前已与财务部门确认。
项目按阶段推进：需求阶段用两周梳理报销流程、审批规则和报表要求，形成需求规格说明，财务负责人、IT 负责人和项目经理参加评审，评审通过后需求形成基线。设计阶段用两周完成流程设计、权限设计和接口设计，评审确认与现有财务系统的对接方案。开发阶段用四周完成编码和单元测试，每周同步进度，开发完成后提交可测试版本。测试阶段用两周执行功能测试和回归测试，测试报告显示主要流程通过，遗留两个报表格式问题，约定上线前修复。交付阶段完成部署、财务人员培训和验收签字。
项目进行到测试阶段时，财务部门提出增加“按项目维度汇总报销”的需求。项目经理组织评估：该需求涉及报表模块和数据结构调整，预计增加一周开发量和三天测试量。变更申请提交后，由财务负责人和 IT 负责人审批，考虑到上线时间刚性，决定本期先按现有维度上线，项目维度汇总放入二期。变更结论记录在需求文档和项目计划中，本期范围保持不变，二期需求单独建项。
这个例子展示了瀑布模型的几个动作：阶段评审确认产出物，需求基线固定本期范围，变更走评估和审批，未批准的变更明确去向。它也说明瀑布项目并非完全拒绝变化，而是把变化纳入受控路径，并清楚记录对范围和进度的影响。
常见误解：瀑布模型不等于不能回头
关于瀑布模型最常见的误解，是把它理解为“一旦进入下一阶段就绝对不能回头”。实际运行中，瀑布模型允许受控回溯：测试阶段发现设计缺陷，可以回到设计阶段修正并重新评审受影响的部分；需求变更获批后，也可以回溯到需求和相关设计、开发、测试环节。受控的含义是回溯有触发条件、有影响评估、有审批记录，而非随意往返。把回溯纳入变更控制，正是瀑布模型处理不确定性的方式。
第二个误解是把瀑布模型等同于一次性交付。瀑布模型描述的是阶段推进逻辑，交付可以是整体一次上线，也可以按阶段或模块分批交付。部分项目在整体瀑布框架下，对某些模块采用迭代方式推进，形成混合模式。混合模式的做法通常是：整体范围、里程碑和外部验收按瀑布管理，内部部分模块按短周期迭代开发和评审，迭代结果汇入阶段交付物。ONES 的说明也指出，企业可根据项目类型和团队特点，在统一的研发管理平台中采用适合的项目管理方式，不必所有项目使用同一种流程；ONES Project 提供敏捷、瀑布、通用任务协同等多种项目模板，并可根据业务需求灵活定义项目类型与相关组件。
第三个误解是把瀑布模型视为过时方法。瀑布模型在需求稳定、责任边界清晰、需要阶段性确认的场景中仍有明确价值；它的局限在于应对高频变化的成本较高。选择瀑布、迭代还是混合模式，取决于需求确定性、变更代价、交付节奏和外部约束，而非方法的新旧。理解这一点，比记住阶段名称更重要。
常见问题
瀑布模型和迭代开发可以同时用在一个项目里吗？
可以。常见的做法是整体范围、里程碑和外部验收按瀑布管理，内部部分模块按短周期迭代开发和评审，迭代结果汇入阶段交付物。这种组合通常称为混合模式，适合整体交付节点固定、局部需求仍需探索的项目。采用时需要在项目计划中明确哪些部分按阶段推进、哪些部分按迭代推进，并约定迭代产出如何进入阶段评审。
需求在开发阶段发生变化，瀑布项目一定要全部返工吗？
不一定。变更获批后，团队先评估影响范围：涉及哪些设计、代码、测试用例和计划节点，再决定回溯到哪一阶段修正。影响局限在局部模块时，只需修改相关产出物并重新评审受影响部分；影响范围较大时，才需要调整阶段计划甚至重新确认基线。关键在于变更走评估和审批，并记录对范围、进度和成本的影响，避免口头变更分散在各处。
阶段评审不通过时，项目应该怎么处理？
评审不通过意味着本阶段产出物未达到进入下一阶段的条件，项目留在当前阶段整改。通常需要记录不通过的具体问题、责任人和完成时限，整改后重新评审。评审结论为有条件通过时，可以把非阻塞问题列为待办，约定在后续阶段完成，但需明确待办不影响下一阶段的关键工作。评审标准建议在阶段开始前就与参与角色对齐，减少结论分歧。
小型项目也适合用瀑布模型吗？
项目规模不是决定因素，需求确定性和变更代价更关键。一个小型项目如果范围和验收标准在启动前已经清楚，按阶段推进可以让责任和交付节点更明确；如果需求高度不确定、需要边做边验证，小型项目同样更适合迭代方式。阶段数量可以按项目规模裁剪，例如把设计与开发合并、把测试与交付衔接得更紧，但阶段确认的动作仍应保留。
瀑布项目里，基线应该什么时候建立？
需求基线通常在需求评审通过后建立，作为后续设计、开发、测试和验收的共同参照。计划基线可以在项目计划确认后建立，里程碑基线则对应关键时间点或决策点。基线建立后并非不能调整，而是调整需要走变更流程并保留版本记录，这样才能对比计划与执行的偏差，追溯每次变更的影响。基线设置过晚，变更控制会缺少参照；设置过早，则可能把尚未确认的内容固定下来。
