瀑布开发不是不迭代，是节奏不同

开篇：一个让你坐不住的真相

去年秋天，我在一家中型银行的科技部做敏捷转型咨询。对方的 PMO 总监把我拉到会议室，指着墙上那张 A3 纸打印的 Scrum 流程图，压低声音说了一句话，让我至今忘不了：

“你别跟我讲敏捷那套迭代。我们现在的瀑布项目，光是需求评审就走了 11 轮，这叫没迭代？”

他不是一个抗拒变化的老派管理者。他的团队在用 PingCode 管理着 200 多个并发需求，迭代计划、故事点估算、燃尽图一应俱全。但他坚持认为，主流敏捷布道者对“瀑布”的描述，跟他亲眼见到的完全不是一回事。

那次对话迫使我回头重新审视一个问题，一个在项目管理圈被反复争论、却极少有人说清楚的问题：

瀑布开发真的是不迭代吗？

我的答案是：不是。瀑布开发从来不是不迭代。它是另一套迭代节奏，一套被教科书简化、被敏捷运动标签化、被大多数从业者误读了的节奏。

这篇文章不是要为瀑布“翻案”，也不是要贬低敏捷。我要做的是把两种迭代逻辑拆开揉碎，让你看到它们真实的工作方式、各自的取舍逻辑，以及在什么情况下你应该选择哪一种节奏。我会用到我亲自参与过的大型项目案例，以及 PingCode 在服务 100 人以上组织时呈现出来的真实数据模式。

读完这篇文章，你不会再纠结“该用瀑布还是敏捷”这种伪问题。你会开始问一个更精准的问题：这个项目，应该跑在哪种迭代节奏上？

一、重新定义“迭代”：你不定义清楚，后面全是废话

在讨论瀑布和敏捷谁更“迭代”之前，我们得先做一件很多人跳过去没做的事，把“迭代”这个词的定义摆到桌面上。

我在给企业做项目管理培训时，经常会做一个简单测试。我问学员：“你们觉得什么叫迭代？”得到的回答大致分成三类：

• “迭代就是做一版，然后改一版。”
• “迭代就是 Sprint，两周一个循环。”
• “迭代就是需求可以变，不用一开始定死。”

这三种回答，没有一个触达迭代的本质。

1. 迭代真正的定义应该是什么

从系统论和控制论的角度看，迭代是指：一个系统基于前一轮输出的反馈，来修正下一轮输入或过程的行为。

关键词不是“快慢”，不是“周期长短”，不是“要不要开站会”。关键词是三个：前一轮输出、反馈、修正下一轮。

只要满足这个条件，它就是迭代。不管这个过程是发生在两周内，还是两个月内，还是两个季度内。

我举个非软件行业的例子帮你理解。建筑行业是典型的“瀑布式”行业，先设计，再打地基，再盖楼，再装修。但你知道建筑行业有多少轮“回退”吗？设计院出图之后，施工方在打桩阶段发现地质条件跟勘察报告不一致，怎么办？设计院必须修改图纸，重新计算荷载。这个过程就是迭代。它不是开发软件的迭代，但它完整满足“基于前一轮反馈修正下一轮输入”的定义。

软件行业也一样。需求文档写完之后，在概要设计阶段发现某个接口的调用逻辑根本走不通，设计团队找产品经理重新对齐需求，这也是迭代。只不过，这个迭代没有发生在 Sprint 里，它发生在另一个时间尺度上。

2. 迭代和增量的混淆，让这场讨论变得更糟

敏捷圈有一个根深蒂固的表述：“敏捷是迭代且增量的；瀑布是线性的、非迭代的。”这句话被 Scrum Guide、SAFe 框架、无数敏捷培训课程反复传播。但它有一个致命问题：它把“迭代”和“增量”两个概念强行捆绑，还把“非增量”偷换成了“非迭代”。

• 迭代（iterative）：通过反复精炼来逼近最终结果。
• 增量（incremental）：分批次交付功能，每一批都是可用的子集。

瀑布项目可以高度迭代（在每个阶段内部反复修正），但它是弱增量的，交付通常集中在一个或两个大的节点。敏捷项目既是高度迭代的，也是高度增量的，每个 Sprint 交付一个可工作的小增量。

所以正确的对比不是“敏捷迭代 vs 瀑布不迭代”。正确的对比是：

“敏捷是高频迭代 + 高频增量” vs “瀑布是低频迭代 + 低频增量”。

差的不是“有没有迭代”，差的是“迭代发生在什么节奏上”。

二、瀑布的“慢迭代”：你要的迭代，它一直在做，只是你看不见

现在我们把镜头推到瀑布模型内部。主流教科书把瀑布画成一条自左向右的单向箭头：需求→设计→编码→测试→部署。这幅图是万恶之源。它让无数人以为，瀑布就是一个阶段做完、签字画押、扔给下游、永不回头的过程。

任何在真实项目里待过的人都知道，这幅图是假的。

真实瀑布项目的迭代，隐藏在两个层面：

• 第一层：阶段内部的隐式迭代，在同一个阶段里，反复试探、验证、推翻重来。
• 第二层：阶段之间的显式回退，下游阶段发现致命问题时，整个项目被强制拉回上游阶段。

这两个层面的迭代，比敏捷的 Sprint 更难看见，但它们是真实存在的。我们一层一层来看。

1. 阶段内部的隐式迭代：需求文档背后的几十版草稿

2021 年我参与了一个省级政务平台的建设项目，合同约定了严格的瀑布交付流程。项目启动之后，需求分析阶段原计划用 6 周完成。实际用了多久？11 周。

不是需求分析师懒，也不是甲方不配合。是迭代就发生在需求分析阶段内部。80 多个业务部门提交了超过 400 条原始需求，需求分析师需要逐条梳理、关联、去重、发现冲突。每梳理一轮，就会发现新的问题，然后把问题清单发回给业务方确认。业务方确认的过程又会引出新的需求变更。

这个过程就是一个典型的阶段内闭环迭代：

1. 收集需求（输入）
2. 分析、建模、写文档（处理）
3. 提交业务方评审（输出）
4. 收到业务方修改意见（反馈）
5. 回到第 2 步继续分析，或回到第 1 步补充采集（修正下一轮输入）

这个循环在 11 周里跑了至少 7 轮。每一轮都是货真价实的迭代。只不过，它发生在需求阶段内部，没有跨越需求到编码的边界。那些说“瀑布不迭代”的人，恰恰是因为只看了阶段的边界，没看阶段内部发生了什么。

如果你用了 PingCode 这样的工具来管理这个过程，你会发现在“史诗-特性-用户故事”的多级需求管理视图里，需求的版本变更记录密密麻麻。一个用户故事被反复修改五六版，优先级被调整七八次，产品负责人在用户故事上标注的“业务价值”数字也在不断滚动。这是一个高度迭代的过程，只不过它没有用 Sprint 来框定节奏而已。

2. 阶段之间的显式回退：把“不该发生的返工”重新理解为“必要的纠正”

瀑布的第二个迭代机制更让敏捷践行者嗤之以鼻：阶段回退。在经典的瀑布模型里，如果你在测试阶段发现了一个需求层面的缺陷，理论上应该回退到需求阶段去修正。敏捷圈对此的批判是，这种回退成本极高，是瀑布最大的失败。

我同意前半句：成本高是事实。但后半句“是失败”需要分情况讨论。

在参与 PingCode 服务的中大型客户时，我注意到一个规律：那些需要在项目中期回退需求的组织，往往不是需求阶段没做好，而是他们面对的领域复杂度决定了需求不可能一次性做对。银行核心系统、制造业 MES 系统、政府行政审批平台，这些领域的业务规则多到恐怖，互相依赖关系纠缠得像一团乱麻。无论前期投入多少时间做需求分析，不可避免地会有 15%-25% 的需求在详细设计或编码阶段才暴露出真正的问题。

在这种场景下，阶段回退不是“失败”，而是对复杂性的必要回应。它是系统在告诉你：“你之前掌握的信息不够，现在新信息出现了，请重新决策。”

我观察到的差异在于：

• 低复杂度项目：前期需求可以做对 90% 以上，阶段回退是浪费，应该用敏捷的快速迭代替代。
• 高复杂度项目：前期需求只能做对 60%-70%，剩下的 30% 无论如何要到后期才能暴露。在这种情况下，阶段回退不可避免。争论“应不应该回退”没有意义，应该争论的是“如何让回退的成本可控”。

回到本章的核心论点：瀑布不是不迭代，它是把迭代延迟到了阶段内部和阶段之间的转折点上。这个节奏比敏捷慢很多，但它的逻辑是完整的。你能否接受这个节奏，取决于你能否接受它对应的成本和风险结构，这一点我放到本文后半部分细讲。

三、敏捷的“快迭代”：它的真正优势不是迭代本身，而是压缩了反馈闭环

讲完瀑布的迭代，我必须同样诚实地说清楚敏捷的迭代是什么，以及它真正的优势到底在哪。

敏捷不是“有迭代”而瀑布“没有迭代”。敏捷的真正差异在于两点：

• 反馈闭环被压缩到了 1-4 周的尺度
• 每次迭代都交付一个可评审、可演示的增量

这两点的叠加，产生了敏捷的独特优势。但同样，这两点的叠加也带来了敏捷在特定场景下的不适配。我们分开说。

1. 压缩闭环的威力：在 PingCode 的一个 120 人团队里看到了什么

去年我跟进了一个智能驾驶解决方案团队的项目管理实践。这个团队大约 120 人，拆成 9 个 Scrum Team，用 PingCode 管理从需求到交付的全流程，每个 Sprint 固定两周。

在切入 PingCode 之前，这个团队用的是类似瀑布的分阶段模式：需求做两个月，然后设计一个月，然后集中编码三个月。他们当时遇到的典型问题是：编码做到第 6 周的时候，产品经理在评审演示中发现某个核心算法的表现跟预期偏差严重，导致整个底层架构需要重新设计。前 5 周的工作量几乎废掉 40%。

切到 PingCode Scrum 模式之后，变化很明显：

• 每个 Sprint 结束时必须输出可演示的算法模块增量
• 产品和算法负责人在 Sprint Review 上直接看到实际效果
• 偏差在第 2 个 Sprint 就被发现了，而不是在第 6 周集中爆发

我调了他们切换前后的 PingCode 数据：

数据很清晰：敏捷没有消灭偏差，但它让偏差被更早地看见。偏差还是那些偏差，但看见偏差的时间窗口从 6 周压缩到了不到 2 周。这就是反馈闭环压缩的威力。

但我必须指出一个很多人忽略的细节。这个团队之所以能压缩反馈闭环，不仅仅是因为他们开始“跑 Sprint”。更重要的是，他们有能力在两周内产出一个可以演示的增量。这一点在算法类、模块化程度高的软件产品上相对容易做到。在另一些类型的项目里，我马上会讲到，这件事本身就极其困难。

2. 敏捷“快迭代”的隐秘前提：可演示增量不是天然存在的

敏捷有一条铁律：每个 Sprint 结束必须产出一个“潜在可交付的产品增量”。这条规则隐含了一个极为苛刻的前提：你的系统架构和业务逻辑允许你在两周内切出一个可以独立演示的价值单元。

这在很多大型核心系统里几乎不可能。我举一个真实案例。一家大型保险公司的理赔核心系统改造项目，涉及十几个外部系统接口、上百条理赔规则、多层审批流。需求阶段梳理出的用户故事超过 700 个。问题是：任何一个用户故事都无法在两周内独立完成开发、联调、测试、演示，因为联调依赖外部系统，外部系统有自己的排期，不在你的 Sprint 节奏里。

这个案例不是要否定敏捷。恰恰相反，这个团队最终采用了 Scrumban 的方式，把 Sprint 周期拉长到 4 周，并接受“并非每个 Sprint 都有完整可演示增量”的现实。他们用了 PingCode 的迭代看板来跟踪每个开发任务的进展，同时保持了两周一次的站会和迭代回顾，这是一种追求“快节奏的可见性”而非“快节奏的交付”的务实选择。

这个案例说明了什么？不是所有项目都有条件跑“快迭代”。当你的系统耦合度太高、外部依赖太重、单个功能点的全链路实现周期长于你的 Sprint 长度时，强行要求每个 Sprint 产出可演示增量只会制造虚假进度。

敏捷的“快迭代”是一种强大的节奏，但它不是无条件的。

四、为什么“瀑布不迭代”这个说法如此深入人心：拆解传播链条

既然瀑布模型内部确实存在迭代机制，为什么整个行业几乎一边倒地认为“瀑布不迭代”？这个说法是怎么流行起来的？

我梳理了一条清晰的传播链条，它揭示了行业认知是如何被一层层简化的。

1. 第一层简化：Royce 的瀑布论文被断章取义

1970 年，Winston Royce 发表了那篇著名的《Managing the Development of Large Software Systems》。大多数敏捷布道者引用这篇论文来证明“瀑布模型是 Royce 提出的一种线性模型”。

问题是，Royce 在原文里明确提出了“做两次”的主张，“规划先做一个试点版本，扔掉它，然后基于经验重新做正式版”。他还强调下游阶段发现问题时必须回退到上游阶段。他的原图是有反馈回环的，不是一条从左往右的直线。

真正的“单向无回退”瀑布模型，是后来军方标准 DoD-STD-2167 和某些教科书为了简化教学而创造的。Royce 本人的原意被大规模误传。

2. 第二层简化：敏捷宣言的“对立面”叙事

2001 年敏捷宣言发布时，17 位签署者需要为自己的新理念找一个鲜明的对比对象。“瀑布”恰好站在了所有敏捷价值观的对立面：

• “个体和互动 高于 流程和工具” ← 瀑布被描绘成流程至上的代表
• “工作的软件 高于 详尽的文档” ← 瀑布被描绘成文档驱动的代表
• “客户合作 高于 合同谈判” ← 瀑布被描绘成合同导向的代表
• “响应变化 高于 遵循计划” ← 瀑布被描绘成抗拒变化的代表

这个叙事在传播上是极其高效的。它把复杂的项目管理选择简化成了一套清晰的价值排序。但它的代价是：把瀑布“妖魔化”为一个僵硬、愚蠢、不可理喻的模型。

你不能说这个叙事错了，它准确描述了瀑布的很多问题。但它不完整。它没有告诉你瀑布在什么场景下是合理的，也没有告诉你瀑布除了“抗拒变化”之外还有哪些隐性优势。

3. 第三层简化：培训市场的推波助澜

CSM（Certified ScrumMaster）、PSM（Professional Scrum Master）认证培训覆盖了全球数百万从业者。在这些培训中，“敏捷 vs 瀑布”是最经典的教学模块之一。但教学的策略通常是：先描述一个极端化的瀑布案例（需求冻结、客户不见面、测试放到最后），然后展示敏捷如何优雅地解决了这些问题。

这种教学的示范效应非常强，但它强化了一种“瀑布=错误、过时、不迭代”的印象。对于大多数参加培训的学员来说，他们没有接触过“运行良好的瀑布项目”，也没有接触过“运行失败的敏捷项目”。他们学到的是一个被简化过的世界图景。

这三层简化叠加在一起，就形成了今天的行业常识：瀑布不迭代，敏捷才迭代。但这个常识经不起推敲，如果你把它放到我前文描述的真实案例里，它立刻就会暴露出问题。

五、迭代节奏的真正差异：一张表说清楚你在做的到底是什么选择

到现在为止，我已经讲清楚了瀑布有迭代、敏捷的迭代快在压缩反馈闭环、以及“瀑布不迭代”这个说法是怎么传歪的。但这篇文章不能只是“纠正观念”。它必须能指导实践。

所以我要把两种迭代节奏拆成一张可操作的对比表，让你在面对具体项目时，能够识别自己真正在做的是哪种选择。

这张表不是为了制造对立。是为了让你看清楚：你选的不只是“有没有迭代”，你选的是一整套代价结构和适应条件。

六、什么时候该选慢节奏：四个你不应该勉强跑敏捷的场景

我见过太多被敏捷“裹挟”的团队。领导说行业都在敏捷转型，于是全员 Scrum。两周一 Sprint，站会、评审、回顾一个不落。但半年下来，团队更累了，交付质量更差了，大家觉得敏捷是形式主义。

问题不出在敏捷上，出在你用错了节奏。

根据我在一线观察到的模式，以下四种场景下强行跑“快迭代”是灾难性的。你需要的反而是瀑布的“慢迭代节奏”，或者至少是大幅度改良的混合节奏。

1. 需求不可能在两周内稳定下来的项目，但原因是外部依赖，不是用户没想清楚

很多敏捷文章说“需求不稳定就要用敏捷”。这只说对了一半。如果需求不稳定是因为用户需要试错来厘清自己，敏捷是对的。如果需求不稳定是因为你要对接 7 个外部系统，而其中 3 个系统的接口文档还没出来，敏捷帮不了你。

我在一个大型物流平台的整合项目中亲眼见过这种情况。团队跑着两周 Sprint，但 Sprint Planning 上分配的 70% 任务依赖外部物流公司提供接口。外部公司的排期跟你的 Sprint 节奏完全不同步。结果是什么？计划每个 Sprint 完成 30 个任务，实际完成的只有 9-12 个，其他的全部挂上 blocked 标签，一挂就是三四个 Sprint。

这个团队的 PingCode 任务板上，被阻塞的任务积压了厚厚一叠。燃尽图在 Sprint 前半段纹丝不动，后半段才因为移除了几个被阻塞的任务而突然“下降”，这是一幅典型的虚假燃尽曲线。

如果外部依赖决定了单个功能点的全链路实现周期超过 4 周，强行跑两周 Sprint 就是在原地摩擦。

2. 架构稳定性要求压倒一切，银行核心、航电、医疗器械

某些领域的系统一旦上线，回滚代价不是少几万块钱的问题，可能是安全事故或监管处罚。在这种场景下，前期架构设计的稳健性比“快速试错”重要一个数量级。

我参与过某股份制银行信用卡核心的替换项目。技术栈从 COBOL 迁移到 Java 微服务，涉及账户、额度、计息、风控四大核心模块。这个项目的前期架构设计花了整整 7 个月。不是效率低，是每一个架构决策都需要经过反复建模、压力测试、评审。任何一次 Sprint Review 级别的“快速反馈”都不足以验证架构的安全性，你需要的是深度审查，而不是快速试错。

在这种场景下，瀑布的“慢迭代”不是缺陷，是风险控制的必要手段。

3. 合同与合规约束导致交付范围必须预先锁定

政府信息化项目、大型国企招标项目、军工项目。这些项目的共同特征是：合同规定了交付物清单，变更要走正式变更流程，结算按里程碑进行。如果你在这种情况下试图跑一个“拥抱变化”的敏捷流程，你会发现 Sprint 里产生的需求变更不属于合同范围，导致团队做了一堆合同之外的活却拿不到钱。

我帮助一个省级应急管理平台的项目团队做过模式调整建议。他们最初的 Sprint 里，几乎每个 Review 后产品负责人都想加新功能。但加的功能不在合同列表里，验收时甲方不认。财务部门问：“成本上去了，收入不变，怎么回事？”最后他们收敛为：用 PingCode 管理迭代，但在 Sprint 内只拆分合同范围内的任务，变更走单独的变更流程，不混入 Sprint Backlog。这是一种在合规约束下的务实选择。

4. 团队物理分散且时区差距超过 6 小时

敏捷要求每日站会、Sprint Review、Sprint Retro，所有这些活动的有效性都依赖同步沟通。一旦团队分布在东八区和美东之间，时差超过 12 小时，同步沟通成本高到惊人。强行按敏捷节奏跑，你会发现在中国的团队在等美国团队反馈时，Sprint 已经过了一半。

很多全球分布式团队的实际工作方式是：文档先行，异步评审，大节点同步，这正是瀑布流程擅长的事情。文档作为异步沟通的载体，在时区割裂的环境里不是累赘，而是必须品。

七、什么时候该选快节奏：敏捷确实更好用的三种情况

为了平衡论述，我必须同样明确地列出快迭代的适用场景。以下三种情况，如果你还用瀑布的慢节奏，你会输得很惨。

1. 用户自己也不知道要什么，探索型产品

创业公司的新产品、大企业内部的创新孵化项目、为尚未验证的市场开发 MVP。在这种场景下，需求准确性不可能靠前期分析获得，用户自己都不知道自己要什么，直到他看到第一版产品才能给出有意义的反馈。

这种场景下，瀑布的逻辑，前期花大量时间把需求想清楚，是无效的。因为想不清楚。你只能在 Sprint 里用最小成本做出一个假设，扔给用户看反应，拿到反馈，调整方向。

PingCode 的客户中有不少做 SaaS 产品的团队，他们在探索新功能时的典型做法是：用 PingCode 的史诗功能拆出 5-7 个实验性故事，2 个 Sprint 内上到灰度环境，看使用数据，决定是继续投入还是砍掉。这种高频验证，假设→实验→数据→决策，只能发生在周级别的迭代节奏上。

2. 产品生命周期短，市场窗口转瞬即逝

在一些竞争高度激烈的市场里，晚一个月交付就可能丢掉全部市场份额。这时候，任何形式的“把需求全部想清楚再开发”都是商业自杀。你需要的是最快的迭代节奏，即便代价是架构不那么优雅、技术债累积更快。

跨境电商、游戏发行、节日营销类产品都符合这个特征。这些团队不需要一个能用十年的完美系统，他们需要一个能在两周内上线的能在黑五之前抓住流量的可用系统。

3. 团队协作高度成熟，工程实践已经到位

敏捷对工程能力有隐性要求，很多人没有意识到。CI/CD 管道是否完善、自动化测试覆盖率是否够高、微服务或模块化架构是否支持独立部署，这些工程实践决定了你的 Sprint 能不能真的产出可演示增量。

如果一个团队在以上方面都比较成熟，那么快迭代的效率天然高于慢迭代。因为他们具备快节奏的基础设施。没有这些基础设施的团队跑敏捷，就像没有跑道的赛车，引擎再好也开不快。

八、混合模式：给你一套实用的组合打法，别在“纯瀑布”和“纯敏捷”之间二选一

说了这么多，你可能已经意识到了：大多数真实项目既不是纯瀑布也不是纯敏捷。它们是混合体。

问题在于，很多团队的“混合”是糊里糊涂的混合，需求阶段跑敏捷，开发阶段回到瀑布，测试阶段又塞了一堆赶工，最后谁也说不清到底用的什么方法。这不是混合，这是无方法。

好的混合是有意识地选择不同阶段跑不同节奏。我在数十个项目的实践中摸索出了一套可复用的框架，分享给你。

1. 在需求阶段用 Sprint 试错，在交付阶段用瀑布锁范围

这个模式的逻辑是：先发散，后收敛。在项目早期，需求不确定性最大。这时候用 2-4 个 Sprint 来快速制作原型、跟用户反复确认，直到需求相对稳定。一旦需求稳定，后续的设计、开发、测试切换到瀑布式的阶段交付模式，因为这时候“拥抱变化”的收益已经低于“稳定交付”的收益了。

PingCode 支持这种混合工作方式：你可以在需求收集阶段使用史诗-特性-用户故事的多级拆分，配合用户故事地图做可视化规划，让产品负责人反复调整优先级。一旦需求基线确定，你可以把用户故事冻结为迭代待办列表，进入没有范围变更的开发周期。

2. 在大瀑布框架内嵌入微型 Sprint

这种做法在受监管行业尤其常见。整体项目遵循瀑布的里程碑管理，合同节点、付款节点、关键评审不变。但在每个大阶段内部，团队用 Sprint 节奏来组织日常工作。

举个例子：一个能源行业的 SCADA 系统项目，整体 18 个月，分需求、设计、开发、测试、上线五大阶段。但在 6 个月的开发阶段内部，团队拆成了 12 个两周 Sprint，用 PingCode 的任务板做 Sprint 管理和燃尽跟踪。站会照开，回顾照做，但 Sprint Review 只对内演示，不对客户开放，因为客户只看合同约定的里程碑节点。

这种做法兼顾了对客户的合规承诺和团队内部的快速节奏。

3. 按模块拆解节奏：核心模块走慢迭代，边缘模块走快迭代

大型系统中往往有几个模块是核心命脉（例如支付引擎、风控算法），不容有失；而大量外围模块（报表、管理后台、通知系统）容错空间较大。对核心模块适用瀑布的慢节奏，充分设计，严格评审；对外围模块适用敏捷的快节奏，快速交付，用户不满再改。

我在一个支付平台的建设中用过这个策略。支付核心经历了 4 个月的需求和设计评审，而商家后台的 30 多个功能点是按 Sprint 快速交付的，用户反馈也很及时。核心系统上线至今没有发生过重大事故，因为慢节奏保证了架构质量。

九、在 PingCode 里看到的数据规律：快节奏和慢节奏的团队，到底谁更高效

在跟踪 PingCode 服务的中大型客户时，我注意到一个有趣的数据规律。这些客户中，既有跑纯 Scrum 的，也有跑混合模式的，还有跑类瀑布模式的。我拉取了一组脱敏后的运营数据，对“交付效率”和“交付质量”两个维度做了交叉分析。

以下是观察到的模式（数据来自 2023-2024 年通过 PingCode 管理的 60 多个 100 人以上组织的项目，已脱敏）：

从这组数据里我读出了三条洞察：

1. 混合模式和大瀑布内嵌 Sprint 的交付达成率最高，高于纯 Scrum 和纯瀑布。这说明有意识地在合适阶段切换合适的节奏，比“选边站”更有效。
2. 纯 Scrum 和纯瀑布的交付达成率都不如混合模式。纯 Scrum 的弱点在于频繁变更拉低了达成率；纯瀑布的弱点在于需求冻结后变更几乎不可能处理，导致后期大量非标准操作。
3. 缺陷密度最低的不是纯敏捷，而是大瀑布内嵌 Sprint。这说明在核心系统上，“先想清楚再动手”对质量的正向贡献非常显著。

当然，这些数据有样本偏差，受 PingCode 客户群体的行业分布影响。但它至少说明了一点：最高效的团队不是“敏捷原教旨主义者”也不是“瀑布捍卫者”，而是清楚知道什么阶段该用什么节奏的务实派。

十、下一步怎么行动：给你一个自测框架和一个决策树

读到这里，你可能会问：“道理我懂了，但我的项目到底该用哪种节奏？”

我问过自己同样的问题，在无数次踩坑之后，我总结了一个自测框架。你花 10 分钟回答以下 6 个问题，就能大致定位你的项目适合的迭代节奏。

1. 迭代节奏自测：六个问题帮你快速定位

每个问题按 1-5 分打分（1 分=完全不适用，5 分=完全适用）：

1. 需求稳定程度：项目启动时，你对需求的把握程度有多高？（5 分=需求高度稳定，变化极少）
2. 外部依赖程度：单个功能点从开发到交付过程中，依赖外部团队或系统的等待时间有多长？（5 分=几乎无外部依赖）
3. 系统容错空间：你的系统对缺陷的容忍度有多高？（5 分=容忍度极高，缺陷不会造成重大损失）
4. 交付节奏约束：合同或干系人是否要求按里程碑分批交付？（1 分=严格按里程碑，5 分=持续交付可接受）
5. 团队分布协同度：团队是否在同一地点、同一时区、沟通同步成本很低？（5 分=高度同步）
6. 工程基础设施：CI/CD、自动化测试、模块化架构的成熟度有多高？（5 分=高度成熟）

计算总分并参考下表：

2. 如果你今天就要做出一个选择

如果上面的自测你来不及做，给你一个最简单的判断口诀：

“能快则快，该慢则慢。问的不是‘能不能快’，是‘慢的代价你能不能承受’和‘快的风险你能不能扛住’。”

具体地说：

• 如果你能承受快速试错的代价（架构不完美、技术债累积、偶尔线上小故障），那选快节奏。
• 如果你不能承受上线后重大事故（金融、医疗、基础设施领域），那在核心模块上选慢节奏。
• 如果你不确定，用一个 Sprint 或一个迭代周期做实验，收集数据，再判断。

不要盲从行业热点。敏捷很好，但敏捷不是唯一对的。瀑布被妖魔化了，但它也不是唯一对的。错的是“放之四海皆准”的执念。

结语：选择你的迭代节奏，而不是选择你的阵营

这篇文章写到这里，已经远超传统“瀑布 vs 敏捷”对比文章的篇幅。我有意这样做，因为这个话题值得被严肃对待。它不是一场网络辩论赛，你站哪一方无所谓。它影响的是数千人团队的日常工作方式，影响的是项目的成本、质量和士气。

我在文章开头提到的那位银行 PMO 总监，后来做了两件事。第一，他把墙上的 Scrum 流程图换成了 PingCode 的迭代概览页，实时燃尽图、需求变更趋势、迭代达成率一把抓。第二，他在部门的周会上宣布了一条新的原则：

“我们不再争论该用瀑布还是敏捷。每个项目启动时，我们只讨论一个问题：这个项目的迭代节奏应该跑多快？”

这条原则比任何方法论的标签都更务实。

你的下一步行动很简单：拿这篇文章里的自测框架，在你当前的项目上打一次分。看看分数落在哪个区间。如果分数告诉你需要调整节奏，那就调整，哪怕这意味着你要跟领导争取更长的 Sprint 周期，或者意味着你需要说服团队接受一段时间的需求冻结。

迭代是手段，不是目的。目的是在你所处的约束条件内，用最合适的节奏把产品做好。这句话值得被你记下来。