本文探讨了敏捷（Agile）开发方法的实际价值，认为其定义模糊不清，主要作为对传统瀑布模型的反驳而存在。然而，瀑布模型的缺陷及其解决方案（如原型设计和持续客户参与）早在1970年代就已被提出。随着大型语言模型（LLM）的兴起，行业正在回归“规范驱动开发”，强调详尽文档的重要性，这与敏捷的核心原则相悖。因此，是时候重新审视软件开发，并将敏捷视为过时的历史产物。
什么是“真正的敏捷”？
敏捷方法席卷了整个软件行业，但它的定义却始终模糊不清。每当有人质疑某种敏捷实践时，总会有人说：“啊，那不是 真正的敏捷”。然而，当我们回归其源头《敏捷宣言》（2001年）时，会发现它并没有提供太多具体指导。
宣言中的内容大多是些含糊的陈词滥调，例如：
客户合作高于合同谈判。
有些原则在商业上甚至是行不通的，比如“欢迎需求变更，即使在开发后期”。如果行业中流行的做法不是“真正的敏捷”，而宣言本身又缺乏实质内容，那么敏捷到底是什么？
敏捷的本质：反瀑布模型
敏捷的定义，很大程度上是建立在它所反对的事物之上——那就是 瀑布模型（Waterfall）。在敏捷的叙事中，如果你不采用敏捷，那你就在使用瀑布模型，而瀑布模型是 无效的。
然而，软件行业早在1970年就清楚地认识到瀑布模型的问题。其概念的提出者 Winston W. Royce 在论文中就明确指出了其弊端，并建议采用以下改进方法，这些方法后来竟被认为是敏捷的“创新”：
- 从程序设计入手。
- 制作软件原型 以收集信息并完善需求。
- 让客户参与进来，并且这种参与应该是 正式、深入和持续的。
事实是，这些见解在人类登月后一年就已发表。 iterative development（迭代开发）并非新事物。1976年的一篇论文甚至指出：
系统开发者常常只有在他们试图用设计来满足需求时，才能确定需求的不足。
这表明，在《敏捷宣言》出现之前，迭代开发 和 重视规范 早已是严谨工程师的共识。
规范驱动开发的回归
大型语言模型（LLM）的出现，正在改变我们编写代码的方式，也让软件行业的风向发生了变化。一个明确的积极趋势是：软件专业人员 重新开始编写规范（specs）了。
LLM 和许多程序员一样，在面对模糊不清的需求时表现不佳。为问题编写精确的规范，正成为生成正确代码的有效工具。这与敏捷的核心原则形成了鲜明对比：
- 敏捷说：“工作的软件高于详尽的文档”。
- 规范驱动开发则认为：“详尽的文档创造工作的软件”。
说到底，这并非什么新思想。正如 Royce 在1970年所写：
在编码开始之前，文档、规范和设计这三个词指的是同一件事。如果文档很糟糕，设计就很糟糕。如果文档还不存在，那么设计也就不存在，有的只是一些想法和讨论，价值不大。
回顾1970年代的文献，我们不禁要问，2001年的敏捷到底带来了什么？它定义模糊，宣称解决的问题在半个世纪前就已被更严谨的工程师解决了。随着技术领域的不断演进，我们是时候用全新的视角来看待问题，并将敏捷扔进它应属的历史垃圾箱里。