---
name: retrospective
description: 根据笔记、便利贴或问卷主持一次团队复盘：哪些做得好、哪些不好、反复出现的模式、用简短的 5 个为什么找根因，以及 1 到 3 个各有负责人和日期的改进实验，可用“好/不好/下次试试”、Start/Stop/Continue 或 4L 格式。适用于团队要开或整理复盘会、迭代回顾（Sprint Retrospective）、项目复盘、经验总结，或问“下次该改什么”时。
---

# 团队复盘

只有下一个迭代或项目真的有所不同，这一小时的复盘才值得。Scrum 指南的说法是：规划“提高质量和效能的方法”。所以产出不是一串感受，而是团队要尝试的 1 到 3 个改变，每个都有负责人和日期，并且先检查上次复盘的改进项。

## 适用场景

- 一个迭代、项目、发布或季度结束时。
- 团队手上有原始输入（问卷回答、便利贴、Slack 讨论串），需要归纳成主题和行动。
- 现场主持前，先准备主持人的流程安排。
- 不适用于影响到客户的单次事故：那种情况请写带时间线的事故复盘。

## 需要准备

- 原始输入：笔记、问卷回答或看板导出。如果没有，就给出主持流程和空白模板。
- 覆盖的时间段或项目，以及参与者。
- 上次复盘的行动项（如有）。没有的话，写“没有上次行动项的记录”。
- 偏好的格式。没有的话，用“做得好 / 做得不好 / 下次试试”（这个技能的既定格式；它最直白）。

## 步骤

1. **先检查上次复盘的行动项。** 每一项：已完成、未完成或已放弃，用一行说明情况。如果超过一半没完成，这次的第一个实验就是：行动项更少、更小。
2. **选格式。** 大多数团队用“做得好 / 做得不好 / 下次试试”。团队需要改变行为时用 Start / Stop / Continue。这段时间学到很多东西时（比如第一次发布）用 4L（Loved 喜欢、Loathed 讨厌、Learned 学到、Longed for 期望）。一次复盘只用一种格式。
3. **把输入归纳成主题。** 合并重复项，统计每个主题有几个人提到。找反复出现的模式，而不是一次性事件。排名靠前的主题，用引号保留参与者的原话；除非输入本来就署了名，否则隐去姓名。
4. **找出前 2 个问题的根因。** 一直问“为什么？”，直到找到团队能改变的东西。精益企业研究院（Lean Enterprise Institute）把这个方法追溯到丰田的大野耐一，并指出“5”这个数字并不是重点。遇到团队无法控制的原因就停下，并说明。绝不停在某个人身上（“小王忘了”）：要问流程为什么让这件事可能被忘掉。
5. **选 1 到 3 个实验。** 每个实验都是下一阶段的一个具体改变，小到可以尝试，有一位负责人（一个人）、一个复查日期，以及怎么判断它有效。如果团队提了 8 个行动，保留预期效果最大的 3 个，其余暂缓。
6. **现场开会的话，安排流程。** 60 分钟的会，Atlassian 的 Team Playbook 这样分配：定基调（5 分钟）、收集输入（15）、找模式（20）、选行动（15）、收尾（5）。提醒大家，目的是改进，不是追责。

## 输出格式

```markdown
# 复盘 — [团队 / 项目]，[时间段]

**格式：** [做得好 / 做得不好 / 下次试试 | Start/Stop/Continue | 4L]
**参与者：** [姓名或人数]

## 上次复盘的行动项
| 行动 | 负责人 | 状态 | 情况 |
|---|---|---|---|
| [行动] | [姓名] | 已完成 / 未完成 / 已放弃 | [一行] |

## 做得好的
- [主题] — [n] 人提到 — “[有代表性的原话]”

## 做得不好的
- [主题] — [n] 人提到 — “[有代表性的原话]”

## 根因
**[问题 1]**
- 为什么？[回答] → 为什么？[回答] → 为什么？[回答] → 根因：[团队能改变的东西]

## 下一个[迭代 / 项目]的实验
| 实验 | 负责人 | 复查时间 | 怎样算有效 |
|---|---|---|---|
| [具体的改变] | [姓名] | [日期] | [可观察的信号] |

## 暂缓
- [这次没选中的想法]
```

## 示例

**输入：**“平台组，第 14 个迭代复盘，6 个人（产品经理：林娜），问卷回答：‘演示很成功’（3）、‘导入模块结对编程很有帮助’（2）、‘临时改需求太多’（4）、‘测试周四才拿到构建，没时间测’（3）、‘站会开 25 分钟’。上次复盘的行动项：‘张颖搭建预发布环境’——已完成，第 3 天起上线。讨论中提到：需求在最后 2 天才完成；后期改需求导致 2 个需求重做；迭代规划后的需求直接找到开发。”

**输出：**

```markdown
# 复盘 — 平台组，第 14 个迭代

**格式：** 做得好 / 做得不好 / 下次试试
**参与者：** 6 人

## 上次复盘的行动项
| 行动 | 负责人 | 状态 | 情况 |
|---|---|---|---|
| 搭建预发布环境 | 张颖 | 已完成 | 第 3 天起上线 |

## 做得好的
- 迭代演示 — 3 人提到 — “演示很成功”
- 导入模块的结对编程 — 2 人提到

## 做得不好的
- 后期改需求 — 4 人提到 — “临时改需求太多”
- 测试时间被挤压到最后 — 3 人提到 — “测试周四才拿到构建，没时间测”
- 站会太长 — 1 人提到

## 根因
**测试时间被挤压到最后**
- 为什么？构建周四才到测试手上 → 为什么？需求在最后 2 天才完成 → 为什么？后期改需求导致 2 个需求重做 → 为什么？迭代规划后的需求直接找到开发 → 根因：迭代规划之后的变更没有规则。

## 下一个迭代的实验
| 实验 | 负责人 | 复查时间 | 怎样算有效 |
|---|---|---|---|
| 规划后的变更统一经过产品经理，由产品经理换出一项已有工作 | 林娜（产品经理） | 第 15 个迭代复盘 | 迭代中途重做的需求为零 |
| 测试在迭代结束前至少 2 天拿到构建 | 张颖 | 第 15 个迭代复盘 | 测试反馈有 2 天以上的测试时间 |

## 暂缓
- 缩短站会（只有 1 人提到；再次出现时再讨论）
```

## 发送前检查

- [ ] 列出任何新行动之前，上次复盘的行动项都有了状态。
- [ ] 实验不超过 3 个，每个都有一位指名的负责人、复查日期和成功信号。
- [ ] 每条根因链都止于团队能改变的东西，而不是某个人的名字。
- [ ] 主题的人数与输入一致；没有引用任何没人说过的话。
- [ ] 除非输入本来就署了名，个人意见都是匿名的。

## 常见错误

- 以“加强沟通”收尾。写清楚改变：谁、做什么不一样、从什么时候开始。
- 写 10 个行动项。团队能完成 1 到 3 个；其余的会消磨大家对复盘的信任。
- 跳过做得好的部分。它告诉团队在做改变时要保住什么。