文章指出，敏捷开发虽然席卷软件行业，但其定义模糊不清，敏捷宣言内容空泛且难以实践。作者认为敏捷更多是通过反对瀑布模型来定义自己，而实际上瀑布模型的缺陷早在1970年就被指出。文章质疑敏捷运动的实质意义。

告别敏捷：一场迟来的反思

2026年4月14日

敏捷开发已死，而我们甚至从未真正认识过它。

敏捷浪潮如海啸般席卷整个行业，但每当有人质疑时，总会听到"那不是真正的敏捷"的辩解。然而翻开2001年的《敏捷宣言》，这份所谓"软件新时代的启蒙文件"，我们惊讶地发现它实际上言之无物——最好的情况是些模糊的陈词滥调（如"客户合作重于合同谈判"），最糟的情况则是商业上完全不可行的建议（如"欢迎需求变更，即使在开发后期"）。

敏捷的本质悖论在于：如果敏捷产业从未正确实践敏捷，而宣言本身又近乎空洞，那么它究竟是什么？

【"软件行业的幽灵：瀑布模型"】 敏捷始终通过否定来定义自己——它声称要对抗的是早已被证伪的瀑布模型。但早在1970年，Winston W. Royce就指出瀑布模型的缺陷，并提出了解决方案： - 从程序设计开始 - 制作原型以完善需求 - 持续深度对接客户

这些后来被标榜为"敏捷创新"的理念，实际在阿波罗登月次年就已提出。1976年Bell和Thayer的论文更通过实证研究证明：需求问题会在开发过程中动态变化，开发者往往在实施设计时才能发现需求缺陷。显然，迭代开发在敏捷出现前数十年就已存在并持续完善。

【规范驱动开发的复兴】 随着基于海量编程数据训练的廉价大语言模型（LLM）普及，软件开发正在经历范式转移。一个显著变化是：专业人士重新开始重视规范编写。LLM与人脑类似，在模糊需求面前表现欠佳，而精确的规范描述能有效生成正确代码。

这直接挑战了敏捷"可运行软件优于详尽文档"的信条。规范驱动开发告诉我们："详尽文档创造可运行软件"。正如Royce所言："在编码开始前，文档、规范和设计三位一体。糟糕的文档意味着糟糕的设计，没有文档就等于没有设计。"

回望1970年代那些逻辑严密的工程论文，我们不得不质疑2001年的敏捷究竟带来了什么。它用模糊定义包装早已被解决的问题，而如今，随着LLM推动行业变革，是时候用新视角审视过去，将敏捷送入它应有的历史垃圾桶了。

（注：原文中的技术文献引用及咨询信息等次要内容已酌情删减）

以下是评论内容的总结，平衡呈现各方观点：

【反对Agile的观点】 1. 认为Agile解决的是错误问题（代码不是瓶颈），实际项目失败多因需求分析不足 - "Agile was always aiming to solve the wrong problem...poor specs, terrible analysis kill projects" (评论1) - "从scrum master到planning poker都很愚蠢...只是作秀" (评论6)

2. 批评Agile异化为僵化流程，背离初衷

• "大A敏捷(A-gile)根本不敏捷...变成了强调计划的臃肿流程" (评论13)
• "敏捷始于宣言，终于Jira" (评论18引用Flight手册)

【支持Agile的观点】 1. 认为迭代开发符合认知规律 - "通过工作软件迭代才能理解真实需求" (评论16) - "循环开发不是空洞口号，而是生活规律" (评论25)

2. 强调核心原则仍有效

• "只需要4句宣言：个体互动重于流程工具..." (评论13)
• "6个月后团队没人想回到旧工作方式" (评论26)

【中立/反思观点】 1. 方法论取决于执行者 - "成败关键在人而非方法...AI时代仍可适用" (评论21) - "没有放之四海皆准的系统...持续创新就会持续犯错" (评论24)

2. 形式化导致异化

• "初衷是提供指南而非规则，但被商业化为课程" (评论21)
• "项目管理缺乏科学基础，多是'巫术'" (评论19)

3. 不同场景适用不同方法

• "F-35软件、网页和玩具程序不能等同讨论" (评论20)
• "经历过瀑布模式痛苦的人才能理解敏捷价值" (评论17)

关键矛盾点：原始敏捷理念(小a敏捷) vs 商业化的形式主义敏捷(大A敏捷)，以及是否真正解决软件开发的核心瓶颈问题。