一个从未被作者本人主张过的方法论，怎么就成了整个行业的\"圣经\"？
━━━ ━━━ ━━━
缘起：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 逝世，他留下了哪些终极安全哲学？
AI Agent 的"操作系统"呼之欲出：红帽 Skill 仓库释放的重磅信号
常见问题（FAQ）
Q1：这篇文章主要讲什么？ 1970年，一位名叫 Winston W. Royce 的软件工程师在 IEEE WESCON 会议上发表了一篇题为《Managing the Development of Large Software Systems》的论文。 Q2：还有哪些关键事实？ Royce 提出了五个关键的改进建议： 1. 程序设计先行（不是需求写完了就直接写代码） 2. 把设计文档写透 3. 做两次（先做原型）——交付给客户的版本，应该是第二个版本 4. 计划、控制和监控测试 5. 让客户全程参与，不只是需求阶段来一次 看到了吗？ Q3：有哪些值得注意的细节？ 原型、迭代、客户持续参与——这些后来被贴上\"敏捷\"标签的核心理念，早在1970年就被 Royce 写在纸上了。 Q4：核心结论是什么？** ━━━ ━━━ ━━━ 缘起：1970年的一篇论文 1970年，一位名叫 Winston W. Royce 的软件工程师在 IEEE WESCON 会议上发表了一篇题为《Managing the Development of Large Software Systems》的论文。
