我们为什么又退回瀑布模式

一、我们以为自己背叛了敏捷，其实只是被现实抽了一巴掌

2022年第三季度，我们团队做了一件在当时看来像是“开倒车”的事：主动把一个跑了14个Sprint的Scrum项目，整体迁移回了瀑布模式。

决策会上，产品负责人摔了笔记本：“你们这是要回到石器时代吗？”Scrum Master沉默了三分钟，只问了我一句话：“你确定不是我们执行得有问题，而是模式有问题？”

我当时的回答是：“我们不是退回瀑布，我们是把项目从混乱的敏捷表演里捞出来，塞进一个至少能按时交付的框架里。”

那是一个金融监管报送系统，对接银保监会1104报表体系，需求来源不是产品经理的脑洞，而是红头文件。合规口径、字段映射、校验规则全部白纸黑字写死，变更只能等下一版制度下发。而我们用Scrum跑了一年，每个Sprint都在“响应变化”，但实际上根本没变化可以响应；每次评审会都在演示一个从未被真正验收的功能，因为真实验收标准是监管验收，而不是Product Owner点头。

更惨的是，由于迭代式交付，数据库模型被反复修改了7次，每次迁移都是一场灾难。开发团队怨声载道，测试团队疲于回归，业务方一脸茫然：“你们到底什么时候能上线？”

那一年，我们交付了0个可上线的完整功能，却消耗了整整4200人天。

我不知道你们是否也经历过类似的时刻，当所有人都告诉你敏捷是未来，你却在每个站会上怀疑人生。如果有，这篇文章或许能给你一点不孤单的感觉，以及一些我们在泥潭里摸爬滚打后沉淀下来的真实判断。

二、先给结论：你看到的“退回”，其实是团队在做一次被迫的模式纠偏

在软件开发领域，如果你敢公开说“我们退回了瀑布”，大约会收获三种反应：敏捷原教旨主义者会觉得你堕落了；咨询顾问会觉得你失败的案例可以拿去卖课；而更多一线管理者会私信你：“兄弟，你们具体怎么做的？我们也在纠结。”

我在这里要把结论说得非常直白：没有一种方法论天然优于另一种，只有适不适合你的项目基因。而“退回瀑布”这个动作，很多时候不是技术决策，是生存决策。

过去五年，我以技术合伙人或架构师身份深度参与过4个大型项目的模式切换决策，其中2个走向了纯瀑布，1个走向了严格门禁的增量迭代（某种意义上也是瀑布），只有1个成功跑通了Scrum。同时，我也以外部顾问身份诊断过超过20个所谓“敏捷失败”的团队，发现一个残酷的共性：超过70%的团队其实从一开始就不具备跑Scrum的客观条件，他们只是被“敏捷”这个词绑架了。

这不是我拍脑袋的数据。2023年，我和另外两位同行用半年时间追踪了17个中大型软件项目（团队规模均在40人以上，合同金额超过500万），回收了214份有效技术管理者问卷，发现几个让人脊背发凉的事实：

1. 在需求确定性高于80%的项目中，强行使用Scrum导致整体工期平均超出计划37%，而瀑布模式超出计划仅9%。
2. 在涉及合规审计、外部监管的项目中，瀑布模式的首次验收通过率达到83%，Scrum模式仅为41%，且后者平均需要多2.3轮整改。
3. 团队对工作模式的满意度与模式本身无关，而与“预期稳定性”强相关，当团队成员无法预知下个Sprint要做什么、什么时候算完工时，离职意愿会飙升2.1倍。

这些数字说出来很得罪人，但它们指向同一个结论：瀑布模式没有死，它只是在等待那些需要它的项目长大。而很多我们以为的敏捷失败，不过是把一辆需要铁轨的火车，硬开上了F1赛道，然后抱怨它跑不快。

三、先别急着站队，看看我们踩过的三个深坑

很多团队从敏捷“退”回瀑布，都是在反复触礁之后才被迫承认问题。但我们事后复盘发现，其实早在转型最初，坑就已经明晃晃地摆在那里了，只是当时我们选择性失明。

1. 坑一：把“需求变化”当信仰，却不看变化的来源是谁

Scrum指南里对“拥抱变化”的阐述有一个隐含前提：变化来自市场反馈或用户洞察，且变更成本可控。

但在大量B端项目、G端项目或强监管行业里，变化的来源根本不是用户，而是政策、上级单位、集团红头文件或跨系统对接方的协议变更。这些变化的特点是：不可协商、不可推迟、不可拆分、不可验证。你没办法用一个Sprint的增量去试探监管口径是否行得通，你只能全部做完、全部测完，然后提交上去等待“生或死”的裁定。

我们那个金融项目就是典型。需求源头是1104报表制度，每半年更新一次，每次更新都意味着几十张报表的字段、校验规则、报送口径全部改变。Scrum模式下，我们试图把更新拆成若干个User Story分批交付，结果是每批交付后都无法单独验证，因为监管校验是一个全量逻辑，必须44张报表全部跑通才能判断对错。于是我们陷入了一个荒诞的循环：每次Sprint Review展示的都是“假定其他部分已就绪”的半成品，而业务方无法给出任何有效反馈。

当变化的来源决定了你必须“整体交付、整体验收”时，任何增量迭代都是伪增量。这种情况下，瀑布不是保守，是诚实。

2. 坑二：把“自组织团队”当成免管理金牌，结果没人对最终结果负责

Scrum强调团队自组织，减少命令控制式管理。但在超过40人的项目里，当你把三四个Scrum团队拼在一起跑LeSS或SAFe时，跨团队依赖、接口契约、数据一致性、技术债务的跨迭代传递会迅速击穿“自组织”的浪漫想象。

我们内部做过一个统计：在一个由4个Scrum团队协同的大型项目中，Sprint内因跨团队接口变更导致的阻塞时间占总工期的22%，而这些问题在Sprint Planning时几乎从未被充分识别，因为每个团队只看自己的Backlog。PMO为了救火，不得不每周增加一场“跨团队对齐会”，结果这个会的时长从1小时膨胀到4小时，最后变成了另一种形式的瀑布式顶层设计会，既没有Scrum的灵活，也没有瀑布的严谨。

我还观察到一个更危险的信号：当“团队自组织”掩盖了架构决策缺失时，最终的技术债务会由最底层的开发人员承担。因为没有人有权力在Sprint 0做足够的前期设计，每次都是“先做出来再重构”，而重构永远排在下一个Sprint的优先级末尾，最后变成一个永远不会到来的“技术优化Sprint”。

这不是Scrum的错，是我们误以为Scrum可以替代系统架构和项目管理。但当一个团队的规模、系统复杂度、交付风险超过某个阈值时，你必须重新引入适度的事前规划和阶段性门禁，哪怕它们看起来很不“敏捷”。

3. 坑三：数据告诉我们“看得见的进度”比“响应力”更值钱

2023年我们做的那次调研里，有一个开放问题：“请描述你经历过的敏捷转型中最大的挫败感。”排名第一的答案不是“需求变更太频繁”，而是“不知道项目到底进展到了哪里”。

Scrum依赖燃尽图、速率、用户故事点来衡量进度，但这些指标在非技术背景的项目赞助人（Sponsor）眼里几乎等于天书。我见过太多次这样的场景：项目经理在月会上展示Sprint燃尽图，证明“我们按计划在消化故事点”，而甲方领导只问了一句：“所以功能A到底什么时候能上线？”，答案却是“可能在三个Sprint之后，因为还依赖B团队、C接口和一个还没评估的变更”。

这种不确定性对业务决策是致命的。业务方要做市场预热、要安排培训、要协调上下游系统切换时间表，他们需要的是一个承诺，一个时间点，一个明确的交付范围。而这些恰恰是瀑布模式最擅长提供的东西：里程碑、交付清单、签字验收。

我并不是说瀑布一定能准时交付，但当业务对确定性的渴求超过对响应速度的要求时，瀑布的缺陷（比如变更成本高）反而变成了可接受的代价。因为业务宁可接受一项高成本的变更流程，也不愿意面对一个永远无法给出承诺的开发计划。

四、五个现实因素，把我们一步一步推回了瀑布

如果前面讲的是教训，那这一节我想直接罗列让我们最终拍板的“稻草”。每一根稻草单独看也许还能扛，但五根叠在一起时，任何团队都会做出和我们一样的选择。

1. 需求冻结期长达6个月以上，且变更要走管委会审批

我们服务的客户要求：需求规格说明书签字确认后，任何变更必须提交变更控制委员会（CCB），审批周期不少于15个工作日，且变更引起的成本由乙方承担。在这种合同框架下，Scrum强调的“每个Sprint都可以调整Backlog”不但没有正面价值，反而变成了合同风险。Product Owner每调一次优先级，我们就要走一次变更流程，法务、商务、交付经理全要介入，一个Sprint的调整成本可能比开发成本还高。

所以不是我们不想响应变化，是组织形式和契约结构已经把“拥抱变化”的大门焊死了。这种情况下，一次性把需求分析做透、签署基线，然后冻结，是最经济的做法。

2. 验收标准是黑盒式的全量测试，不支持增量验收

金融系统的验收经常是：准备一整套测试用例（2000+条），在准生产环境一次性执行，然后出具测试报告。监管验收更没有商量余地。这意味着即使我们内部用Scrum完成了若干个增量，也无法把这些增量交付给客户创造价值，只能堆在代码仓库里积压。

这其实是很多B端项目的共性困境：价值交付的粒度不是由开发团队决定的，而是由客户的业务流程和验收机制决定的。当最小可交付单元大于你们一个Sprint的产出时，继续切割只是自娱自乐。

3. 团队规模突破60人，跨团队沟通成本指数级上升

我们巅峰期有6个并行Scrum团队，涉及前台、中台、后台、数据、报表、接口6个模块。虽然名义上有Scrum of Scrums机制，但实际运作中，跨团队的技术决策、接口定义、数据库变更频繁冲突，一个团队的一次重构可能导致另外两个团队当周的工作全部作废。

最终我们被迫设立了“架构委员会”，每周召开一次跨团队设计评审会，所有接口变更、表结构变更必须提前一周提交设计文档并通过评审才能开工。这个机制，你猜怎么着，其实就是瀑布模式里“概要设计-详细设计-评审-基线”的变体。当我们意识到自己正在从侧面重建瀑布时，“退回”就已经只是时间问题了。

4. 团队成员的技能结构和经验分布不支持高频角色切换

Scrum希望团队成员是T型甚至π型人才，能够跨职能协作。但在我们的团队中，有大量深耕某一领域的专家：有一位做监管报表的老师傅，只会写存储过程和SQL，不懂任何前端技术；有两位核心系统开发人员，十年经验全在COBOL上；测试团队长期依赖手工测试，自动化测试能力几乎为零。

不是我们不想培训，而是项目的交付压力根本不允许团队在Sprint内花时间去“学习成长”。结果就是每个Sprint里，符合“全栈”标准的人被反复征用，成为瓶颈，而其他人要么闲置等待，要么硬着头皮干不擅长的活，产出大量低质量代码。这种情况下，不如回归瀑布的分工模式：设计阶段由架构师主导，编码阶段由专业开发负责，测试阶段由测试团队收尾，虽然看起来“传统”，但对于目前的人员结构来说，反而是效率最高的方式。

5. 使用PingCode让我们看清了自己执行敏捷的真实水平

这一条我想客观地说一下，因为这件事确实发生在我们的决策链条里。

在挣扎期，我们采购了PingCode来加强项目管理。平心而论，PingCode对Scrum的支持是非常完整的：从Epic-Story-Task的多级需求拆分，到迭代规划、故事点估算、燃尽图、回顾会议记录，整个流程相当标准。我们原以为用上专业工具就会变好。

但用了一个季度之后，数据反而让我们冷静了下来。PingCode的Insight模块可以生成非常细致的迭代分析报告，我们拉出了过去6个Sprint的数据，发现：

• 每个Sprint的平均需求变更率（Sprint开始后新增或修改的Story比例）高达34%，但其中82%的变更并非来自外部市场反馈，而是内部需求澄清不足导致的补充和修正。
• Sprint燃尽图呈现出一种典型的“断崖式下跌”，前8天几乎平坦，最后2天垂直下降。这意味着团队实际上是在Sprint末“赶工”，而非持续交付。
• 用户故事的实际开发时长（从In Progress到Done）平均为8.3天，但其中有3.5天消耗在了“等待前置依赖就绪”，而这部分前置依赖在Sprint Planning时完全没有被识别。

这些数据让我们不得不承认：不是Scrum不行，也不是PingCode不好用，而是我们从头到尾就没跑出真正的Scrum。我们只是在用Sprint的壳，装了一个混乱的微型瀑布。既然微型瀑布如此低效，不如干脆回归大瀑布，至少各阶段的依赖关系是显式的、可以被管理的。

PingCode后来在我们的瀑布项目中也没有被闲置，而是被我们改造用来管理需求追踪矩阵和阶段审计，这一点后面我会细说。但当时那几份Insight报告，确实是压垮我们对敏捷幻想的最后一根稻草。

五、不是PingCode不够好，而是我们把它用错了地方

我知道如果这篇文章被PingCode的团队看到，可能会觉得我把工具和模式失败做了不当关联。所以我想非常明确地说：PingCode是我们在混乱期唯一还能提供数据透明度的工具，它没让我们成功，但它让我们死得明白。而在后续的瀑布模式运行中，我们继续使用PingCode，并且找到了一种让它发挥真实价值的方式。

这一段，我想讲三个PingCode给我们的真实教训，以及后来我们怎么把一款Scrum工具用在了瀑布项目里。

1. 工具的数据可视化能力，揭开了我们“伪敏捷”的伤疤

前面提到的Insight报告只是冰山一角。PingCode还有一个我们后来重度使用的功能：自定义工作流和状态流转时长统计。我们设置了一个专门追踪“Story被阻塞”的状态，然后拉出了三个月的数据，发现Top 3阻塞原因分别是：

1. 接口定义未确认，占阻塞总时长的41%
2. 第三方系统联调环境不可用，占26%
3. 需求细节待业务方澄清，占18%

这三个原因没有一个可以通过增加Sprint频率或调整站会方式来解决。它们需要的恰恰是前置的、完整的、签字画押的跨系统接口定义，以及稳定的联调环境窗口。而这正是瀑布模式下概要设计和集成测试阶段重点解决的问题。

PingCode的数据没有说谎，它诚实到让人难堪，我们所有的敏捷实践，都在绕着这些真正阻塞点打转，而从未触及核心。当我们把这些问题摆上管理层会议时，退向瀑布就成了一个水到渠成的共识，而不是某个人的独断专行。

2. 我们用PingCode搭建了“瀑布模式下的需求追踪矩阵”

退回到瀑布后，我们并没有抛弃PingCode，而是做了一次非常规的“改造”。

瀑布模式最大的痛点之一，是需求回溯和变更影响分析。一份200页的需求规格说明书，当你改了一个字段定义，如何快速知道哪些设计文档、哪些代码模块、哪些测试用例需要同步修改？传统的做法是靠Excel矩阵，维护成本极高且极易出错。

我们利用了PingCode的多级需求关联能力和自定义字段，建立了一套需求追踪体系：

• 第一级：业务需求（Epic层级，对应需求规格说明书中的功能域）
• 第二级：功能需求（Feature层级，对应每个功能模块）
• 第三级：系统需求（Story层级，但不再用于Sprint，而是用于详细设计条目）
• 每个系统需求关联对应的设计文档（Wiki组件）、代码库（通过集成）、测试用例（Testhub组件）

当某个需求变更时，我们可以在PingCode中一键查看所有受影响的下游工件，变更影响分析的时间从原来的2-3天缩短到了半天。这个实践让我们在瀑布模式下获得了类似敏捷的可追溯性，甚至比我们之前跑Scrum时需求管理做得更清晰，因为当时的需求拆分过于随意，关联关系经常断裂。

这个案例也让我想清楚了一件事：工具的价值不取决于它被设计用来支持哪种方法论，而取决于你如何用它解决真实的管理问题。

3. 如果你一定要留在敏捷阵营，PingCode能帮你守住底线

尽管我们团队最终退回了瀑布，但我必须公平地说：如果我们的项目条件稍好一些，需求变更确实来自市场、验收支持增量交付、团队具备跨职能能力，那么PingCode绝对是一个能显著降低Scrum执行难度的工具。

它至少能帮团队解决三个最头疼的问题：

• 多级需求结构化管理，避免需求散落在聊天记录和邮件里；
• 迭代进度实时可视化，让项目经理和业务方都能看懂“现在到哪了”；
• 与代码、测试、文档打通，减少跨系统切换的摩擦。

但这些的前提是，你的项目本身适合Scrum。工具可以锦上添花，但无法雪中送炭。如果你的“雪”是需求冻结、全量验收、百人团队、专业壁垒，那用什么工具都改变不了你终将退向瀑布的事实。

六、什么时候你应该退，什么时候你应该再扛一下，一套可复用的决策框架

我从不鼓励任何团队在没有充分评估的情况下贸然退回瀑布，因为退回本身也有代价：团队士气可能受损、已经建立的部分敏捷习惯可能崩塌、管理层可能从此对任何方法论创新都持怀疑态度。

所以在那次决策之后，我们内部沉淀了一套相对系统化的评估框架，在此分享出来。它未必完美，但至少帮我们在后续的其他项目中少走了很多弯路。

1. 五个必要条件，缺一个，Scrum就可能反噬你

我们设定了五个条件用来判断一个项目是否适合Scrum，如果有一条不满足，就要亮黄灯；如果两条不满足，建议考虑混合模式；如果三条及以上不满足，请认真考虑瀑布。

在我们的那个项目中，5个条件有4个亮了红灯，我们当时却硬跑了14个Sprint。现在回头看，那14个Sprint就是我们为缺乏评估框架付出的学费。

2. 四个“可以再扛一下”的信号

并不是所有困难都值得让你退回瀑布。有些痛苦是敏捷转型过程中的正常阵痛，扛过去之后的收益可能远超短期折腾。如果你遇到的是以下四种情况，我建议再给Scrum一些时间，同时辅以工具和流程微调：

• 阵痛型混乱：团队刚开始跑Scrum不到3个月，站会还开不明白，燃尽图总是断崖。这很可能是学习曲线问题，而非模式问题。建议至少跑满6个Sprint再评估。
• 需求变动确实来自真实用户，但变更频率和幅度超出预期：这说明你们的市场就是高度不确定的。此时应该优化的不是退回到瀑布，而是缩短Sprint周期、强化DoR（Definition of Ready），或者引入更轻量的用户故事地图来做全局规划。
• 进度可视化差，但交付物质量在提高：如果业务方只是抱怨“看不懂敏捷报告”，但你们实际交付的可用功能在持续变多、变好，那么问题出在沟通层面，而非模式层面，可以使用PingCode这类工具的自定义仪表板去生成业务方能理解的视图。
• 跨团队依赖混乱，但组织正在做架构治理：如果公司正在推行API First、契约测试、领域驱动设计，这些基础能力建好后，跨团队依赖问题会大幅缓解。盲目退回瀑布可能让你错失整个组织级的效率提升红利。

退不退瀑布，不能基于情绪，要基于条件评估。但有一点是肯定的：当你一直在为模式辩护，而不是用模式解决问题时，那个模式本身就已经成为问题。

七、退回去之后，我们没有变回“老派瀑布”，而是做了一些改良

很多人对瀑布模式的想象还停留在20世纪：厚重的需求文档、长达三个月的设计阶段、最后一个月才发现集成错误。但事实上，瀑布模式在几十年间也有大量演进，尤其在工程实践和风险控制方面，早已不是僵化的代名词。

我们在回归瀑布时，明确了一个原则：保留那些在敏捷期间被验证有效且与瀑布框架不冲突的做法。以下是我们实际落地的四个关键改良。

1. 在每个阶段内嵌入迭代式评审

传统瀑布最大的风险之一是“阶段末惊爆”，需求做完了才发现设计有误解，设计做完了才发现编码实现不了，编码做完了才发现测试用例跑不通。为此，我们把每个大阶段内部切成了若干个1-2周的“微迭代”，每个微迭代结束时必须进行一次小范围技术评审或原型演示。

例如在设计阶段，我们设定了四个评审节点：架构概念评审、关键接口设计评审、数据模型评审、完整设计基线评审。每一个节点都有明确的通过标准，不通过则打回修改。这实际上把Scrum的“频繁检视与调整”思想植入了瀑布框架，既保住了里程碑管理的确定性，又大幅降低了晚期发现问题的高昂返工成本。

2. 用“特性小组”替代“职能孤岛”，但保持阶段主导

我们保持了瀑布模式的阶段划分，需求、设计、编码、测试、上线，但不再像过去那样让需求分析师把文档“抛过墙”给设计师，设计师再抛给开发，开发再抛给测试。取而代之的是，每个阶段由对应的专业角色主导，但其他角色从一开始就派驻代表参与。

比如在需求阶段，开发组长和测试组长分别派驻1-2名资深人员参与梳理和评审，他们有权对需求的“可测试性”“可实现性”在现场发出质疑。这种方式让“质量左移”在瀑布框架下依然得以实现，还避免了Scrum模式下因技能不对口导致的效率损失。

3. 严格管理变更，但不关闭变更通道

退回瀑布最容易被诟病的就是“拒绝变更”。但我们不想变成那种一签字就铁板一块的团队。所以我们设计了一套分层变更管理机制：

• L1微小变更（如UI文案调整、非关键校验规则微调）：PM在周例会上通报即可，无需走CCB。
• L2中等变更（影响单个模块内部逻辑但不影响接口）：由技术负责人评估工作量，若累计工作量不超过阶段总计划的5%，可自行吸收；若超过，升级至CCB。
• L3重大变更（影响接口、数据结构、已签署基线的业务规则）：必须走正式CCB流程，并评估对总工期和成本的影响。

这个机制运行了半年后，我们发现80%以上的变更请求实际上都属于L1或L2量级，它们被高效地处理掉了，并没有成为拖延项目的障碍。而真正需要上CCB的L3变更，每次发生都确实值得全团队停下来重新评估，这与瀑布模式的“谨慎变更”精神高度一致，又不失灵活性。

4. 继续用PingCode做需求追踪和审计留痕

这一点在前面已经提过，再补充一个细节：我们对PingCode的使用，最终沉淀为一套可被第三方审计的开发过程证据链。金融监管项目要求所有需求、设计、代码、测试用例之间具备完整的追溯关系，且任何变更都必须有审批记录。PingCode的关联追踪和操作日志完美覆盖了这一需求，甚至在我们通过CMMI 3级评估时，评审员对这套电子化追溯体系给予了很高评价。

这让我后来在跟同行交流时常说一句话：“如果你以为退回了瀑布就要退回到Excel和Word，那你只是退回了上个世纪。工具和管理模式可以分开选择，用21世纪的工具跑瀑布，不比用Excel跑Scrum丢人。”

八、写给管理者：怎么把“退回瀑布”这件事说得体面，做得漂亮

很多技术管理者不敢提“退回瀑布”，不是因为技术判断不清晰，而是担心被贴上“保守”“开倒车”的标签。但根据我的经验，如果你把决策逻辑讲清楚，绝大多数团队反而会松一口气，因为他们早就被虚假的敏捷表演搞得精疲力竭。

1. 开场不要道歉，要陈述事实

错误示范：“对不起大家，我们敏捷转型可能失败了，现在需要退回瀑布。”

正确示范：“过去一年，我们一起实践了Scrum，积累了大量宝贵的过程数据。通过这些数据，我们发现当前项目的几个客观特征，需求冻结、全量验收、跨团队依赖复杂度高，使得Scrum模式在这个特定项目中无法发挥优势。因此我们决定切换为一种更匹配的模式，我会在接下来的时间里详细解释数据和决策依据。”

不要用“后退”这个词，用“模式匹配”。这不是政治正确，而是事实。你确实是在为特定项目选择最适合的方法，而不是在方法论的鄙视链上往下滑。

2. 公布数据，让团队看到你不是拍脑袋

把类似我前面提到的PingCode Insight报告、阻塞原因分析、工期偏差数据公开给核心团队。当大家看到“我们34%的Story变更源于内部澄清不足”“42%的工时消耗在等待依赖”时，不用你多说，他们自己会得出和你一致的结论。

我在那次决策会上就用了一套数据驱动的沟通方式：先投影PingCode的燃尽图趋势和阻塞分析，再列出项目实际交付绩效与同期其他瀑布项目的对比，最后才提出切换建议。整场会议下来，质疑最激烈的Product Owner都沉默了，因为他看到了自己的Backlog中有多少从未被真正验收的无效故事。

3. 明确保留哪些敏捷实践，消除“全盘否定”的恐惧

团队成员会害怕退回到命令控制式的管理模式，害怕每天写日报，害怕变成螺丝钉。所以你必须明确宣布：站会不会消失，只是形式会变；评审与回顾不会消失，只是频率会变；任务领取不会变成派工制，只是在阶段计划框架下的自主认领。

我们甚至保留了“回顾会议”这个仪式，在每个阶段的末尾进行，讨论该阶段的好、坏与改进点，并记录在PingCode的回顾板上。唯一的区别是，话题从“Sprint内的协作问题”变成了“该阶段内上下游衔接的质量问题”。团队接受度非常高，因为大家讨论的是真实存在的痛点，而不是为了符合Scrum指南而硬找话题。

4. 设立一个“再评估节点”，让退水变成可逆的

宣布决策时设定一个时间点，比如三个月后，进行一次系统性复盘。评估：项目当前的各项指标是否在改善？团队满意度是否提升？是否存在部分环节可以重新引入更轻量的迭代？

这个做法有两个好处：一是给那些仍然相信敏捷的成员一个希望，减少心理抵触；二是避免退回到瀑布后自己陷入惯性，错失未来可能出现的改进窗口。不要让退回瀑布从一个灵活的策略变成新的僵化教条。

九、你现在该做的，不是急着站队，而是对自己的项目做一次诚实的体检

这篇文章写到现在，如果你只带走一句话，我希望是：没有一个通用流程能解决所有问题，对项目最负责任的态度，是定期审视当前条件，并勇敢地选择最匹配的工作方式，哪怕它的名字听起来没那么时髦。

所以接下来我想给你一些具体可操作的行动建议，而不是停留在理念层面。

1. 现在就拉一份真实的过程数据，别靠感觉

无论你用的是什么项目管理工具，Jira、PingCode、飞书项目还是腾讯TAPD，去拉出最近3-6个月的数据。重点看四个指标：

• 需求变更率及来源分类（外部反馈 vs 内部补漏）；
• 任务实际周期分布（活跃编程时间 vs 等待时间）；
• 阻塞原因的帕累托分析（找到占80%阻塞时长的前三个原因）；
• 每个交付周期内真正被客户验收通过的功能点数（不是故事点完成数，是验收通过数）。

如果这四个指标的数据让你不舒服，那就说明你可能已经在一条错误的路上走了太久。

2. 做一次“方法论适配度评估”，带上至少三个角色一起

不要让项目经理一个人拍板。请务必拉上：一位最资深的架构师（他能判断系统复杂度）、一位最接近客户的产品负责人（他能判断需求的真实波动性）、以及一位在项目中待得足够久的开发组长（他能感知团队的日常煎熬点）。用我在第六节提供的五个条件，每人独立打分，然后对齐。如果三人中有两人给出了红灯信号，就值得启动决策讨论。

3. 如果你决定退，请至少保留三个敏捷遗产

退回到瀑布不等于全盘复古。无论你怎么改，下面三样东西请尽最大努力保留下来：

1. 频繁的小范围技术评审，它能防止百分之七十的返工灾难。
2. 可追溯的电子化工件管理，别再回到Word和邮件附件的地狱。工具可以换，范式不要丢。
3. 定期的团队回顾会议，不管叫Retro还是复盘，它是团队持续进化的唯一机制。

4. 如果你决定继续扛，请把“扛”变成“改”

并非所有团队都该退。如果你的条件评估显示Scrum前提大多成立，只是执行上出了问题，那么请停止无畏的自我消耗，立刻着手以下三件事：

• 收紧DoR（就绪定义）：没有经过PO确认、没有拆解出依赖、没有可验证验收标准的Story，绝对不允许进入Sprint。哪怕这意味着Sprint Planning时只能塞进原来一半的Story。
• 用PingCode或同类工具建立跨团队的依赖可视化看板：让每一个团队都能在Planning时看得到来自其他团队的输入需求和输出承诺，而不是靠个人关系去口头协调。
• 在Sprint Review中引入真正的外部利益相关方，哪怕只是从业务部门请一位能拍板的领导旁听20分钟。没有真实反馈的Review是团队最大的幻觉来源。

十、后话：我们都是方法论的“游牧民族”

在软件工程领域，有一个悲哀的循环：当项目失败时，我们总倾向于归咎于流程、工具或者人，却很少敢于承认，是我们的选择从一开始就错了。

瀑布模式没有被敏捷消灭，正如敏捷没有被DevOps消灭一样。它们只是退到了自己更适合的领地。那些在航天、医疗、金融、核电、航空管制领域默默运行的瀑布项目，支撑着这个世界上最不能出错的系统。那些在互联网、SaaS、移动应用领域高速迭代的Scrum团队，创造着我们这个时代最丰富的数字体验。没有谁更先进，只有谁更匹配。

作为技术管理者，我们的核心职责不是成为某种方法论的布道者，而是成为自己项目现实条件的诚实翻译官，看清它是什么，承认它需要什么，然后勇敢地去拿那个最适合的工具，哪怕它不够新潮，哪怕它曾经被我们亲手抛弃。

退回瀑布，不是失败，是一种务实的清醒。

下一步行动：如果你正在经历类似的挣扎，我建议你从以下三个动作中任选其一，在本周内完成：

1. 打开你的项目管理工具，导出最近一个季度的任务数据，用我在第九节列出的四个指标跑一次分析。
2. 约上架构师和产品负责人，花一小时用第六节的五条件框架做一次坦诚的评估。
3. 如果评估结果指向切换，不要害怕，先从小范围试点开始，比如选择一个子系统用改良瀑布模式跑一个完整周期，然后用数据去说服更大的决策圈。

无论你最终站在模式光谱的哪个位置，都比盲目跟随潮流的人，更靠近项目的真相。