敏捷宣言

为什么很多团队无法达成真正的敏捷开发？

因为敏捷对人的要求很高。

• “个体和互动 高于 流程和工具”，要求大家语言一致，理解一致，最好我说半句，你就知道后半句是什么。
• “工作的软件 高于 详尽的文档”，要求大家对代码足够熟，不然没有文档，心里就发虚。
• “客户合作 高于 合同谈判”，要求大家能理解需求，知道客户嘴上说的是什么，背后真正要的又是什么。
• “响应变化 高于 遵循计划”，要求大家既能快速执行，又能在未知领域里不乱掉。

说到底，这些话的意思都是一样的：团队成员要有比较一致的业务能力、技术能力和协作能力。最好你一个眼神，我就 get 到你是想创建接口、重构实现，还是准备砍需求、改设计。

这是个很高的要求。

敏捷工程实践

看一眼敏捷宣言的签署者名单，也确实，他们大概是有这个能力和认知的。

但现实是，你是不可能在招聘市场上找到 Martin Fowler、Kent Beck 的；你也没法克隆你自己，来组成一个共享脑电波的团队。

所以，我们才需要各种敏捷的仪式：Standup、IPM、Sprint Review、Retrospective、Backlog Refinement；各种技术实践：Pair Programming、TDD、重构、Code Review。

当然，通常被吐槽“假敏捷”的对象，也是这些“仪式”：站会过流水账，评审开成老板秀，回顾是吐槽大会，结对成了示范表演，Code Review 成了一起来找茬。

因为本质上，这些活动都是为了达成敏捷宣言里那个高要求：同认知、同能力。

• 降低任务复杂度的上限。Backlog Refinement、IPM 先做需求分析、任务拆分，再靠各种会议同步信息、传递上下文，尽量别让大家各自脑补，最后做出来五个版本。
• 提升团队能力的下限。Pair、mentor、分享、Code Review，本质上都是在做人才梯队，让新加入的同事尽快接近平均能力线，而不是全靠几个老师傅硬撑。

一上一下，把团队的能力提升到基线以上，你才能谈后面的东西：迭代式开发、估点、自由捡卡、Trunk-Based 开发、自动化测试替代一部分 Code Review。

Agent as Colleague

Agent 的能力，当然还是取决于使用者的能力和技巧。你问得清不清楚，拆得好不好，约束写没写明白，差别会很大。

和人一样，你需要去训练它，培养它，甚至是管理它。你得让它知道什么样的结果是好结果，什么样的结果是坏结果；你得让它知道什么样的行为是被鼓励的，什么样的行为是被禁止的；你得让它知道什么样的目标是重要的，什么样的目标是次要的。

另外，Agent 还具备两个人类同事没有的特点：

一个是，它的能力可以大量复制。Multi-Agent、Sub-Agent 可以并行跑起来。你不是多了一个助手，你是多了一个可以随时拉起来的小队。

另一个是，它的能力几乎可以即时获得。Skills 即插即用，你不需要等新人培训。装上 Frontend Skill，马上就能帮你写 React 组件。

如果把 Agent 当成团队成员来看，你会发现它天然接近敏捷的需要：同认知、同能力，而且还能横向扩容、纵向升级。

• “个体和互动 高于 流程和工具” —— 某种意义上，真的就是 chat with agent。
• “工作的软件 高于 详尽的文档” —— agent 会去读你的代码，而且通常读得很认真。
• “客户合作 高于 合同谈判” —— 你不用谈判，你自己就是需求方。
• “响应变化 高于 遵循计划” —— 你随时改主意，它就跟着重跑。

200x??

上个月，我利用 Agent 重写了一个内部工具。1 human + 3~5 Agents 的团队组合，最后评估出来的效率提升接近 200x。

这个数字单看，确实有点夸张，像某种卖课营销号。

但如果你把这些 Agents 都当成真实可协作的同事来看，这件事就没那么玄了。无非是一个 6 人的全功能团队：1 个 PO/BA，加上 5 个 developer/tester。

这样一拆，平均下来，也就是 30x 左右。

再往下算，还有很多以前默认会消耗的时间被省掉了：会议、培训、上下文同步、等人、找人、休息、吃饭。硅基生物毕竟只吃电，不吃外卖。

再平均一下，可能也就10x —— 顶尖程序员可以达成的量级。

所以，Agent 不只是代码写得快。更重要的是，它是以团队的方式在工作。它的效率提升，来源于它在多个维度上放大了人的能力：执行力、协作力、学习力。

如果你对这个 rewrite 的过程感兴趣，也可以看我前面那篇 从数月到一周：Agent Coding 的治理闭环。

ThoughtWorks

ThoughtWorks 是一家优秀的公司。很多时候，它更像一所大学。

现在回头看，在 ThoughtWorks 里的典型成长路线，是 “Thought Worker”：先分析，再思考，最后才是写代码。

我们那时候很看重敏捷、Pair、TDD、DDD 这类训练，每天讨论建模、分析、评估，各种框架和方法论。

以前有一段时间，我其实也会疑惑：为什么要花这么多时间在这些和写代码不相关的事情上？直接 CRUD 不好吗？

现在再看，这些能力恰恰决定了你能带出的Agent 团队的规模和质量。

作为 Tech Lead，你个人能力再强，也未必能稳定做到 10x 于别人。

能不能把问题定义清楚，能不能做好拆解，能不能识别边界和风险，能不能把模糊需求变成稳定约束，却决定了你能不能带出 10x 团队。

• Pair、TDD、DDD 分别训练沟通协作、边界识别、抽象建模，敏捷训练反馈和调整。
• 就连当初的“博客大赛”，现在回头看，锻炼的也不只是写作能力。它训练的是表达能力：把你脑子里的东西讲清楚。放到今天，这就是和 Agent 准确沟通的必须技能。

某种意义上，“1 带 8” 在另一个维度实现了。