瀑布 vs 敏捷：两种项目管理方法论该如何选择

瀑布还是敏捷，这个问题通常出现在两个时刻：项目还没启动，需要定流程；或者现有流程已经反复出问题，想换一种方法试试。

两个时刻要回答的其实是同一个问题：这个项目里，哪些东西必须提前定死，哪些可以边做边学。把瀑布和敏捷看成互斥的两个选项，往往就会在这里走偏。它们是两种常见的项目管理方法论，差别不在新旧，而在对不确定性的处理方式。

下面先把两者的差异讲清楚，再给出可以逐条对照的判断条件，最后说明什么情况下该选哪一端，以及为什么不少项目最终落在两者之间。

瀑布与敏捷，本质区别在哪

瀑布模型：把不确定性挡在前期

瀑布模型把项目切成需求分析、设计、编码、测试、维护等阶段，按固定顺序推进。上一阶段的产出是下一阶段的输入；上一阶段没有通过评审，下一阶段不开始。

它的核心假设是：需求可以在前期说清楚，之后按计划执行就行。好处是边界清楚。每个阶段都有交付物和检查点，预算、工期、范围能在早期形成基线，后续进度对着基线看。

代价出现在变更上。阶段越靠后，改动牵扯的已完成工作越多。需求阶段调整一句话，可能只是改文档；到了测试阶段再调整同一句话，就要重新设计、重新编码、重新测试。改动本身并不难，难的是它牵动了多少已经完成的工作。

值得注意的是，瀑布模型的定义里并不完全排斥回退。发现问题时，流程允许返回上一阶段修正，只是回退被当作异常处理，成本由已经完成的阶段承担。

敏捷：把不确定性放进迭代

敏捷的纲领性文件是 2001 年发布的《敏捷软件开发宣言》，由 17 位软件开发者在一次会议上共同提出，包含四项价值观和十二条原则。四项价值观是：

• 个体和互动高于流程和工具
• 可工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

落地时，敏捷通常表现为短周期迭代：把一个大目标拆成若干小周期，每个周期结束交付一部分可用的成果，再根据反馈决定下一周期做什么。宣言中的原则提到，交付间隔可以从几周到几个月，越短越好；实践中，1～4 周是较常见的区间。

它的假设与瀑布模型相反：需求很难在前期完全说清，与其花时间猜，不如尽快做出可验证的部分，用真实反馈替代会议室里的推断。

两者不是先进与落后的关系

敏捷出现得晚，但晚不等于更好。选择依据不是哪种更新，而是项目的不确定性分布在哪里、变更代价有多大、组织能承受多快的节奏。同一个组织里，不同项目采用不同方法，是正常状态，不是管理混乱。

判断之前，先看四个条件

比较容易犯的错误，是先挑方法，再找理由。更稳妥的顺序是先描述项目，再对号入座。以下四个条件基本决定了你的项目更适合哪一端。

需求有多确定

判断标准可以简化成一句话：能不能在启动前把需求写到验收时不用争论的程度。

如果需求来自明确的合同、法规、标准或已有的业务流程，参与方对结果有共识，不确定性就低。如果需求来自对市场的判断、对新用户的理解，连提出需求的人自己也在摸索，不确定性就高。

这里要区分需求数量和需求确定性。需求条数多但边界清楚，不代表不确定；需求条数少但方向反复，不确定性反而更高。

变更会发生在什么阶段、代价多大

同样是变更，代价差别很大。

如果改动只涉及尚未开始的模块，代价有限；如果改动会推翻已完成的设计、已通过的测试、已签署的验收文件，或者要重新走一遍合规审查，代价就高。有些领域的变更还涉及外部审批，时间和资金成本都不由团队控制。

变更代价高，意味着前期把范围定清楚更划算；变更代价低，意味着过早冻结范围反而浪费了调整的机会。

交付节奏由外部约束还是内部节奏决定

有些项目的交付节点是外部给定的：上线窗口、招标要求、监管期限、与其他系统的对接时间。这类项目一旦错过节点，损失很难靠后续迭代补回，稳定的阶段计划价值更高。

有些项目的节奏由团队自己掌握，可以先交付一部分验证市场反应，再决定后续投入。这类项目更看重反馈速度和调整空间。

客户参与方式和治理要求

敏捷对参与方有实际要求。它需要业务方能在每个周期内给出反馈、参与优先级排序，而不只是在启动和验收时出现。如果业务方无法持续投入，迭代评审会容易变成形式，反馈链条断掉，敏捷就容易退化成一套会议流程。

反过来，如果项目涉及较强的合规、审计、责任追溯要求，需要留痕、需要阶段性审批、需要明确的责任边界，那么完全依赖口头协作和持续调整的方式，会在治理层面遇到阻力。

四个维度上的对称比较

把上面四个条件落到具体差异上，可以对照下表。需要说明的是，这张表描述的是两种方法的典型形态，实际项目往往落在中间地带。

计划与范围：一次定清与逐步收敛

瀑布的计划更像一次性的产物，敏捷的计划更像持续更新的过程。这不代表敏捷不做计划。敏捷规划同样需要明确目标、边界和优先级，只是把详细规划放在更接近执行的时间点上做，远期保持高层级。

反馈节奏与风险位置

两种方法真正的差别，在于风险暴露的时间。瀑布把大量验证工作放在后期，一旦前期理解有偏差，问题会在集成或验收时集中出现。敏捷通过短周期交付，让需求偏差和技术风险在成本还低的时候暴露。

风险提前暴露不等于风险消失。敏捷只是把大风险拆成了若干个更早出现的小风险，这需要团队有能力在每个周期结束前真正完成可交付的成果，否则迭代只是把进度压力切成小块。

协作与文档：职责边界与共同负责

瀑布按职能划分角色，需求、设计、开发、测试各自负责自己的阶段，靠文档衔接。这种分工在人员规模大、地域分散、需要轮换交接的场景下更稳定。

敏捷强调跨职能团队和直接沟通，文档相应精简。它的前提是团队稳定、成员愿意共同承担结果。如果团队流动性大、成员习惯只对自己的环节负责，跨职能协作容易停留在口号上。

四种常见误读

敏捷不等于不做计划

敏捷反对的是把远期细节过早写死，不是反对计划本身。持续调整优先级，前提是有优先级；每个迭代要交付什么，也需要明确。缺少计划能力的团队用敏捷，得到的通常是节奏混乱，而不是灵活。

瀑布不等于不能回头

瀑布流程中同样存在评审、修正和回退。它的特点不是绝对线性，而是回退成本高、需要通过变更流程管理。把瀑布理解成错了也要走到底，是对流程的误解。

敏捷不等于更快

敏捷缩短的是反馈周期，不是交付总量。如果需求本身不确定，敏捷能让团队更早发现方向偏差，避免把资源投在错误的地方；如果需求本来就是明确的，短周期的评审和协调反而会增加开销。速度取决于项目特征，不取决于方法名称。

不能只看成功率数据

行业里经常被引用的项目成功率统计，多数来自不同年份、不同样本和不同判定口径的调研，数值差异很大。这类数据可以说明项目管理水平整体还有提升空间，但不适合直接用来证明某一种方法一定优于另一种。

条件化选择：什么情况优先选哪个

优先选择瀑布的情形

• 需求边界清楚，验收标准可以事先写明白
• 变更代价高，或者变更需要外部审批
• 交付节点由外部给定，错过之后很难补救
• 项目涉及较强的合规、审计和追溯要求
• 团队分布在多个地点，成员流动性较高，需要靠文档衔接

优先选择敏捷的情形

• 需求方向不完全清晰，需要一边做一边验证
• 变更代价低，调整空间比稳定更重要
• 交付节奏由团队掌握，可以先交付一部分再看反馈
• 业务方能够持续参与，愿意在每个周期做优先级取舍
• 团队规模不大、相对稳定，具备跨职能协作条件

两者都不完全适用时，考虑分层处理

很多项目同时具备两类特征：一部分工作追求确定性，比如预算、合同、接口、合规、上线窗口；另一部分工作充满不确定性，比如需求澄清、流程重构、方案验证。

这类项目与其在两种方法之间摇摆，不如分层处理：对承诺、资源、审批和关键节点采用较稳定的计划和控制方式；对需求细节、实现路径和优先级采用短周期迭代。更贴近实际的做法，是把预测型和适应型看成一个连续谱，让项目在谱上找到自己的位置，而不是二选一。

分层时有两个要点：

1. 锁定边界，而不是锁定细节。目标、投入上限、关键节点和重大风险要清晰；业务细节留到更接近执行的阶段再确认。
2. 迭代不等于可以无限改范围。变化的入口、决策权限和升级路径要事先约定，否则灵活会变成失控。

选定之后，让方法落地的三个配套条件

方法本身只是框架，能不能用起来，取决于配套条件是否到位。

团队能力与方法匹配

瀑布要求流程执行能力和文档能力，敏捷要求团队具备自我组织和跨职能协作能力。团队现有能力与所选方法不匹配，是实践中常见的失败原因之一。更换方法之前，先评估团队是否具备相应的工作习惯。

参与方的节奏要对齐

敏捷需要业务方按周期参与，瀑布需要业务方在关键评审点做决策。如果参与方的时间投入无法保证，再合理的方法设计也会落空。

度量方式要跟着调整

用瀑布的度量方式考核敏捷团队，或者用敏捷的节奏要求瀑布项目，都会造成扭曲。计划达成率、里程碑偏差适合衡量稳定型项目；需求交付周期、Bug 发现时间、版本验收情况更适合衡量迭代型项目。度量口径不一致，团队会把精力放在满足指标上，而不是解决问题。

回到最初的问题：瀑布和敏捷该怎么选。判断依据不在方法本身，而在项目的不确定性分布、变更代价、交付约束和参与方式。先把这四个条件描述清楚，选择往往就变得清楚了。而当项目同时包含确定性和不确定性时，分层使用两种方法，比坚持某一种更接近实际需要。

常见问题 FAQ

敏捷和 Scrum、看板是一回事吗

不是。《敏捷软件开发宣言》确立的是价值观和原则，属于纲领层面，本身不规定具体做法。Scrum、极限编程（XP）、看板（Kanban）都是在此基础上发展出的具体实践框架，各有侧重：Scrum 通过固定的角色、事件和工件组织迭代；看板更关注工作流动和在制品数量控制；极限编程则把重点放在工程实践上。

选哪个框架，取决于团队当前最突出的问题在哪，而不是哪个名字更流行。

项目已经按瀑布启动了，还能转敏捷吗

可以，但不建议整体推倒重来。切换的主要成本不在流程本身，而在契约与预算周期、验收方式、团队协作习惯。已经按合同和审批流程走到一半的项目，强行改成短周期交付，反而容易两头落空。

相对稳妥的做法是：治理层保留原有的里程碑、预算和审批机制，执行层把剩余工作拆成短周期交付，先让反馈跑起来，再逐步调整管理方式。

团队人数多、跨地区分布，敏捷是不是就不适用

不是绝对不适用，但协调成本会明显上升。单团队敏捷依赖高频直接沟通，团队数量一多，就需要额外机制来对齐：统一迭代节奏、跨团队同步会议、可视化的进度看板，必要时引入规模化框架（如 SAFe、LeSS）来管理多团队协作。

代价是流程变重。小团队直接套用规模化框架，往往只会增加管理开销。

敏捷一定要每天开站会吗

站会是 Scrum 的一种具体实践，不是敏捷的强制要求。它的目的是暴露障碍、同步当天安排，而不是汇报进度。如果会议只停留在逐人汇报，却没有解决任何阻塞问题，可以换一种更适合团队的同步方式。

判断标准很简单：这个会议有没有让问题更早被发现。

小团队、工期很短的内部项目，也要选方法吗

需要的是适配，而不是完整体系。这类项目最大的风险是流程负担超过收益，把时间花在维护文档和会议上。

可以只保留最必要的部分：目标与验收标准说清楚，交付拆成小段，定期同步进展和障碍。项目规模小的时候，方法和工具的差异，通常小于人和沟通的差异。