瀑布模型详解：传统项目管理的6个阶段

在软件研发与项目管理中，瀑布模型经常被当作“传统项目管理”的代表。它把项目从启动到交付运行拆成若干阶段，前一阶段通过检查后再进入后一阶段，整体像水从高处逐级下落。对项目经理和研发管理者来说，先弄清瀑布模型包含哪 6 个阶段、每个阶段要交付什么，再判断项目适不适合用它，比直接照搬一套流程更实际。本文先给出定义，再逐个拆解六个阶段，最后讨论优缺点、适用场景与落地方式。

什么是瀑布模型

瀑布模型是一种按固定顺序推进的软件开发生命周期模型。它把项目划分为若干阶段，上一阶段的输出作为下一阶段的输入，阶段之间设有评审与放行规则。流程自上而下逐级衔接，因此业界用“瀑布”命名这种结构。

这一思想通常被追溯到 1970 年 Winston Royce 的论文《Managing the Development of Large Software Systems》。Royce 在文中描述了按阶段顺序推进的开发框架，后续实践将其概括为“瀑布模型”，用来指代这类线性、文档驱动的过程模型。

瀑布模型有三个容易记忆的特征：

• 顺序推进：阶段基本串行，前一阶段通过评审后才进入下一阶段。
• 文档衔接：前一阶段的文档是后一阶段的输入，文档是阶段之间的主要交接物。
• 阶段门控：每个阶段有明确的交付物与检查点，便于里程碑管理与质量控制。

这三点正是它被视为“传统项目管理”方法论的原因：可计划、可检查、可审计，适合把大型项目拆成多个可分工推进的单元。

瀑布模型的6个阶段

不同资料对瀑布模型阶段的命名略有差异：有的把设计拆成概要设计与详细设计，有的把部署单独列出。本文采用软件工程教材中常见的六阶段口径：制定计划、需求分析、软件设计、编码实现、软件测试、运行与维护。六个阶段自顶向下衔接，共同构成一条完整生命周期。

1 制定计划：明确范围与里程碑

计划阶段要回答“项目要做什么、投入多少、多久完成”。团队在此确认项目范围、资源、排期和主要里程碑，并评估可行性。交付物通常包括项目计划与范围说明，作用是让后续所有阶段都有统一的进度基线可对照。

2 需求分析：写清楚系统要做什么

需求分析阶段把用户与业务方的期望，整理成可确认、可验证的需求，产出需求规格与需求基线。瀑布模型强调需求尽量提前确认，因为后续设计与编码都以它为依据。需求锁定后再变更，需要走正式的变更流程并评估影响范围。

3 软件设计：决定系统怎么实现

设计阶段基于需求规划系统结构：先做总体设计，确定架构、模块划分和模块间接口；再做详细设计，明确模块内部的数据结构、算法与实现细节。设计文档是编码团队的直接依据，也是评审阶段的重要对象。

4 编码实现：把设计变成可运行代码

编码阶段依据设计文档实现功能，同时开展代码走查与单元测试，把前面积累的文档成果转化成可运行的程序。对规模化研发团队，编码规范、代码评审与提交记录管理是否到位，会直接影响后续测试与维护效率。

5 软件测试：验证是否满足需求

测试阶段通过集成测试、系统测试和验收测试等方式，验证实现结果是否达到需求基线。只有通过规定测试与验收标准的版本，才允许进入上线环节。测试报告既是质量凭证，也是项目能否交付的关键判断依据。

6 运行与维护：交付后持续保障

系统上线后进入运行维护阶段，工作包括 Bug 修复、性能优化、运行保障与后续功能增强。维护阶段产生的新需求，往往会开启新一轮生命周期。所以“瀑布”不是一次性的单程票，而是一条可以循环往复的生命周期主线。

需要说明的是，六个阶段是理想化的线性描述。真实项目中很少完全不回退，阶段内发现问题时，通常需要回到上一阶段修正后再继续，因此“允许有限回退”更接近实际执行状态。

瀑布模型：优点与局限

瀑布模型的优点在于阶段边界清晰：每个阶段有独立任务和交付物，方便组织分工、排期与里程碑管理；文档完整，有利于人员交接、过程审计与问题追溯；在需求明确的前提下，进度与质量都较可控。对强调计划与流程的传统项目管理场景，这些特性很有价值。

瀑布模型的局限也同样明显：可运行成果往往到中后期才出现，用户早期难以看到实物；需求一旦变化，会沿设计、编码向后传导，返工成本较高；部分前期问题可能要等到测试阶段才暴露。因此，对需求频繁变化的探索型项目，直接套用瀑布模型并不合适。

这些局限不是要否定瀑布模型，而是提醒团队：它是“在需求较稳定的前提下高效”的模型，选型前应先评估需求的确定性。

什么样的项目适合瀑布模型

比较适合瀑布模型的场景有：

• 需求在项目启动时已较明确，预计不会频繁变化。
• 技术路线成熟，团队对实现方式有把握。
• 项目对文档、流程和可审计性有明确要求，例如政企、金融、军工等受监管或合规驱动的系统。
• 交付周期较长，需要清晰的里程碑对齐多方协作。

不太适合的场景包括：

• 产品处于探索期，需要快速试错验证。
• 市场窗口短，希望尽早拿到可用版本并持续迭代。
• 用户需求需要边做边澄清。

如果团队同时承担需求稳定的“稳态项目”和快速迭代的“敏态项目”，可以在同一管理体系中组合不同过程模型，而不必让所有项目共用一个模板。这也是规模化研发组织的常见做法。

常见问题（FAQ）

瀑布模型和 V 模型、螺旋模型有什么不同？

V 模型可视为瀑布模型的延伸，强调“验证与开发同步设计”：需求分析对应验收测试，概要设计对应系统测试，详细设计对应集成测试，编码对应单元测试，让每一层开发都有对应的测试层。螺旋模型则在顺序结构中加入风险分析，每一轮循环先识别风险、再设计方案与验证，更适合高风险大型项目。三者都承认阶段化推进，差别在于对测试和风险的强调程度不同。

瀑布模型是不是要求需求一次定死？

不是。几乎没有项目能在启动时把需求彻底定死。常见做法是管理好“需求基线”：已批准的需求进入本期范围，新需求或变更先做影响评估，再决定放进本期、下一版本还是暂缓。团队可以保留统一的需求入口持续收集与排优先级，为变更留出受控通道，同时保住瀑布的阶段控制。

什么时候该考虑切换到更敏捷的方式？

可以观察几个信号：需求变更请求出现频率明显上升；团队长期处于“等需求确认”的停滞状态；业务方希望分批看到可用成果而不是一次性验收；返工大多来自需求理解不一致。当这些信号集中出现时，说明顺序推进的前提开始松动，值得缩短交付周期、引入迭代反馈。反之，当范围稳定、业务方只关注最终交付质量时，瀑布式阶段管理仍有优势。

用禅道落地瀑布式阶段管理

把瀑布模型落到日常执行，可以按三步来做：

1. 把阶段转成计划，让每个阶段有明确的开始与结束。
2. 把交付物转成任务，拆到可执行、可跟踪的粒度。
3. 把评审转成节点，用检查点控制阶段之间的放行。

禅道项目管理软件提供需求、任务、用例、Bug、文档等管理对象：可以用需求承接并追踪需求基线，用任务拆解设计与编码工作，用用例承载测试场景，用 Bug 记录和跟踪质量问题，用文档沉淀各阶段的交付物。禅道支持稳态与敏态双模管理，规模化研发团队可以在一个平台上同时编排按阶段推进的瀑布式项目和迭代型项目。若团队需要把代码提交与研发过程关联，禅道生态中的代码托管工具 GitFox 也可承担仓库托管与代码评审相关环节。

掌握瀑布模型的 6 个阶段，不是让团队回到“只靠文档、不碰迭代”的老路，而是帮助你在计划驱动与快速迭代之间做出更清楚的选择。需求明确、重视文档与里程碑的项目，瀑布式阶段管理依然能带来稳定的过程控制；需求不确定的项目，则更适合选择更敏捷的推进方式。两者并不互斥，关键在于与项目自身特点匹配。