AI 编程时代，Scrum 该怎么变？

一个真实的尴尬

我曾经当前 Scrum Master 和 Production Owner, 回想以前的 Sprint Planning，两个小时的会，大家围着一堆用户故事打扑克牌(Planning Poker)。就算是一个"用户登录"的故事，也能讨论个二十分钟——要不要支持 OAuth？密码策略怎么定？错误提示怎么写？最后估了 8 个故事点。

现在呢, 这个功能用 Claude Code 从 spec 到代码到测试，连 OAuth 带 JWT 带密码策略，四十分钟就能搞定。

这不是炫耀 AI 有多厉害。我想说的是：当实现一个功能的时间从"天"缩短到"小时"，咱们花两个小时讨论它该怎么估算，是不是有点本末倒置了？

Scrum 不是不好。2001 年敏捷宣言说得很清楚——"个体和互动高于流程和工具，响应变化高于遵循计划"。可是很多团队把 Scrum 的仪式当成了敏捷本身，忘了敏捷的初心是快速交付有价值的软件。

AI 编程时代，这些仪式该重新掂量掂量了。

Scrum 的哪些假设被打破了？

Scrum 框架建立在几个隐含假设之上。三十年前它们成立，现在有些已经松动了。

假设一："编码是最耗时的环节"

传统 SDLC 里，编码占了开发周期的大头。所以 Scrum 把精力放在规划和协调上——先想清楚做什么，再动手写，避免返工。

现在呢？AI 把编码的边际成本压到了接近零。写一个 CRUD 接口，以前要半天，现在 Copilot 补全加 Claude 生成，十分钟。瓶颈从"写代码"转移到了"想清楚要什么"和"验证对不对"。

传统瓶颈分布：
  需求(15%) → 设计(15%) → 编码(40%) → 测试(20%) → 部署(10%)

AI 时代瓶颈分布：
  需求(30%) → 设计(25%) → 编码(5%) → 验证(30%) → 部署(10%)

编码不再是瓶颈，围绕"编码工作量"设计的估算和排期体系自然就需要重新校准。

假设二："两周是合理的迭代周期"

Sprint 的长度通常是一到四周，最常见的是两周。这个节奏是基于"从需求到可交付软件需要一定时间"的经验。

可是 AI 编程把这个时间大幅压缩了。一个有经验的开发者配合 AI，一天之内就能完成从原型到可测试版本的全流程。两周的 Sprint 里，可能第三天就把活干完了，剩下的时间在等下一个 Sprint Planning。

迭代周期应该跟着交付节奏走，而不是跟着日历走。

假设三："团队需要频繁同步来保持对齐"

每日站会的初衷是好的——让团队成员知道彼此在做什么，及时发现阻塞。可是在 AI 辅助开发的场景下，很多"阻塞"已经被 AI 化解了：

• 不知道某个 API 怎么用？问 AI
• 代码有 bug 跑不通？让 AI 调试
• 不确定架构方案？让 AI 给几个选项对比

以前需要等同事回复、等架构师评审的事情，现在很多可以自己搞定。同步的频率应该取决于真正需要人与人协调的事项，而不是固定的日历节奏。

假设四："故事点能反映工作量"

故事点估算的是"相对复杂度"，但它隐含了一个前提：复杂度和工作量之间有稳定的映射关系。

AI 打破了这个映射。一个"复杂"的功能(比如实现一个完整的认证系统)，如果 AI 能很好地处理，实际工作量可能很小。一个"简单"的功能(比如修复一个诡异的并发 bug)，如果 AI 帮不上忙，反而要花很长时间。

复杂度不再等于工作量。估算体系需要重新校准。

不是废掉 Scrum，是让它回归初心

我不是说 Scrum 该扔了。敏捷宣言的四条价值观——个体和互动、工作的软件、客户合作、响应变化——在 AI 时代反而更重要。

要扔的是那些已经变成形式主义的仪式。

咱们一个一个看。

Sprint Planning → 意图对齐会

传统的 Sprint Planning 花大量时间在"这个故事怎么拆、怎么估、谁来做"上。AI 时代，这些问题的答案变了：

• 怎么拆？ 让 AI 根据 spec 自动拆分任务
• 怎么估？ 编码成本趋近于零，估算的重点转向"验证成本"和"风险"
• 谁来做？ 很多任务变成了"人 + AI"的组合，分工方式不同了

我建议把 Sprint Planning 改成意图对齐会(Intent Alignment)：

## 意图对齐会(30分钟，不超过1小时)

### 1. 本周要解决什么问题？(10分钟)
- 不是列 story，是讲清楚业务目标
- "用户注册转化率太低" 比 "实现 OAuth 登录" 更有价值

### 2. 验收标准是什么？(10分钟)
- 怎么算"做完了"？
- 谁来验证？用什么方式验证？

### 3. 有什么风险和依赖？(10分钟)
- 哪些事情 AI 搞不定，需要人来协调？
- 有没有跨团队的依赖？

注意，没有估算环节。因为在 AI 辅助下，大多数功能的实现时间已经短到不值得精确估算。把时间花在"想清楚要什么"上，比花在"猜要多久"上划算得多。

Daily Standup → 异步状态同步

每天固定时间、固定地点、站着开 15 分钟的会——这个仪式在远程办公和 AI 编程的双重冲击下，越来越尴尬了。

很多团队的站会变成了这样：

"昨天我做了 XXX，今天继续做 XXX，没有阻塞。" "昨天我做了 YYY，今天继续做 YYY，没有阻塞。" (重复 N 次)

这种信息完全可以异步传递。我的建议是用 AI 自动生成每日状态报告，替代站会：

## 每日状态(AI 自动生成)

### 代码变更摘要
- PR #142: 用户认证模块重构(已合并)
- PR #143: 订单导出功能(Review 中)

### 测试状态
- 单元测试：通过 247/250(3 个新增待修复)
- E2E 测试：全部通过

### 阻塞项
- 无自动检测到的阻塞
- [手动标记] 等待第三方支付 API 的沙箱环境

### AI 辅助统计
- 今日 AI 生成代码：约 340 行
- 人工修改比例：18%

真正需要讨论的事情——架构决策、跨团队协调、技术方案分歧——开专题会解决，别塞在站会里。

Sprint Review → 持续演示

两周一次的 Sprint Review，本意是给利益相关者展示成果、收集反馈。可是两周的反馈周期在 AI 时代太慢了。

一个功能从想法到可演示的原型，可能只需要一天。为什么要等两周才给人看？

改成持续演示(Continuous Demo)：

• 功能做完就演示，不等 Sprint 结束
• 用录屏或者部署到预览环境，异步收集反馈
• 每周有一个固定的"开放时间"，利益相关者可以来看最新进展

传统节奏：
  Sprint 1 ──────────────── Review ── Sprint 2 ──────────────── Review
  (两周)                              (两周)

持续演示：
  功能A ── Demo ── 功能B ── Demo ── 功能C ── Demo ── 功能D ── Demo
  (1-3天)          (1-2天)          (2-4天)          (1天)

Sprint Retrospective → 保留，但换个开法

回顾会是 Scrum 里我最认可的仪式。团队停下来反思"什么做得好、什么可以改进"，这个习惯在任何时代都有价值。

但回顾的内容得变。以前讨论的是"代码评审流程太慢""测试覆盖率不够"，现在应该讨论：

• AI 在哪些场景帮了大忙？哪些场景帮倒忙？
• 哪些 prompt 模式效果好？值得团队共享？
• AI 生成的代码出过什么质量问题？怎么预防？
• 人和 AI 的分工合理吗？有没有该人做的事交给了 AI，或者反过来？

## AI 时代回顾会模板

### AI 加速了什么？
- 用 Claude 生成的测试用例质量很高，省了两天
- Cursor 的多文件编辑在重构时特别好用

### AI 搞砸了什么？
- AI 生成的数据库迁移脚本有个隐含的数据丢失风险，差点上线
- 过度依赖 AI 补全，引入了一个已废弃的 API

### 人机协作怎么改进？
- 需要建立 AI 生成代码的 review checklist
- 复杂的并发逻辑还是人写更靠谱

### 值得共享的 prompt/workflow
- @张三 发现的"先写测试再让 AI 实现"的工作流很高效

新的角色定义

AI 不只改变了流程，也改变了角色。

Product Owner → 意图架构师

PO 的核心职责从"写用户故事"变成了"定义清晰的意图"。AI 能把模糊的需求变成代码，但"模糊"的程度决定了结果的质量。

好的意图描述长这样：

# 不是用户故事，是意图规格
intent: "提升用户注册转化率"
context:
  current_conversion: "23%"
  target_conversion: "35%"
  constraints:
    - "不增加注册步骤"
    - "符合 GDPR 要求"
    - "移动端优先"
acceptance_criteria:
  - "A/B 测试显示转化率提升 > 10%"
  - "注册流程 < 60 秒完成"
  - "所有表单字段有实时校验"

这比"作为用户，我想要更简单的注册流程，以便我能更快地开始使用产品"有用得多。就好比你给实习生布置任务，说"把这个页面弄好看点"和给一份设计稿附带标注，出来的东西能一样吗？

我以前带实习生时, 布置任务就是给一个需求文档, 再叮嘱几个注意事项和要求的完成时间, 再让他参考以前的代码, 然后让他们去实现. 现在呢, 我会给一个 spec, 然后让 AI 去实现. 这个 spec 就是意图规格, 它和当年告诉实习生的需求文档和注意事项, 本质上是一样的. 只不过现在换成了 AI 来实现.

Scrum Master → 流程教练 + AI 协作教练

Scrum Master 的角色变化最大。以前主要是"确保团队遵循 Scrum 流程"，现在这个职责的价值在下降——流程本身在简化。

新的价值在三个方面：

1. AI 协作教练：帮团队成员更好地使用 AI 工具，建立人机协作的套路。就像武术中的套路，好的 prompt workflow 也得靠练。
2. 质量守门人：确保 AI 生成的代码经过充分验证，不让速度牺牲质量
3. 持续改进推动者：回顾会的引导者角色不变，但讨论内容转向人机协作的优化

开发者 → 意图表达者 + 质量验证者

开发者的日常从"写代码"变成了"表达意图 + 验证结果"：

传统开发者的一天：
  09:00 站会
  09:15 看需求文档
  09:30 开始写代码
  12:00 午饭
  13:00 继续写代码
  16:00 写测试
  17:00 提 PR
  17:30 下班

AI 时代开发者的一天：
  09:00 看今日目标(异步)
  09:10 写意图描述 / spec
  09:30 AI 生成代码，人 review
  10:00 补充边界条件，AI 重新生成
  10:30 运行测试，修复 AI 遗漏的问题
  11:00 第一个功能完成，开始第二个
  12:00 午饭
  13:00 处理需要深度思考的架构问题
  15:00 Review 同事的 AI 生成代码
  16:00 写文档(AI 辅助)
  17:00 下班

注意看，一天能完成的功能数量从"一个的一部分"变成了"两到三个"。但验证和 review 的时间占比大幅增加——这才是开发者在 AI 时代真正该花精力的地方。

一个实际的转型方案

说了这么多，落地怎么做？不能一夜之间把 Scrum 全改了，团队会炸。

我建议分三步走：

第一步：缩短 Sprint，减少仪式(1-2 个月)

• Sprint 从两周缩到一周
• Planning 从两小时缩到一小时
• 站会从每天改成每周两次(周一、周四)
• 其余时间用异步状态同步替代

第二步：引入 AI 辅助流程(2-4 个月)

• 用 AI 自动生成每日状态报告
• 用 AI 辅助需求拆分和任务分配
• 建立 AI 生成代码的 review checklist
• 回顾会增加"人机协作"议题

第三步：转向持续流动(4-6 个月)

• 取消固定 Sprint 周期，改为持续交付
• Planning 变成每周一次的意图对齐会
• 功能完成即演示，不等固定节点
• 保留双周回顾会，聚焦持续改进

转型路径：

阶段1: 精简 Scrum          阶段2: AI 增强           阶段3: 持续流动
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ 1周 Sprint   │     │ AI 状态报告  │     │ 取消 Sprint  │
│ 1小时 Plan   │ ──→ │ AI 需求拆分  │ ──→ │ 意图对齐会   │
│ 2次/周 站会  │     │ Review清单   │     │ 持续演示     │
│ 保留回顾会   │     │ AI协作回顾   │     │ 双周回顾     │
└──────────────┘     └──────────────┘     └──────────────┘

几个常见的反对意见

"没有 Sprint 怎么做计划？"

Sprint 不是唯一的计划方式。Kanban 的"限制在制品数量"、Shape Up 的"六周周期 + 两周冷却"、甚至简单的"每周一对齐目标"都是可行的替代方案。关键是有节奏，而不是固定节奏。

"没有估算怎么跟老板汇报进度？"

用"已交付的功能数"和"业务指标变化"替代"燃尽图"。老板真正关心的不是你消耗了多少故事点，而是产品有没有变好。

"AI 生成的代码质量不行，不能这么激进。"

这恰恰说明验证环节需要加强，而不是说流程不能变。把省下来的 Planning 和站会时间，投入到 code review 和测试上，整体质量只会更好。

"我们团队还没用 AI 编程工具。"

那第一步不是改流程，是先让团队用起来。工具先行，流程跟上。

New Scrum with AI Checklist

搞转型不能光靠感觉，得有个 checklist 逐项对照。下面这张清单覆盖了流程、角色、工具、质量四个维度，打印出来贴墙上，每完成一项打个勾。

流程瘦身

• [ ] Sprint 周期从两周缩到一周(过渡期)，最终转向持续交付
• [ ] Planning 会议控制在 30-60 分钟，聚焦"要解决什么问题"而非"怎么估点数"
• [ ] 取消 Planning Poker，改用"风险/验证成本"二维评估
• [ ] Daily Standup 改为异步状态同步(Slack/飞书/Teams bot 自动推送)
• [ ] 仅在有阻塞项或架构分歧时召开同步会议
• [ ] Sprint Review 改为"功能完成即演示"，不等固定节点
• [ ] 部署预览环境，让利益相关者随时能看最新进展
• [ ] 保留双周回顾会，增加"人机协作"专题

角色重新定义

• [ ] PO 输出格式从用户故事升级为意图规格(intent spec)，包含上下文、约束、验收标准
• [ ] Scrum Master 增加 AI 协作教练职责，定期分享 AI 工具使用技巧
• [ ] Scrum Master 兼任质量守门人，确保 AI 生成代码经过充分验证
• [ ] 开发者建立"意图描述 → AI 生成 → 人工验证"的工作节奏
• [ ] 开发者把 review 和测试时间占比提升到 40% 以上

AI 工具集成

• [ ] 团队统一 AI 编程工具(Cursor / Copilot / Claude Code 等)，确保每个人都会用
• [ ] 搭建 AI 自动生成每日状态报告的流水线(基于 PR、测试、部署数据)
• [ ] 用 AI 辅助需求拆分——将意图规格自动拆解为可执行任务
• [ ] 建立团队级 prompt 库，积累好用的 prompt 模式和 workflow
• [ ] 在 CI/CD 中集成 AI 代码扫描(安全漏洞、废弃 API、性能问题)

质量守护

• [ ] 制定 AI 生成代码的 review checklist(数据库操作、并发逻辑、边界条件、安全合规重点审查)
• [ ] AI 生成的数据库迁移脚本必须人工 double-check 后才能合并
• [ ] 复杂并发逻辑、安全敏感模块标记为"人工编写优先"
• [ ] 建立 AI 代码质量度量：人工修改比例、AI 引入 bug 数、回滚率
• [ ] 回顾会固定讨论："AI 这个周期帮了什么忙？搞砸了什么？"

转型节奏

• [ ] 第 1-2 个月：精简 Scrum(缩短 Sprint、减少会议、试行异步同步)
• [ ] 第 2-4 个月：AI 增强(接入 AI 工具、自动化状态报告、建立 review 清单)
• [ ] 第 4-6 个月：持续流动(取消固定 Sprint、意图对齐会、持续演示)
• [ ] 每个阶段结束做一次团队满意度调查，用数据决定是加速还是回调

不用一次全勾完。挑 3-5 项最痛的点先改，跑两个迭代看效果，再决定下一步。转型是渐进的，别搞大跃进。

写在最后

2001 年，敏捷宣言的起草者们聚在雪鸟滑雪场，对抗的是瀑布模型的繁文缛节。他们说：别写那么多文档了，先把软件跑起来。

二十五年后，咱们面对的是另一种繁文缛节——Scrum 自己的繁文缛节。两周一个 Sprint、每天一个站会、每个故事都要估点数、每个 Sprint 都要 Review 和 Retro……这些仪式诞生之初是有道理的，但当 AI 把开发速度拉快了一个数量级，它们中的一部分已经从"有用的约束"变成了"无谓的摩擦"。

敏捷宣言的第一条说得好：个体和互动高于流程和工具。

AI 是工具，Scrum 是流程。真正重要的，是团队里的人能不能高效协作、快速交付有价值的东西。某个仪式帮了这件事，留着；只是在消耗时间，果断砍掉。

一句话：别让流程跑在价值前面。

Reference

• Agile Manifesto
• Scrum Guide
• Shape Up by Basecamp
• Kanban Guide

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。