喊了25年的敏捷开发，其实是场误会？

2026年初，一篇题为《告别敏捷》的文章在技术圈炸了锅。作者劈头就问：如果没人能说清什么是「真正的敏捷」，连它的「圣经」——2001年的敏捷宣言都只是模糊的空话，那我们这二十多年在践行的到底是什么？

有人说敏捷是救软件开发于水火的神兵，有人骂它是徒增负担的形式主义；有人靠它年入百万做咨询，有人被它的每日站会、故事点估算折腾得叫苦不迭。更讽刺的是，那些被当作「敏捷创新」的做法——迭代开发、客户参与、做原型，其实早在1970年就被写进了论文，比人类登月只晚了一年。这到底是一场行业集体的皇帝新衣，还是我们从一开始就误解了敏捷？

从反瀑布到造神：敏捷的诞生与变形

2001年2月，17位软件开发者躲进美国犹他州的滑雪度假村，写下了仅68字的敏捷宣言。他们想反抗的是当时僵化的「瀑布模型」——那种要求先把所有需求写死、按顺序走完每个阶段的开发方式，在快速变化的互联网时代早已寸步难行。

宣言的四个核心价值听起来无比动人：个体和交互胜过流程和工具，可工作的软件胜过详尽的文档，客户协作胜过合同谈判，响应变化胜过遵循计划。但问题恰恰出在这里：它太模糊了。什么程度的文档算「详尽」？客户的需求变化要无限制接纳吗？没有具体的操作指南，就给了所有人解读的空间。

很快，敏捷被包装成了「反瀑布」的万能解药：你不做敏捷，就是在做瀑布；瀑布是失败的代名词，所以你必须做敏捷。但很少有人记得，瀑布模型的提出者温斯顿·罗伊斯在1970年就明确说过，纯线性的瀑布行不通，他建议的是做原型、让客户深度参与、反复迭代——这些后来全成了敏捷的「原创理念」。

假敏捷横行：被异化的仪式与真实的困境

敏捷火了之后，很快形成了一套庞大的「工业复合体」：培训、认证、咨询、工具软件……从业者要考CSM、PSM证书，企业要请敏捷教练，团队要开每日站会、做Sprint计划、估算故事点，仿佛做完这些就是「敏捷团队」了。

但IEEE 2024年的研究显示，超过40%的团队在践行「假敏捷」：他们严格遵守所有流程仪式，却唯独忘了敏捷的核心——响应变化和创造客户价值。每日站会变成了走形式的报工，Sprint计划变成了精准到小时的僵化安排，故事点估算成了比谁的数字更「合理」的游戏。

更现实的是，敏捷的很多理念在商业世界里根本走不通。比如「欢迎需求变化，哪怕在开发后期」，客户当然想改，但改需求的时间和成本谁来承担？2025年的行业数据显示，33%的敏捷团队被频繁的需求变更拖垮，29%的成员甚至想回到传统的瀑布模式。而那些真正把敏捷做好的团队，往往是小而精、客户高度参与的项目——这和敏捷宣言里的「普适性」相去甚远。

AI时代的反思：敏捷该往哪去？

生成式AI的出现，给了敏捷最直接的一记耳光。AI写代码需要清晰、明确的需求文档，而不是模糊的「客户协作」——这让开发者们重新捡起了被敏捷贬低的「详尽文档」。有人甚至提出了「规范驱动开发」，和敏捷的「工作软件胜过文档」直接唱起了反调。

但这并不意味着敏捷彻底过时了。它的核心价值——关注人、快速反馈、持续改进，依然是应对复杂项目的有效思路。问题出在我们把敏捷从一种「思维方式」异化成了一套「必须遵守的流程」。

NASA的实践就是最好的例子：作为对安全要求极高的行业，他们没有全盘否定瀑布，也没有硬套敏捷流程，而是把敏捷的迭代思想融入了传统的合规框架里——在关键节点保留严格的审查，在开发过程中加入小步迭代和客户反馈。这种「混合模式」的成功率，反而比纯敏捷或纯瀑布都要高。

我们怀念敏捷，其实是怀念它最初想解决的问题：如何在不确定的世界里，做出真正有价值的软件。但我们不该把它当成包治百病的神药，更不该让它变成束缚手脚的枷锁。

「没有最好的方法，只有适合的方法」——这句话放在软件开发里，再合适不过。敏捷不是终点，它只是我们探索更好开发方式的一个阶段。当AI重新定义软件开发的效率，当企业开始反思形式主义的代价，或许我们该做的不是告别敏捷，而是把它从神坛上拉下来，拆解开，取其精华，然后继续往前走。毕竟，软件开发的本质从来不是遵循什么流程，而是解决问题。