夜雨聆风一个从未被作者本人主张过的方法论，怎么就成了整个行业的"圣经"？
━━━ ━━━ ━━━
缘起：1970年的一篇论文
1970年，一位名叫 Winston W. Royce 的软件工程师在 IEEE WESCON 会议上发表了一篇题为《Managing the Development of Large Software Systems》的论文。
这篇论文后来被引用数以万计，成为了软件工程史上最有影响力的文献之一。
但这里埋着一个彩蛋：Royce 在整篇论文中，从未使用过 "waterfall"（瀑布）这个词。
一次都没有。
他画了一张从需求分析 → 设计 → 编码 → 测试 → 部署的顺序流程图。但画出来，是为了批评它。
"这种方法有风险，且招致失败"
Royce 原话是这样写的：
"The implementation described above is risky and invites failure."
>
（上面所描述的实现方式是有风险的，且招致失败。）
他明确指出，一次性顺序通过的方法只适用于最简单的小项目，"has never worked on large software development efforts"（在大规模软件开发上从未奏效）。
他的真正建议是什么？
"Do it twice" —— 做两次。
Royce 提出了五个关键的改进建议：
- 程序设计先行（不是需求写完了就直接写代码）
- 把设计文档写透
- 做两次（先做原型）—— 交付给客户的版本，应该是第二个版本
- 计划、控制和监控测试
- 让客户全程参与，不只是需求阶段来一次
看到了吗？原型、迭代、客户持续参与——这些后来被贴上"敏捷"标签的核心理念，早在1970年就被 Royce 写在纸上了。
那他是怎么变成"瀑布模型之父"的呢？
# "瀑布"这个名字是别人取的
1976年，Bell 和 Thayer 在一篇题为《Software Requirements: Are They Really a Problem?》的论文中，首次使用了 "waterfall" 一词来描述 Royce 的那张顺序流程图。
1985年，美国国防部发布了 DOD-STD-2167 标准，正式将这种"先全部设计好再动手"的线性流程制度化。军方的采购流程要求严格的阶段评审，供应商只能选择先交付一摞摞文档，再开始写代码。
从那时起，"瀑布模型"就像一尊被错误抬进庙里的塑像，被整个行业供奉了起来。
你有没有发现哪里不对？
写论文的人说"这不行" → 读者只记住了那张图 → 摘掉了警告 → 别人给起了个名字 → 军方的标准把它锁死 → 教科书把它奉为经典 → 面试官问你"瀑布模型的五个阶段是什么"
整个软件工程行业，就这样沿着一个"被截断"的理解，走了几十年。
# 这个误会为什么如此持久？
有人可能会问：既然 Royce 自己都说了有问题，为什么大家还是照着做？
原因一：那张图太有说服力了。
从需求到部署，一条干净整洁的箭头，自上而下。人脑喜欢简单的因果链——Royce 的图满足了这个偏好，而他的五条建议太"软"了，不容易被记住。
原因二：管理者的偏好。
从一个管理者的角度看，"先全部需求冻结→再排期做→再测试→最后发布"听起来像是可以掌控的。迭代、原型、客户持续参与，意味着不确定性——而管理者最怕不确定性。
原因三：军方的标准影响力太大。
DOD-STD-2167 影响了整个90年代的软件开发实践，尤其是那些为大客户做 contract-to-order 开发的公司。当一个标准要求你每阶段提交正式文档并通过评审，你就没有动力去迭代。
# 有趣的是，批判瀑布模型最有力的人，就是Royce自己
Royce 在 1970 年的论文中写道，顺序单次的开发方式是 "risky and invites failure"。他建议 "do it twice"。
换句话说，Royce 才是最早的"瀑布批判者"。
他批评一个他自己从未命名过的方法论，而人们却把他当作这种方法的代言人。这就像你写了一篇文章说"不要在高速公路上逆行"，结果别人把你的文章当作"高速公路驾驶指南"来引用。
# 这对今天的我们有什么启示？
你可能会说：现在大家都在搞敏捷 / DevOps / 持续交付了，谁还用瀑布啊？
但"瀑布思维"从未真正消失：
- 产品经理说"这个季度所有需求 Freeze"
- 老板说"先让我看到完整的 PRD 再立项"
- 项目经理说"这个版本的 scope 不允许再改了"
这些都是"瀑布心态"的残余。它们不是 Royce 的错——Royce 从没让你这么干。
真正有价值的教训是：
一个方法论的影响力，往往不取决于它是否正确，而取决于它是否容易被简化。
Royce 的论文包含了一个深刻的洞察和五条有远见的建议。但行业选择了记住最简单的那部分——一张图、几条箭头、五个方框。
2026 年的今天，当我们嘲笑"瀑布模型"是老古董的时候，不妨想一想：今天我们追捧的每一个方法论，有多少也是被简化和误读的结果？
也许，从来就没有什么"瀑布模型"，有的只是一张被误解的图，和无数没有读完原文的读者。
━━━ ━━━ ━━━
# 参考文献
- Royce, W.W. (1970). "Managing the Development of Large Software Systems." *Proceedings of IEEE WESCOM*, Vol. 26, pp. 1-9. — 本文的主角。Royce 提出顺序开发流程但立即批评之，"waterfall"一词从未出现，建议"do it twice"和客户全程参与。
- Bell, T.E. and Thayer, T.A. (1976). "Software Requirements: Are They Really a Problem?" *Proceedings of the 2nd International Conference on Software Engineering*, pp. 61-68. — 首次使用 "waterfall" 一词来描述 Royce 的顺序流程图。
- United States Department of Defense (1985). *DOD-STD-2167: Defense System Software Development*. — 将线性瀑布流程制度化为美军软件开发标准，对行业产生了深远影响。
- United States Department of Defense (1988). *DOD-STD-2167A*. — 2167的更新版，试图提供更多灵活性，但大体仍保持线性阶段评审的模式。
- Larman, C. and Basili, V.R. (2003). "Iterative and Incremental Development: A Brief History." *IEEE Computer*, Vol. 36, No. 6, pp. 47-56. — 追述迭代开发方法的历史，其中详细考察了 Royce 论文被误读的经过。
- McConnell, S. (1996). *Rapid Development: Taming Wild Software Schedules*. Microsoft Press. — 对瀑布模型的局限性有深入分析，引用了 Royce 原文中的警告。
━━━ ━━━ ━━━
*📝 本文为 LeisureLinux 公众号原创。分享给你的程序员朋友，看看他们知道这个故事吗？*
从 IDE 到 Desktop Agent：软件工程的“驾驶舱”正在退场？
Token狂欢结束，谁来收拾烂摊子？—— Revenium的AI成本可观测之道
软件供应链安全范式变革：PURL元数据标准化、生态系统融合与“SBOM混淆”漏洞深度研究
痛失泰斗！Multics 奠基人、RISKS 主持人 Peter G. Neumann 逝世，他留下了哪些终极安全哲学？
