夜雨聆风我不是反对敏捷，我是受不了它的仪式
讲真，我对敏捷的感情很复杂。
理论上每人三句话：昨天干了啥、今天干啥、有没有卡点。实际上呢？十个人的站会能开 25 分钟，一半时间在听两个人扯实现细节，剩下的人低头盯着自己的鞋。说实话，那种煎熬我现在想起来都烦——每天雷打不动浪费这二十分钟，谁的火不往上窜。纯纯的形式主义，糊弄学典范。
后来我们上了 AI coding agent 。最直接的变化是什么？是「昨天干了啥」这个问题，问不出来了。
因为昨天干活的不全是人。一个 agent 半夜跑了二十几轮，改了八个文件，中间还因为环境配置卡了十轮——这事是真的，有篇测评里说，装个依赖、配个 Playwright 路径,人类 90 秒搞定， agent 能来回折腾十几轮。我早上来看日志，得花十分钟才能搞清楚它到底干了啥、对不对。
那我站会上让一个人复述这个？没意义。
AI-Scrum 那帮人也意识到了。我看到一个说法，挺扎心：在半数成员是 AI 的团队里，站会不再是「你昨天做了什么」，而是人类成员去翻 agent 的自动化输出日志，看哪个 bot 的测试套件挂了，还得学会读 agent 的「置信度分数」。
你品品。这还是站会吗？这是验尸。
把站会停了。改成每天早上看一份 agent 跑出来的测试报告 + 异常清单。三分钟,比站会高效十倍。
仪式死了。但敏捷想解决的那个问题——信息同步、快速暴露卡点——一点没少，反而更快了。
主流说「敏捷加 SDD 结合一下就行」，我觉得这是和稀泥
现在但凡聊 AI 开发流程，标准答案都是这一套：传统敏捷还有价值，跟 Spec-Driven Development(规格驱动开发)结合一下就好。
听着特别周全。也特别没用。说难听点，这就是典型的正确的废话，谁听了都点头，谁照着干都懵。
我去翻了一圈资料。 SDD 这东西今年是真火——Spec Kit 这个工具到 2026 年年中已经拿了 9 万多 GitHub star ，集成了 30 多个 agent ； Kiro 、 BMAD 这些 SDD 工具一抓一大把，连 arXiv 上都有专门的论文,标题就叫《从代码到契约》。
SDD 的核心就一句话:规格文档(Spec)是唯一事实来源。需求要变?先改文档，再让 agent 从文档生成代码。改代码之前必须先改 spec 。
发现问题没有?
我把敏捷宣言翻出来又读了一遍。第二条价值观,白纸黑字:可工作的软件,高于详尽的文档。
SDD 干的事,正好把这条反过来了。文档重新坐上了头把交椅,成了第一公民,代码反倒成了从文档「派生」出来的二等产物。
这不是「结合」。这是其中一条价值观被直接掀翻了。
那帮说「结合一下就好」的人,要么没真用过 agent,要么没认真读过敏捷宣言。这话我说出来可能得罪人,但憋着更难受。你不能一边供着「软件高于文档」,一边又说「改代码前先改文档」——这俩是打架的,硬凑在一起就是自相矛盾,看着就别扭。
承认这一点不丢人。敏捷宣言 2001 年写的时候,世界上还没有能读懂自然语言规格、自己写代码的机器。那时候详尽文档确实是负担,因为写完就过时,还没人维护。现在不一样了,文档是 agent 唯一能精确接收的指令。文档过时,agent 就给你生成一堆漂移的、幻觉的、看着对其实跑不通的代码。
所以「软件高于文档」这条,在 agent 时代得改。我认。
但只有这一条。
一条被掀翻，三条反而被焊死了
很多人看到一条价值观被推翻,就慌了,以为整个敏捷塌了。
恰恰反过来。剩下那几条,在 agent 时代不是变弱,是被焊死了。
「拥抱变化,高于遵循计划」——以前改需求,得排期、估点、等下个迭代。现在?我改一句 spec,agent 半小时给我重新生成一版。变化的成本被压到了地板上,拥抱变化第一次成了真的,而不是 PPT 上的口号。
「可工作的软件是首要进度度量」——这条更狠了。以前一个 sprint 两周,两周后才有可演示的东西。现在 agent 一晚上就能跑出能点的原型。进度不再按 sprint 算,按小时算。
最关键的是反馈循环。
敏捷的命根子就是反馈快。过去我们把反馈循环从「半年一次大版本」压缩到「两周一个 sprint 」,就觉得自己很敏捷了。现在 agent 把它压缩到了——分钟级。它写完一段,测试套件立刻跑,挂了立刻改。
两周,变成两分钟。这才是敏捷宣言里那个「频繁交付、尽早反馈」的精神被推到的极致。
我做测试的,对这条体会最深。测试不再是 sprint 末尾那道关卡了。它前移到了 spec 阶段——你写规格的时候,验收标准就得写清楚,因为 agent 是照着这个标准来生成和自测的。 spec 写得含糊,agent 就给你瞎糊弄,生成一坨看着能跑实则全是坑的玩意儿,返工返到你想砸键盘。测试左移,左移到了代码还没出生的时候。
所以你看,敏捷的「仪式」死了(站会、估点、燃尽图),敏捷的一条「价值观」被反转了(文档),但敏捷的「内核」——快速反馈、拥抱变化、可工作软件优先——反而活得比任何时候都精神。
这事的本质是:大家一直把「 scrum 的那套仪式」当成了敏捷本身。 AI agent 来了,正好帮我们把仪式的壳敲碎,露出里面真正值钱的内核。
那接下来,你该停掉哪个会
我不知道你团队具体长啥样,所以下面这些只是我自己的判断,你掂量着用。
如果你团队已经在大规模用 coding agent,我的建议很简单:别再纠结「敏捷还适不适用」这个伪问题。敏捷从来不是一套会议日程。
但你的团队不是我的团队。也许你那儿,那十分钟的面对面,本身就是唯一能让大家还像个团队的东西。
那这场会,到底是仪式,还是粘合剂?
这个我替你答不了。
