瀑布开发不是老古董，是方法论

一、为什么我们总在争论一种“错误的分手”

2017年冬天，我带团队接了一个政府政务系统的二期改造项目。合同很死：总预算卡在470万，交付日期精确到日历天，变更流程长到可以把一个简单的字段调整拖成两周的公文流转。团队里两个刚从互联网大厂跳来的工程师看完成需求规格说明书，当场就说：“这项目用瀑布来管，不是找死吗？都什么年代了还写几百页的《软件需求规格说明书》，咱们直接建个Backlog，每两周一个Sprint，干起来再说。”

我没有反驳，只是请他们把合同里的违约金条款再读了一遍，又把甲方信息中心去年驳回变更申请的邮件翻出来。第二天，我们在会议室白板上画了一条从左到右的长箭头，清清楚楚写了六个阶段：需求、设计、编码、测试、部署、维护。我说：“这次的项目，用这条线来管。不是因为我不知道敏捷好，而是因为这列火车没有临时停靠站。”

项目最终按期上线，验收签字那天，甲方技术负责人说了一句话：“你们是我见过最规矩的乙方，连设计变更的影响都能提前在文档里标出来。”那两个工程师也来找我，说这跟他们过去听说的瀑布完全不一样，“原来瀑布不是压死人的文档，是大家真的把事情想清楚了再动手”。

这件事让我彻底明白：方法论的争论，大多数时候都不是在讨论方法论本身，而是在讨论自己过去的创伤。一个人被“假瀑布”折磨过，就觉得瀑布等于僵化；一个人被“假敏捷”坑过，就觉得敏捷等于无序。而真正经历过复杂交付的人都会告诉你，瀑布开发不是老古董，它是解决特定问题的精密工具，甚至是一种被严重低估的工程哲学。

二、核心结论：没有过时的方法，只有错配的场景

在软件工程界，我们长久以来犯了一个低级错误：把方法论的选择变成了信仰之争。好像选择了Scrum，就要烧掉所有的甘特图；选择了Waterfall，就要把用户故事卡扔进垃圾桶。这种做法，就像要求一个建筑师要么只用锤子，要么只用锯子，荒谬至极。

瀑布模型（Waterfall Model）在1970年被温斯顿·罗伊斯（Winston Royce）正式提出时，那篇论文的标题其实叫《管理大型软件系统开发》。注意“大型”两个字。罗伊斯从一开始就强调，当一个系统的规模和复杂度超出某个阈值，前置的设计和文档就不是冗余，而是生存必需品。只是后来无数中小型项目滥用瀑布，把它搞成了臃肿的官僚流程，最终让瀑布背上了“老古董”的黑锅。

我在这里想给出的核心结论只有三句话：

1. 瀑布最适合需求确定性高、变更成本极高的项目。不是因为它“死板”，而是因为它把风险控制前置到最便宜的阶段，纸面上的设计。
2. 敏捷最适合需求模糊、价值验证优先的项目。因为它能通过快速交付学习，哪怕扔掉半成品，沉没成本也极低。
3. 绝大多数优秀的技术组织，都在运行一种“披着敏捷外衣的瀑布”或者“带有迭代思想的瀑布”。真正纯粹的任何一种，都只存在于咨询公司的PPT里。

所以我今天写这篇文章，不是为了给瀑布翻案，更不是要贬低敏捷，我自己带的好几个产品团队至今仍然在使用Scrum框架。我想做的是，把这两种方法论从“宗教战争”里捞出来，重新放回“工具箱”里，让你在下一个项目启动会上，能根据事实和逻辑而不是焦虑和偏见，做出扎扎实实的决策。

三、两种“基因”：还原论与涌现论的工程分野

要理解为什么瀑布在某些场景下非但不过时、反而更高效，我们必须回到方法论的底层哲学。这不是掉书袋，而是真正能帮你判断“这次到底该用什么”的思考框架。

1. 瀑布的背后是“还原论”

还原论认为，一个复杂系统可以被拆解成若干相互独立的组成部分，只要把每个部分做到正确，组合起来的系统就是正确的。你家的房子就是这么盖的：先打地基，再建立柱，再做外墙，不可能今天客厅改位置、明天卫生间换楼层。这种方法的隐含假设是：我们可以在项目初期，以足够低的成本，把所有需求弄清楚并固化下来。

基于这个假设，瀑布把项目切成几个顺序阶段，每个阶段的输出是下一阶段的输入。需求分析做完才做概要设计，概要设计做完才做详细设计。表面上看这太僵硬了，但你如果做过大型银行核心账务系统的替换，你就会知道：当涉及的资金清算规则跨越几十年沉淀下来的成百上千条业务规则时，你在第一行代码写出之前，必须用文档把所有这些规则之间的关系梳理清楚。任何设计上的遗漏，到了测试阶段可能就是几百万的清算差异。这种成本，没有任何一个敏捷迭代能兜得住。

2. 敏捷的背后是“涌现论”

涌现论的逻辑正好相反：它相信复杂系统的正确形态不可能事先设计出来，只能在持续运行、持续反馈中“涌现”。就像交通路网的形成，没有任何一个规划师能在一百年前画出今天的所有路线，但通过无数司机的即时选择、信号灯的反馈调节，一个高效的路网自然浮现了。

所以敏捷不做长达几个月的需求分析，而是直接做一个最小的可用版本扔给用户看，用户说“不对”，马上改。这在一款面向C端消费者的社交软件上非常有效：你根本猜不到用户会几点刷视频、喜欢什么滤镜，快速试错就是唯一正确的做法。

这两种哲学没有高下之分，只是适用的系统特性不同。当一个系统的状态空间是有限的、规则是已知的，还原论效率最高；当一个系统的状态空间是开放的、规则由用户的行为共同创造，涌现论是唯一出路。这就是为什么我们不能用“潮流”来选方法论，而要像选手术刀还是止血钳一样，看“病灶”在哪里。

四、三个最常见的误区，让瀑布背负了不该背的骂名

在多年的咨询和工作经历中，我观察到很多团队对瀑布的抵触，来自于他们经历过糟糕的“伪瀑布”，而不是真正的工程化管理。这里我拆解三个最典型的误区。

1. 把“瀑布”等同于“没日没夜写文档”

2008年前后，国内很多软件公司过CMMI 3级，当时的做法极其粗暴：需求规格说明书要求150页以上，概要设计100页，详细设计恨不得把每一行伪代码都写出来。结果文档成了目的，软件反而成了副产品。这不是瀑布的错，而是管理僵化把手段当成了目的。

真正的瀑布强调的文档，是用来沟通和存档的“最小必要信息集合”。比如，接口文档必须写明字段类型、长度、是否必填、异常返回码，这些是无论用什么方法论都逃不掉的；但对于用户界面的风格描述，瀑布文档里只需要写出约束条件（如“色系与现有政务平台保持一致”），而不需要像美工稿一样精确到像素，那个留给原型图就够了。

2. 认为瀑布“不允许任何变更”

这是流传最广的误解。罗伊斯在1970年的原版论文里，就明确指出在测试阶段发现问题，应当回溯到设计甚至需求阶段进行修改。换句话说，瀑布本身就带着“反馈回路”。只是那个回路的时间尺度比较长，可能是“阶段门”审核，而不是每天站会。

在实际操作中，成熟的瀑布项目管理会预留“变更控制流程”，我们把它叫作CCB（变更控制委员会）。任何一个变更都要评估：影响范围多大？增加多少成本？合同是否允许？在银行、核电、航天等系统中，这种流程不但不是累赘，反而是生存必需。你不能因为看到用户说“这个按钮换成红色更好看”就临时改，因为你可能没意识到这个按钮的颜色关联着某种合规审计规则。不是不能变，而是变之前必须看得见代价。

3. 误以为瀑布项目管理不需要沟通

很多人把瀑布想象成：需求分析师把几百页文档扔给设计师，设计师画完UML扔给程序员，程序员写完扔给测试，全程不说话。这如果叫瀑布，那叫灾难。真实的瀑布项目，多阶段之间有非常密集的评审会、技术交底会、接口对齐会。只是这些沟通大多前置在需求阶段和设计阶段完成，进入编码阶段后沟通频率开始降低，但遇到设计未覆盖的问题时仍需立即升级。

相比之下，敏捷的沟通分布更均匀，每天都有站会，每个Sprint有回顾和评审。两种沟通策略不存在谁更多、谁更少的问题，只存在“沟通发生在什么时间点”的问题。

五、一个被忽视的决策框架：信息密度与反馈周期

做了这么多年项目，我逐渐提炼出两个指标，用来判断一个项目到底适合瀑布还是敏捷，比任何教科书里的“需求稳定不稳定”都更本质。

1. 信息密度

信息密度是指：为了保证团队成员在各自工作中不互相伤害，需要共享的知识量和精细度。比如开发一个开放API，你需要传递的信息可能包括鉴权方式、QPS限制、字段约束、错误码体系、幂等性要求，这些都很具体，必须准确，写错了就可能被调用方循环攻击。这种情况下，信息密度极高，而文档天然就是高密度信息的最佳载体。你不可能希望这些信息通过口头传递，两轮就失真了。

反过来，开发一个内容推荐流排序算法，早期你需要共享的信息可能仅仅是：我们希望在点击率和停留时长之间寻求平衡，采用多目标强化学习方案先试一下。这些信息密度低，一句话就能对齐，完全没必要费劲写设计文档。

所以结论很直接：信息密度越高的模块，越需要瀑布式的文档和签名确认流程；信息密度越低、越依赖个人经验和直觉的部分，越适合敏捷白板加即时沟通。

2. 反馈周期

反馈周期是指：你做一个决策，多久之后能知道它是对是错，以及修改这个决策的成本有多大。如果你写一行Python脚本，运行出错，一秒钟内就能看到报错并改正，反馈周期极短，适合敏捷。如果你设计一块电路板，投板、生产、贴片，拿到实物要六周，当你发现某个引脚信号有干扰时，修改一次再投又要六周，反馈周期长达三个月。这种情况，你必须在第一次投板前，把所有能模拟仿真的工作做到极致。这就是瀑布。

过去很多团队在敏捷转型时摔跟头，不是因为不会开stand-up meeting，而是因为他们手上的项目，反馈周期根本就不适合两周一个Sprint。比如要对接医保结算引擎的项目，需求来自于一年更新一次的国家医保目录，你迭代给谁看？用户说“这个药品报销比例不对”，你能两周内改吗？必须等政策确认。这时候，老老实实把瀑布走完，把版本锁定，等下次政策更新窗口再统一变更，才最合理。

六、我在 PingCode 中看到的一种“混合式生存样本”

说到工具，我曾经很怀疑国内的工具平台能否同时承载两种截然不同的管理哲学，直到2022年我在一次交流中深度体验了 PingCode 的项目管理模块，才意识到一些新的可能。虽然那段时间我带的是偏互联网的产品团队，但 PingCode 恰恰是用在多家百人以上中大型企业的真实场景里的，这些企业的项目复杂度和交付压力，远比创业公司难缠。

以我跟踪的一家金融科技公司为例，他们使用 PingCode 的时候，并行跑着两套逻辑完全不同的项目：核心支付路由的底层改造（需求固定、接口协议预定义、强审计要求），以及面向商户的SaaS后台运营工具迭代（需求变化快、每周发布）。如果强迫他们二选一，要么核心改造延期出合规风险，要么运营工具慢成蜗牛丢失市场。他们的做法非常朴实：在 PingCode 里为两类项目创建了不同的项目模板和字段规则。

1. 支付路由项目的瀑布式配置

他们新建项目时选择了类似瀑布的模板，工作项类型不再是 Epic、Story、Task，而是直接映射为需求规格、技术方案、接口开发、集成测试、验收报告。里程碑与甘特图功能被重度使用，每条需求前置关联了评审记录，重要节点需要三位以上责任人电子签名确认。变更请求会触发一个自定义流程，自动拉入法务和合规审核人。

这件事用 PingCode 做，和当年我们用 Excel 加邮件审批最大的不同是：变更链路和决策上下文全都在一个系统里留痕，而不是散落在不同人的聊天记录里。对于审计要求高的项目，这种“瀑布的工具化”简直是救命稻草。

2. SaaS 后台的敏捷配置

同一个团队里的另一个小组，用 PingCode 的 Scrum 项目模板，跑着标准的 Sprint 计划会议。需求池用 Epic 做长期规划，Product Backlog 按价值排序，每个 Sprint 从任务看板拖拽。连站立会议都是直接投屏 PingCode 的任务墙，谁没更新、哪个任务阻塞了，一眼看到底。

最让我印象深刻的是，这两个项目在 PingCode 的全局视野下数据是打通的，管理层可以在一个仪表盘上看到支付路由的里程碑偏差和 SaaS 后台的 Sprint 燃尽图。这也就是说，你不需要因为用了瀑布而退回到石器时代的管理方式，也不需要因为走了敏捷就放弃对合规和里程碑的管控。工具最终服务于你的方法论决策，而不是反过来被工具框死。

七、给技术管理者的行动建议：像选乐高组件一样选管理单元

读到这里你可能会说：“道理我懂了，但明天公司开项目启动会，我到底怎么办？”我在这里给出四步具体可操作的建议，以及每一步中的判断话术。

1. 在项目正式开始前，花一小时做“确定性体检”

在办公室拉上产品负责人（PO）、技术负责人和业务方代表，用下面这个表格打分。不要争，每个人凭经验打，取平均数。

得分超过20分：请果断偏向瀑布或“阶段门”瀑布变体。得分低于10分：敏捷将是更安全的时间投资。得分在中间：继续读下一条。

2. 将项目拆成“确定性模块”和“探索性模块”

几乎所有大型项目都包含两类工作：有一块是核心引擎、支付通道、加密模块，这些需求是确定或可提前确定的；另一块是用户界面、运营后台、推荐算法，这些是需要猜测和验证的。把前者用瀑布控制，后者用敏捷探索。关键动作是：定义清楚这两个模块之间的接口。接口是一份必须用文档严格固化的契约，任何一边的内部实现变化都不能突破此契约。

我见过做得好的团队，直接把接口规范放在 PingCode 的知识库模块里，用版本控制锁定。两个小组一个按 Sprint 节奏跑，一个按里程碑计划走，每周三开一个“接口契约委员会”十分钟对齐会。就是这么朴素，却异常高效。

3. 建立“流程选择委员会”，别让单个人拍板

很多公司的悲剧在于，CTO 一激动，要求全公司上敏捷；过半年发现不对，又说我们回到瀑布。这不是方法论的问题，这是决策机制的问题。我建议凡涉及 3 个月以上、3 人以上的项目，必须由技术负责人、产品负责人、交付经理三人小组，在项目章程阶段就明确本项目的管理方法选型，并记录理由。这个记录要存档。为什么？因为这样半年后复盘，你就能分得清到底是方法论没选对，还是执行没到位。否则永远是“敏捷没效果，瀑布太磨叽”的模糊抱怨。

4. 把“容错预算”写进项目合同或者内部立项单

无论你用什么方法，都要为它支付成本。如果你选敏捷，就要给自己留出一定比例的“失败Sprint”空间，比如每个季度允许一个Sprint的可交付增量（Increment）被完全抛弃，这个Sprint的成本就是学习的学费。如果你选瀑布，就要预留变更预算，比如项目总人天的15%可以用于应对计划外的变更评估和修改。把这些成本显性化、货币化，团队才不会内耗。

八、不同情况下的取舍：什么时候必须坚持瀑布，什么时候必须拥抱敏捷

在这最后一部分，我想具体到几个典型场景，给出我个人明确的偏向。这些偏向来自多次真金白银的项目复盘，没有理论正确，只有现实最优。

1. 金融核心系统、支付清算、账务系统，坚持瀑布，没有商量

我曾经参与过一家城商行的核心替换项目，在测试阶段发现一个利息计算的小数点进位规则在需求书里没写清楚。这个规则牵涉到存贷款、理财、信用卡三个业务部门的计算引擎，要修正必须三个部门分别确认，且会计科目要跟着调。结果变这一条规则，整整耗了两个月，而实际上，如果当初在需求阶段多花10个小时把计息规则矩阵画全，根本不会出现这个问题。

在这些领域，前期投入的设计和文档不是浪费，而是购买“避免后期灾难”的保险。我见过最惨痛的案例是一个P2P平台早期因为快速迭代，把资金路由逻辑没理清，最后导致上千笔提现异常，CEO直接进去了。别说敏捷，任何不以“全业务模型梳理干净”为前提的快速开发，在金钱和监管面前全是原罪。

2. ToC 营销活动页、内容产品 MVP、内部效率工具，坚定用敏捷

这个无需赘述。当一个页面的生命周期可能只有一周，价值完全由用户行为定义时，瀑布的需求阶段还没走完，市场窗口就关门了。正确的做法是：把质量和测试的刚性底线保留（例如支付不能被玩坏），但页面样式、交互流程、文案统统以最快速度推向用户。

我自己的团队做内部CRM系统时，也犯过错。一开始做了两个月的需求调研，画了完整的原型，结果上线后销售团队用了一周，说不是他们想要的顺序。后来我们改用两周一个版本，直接把真实销售拉进评审会，每次只交付一点点但都是他们当下最痛的功能，反而两个月后系统渗透率从20%提到了70%。

3. 软硬结合、IoT、汽车电子，采用“瀑布框架+敏捷内芯”

硬件有不可更改的物理周期，但有部分软件可以独立迭代。这里的取舍是：硬件设计、结构设计、关键嵌入式软件开发走瀑布，但上层应用、用户界面、云平台服务可以用敏捷。重要诀窍是定义好固件与应用的接口版本号，以及严格的硬件抽象层（HAL）。只要接口不动，上下可以异步。这是典型的“稳敏双态”，也是江西那家农商银行在移动金融研发体系里探索的方向。

4. 政府项目、公共事业系统，优先满足合规，再谈效率

政府的验收标准里，文档完备性本身就是一种交付物。你哪怕用敏捷把系统做得再牛，没有需求确认签字、没有阶段性评审纪要，验收环节直接挂掉。这不是落后，这是体制的约束条件。你要做的是在约束条件下最优，而不是抱怨约束存在。聪明做法是：以瀑布的里程碑满足合规，但在每一个阶段内部执行小批量的技术交付。比如，需求评审通过后，进入设计阶段，虽然整体设计是签批的，但开发内部可以按功能模块划分迭代，只要对外不可见。

九、写在最后：聪明团队只关心“当下最优”，愚蠢团队才争论“古今对错”

写这篇文章的时候，我翻出了2017年那个政府项目的复盘笔记。笔记的最后一页我写了一句话，现在看来依旧适用：“当我们停止讨论‘敏捷好还是瀑布好’，开始讨论‘这次的项目，最容易在哪死，我们用什么方式防’，团队就成熟了。”

如果你今天看完这六千多字，什么也没记住，只记住两件事就好：第一，瀑布是一套高成本的精密控制手段，用来应对那些“不能出错”的系统；第二，敏捷是一套低成本的快速学习手段，用来寻找那些“没人知道答案”的问题。你不能用控制的手法去搞探索，也不能用探索的心态去搞基建。

那么，作为一名技术管理者，下一步可以怎么做？很简单：在下一个项目的章程文档里，专门加一个章节，叫做“管理方法选择及理由”。用我今天给出的确定性评估表格，给出你的判断。把这个决策公示给团队，让大家知道这一次我们为什么用这种节奏工作，是因为项目自身的特性，而不是因为谁的一时兴起。当你把这件小事坚持做三个项目以上，你就会发现整个团队的方法论素养都在提升，而“瀑布还是敏捷”的无谓争吵也消失了。

如果你需要一套能同时承载这两种管理哲学的工具，可以考虑亲自去试用 PingCode，看看它的项目模板、自定义工作流和全局仪表盘。但无论你用什么工具，请一定记住：方法论永远只是手段，让团队变得更聪明、让项目死得少，才是目的。