教科书式瀑布开发不存在，真实项目是混搭

一、我为什么敢说“教科书式瀑布”从未存在过

2016 年，我接手过一个被董事会判定为“流程完美”的失败项目。这家公司花了 11 个月做需求调研，输出了一份 427 页的 PRD，每一页都经过三方签字确认。设计阶段又花了 4 个月，架构图精美到可以裱起来挂在会议室。然后编码阶段开始了，第 3 个月，市场变了，竞争对手上线了同类产品，价格只有我们预估成本的 60%。项目进入“硬撑模式”，又撑了 8 个月，最终交付的系统上线即闲置。我翻遍了那份 PRD，找不到任何一段关于“如果市场变了我们怎么办”的内容。

复盘会上，项目经理说了一句话让我记到现在：“我们严格执行了瀑布模型，每一个阶段都认真完成了。”我说：“你们执行的是一种宗教仪式，不是项目管理。”

那件事之后，我开始系统性地回顾自己参与过的 30 多个项目，包括后来在 PingCode 服务客户时观察到的数百个团队案例。我发现一个事实：严格遵循教科书瀑布模型的项目，一个都没有成功过。而那些被定义为成功的项目，没有一个严格遵循任何一种单一方法论。

这篇文章不是要跟你讨论“瀑布和敏捷哪个好”。这种讨论在过去二十年里已经变成了一种宗教战争，除了制造对立，没有解决任何实际问题。我要讲的是：真实世界里的项目，从来都是混搭出来的。 以及，为什么认识到这一点，比你选择哪一种方法论重要十倍。

二、“瀑布”这个词本身就是被误解的

大多数人对瀑布模型的理解来自一张流传了几十年的图：需求→设计→编码→测试→维护，箭头一条条往下指，像水流一样不可逆转。但很少有人读过 Winston Royce 1970 年那篇原始论文。

我专门去翻过原文。Royce 在那篇论文里确实画了一个线性的流程图，但他在同一篇论文里明确写道：“以这种方式实施开发是有风险的，并且会导致失败。” 他提出的是一个带有反馈循环和迭代机制的改进模型，而不是那个被后人简化的“一条路走到黑”的版本。换句话说，连瀑布模型的提出者本人，都不认同我们今天所说的“瀑布模型”。

这个误解造成了持续数十年的行业影响。一代又一代的软件工程师被教导要“先完整分析需求，再做设计”，仿佛需求是可以被提前完整认知的静态对象。但任何一个做过真实项目的人都知道，用户在看到第一版可运行软件之前，根本不知道自己要什么。 这不是用户的问题，这是人类认知的基本规律。

我在 PingCode 服务的一家金融科技企业有一个典型案例。他们在启动一个风控系统项目时，业务方提供了 89 项功能需求，全部标注为“必须”。但当我们帮助他们用用户故事地图重新梳理后，发现有 41 项需求的真实业务场景在未来 18 个月内出现的概率低于 5%。如果按瀑布方式全部开发，这个项目至少要 14 个月，而真正产生价值的核心功能只需要 4 个月就能上线验证。他们最后选择了后一种路径，4 个月后上线了核心风控引擎，6 个月后开始根据真实运行数据调整后续开发计划，原来的 89 项需求里，有 27 项被永久放弃了，因为实际数据证明了它们根本不值得做。

三、真实项目的底层逻辑：永远处于两种力量的拉扯中

做了这么多项目之后，我总结出一个观察：每一个真实项目，都同时面临两种相反的拉扯。

一边是“需要确定性”的诉求。财务部门需要预算，采购部门需要合同，管理层需要里程碑，客户需要交付承诺。这些都是刚性的，你不能跟 CFO 说“我们这个季度预算不确定因为我们在做敏捷”。

另一边是“必须应对变化”的现实。竞争对手不会等你，技术栈会更新，用户认知会变化，监管政策会调整。你也不可能跟市场说“等我们完成这个 Sprint 再变”。

这两种力量不是非此即彼的关系。它们同时存在于每一个项目中，项目管理者的真实工作，是在这两股力量之间动态寻找平衡，而不是选择站队。

这个结论不是理论推演出来的，是我在复盘几十个项目后提炼的规律。某家大型保险公司的理赔系统改造项目让我印象特别深刻。他们的理赔计算规则是极其确定的，保监会备案的条款，一个字不能改。这部分需求天然适合瀑布式的完整分析和严格冻结。但是，理赔员使用的移动端操作界面、客户端的报案引导流程、数据看板的呈现方式，这些是高频变化、高度依赖用户反馈的部分，天然适合迭代式交付。同一个项目，同一个团队，他们在核心计算模块采用严格的阶段门控，在交互层采用两周迭代。这个项目按时上线，至今还在稳定运行。如果强行要求整个项目遵循同一种方法论，要么核心模块质量失控，要么交互层迟迟无法交付。

四、当我们在说“混搭”时，到底在说什么

1. 时间维度上的混搭

最常见的混搭发生在一个项目的不同阶段。我和 PingCode 的多个企业客户交流时发现，很多团队都在不自觉地做这件事，但因为缺少明确的理论框架，他们往往不敢承认自己在“混搭”，怕被批评为方法论不纯。

实际的做法通常是这样：项目的前 15%-20%，采用接近瀑布的方式。 这个阶段的核心任务是理清业务边界、识别核心风险、建立架构基线。你不需要在这个阶段输出 400 页文档，但你必须有明确的“什么能做、什么不能做、什么先做、什么后做”的判断。这个判断一旦做出，就和团队达成了一份契约，不是冻结需求，而是冻结优先级框架。

项目的中间 50%-60%，采用接近迭代的方式。 以 2-4 周为一个交付节奏，每一个迭代产出可演示、可测试的功能增量。在这个阶段，变化是被欢迎的，但所有的变化都必须回到第一阶段建立的优先级框架中去排队，你不能在迭代中随意塞入影响架构基线的变更，你要塞的是同一个优先级区间内、不影响核心约束的调整。

项目的最后 20%-25%，又回到了接近瀑布的方式。 联调、全量回归、性能压测、安全审计、上线演练，这些活动天然需要冻结范围和严格的阶段控制。你不能在压测前一天还在改代码，但这就是很多“纯敏捷”团队实际在做的事。

2. 模块维度上的混搭

更精细的混搭发生在同一个项目的不同模块之间。我在 PingCode 接触的一个工业物联网平台项目就是典型例子。这个项目需要同时交付三个子系统：设备数据采集层、数据存储与计算层、业务应用与可视化层。

设备数据采集层需要和几十种工业协议打交道，接口规范是行业标准，变更成本极高。团队对这一层采用了严格的预设计和阶段评审，你先要证明你的协议解析方案能覆盖所有目标设备类型，才能进入编码阶段。这本质上是瀑布思维。

数据存储与计算层有一定灵活性，但核心的数据模型不能频繁变更，否则下游全部受影响。团队采用了“架构先行、算法迭代”的方式，数据模型用瀑布，计算逻辑用迭代。数据模型提前设计并冻结，但具体的异常检测算法、预测模型可以每个迭代优化。

业务应用与可视化层则是完全的迭代模式。业务用户每周都能看到新的看板和报表，随时提修改意见，团队快速响应。

三个子系统，三种方法论的配比，同时推进，同一天上线。那个技术总监后来跟我说了一句话：“要是逼我用一种方法论管三个子系统，我至少会搞砸其中两个。”

3. 角色维度上的混搭

还有一种容易被忽视的混搭发生在不同角色之间。项目经理需要里程碑和甘特图来向上汇报，开发团队需要看板和每日站会来协同工作，测试团队需要冻结版本才能完成回归。这不是“流程混乱”，这就是真实组织的运作方式。

我见过最务实的做法是：PM 层面用里程碑图管理关键交付节点（瀑布式），研发团队内部用迭代看板管理每日任务（敏捷式），对外给客户的承诺基于里程碑，内部对变化的响应基于迭代。两层之间的信息通过周例会和风险预警机制打通。这套做法没有任何方法论专家会推荐，但在实际项目中极其有效。

五、最常见的“混搭失败”模式

既然混搭是必然的，为什么很多团队的混搭仍然失败？我从 PingCode 服务过的客户案例中归纳出了四种典型失败模式。

1. 名义敏捷、实质混乱

这是最常见的一种。团队宣称在做 Scrum，取消了所有文档、取消了需求评审、取消了设计评审、取消了测试用例。他们把“拥抱变化”理解为“不用提前想清楚”。结果就是每一个 Sprint 都在往不同的方向冲，代码质量持续下降，没有人知道系统现在的完整状态是什么。

这根本不是混搭，这是把方法论当成了不做工程管理的借口。

混搭的前提是你两种方法论的优点都想要。你想要瀑布的架构前瞻性和风险可控性，也想要敏捷的响应速度和反馈频率。结果你把两种方法论的优点都丢了，既没有架构前瞻性（因为没人做设计），也没有响应速度（因为代码已经乱到改不动）。

2. 分层错位

有些团队确实意识到了要分层混搭，但分错了层。他们把需要稳定的东西放在迭代层，把需要变化的放在冻结层。

我诊断过的一个项目在这方面堪称典型。他们把用户权限模型放在了两周迭代里，结果是每一次新迭代都可能改变权限逻辑，下游的所有业务模块都要跟着改，整个系统一直处于不稳定状态。与此同时，他们把前端 UI 组件的颜色和布局设计冻结了 6 个月，理由是“要保持品牌一致性”，结果用户在可用性测试中反复反馈的问题一直得不到解决。

应该冻结的是影响面大、变更成本高的核心抽象；应该迭代的是影响面小、需要快速验证的用户体验。 把这句话反过来做，就是灾难。

3. 缺乏明确的切换规则

混搭模式最大的风险不在于“什么时候该用什么”，而在于“什么时候不该用什么”。很多团队在项目早期确定了“架构用瀑布、业务用迭代”的大原则，但从来没有约定过：当迭代中发现的问题触及架构层，怎么处理？

问题发生时的典型场景是：一个开发在迭代中发现自己需要改一个核心数据模型才能完成用户故事。如果他能直接改，架构冻结就是一句空话。如果他不能改，用户故事就完不成。这时候没有规则，只有扯皮。

解决这个问题需要一个清晰的升级和决策机制。我在帮助团队制定这种规则时通常会明确三个问题：

• 谁有权力提出架构变更请求？（建议：技术负责人或架构师，而非任意开发）
• 变更请求的评估标准是什么？（建议：影响范围、变更成本、不改变的代价、是否有替代方案）
• 审批的时效是多长？（建议：不超过 48 小时，否则迭代节奏会被打乱）

这三个问题看似简单，但在实际项目中能解决 80% 以上的架构层冲突。

4. 度量体系混乱

这是混搭模式更深层的问题。当你同时使用瀑布和迭代两种方式时，你用什么指标来衡量项目健康度？

纯瀑布项目用里程碑达成率和需求偏差率。纯敏捷项目用速率和燃尽图。混搭项目如果同时使用这两套指标，会得到矛盾的信息。比如，你的迭代速率非常稳定，Sprint 目标每次都达成，但里程碑严重滞后，这说明你在高效地开发错误的东西。又比如，你的里程碑全部按时达成，但每个迭代的速率持续下降，这说明团队在透支质量和士气来追赶节点。

我建议的度量体系是三层的：

• 战略层：里程碑达成率和关键风险缓解率，回答“我们走在正确的路上吗”
• 交付层：迭代速率和需求吞吐量，回答“我们走得快不快”
• 质量层：线上缺陷密度和技术债务指数，回答“这条路会不会越走越难”

三层指标任何一个出现异常，都需要触发管理干预。不是某一层出问题就在那一层解决，而是三层要联动分析。

六、PingCode 客户的真实混搭实践模式

我观察了 PingCode 平台上多个百人以上规模的企业研发团队，提炼出了三种在实践中被反复验证有效的混搭模式。这些不是我发明的，是我从客户的实际操作中总结出来的。

1. “稳态-敏态”双速模式

这个模式在国内金融和运营商行业尤其常见。一家 PingCode 服务的头部券商的研发中心，将其业务系统明确划分为两大类：

稳态业务：交易核心、清算系统、账户系统。这部分的需求来源于监管规则和交易所接口规范，变更周期以季度甚至年为单位。团队采用完整的阶段规划，需求文档、设计文档、测试用例一应俱全，变更是例外而非常态。

敏态业务：行情展示、智能投顾、用户运营工具。这部分需求来源于市场变化和用户反馈，变更周期以周为单位。团队采用 Scrum，两周一个迭代，以用户故事为工作单元。

关键点在于：这两类业务共享底层数据和服务。稳态团队为敏态团队提供稳定的 API 和数据服务，敏态团队在这些服务之上快速试错。稳态团队的任何变更都需要提前通知敏态团队，敏态团队发现的底层服务问题通过正式渠道反馈给稳态团队。这不是两个独立运转的系统，而是同一个生态中不同节奏的共生体。

这家券商用这种模式，在 2023 年同时完成了交易系统的架构升级和两个面向客户的创新产品上线，如果强行用一种方法论管理，这是不可能的。

2. “硬壳软芯”架构驱动模式

另一种常见的混搭模式是围绕技术架构本身设计的。我在 PingCode 协助的一家工业软件公司采取了这种策略。

他们的产品有一个非常稳定的内核，工业数据的采集、清洗、存储引擎。这部分代码的变更会影响所有上层应用，而且对性能和可靠性要求极高。团队对内核采用了极度严格的管理方式：每一个内核改动都需要经过架构委员会评审，每一个发布都需要全量回归测试，每一个 API 的变更都需要提前两个迭代周期公告。

但内核之外的应用层，包括数据分析工具、可视化组件、行业解决方案模板，全部采用快速迭代模式。每个行业解决方案团队可以根据客户反馈在两周内完成一个特性的开发和上线，只要他们不触碰内核的接口约定。

这种模式的核心隐喻是：内核像一座城市的地铁系统，一旦建成就不能轻易改动，延伸和调整需要周密规划。应用层像地面上的店铺和活动，可以频繁变化、快速试错。 城市不会因为开了新餐厅就改动地铁线路，地铁线路的调整也不会影响本季度的餐厅菜单。

这种模式要求技术架构天然支持这种隔离。如果你的代码是一个大泥球，内核和应用层耦合在一起，这个模式就不适用。但如果你已经有了清晰的分层架构，这是最高效的混搭方式。

3. “瀑布问路、敏捷赶路”阶段切换模式

这是最适合不确定性较高的创新项目的混搭方式。一家 PingCode 服务的医疗科技公司在启动一个 AI 辅助诊断项目时采用了这种方法。

项目的前四周，他们没有写一行代码。他们用这四周时间完成了需求澄清、技术可行性验证、数据可用性评估、关键架构决策和风险清单梳理。这四周的工作方式完全是瀑布式的，输出物、评审会、签字确认、阶段门控。我问他们的技术负责人为什么这么做，他说：“如果你不知道前面的路有没有悬崖，你不能先跑起来再说。”

四周之后，他们进入了快速迭代模式。每两周一个 Sprint，每个 Sprint 产出可演示的模型增量，定期邀请医生来试用和反馈。这个阶段持续了五个月，方向调整了三次，但每一次调整都在四周探索阶段确定的安全边界内。

上线前最后三周，他们又切换回了瀑布式的质量保障流程：冻结功能、全量回归、性能基准测试、安全审计、上线演练。技术负责人对此的解释是：“上线不是迭代，上线是一个不可逆的事件。你只有一次机会做对。”

这个项目后来成了他们公司的标杆。我复盘时注意到，整个项目的周期分配大致是：10% 瀑布式探索 + 75% 敏捷式构建 + 15% 瀑布式收尾。 没有任何方法论教科书提到过这个比例，但在这个具体场景下，它就是最优解。

七、混搭不是随意组合，是基于约束的设计决策

说了这么多案例，我需要明确一个立场：混搭不是“什么好用就用什么”的实用主义口号，而是一种需要严格纪律的工程决策。

每一次方法论的混合，都应该基于对具体约束条件的分析。我在评估一个项目应该采用怎样的混搭配方时，通常会回答以下四个问题：

1. 需求的不确定性有多高？

这不是一个主观感受问题，而是可以量化的问题。我会让团队回答：

• 有没有已经上线的竞品可以参考？（有参考，不确定性降低）
• 目标用户是否有明确的使用场景和痛点？（有，不确定性降低）
• 业务规则是否依赖外部因素如监管政策？（依赖，不确定性升高）
• 技术方案是否涉及团队未曾使用过的新技术栈？（涉及，不确定性升高）

这四个问题的答案会决定你应该分配多少“瀑布预算”给前期探索，以及多少“敏捷预算”给中期迭代。不确定性越高的项目，前期瀑布式探索的比例越大，不是不做敏捷，而是你需要更多的时间先搞清楚方向再开始跑。

2. 变更的爆炸半径有多大？

这是决定模块层面混搭策略的核心问题。你需要评估系统的各个模块中，哪些模块的变更会引发大范围的连锁反应，哪些模块的变更影响是局部的。

一个实用的评估方式：画出模块依赖图，数一下每个模块被多少个其他模块直接或间接依赖。 被依赖越多的模块，变更成本越高，就越适合用瀑布式的冻结和管理。被依赖越少的模块，变更成本越低，就越适合敏捷式快速迭代。

我见过的最好的实践是，团队在一个大型项目中把所有模块按照“变更爆炸半径”分为三个等级：

• 核心层：被 20+ 模块依赖，变更需架构委员会审批，冻结周期按季度
• 中间层：被 5-19 个模块依赖，变更需技术负责人审批，冻结周期按迭代
• 边缘层：被 0-4 个模块依赖，团队自主决定，无冻结要求

这种基于依赖关系的分层策略，比任何基于直觉的“这个重要那个不重要”的判断要可靠得多。

3. 团队的认知负载是否已经过载？

这是混搭策略最容易忽略的一个维度。不同的方法论对团队有不同的认知要求。一个同时在用甘特图管理里程碑、用看板管理每日任务、用燃尽图追踪迭代进度、用缺陷密度度量质量的团队，其认知负载远高于单一方法论的团队。

我有一条经验法则：如果团队成员需要同时关注超过三种不同的管理视图，认知负载就已经过载了。 这时候要么简化工具，要么把角色分开，让 PM 管里程碑，让 Scrum Master 管迭代，让 Tech Lead 管质量，而不是要求每个人关心所有维度。

在一家 PingCode 客户那里，我建议他们把项目管理工具的使用做了角色拆分：

• 项目经理和产品负责人使用甘特图和里程碑视图做对外承诺和向上汇报
• 开发团队只使用迭代看板，他们看到的工作项来自甘特图的分解，但他们不需要关心甘特图本身
• 测试团队使用测试计划和质量仪表盘，他们关心的是版本质量，不关心迭代速率

拆分之后，每个角色只需要关注和自身工作最相关的 1-2 个视图，认知负载大幅降低，团队的满意度显著提升。

4. 合同的付款条款怎么写？

当我问到这个问题时，很多技术团队会愣住。但在中国企业级市场，合同结构直接决定了项目管理模式的可行性。

如果合同是按里程碑付款的，比如需求确认后付 30%、系统上线后付 40%、验收后付 30%，那你就不能指望客户接受“需求可以在迭代中持续调整”。客户会问：“需求确认的时候你已经收了我 30% 的钱，现在告诉我需求要变？”

这不是客户不专业，这是商业契约的基础逻辑。在这种合同结构下，你能做的混搭是很有限的。你可以把每个里程碑内部的执行方式改为迭代式，但里程碑本身的定义和交付物必须保持清晰和稳定。

反过来，如果合同是按人天或按迭代付费的，你就有了更多灵活调整的空间。但你需要额外注意另一种风险，客户可能会觉得“既然可以随时调整，我为什么要为前面的错误决策买单”。

我的建议是：项目启动之前，就和商务、法务一起梳理合同结构对方法论的约束。 很多技术团队从来不关心合同内容，等到发现合同和实际工作方式冲突时，矛盾已经不可调和了。

八、你的项目应该怎么做？一份可操作的混搭决策指南

我不打算给你一个“万能配方”，因为并不存在。但我可以给你一套决策流程，帮助你为自己的项目找到合适的混搭策略。

1. 第一步：画出项目的“确定性剖面”

在项目启动的第一周，把计划中的需求或特性按确定性高低排列在一张图上。确定性的判断标准是：

• 高确定性：有明确的法规、标准或合同依据，或者已有成熟的参考实现
• 中确定性：团队有类似经验，但具体细节需要在执行中明确
• 低确定性：团队缺乏经验，或者依赖尚未验证的假设

这张图就是你的“混搭基础地图”。高确定性区域适合采用瀑布式的预设计和冻结，低确定性区域适合采用迭代式探索和验证。

2. 第二步：识别不可逆决策

不是所有决策都是平等的。有些决策一旦做出就很难回头，技术栈选择、核心数据模型设计、对外 API 契约、安全架构模式。这些决策需要瀑布式的分析深度和审批流程。

有些决策的逆转成本很低，页面布局、菜单结构、报表样式、默认参数值。这些决策可以在迭代中快速验证和调整。

把不可逆决策和可逆决策分开管理，是混搭策略最关键的第一步。

3. 第三步：设定混搭边界和切换规则

这是最容易被跳过的步骤，也是混搭失败最常见的原因。你需要明确：

• 边界定义：哪些模块属于“稳定区”，哪些属于“迭代区”？边界在哪里？
• 边界管理：迭代区的变更如果触及稳定区，怎么处理？（建议：建立正式的变更请求通道）
• 切换条件：什么情况下项目需要从迭代模式切换回瀑布模式？（建议：当连续三个迭代出现速率下降或缺陷率上升时）
• 争议仲裁：当团队对方法论选择有分歧时，谁来拍板？拍板的依据是什么？

把这四条写下来，不需要很长，一页纸就够了。但必须白纸黑字，全员知晓。没有书面约定的混搭，最终一定会变成混乱。

4. 第四步：选择合适的工具链

混搭对工具链的要求其实比单一方法论更高。你需要一个能同时支持多种管理视图的平台，而且这些视图之间的数据要打通。如果用三四个工具拼凑，信息孤岛会让混搭模式很快崩溃。

我在 PingCode 平台上看到的一个有效实践是：

• 用史诗和特性做高层级的路标规划（瀑布式里程碑管理）
• 用用户故事和任务做迭代级的工作拆解（敏捷式 Sprint 管理）
• 用测试用例和缺陷做版本级的质量门控（瀑布式质量保障）
• 三者之间通过需求关联和状态同步保持数据一致性

工具本身不能替你选择方法论，但不合适的工具会让你已经选好的方法论无法落地。

5. 第五步：每月做一次“方法论审计”

这是我个人在实践中总结出来最有价值的一个习惯。每个月花一小时，和团队一起回答以下问题：

• 这个月我们实际的工作方式，和我们计划的方法论有多大偏差？
• 这些偏差是有益的适应，还是无意的偏离？
• 有没有什么模块被我们过度管理了？（瀑布式管理用在低风险模块）
• 有没有什么模块被我们管理不足了？（敏捷式管理用在高风险模块）
• 下个月我们需要调整什么？

方法论审计的目的不是检查“我们有没有严格遵守某种方法论”，而是检查“我们当前的方法论选择是否仍然适合项目的实际情况”。 项目是动态的，方法论也应该是动态的。用固定的方法论管理变化的项目，和用固定需求管理变化的市场一样荒谬。

九、总结：一个成熟的团队应该具备的素养

写到这里，我想回到最开始那个 427 页 PRD 的失败项目。多年以后我重新审视那个项目，我发现问题的根源不在于瀑布模型本身，而在于一种思维惯性：我们把遵循方法论当成了目标，而忘记了方法论只是达成目标的手段。

一个成熟的工程团队，最重要的素养不是精通某一种方法论，而是具备以下三种能力：

第一，能够准确诊断当前项目面临的核心约束。 不确定性在哪个层面？最大风险是什么？哪些决策不可逆？哪些假设需要快速验证？回答不了这些问题，任何方法论都是盲目的。

第二，能够基于诊断结果选择合适的方法组合。 不是“我们用的是 Scrum”或“我们是瀑布团队”，而是“在这个项目的这个阶段，面对这个具体的挑战，我们选择这样做”。

第三，能够在执行过程中持续审视和调整。 项目在变化，团队在成长，市场在演变。上个月有效的配方，下个月可能就失效了。保持敏锐，保持谦逊，保持调整的勇气。

这三点比你会开站会、会画燃尽图、会写用户故事重要一百倍。工具和仪式是表面，诊断和决策能力才是内核。

教科书里的瀑布开发从来不存在，未来也不会存在。 真实世界的工程项目，从第一块砖落地的那一刻起，就在不断地根据现场情况调整施工方案。没有建筑师会因为工地和图纸不完全一致而惊慌，也没有总包会因为用了两种不同的浇筑方法而觉得自己“方法论不纯”。软件工程和建筑工程在这个层面上没有本质区别，真正的专业性，体现在你如何应对现实和理论之间的张力，而不在于你背诵了多少条方法论教条。

十、下一步你应该做什么

如果你读到了这里，我建议你下周就做三件事：

第一件，开一次“方法论审计”会议。 不管你们现在声称在用 Scrum、Kanban 还是瀑布，花一个小时，诚实地列出你们实际的工作方式和声称的方法论之间的差距。不需要评审任何人，只需要看清现实。

第二件，画出你们当前项目的“确定性剖面”。 把正在做的需求按确定性排列，标出哪些是真正确定的需求，哪些本质上只是假设。然后检查一下，你们有没有给假设分配了过多的前期分析时间，或者给确定性需求分配了过少的预设计时间。

第三件，找出你们项目中变更成本最高的三个模块。 检查它们目前的管理方式，是不是和它们的变更成本匹配。高风险模块有没有足够严格的变更控制？低风险模块是不是被过度管控了？

这三件事做下来，你很可能就会发现一些“原来我们一直在用错误的方式管理正确的事情”的瞬间。不需要立刻全面变革，先从最明显的问题开始调整，下一次迭代就见效。积累几次成功的微调，团队对方法论的焦虑就会转化为对方法的信心。

这才是真正的工程素养。不管工具怎么变，概念怎么换，看清约束、做出选择、持续调整的能力永远不会过时。