三个真实场景证明瀑布开发依然能打

不是敏捷不行,是你把场景搞错了

去年冬天,我接手了一个医疗器械软件项目的咨询诊断。技术团队用Scrum跑了三个迭代,每次Sprint Review都被产品负责人叫停，不是因为代码质量差,而是因为每个迭代产出的功能增量,放到医疗器械注册的框架里,都不构成一个“可提交审评的交付物”。当开发团队开始第八次修改需求文档的时候,项目经理在会议室里说了一句话让我记到现在:“我们不是在做软件,我们是在用代码写一份法律文件。”

这句话点醒了我。过去十年,敏捷社区的叙事把瀑布模型塑造成了一个过时的、僵化的、甚至有些可笑的存在。但我在一线见过的数十个中大型项目里,恰恰是那些“敢用瀑布”的团队,在需求确定性极高的场景下交出了最漂亮的成绩单。问题从来不是瀑布或敏捷哪个更好,而是你有没有在正确的场景里使用正确的工具。

这篇文章不打算做“各打五十大板”的和事佬。我要给你三个真实的高压场景,解释为什么在这些地方,瀑布开发不仅没有死,而且是项目成功的唯一保障。文末我会给出一个可操作的决策框架,帮你在下一个项目启动时做出准确判断。

一、把结论说在前面:瀑布的护城河在哪里

如果只用一个词解释瀑布模型的核心价值,我会选“可审计的阶段性承诺”。这不是一句空话,它包含了三层含义:

第一,每个阶段的输出物是下一个阶段的合同。需求规格说明书不是参考文件,而是开发团队和甲方的法律约定。详细设计方案不是建议,而是编码的唯一依据。这种刚性在互联网产品经理看来是噩梦,但在一个合同额上千万、验收标准写满三百页的政府项目中,它是保护双方的铠甲。

第二,变更成本前置。瀑布模型把“思考”和“修改”放在了编码之前。这个设计在敏捷爱好者眼里是“浪费时间”,但它的底层逻辑是:当你无法承受上线后的修改成本时,宁可花三倍时间把需求搞清楚再动手。

第三,管理复杂度恒定。对于百人以上的跨部门协作项目,瀑布的阶段里程碑让总经理、财务总监、合规官这些非技术角色也能读懂项目状态。“设计阶段完成”意味着他们已经可以核算40%的合同款是否该支付了，这在敏捷的“我们刚完成了Sprint 7的velocity是23个story points”面前,是天壤之别。

这三层护城河,在接下来的三个场景中会被反复验证。

二、场景还原:什么团队在什么条件下依然首选瀑布

让我们跳出理论辩论,看看那些真实存在、每天都在发生的项目现场。

1. 场景一:核电站数字化控制系统的“一次成型”困境

2019年,我有机会近距离观察一个核电DCS(数字化控制系统)软件项目的交付过程。这个项目的需求文档厚度超过2000页,其中约60%的内容不是功能描述,而是安全合规条款、故障模式分析和冗余设计约束。团队的配置让我印象深刻:40个开发人员,配了12个专职需求分析师和8个测试规范编写者，测试团队在代码还没开始写的时候就已经进场了。

为什么是这个配置?因为核安全监管机构(IEC 61508和IEC 60880标准)要求每一行代码都能追溯到一条经过审批的需求,而每一条需求都必须对应一套经过独立验证的测试用例。这不是“要不要做”的选择题,而是“做不到就不能并网发电”的生死线。

在这个场景里,敏捷所倡导的“欢迎需求变更”是灾难。任何一个功能修改,都可能触发安全分析重做、测试用例重写、监管机构重新审批，时间成本不是一周,而是六到九个月。瀑布的“需求冻结-设计审批-编码-测试”流水线,恰恰是应对这种监管环境的最优解。

有人会问:那如果需求确实有错怎么办?答案是在需求分析阶段投入足够多的时间和领域专家。这个项目在需求阶段就花了11个月,把一名退役核电站运行工程师和两名安全分析师请进了需求评审会议室。他们不是因为喜欢开会,而是因为第一行代码写下去之后,改错的代价是写对的100倍以上。

我从这个案例里学到了一条至今受用的判断标准:当一个项目的“上线后修改成本”趋近于无穷大时,前置的瀑布式规划就不再是可选项。

2. 场景二:政府招投标项目的“合同即铁律”

第二个场景我敢说在中国做To G(政府)或To B大客户的同行都感同身受。一个典型的政府信息化项目是这样启动的:甲方花了半年做可行性研究,又花了三个月招投标,最终签下来的合同里,功能清单写到了三级菜单,交付时间精确到天,验收标准列了七八页。你这时候跳出来跟甲方说“我们用敏捷吧,每个迭代根据你的反馈调整方向”，对方的采购处处长会用看疯子的眼神看着你。

不是说这些甲方的决策者不懂技术。他们太懂了:他们懂的是政府采购法、懂的是审计流程、懂的是如果项目超预算或延期,自己是要被问责的。在他们眼里,合同不是协作协议,而是一张带着法律效力的军令状。而瀑布模型提供的阶段性交付物，需求规格说明书、详细设计文档、测试报告，恰恰是审计时能拿出来的证据链。

我曾在PingCode服务过的一个大型国企信息化项目上看到过这个逻辑的完美演绎。这个项目涉及三个事业部、六个处室的业务系统整合,合同金额超过三千万,实施周期十八个月。项目启动时,PingCode团队做的第一件事不是拉看板,而是和甲方一起花了两个月,把合同附件里的500多条功能需求逐条拆成了可追溯的需求矩阵。每条需求都标注了优先级、验收标准和关联的合同条款编号。这一套做完,所有人都知道两件事:第一,这个项目边界清晰了;第二,谁也别想在第十八个月的时候说“我还要加一个模块”。

有人可能觉得这个案例太“体制内”了,不具备普适性。但我想反问:你所在的公司有没有接过固定总价的外包项目?有没有签过带违约条款的交付合同?如果你的回答是“有”,那么在那个项目里,你就是“体制内”，合同就是你的体制。

3. 场景三:航空航天软件中的“全生命周期可追溯”

第三个场景来自我一个在航天领域做嵌入式软件的朋友。他们团队开发的飞控软件,编译完之后的二进制文件只有不到2MB,但配套的文档超过了300MB。每一行C代码都必须对应一条需求、一个设计决策、一个单元测试用例、一个集成测试场景和一个验收测试条目。这就是DO-178C(航空软件适航标准)里的“双向可追溯性”要求，从需求到代码,从代码到测试,两条链路缺一不可。

在这种标准下,瀑布的V模型几乎是天然的合规框架。左侧是需求分解和设计深化,右侧是对应层级的测试验证,每一个左侧的产出物在右侧都有一个验证环节等着它。这个结构的精妙之处在于:它把“质量”从一种主观感受变成了一个可审计的事实。

你可能会说:敏捷也可以写文档、也可以做追溯啊。理论上没错,但实践上几乎不可能。原因很简单:敏捷的“响应变化”和DO-178C的“变更影响分析”之间,存在不可调和的成本矛盾。航空软件里,哪怕修改一行代码,都必须评估它影响的全部需求、设计、测试用例和已通过的审查报告，这个过程严格遵守更改控制委员会(CCB)的流程,平均耗时三到五天。如果你每两周一个迭代都在改代码,你的CCB会直接累死在会议室里。

这个场景解释了我在文章开头提到的那个医疗器械软件团队遇到的问题。医疗软件遵循IEC 62304标准,它对软件安全分级和文档追溯的要求虽然没有航空那么严苛,但逻辑是一样的:当软件失效可能危及人的生命时,开发过程本身就必须是可被监管机构审计的。瀑布模型不是技术偏好,而是合规成本最优解。

三、常见误区:逼死项目的从来不是瀑布,而是这些隐性陷阱

回顾我过去参与评审和诊断的项目失败案例,真正让瀑布模型背锅的,其实是这三个被反复踩的坑。

1. 误区一:用瀑布的壳装敏捷的心

最常见的一种拧巴:团队对外宣称“我们用的是瀑布”,在合同和组织架构上也按瀑布的阶段划分,但内部执行时项目经理默许了“需求明确的部分先开发,不明确的部分边开发边确认”。这在项目管理圈有个专门的名字叫“需求蠕变”，你以为你在用瀑布严格管控,实际上你的项目已经偷偷变成了一个没有迭代节奏的、混乱版的敏捷。

结果是什么?到了联调阶段,那些“边开发边确认”的模块之间接口全乱套,项目延期成定局,然后团队复盘时说:“看,我就说瀑布不行吧。”，你用的根本不是瀑布,你是在用瀑布的文档体系给失控的敏捷打掩护。

正确的做法是:如果你判断这个项目需要瀑布,就必须在需求评审完成之后物理上冻结需求文档,任何需求变更都走正式的变更控制流程,包括影响评估、成本核算和甲方确认签字。这套流程看着笨重,但它恰恰是瀑布应对变更的正确姿势。

2. 误区二:在“伪确定性”需求上强行用瀑布

这是另一个极端。有些项目经理接到项目之后,不管三七二十一,先按瀑布的套路把需求文档写到几百页,然后发给甲方签字。他觉得签字了需求就确定了,殊不知那个签字页在甲方眼里只是“我看了,大概就这些吧,具体细节后面再说”。

我做项目诊断时最怕看到这种情况:合同签了,需求文档签了,但需求文档的内容经不起推敲。你问项目经理:“这个用户权限模型,你们和甲方在正式会议上确认过细节吗?”他会说:“甲方签过字了,我们默认没问题了。”然后项目做到一半权限模型推倒重来，因为签字的时候双方对于“权限”的理解完全不一样。

这种场景下的真正问题是:需求本身不具备被瀑布处理的确定性,但团队误以为有签字就等于有共识。判断一个需求是否足够确定,不是看文档多厚、签了多少字,而是看你能否对每一条需求回答出“验收标准是什么”。如果30%以上的需求条目你写不出可量化的验收标准,那么无论你多希望用瀑布,这个项目本质上还是需要敏捷的探索式交付。

3. 误区三:把瀑布的“顺序执行”理解为“一次性执行”

这是老生常谈但我几乎每个月都能看到活生生的例子。团队用瀑布,需求阶段花了三个月,期间没有任何开发人员参与;设计阶段花了两个月,画完流程图才发现有个核心模块的技术可行性根本没验证过;等开发做到一半发现需求理解有偏差,返工成本已经上来了。

瀑布的“顺序执行”不代表“一次性做对”。高质量的瀑布执行,是每个阶段中都嵌套着微小的迭代。需求阶段里,产品经理写完一版需求要拉开发负责人看技术可行性;设计阶段里,架构师画完概要设计要拉核心开发做设计评审和原型验证。这些在一个阶段内部的快速反馈,才是瀑布能在高压场景下成功的关键。那些说“瀑布不允许迭代”的人,要么没做过真正的瀑布项目,要么是在竖一个攻击的稻草人。

四、决策逻辑:五维模型帮你判断这个项目该不该上瀑布

聊完场景和误区,我把我这些年反复使用的一个决策框架分享给你。这个框架我从2018年开始迭代,帮我在面对新项目时快速判断模型倾向。

我把评判维度拆成五个:

如果一个项目在五个维度上同时偏向瀑布,那么不要犹豫,你就应该用瀑布。反之,如果三个以上维度偏向敏捷,那么即使项目规模很大,也值得认真考虑Scrum或混合模型。如果各维度信号矛盾,那么你可能需要的是一个分层的混合策略，接下来我会讲这个。

五、以PingCode为例:大团队如何用工具把瀑布管“活”

聊完决策框架,我想讲一个具体工具层面的观察。在PingCode服务的中大型客户中,有一个我反复看到的模式:最好的瀑布项目不是靠人管出来的,而是靠工具把流程固化成肌肉记忆。当你的项目有100人以上、涉及三个以上的供应商时,靠项目经理一个人盯在身后催文档、催评审、催签字,是不现实的。

我观察到PingCode在支持瀑布项目时的几个设计点,恰好对应了上文提到的那些高风险场景:

第一,需求-任务-测试用例的全链路追溯。在核电或医疗类项目中,合规审计的核心诉求是“你给我看这个功能对应的需求是哪一条,设计文档在哪里,测试用例有没有覆盖,测试结果是什么”。PingCode在需求管理模块里,支持从史诗到特性到用户故事再到开发任务和测试用例的垂直穿透查看,一个外部审计人员可以顺着一条需求ID在五分钟内看到全部相关产出物，这在传统Excel和Word管理模式中几乎不可能实现,因为文档一多链接就会断裂。

第二,阶段评审的线上化与留痕。瀑布项目的关键节点评审如果不留痕,等于没做。我见过最离谱的情况是一个项目的设计评审会开了三个小时,讨论了很多重要决策,但会后没有人写会议纪要,三个月后开发团队和设计团队对着一份有歧义的设计文档互相指责。PingCode的评审功能支持在设计文档或需求条目上直接发起评审流程,所有评审意见、修改记录和最终审批状态都被持久化在系统里,而且可以设置强制审批门禁，上一阶段没有审批通过,下一阶段的任务就无法创建。这套机制把瀑布的“阶段门禁”从一种理论要求变成了系统级的硬约束。

第三,进度透明化对甲方信任的建立。政府或大型国企项目的甲方对进度的焦虑感是非常真实的。他们不见得懂开发,但他们非常在意“我的钱花到哪里了”。PingCode的迭代概览页面提供了燃尽图、进度百分比和里程碑完成状态的可视化视图,这些信息不需要任何技术背景也能看懂。我在那个三千万的国企项目上线时,甲方的项目负责人专门提到:“每周五下午我打开系统看一遍进度,然后截图发到我们自己的OA群里,领导就不再催我了。”一个稳定、透明、不需要反复解释的进度仪表盘,在瀑布项目里的价值远超功能本身。

不过我也要说清楚:工具本身不能代替方法论判断。PingCode可以让你把瀑布跑得更顺,但它不能替你决定这个项目该不该用瀑布。那个判断,必须由你基于上文五维模型自己做。

六、如何把“适合用瀑布”的判断落地为行动

如果你的项目经过五维模型判断,确实适合用瀑布,接下来的问题就是如何启动。以下是我在过去项目中总结出来的五步启动法。

1. 第一步:建立需求基线并冻结版本号

需求文档不是写出来就完事,你必须在项目启动会上当众做一件事:把需求文档的最终版本号秀出来,然后告诉所有参会者,从此刻起,这份文档的版本从V0.9变成了V1.0,进入变更控制状态。这不是一个形式主义动作,而是一个心理契约的建立，它告诉所有人,游戏的规则变了。

2. 第二步:将需求条目与合同条款做映射

在政府或大客户项目中,这一步直接决定了你验收时的效率。每一条核心功能需求,后面都标注对应的合同附件编号和验收条款编号。这个动作痛苦,但只要做完了,整个项目的边界就永远清晰。我自己现在判断一个瀑布项目文档质量好不好,第一眼看的就是需求矩阵有没有做、做得细不细。

3. 第三步:设计强制性的阶段评审门禁

定义好每个阶段结束时的评审标准,并且这个标准必须是可客观验证的。“所有需求条目都需要有对应的测试用例”是一个好的门禁条件,“设计质量达到团队认可的水平”不是一个好的门禁条件。门禁不通过,下一个阶段不能开始,这应该是系统级的硬约束,而不是项目经理靠人情去推动的软规则。

4. 第四步:在阶段内部设置快速反馈机制

前面已经提过,这里再次强调:需求阶段里,需求文档的评审必须有开发负责人和测试负责人参与;设计阶段里,概要设计出来后要拉核心开发做技术评审。阶段内部的反馈可以快,也必须快。瀑布的宏观节奏是慢的,但微观执行要快。

5. 第五步:尽早引入测试团队

这是高质量瀑布项目的标志性特征。如果你的测试团队在代码写完之后才进场,你的瀑布项目已经输了一半。测试人员应该在需求评审阶段就参与进来,基于需求编写测试用例，这个动作不仅提前了测试准备,更重要的是,它反向检验了需求的可测试性。如果一个需求被证明无法写出明确的测试用例,那么这条需求本身就是模糊的,应该被返工。

七、不同情况下的项目模型取舍指南

写到这里,我想用一个可以直接拿来用的指南帮你收尾。根据我见过的那些成功和失败的项目,以下四种情况对应不同的模型选择。

1. 情况A:需求固化、合规要求高、团队跨组织

直接选瀑布,不要犹豫。这种项目用敏捷的额外沟通成本和合规风险远大于收益。用瀑布把边界锁死,把文档做足,把评审走稳。

2. 情况B:需求方向明确但细节模糊,合规要求中等

选分层混合模型。整体架构和核心模块走瀑布(需求-设计-开发),用户交互层面和体验优化模块走敏捷。这种分层的关键在于接口必须由瀑布侧定义并锁定,敏捷侧在接口约束内自由迭代。

3. 情况C:需求极不确定,快速验证是核心目标

老老实实用敏捷。别因为项目规模大就默认用瀑布,大项目如果需求不确定,用瀑布会让你在第六个月发现前五个月写的东西全部要重来。用短迭代快速验证,用MVP(最小可行产品)逼出真实需求。

4. 情况D:甲方要求瀑布,但你判断需求不够确定

这种情况在中国To B市场太常见了。你的策略不是去说服甲方改变合同框架,而是在瀑布的框架内争取合理的缓冲。具体做法是:在需求阶段争取更多时间做原型验证;把需求文档里的非核心模块写成可配置项,降低硬编码风险;在合同里明确变更流程,不是拒绝变更,而是让变更的成本透明化。

八、让瀑布“能打”的不是怀旧,而是清醒

这篇文章写到最后,我想把最核心的认知再说一遍。

瀑布开发没有被淘汰,它只是不再是默认选项了。在三十年前软件工程刚刚规范化的年代,瀑布是唯一的、默认的、被不加区分地用在所有项目上的模型。那个年代的滥用,导致了大量的失败案例和一代工程师的集体创伤,所以敏捷运动出现时,大家痛快地和瀑布划清界限。

但过了那个矫枉过正的节点之后,我们这一代工程师应该有能力做出更精细的判断了。不是“瀑布已死”,也不是“敏捷万能”,而是每个项目各有各的约束条件,模型服从约束。当你的项目签在合同上,守在安全线上,活在审计档案里，瀑布是你最锋利的刀。

下一步怎么做:如果你正在规划下一个季度启动的项目,我建议你把上文的五维模型打出来,拉着你的技术负责人和项目经理,对着那个项目的合同和需求,一个维度一个维度地打分。如果结果指向瀑布,就按五步启动法踏实执行,别被“你们还在用瀑布啊”这种技术圈的peer pressure干扰。项目是按需求交付的,不是按开发方法论的流行度交付的。

最后说一句有点个人色彩的话:我尊重每一支在高压场景下把瀑布跑出教科书水准的团队。他们做的事情不酷、不性感、不会被技术大会邀请去讲,但那些核电站的屏幕亮起、那些医疗器械的绿灯闪烁、那些政府系统在截止日当天平稳上线,背后都是他们对“确定性”这三个字的偏执。这个世界需要敏捷的探索者,也同样需要瀑布的守夜人。