---
name: retrospective
description: 根據筆記、便利貼或問卷進行團隊回顧（retro）：做得好的、做得不好的、反覆出現的模式、用簡短的 5 個為什麼找出的根本原因，以及 1 到 3 個各有負責人和日期的實驗，格式可用「做得好／做得不好／下次試試」、Start/Stop/Continue 或 4L。適用於團隊要進行或整理 retro、Sprint 回顧、專案結案檢討、經驗教訓（lessons learned），或問「下次該改什麼」時。
---

# 團隊回顧

只有下一個 Sprint 或專案真的跑得不一樣，花一小時開 retro 才值得。Scrum Guide 把它說成規劃「提升品質和成效的方法」。所以產出不是一串感受，而是團隊要嘗試的 1 到 3 個改變，每個都有負責人和日期，並且先檢查上次 retro 的行動。

## 適用情境

- Sprint、專案、上線或一季結束時。
- 團隊手上有原始資料（問卷回答、便利貼、Slack 討論串），需要整理成主題和行動。
- 現場主持之前，先準備主持人的流程。
- 不適用於對客戶有影響的單一事故：請改寫附時間軸的事故檢討。

## 需要準備

- 原始資料：筆記、問卷回答或看板匯出。完全沒有時，產出主持流程和空白範本。
- 涵蓋的期間或專案，以及參加的人。
- 上次 retro 的行動（如果有）。沒有的話，寫「沒有上次行動的紀錄」。
- 偏好的格式。沒有指定時，用「做得好／做得不好／下次試試」（這個技能的預設值；最直白）。

## 步驟

1. **先檢查上次 retro 的行動。** 每一項：完成、未完成或放棄，用一行說明發生了什麼。如果超過一半沒完成，這次的第一個實驗就是把行動變少、變小。
2. **選擇格式。** 大多數團隊用「做得好／做得不好／下次試試」。團隊需要改變行為時，用 Start / Stop / Continue。這段期間學到很多（例如第一次上線）時，用 4L（Loved 喜歡、Loathed 討厭、Learned 學到、Longed for 渴望）。一場 retro 不要混用格式。
3. **把資料歸納成主題。** 合併重複的內容，計算每個主題有幾個人提出。找反覆出現的模式，而不是一次性的事件。主要主題保留參與者的原話並加上引號；除非輸入本來就有署名，否則人名要匿名。
4. **找出前 2 個問題的根本原因。** 一直問「為什麼？」，直到找到團隊能改變的東西。精實企業研究所（Lean Enterprise Institute）把這個方法追溯到豐田的大野耐一，並指出重點不在數字 5。碰到團隊無法控制的原因就停下來，並寫明。絕不停在某個人身上（「志明忘了」）：要問為什麼流程會讓這件事被忘記。
5. **挑 1 到 3 個實驗。** 每個都是下一個週期的具體改變，小到可以嘗試，有一位負責人（一個人）、一個檢討日期，以及怎麼知道它有效。如果團隊提出 8 個行動，保留預期效果最大的 3 個，其餘先擱置。
6. **如果是現場進行，規劃流程。** 以 60 分鐘為例，Atlassian 的 Team Playbook 這樣分配：定調（5）、收集意見（15）、找出模式（20）、選定行動（15）、收尾（5）。提醒大家目的是改進，不是究責。

## 輸出格式

```markdown
# Retro — [團隊／專案]，[期間]

**格式：** [做得好／做得不好／下次試試 | Start/Stop/Continue | 4L]
**參與者：** [姓名或人數]

## 上次 retro 的行動
| 行動 | 負責人 | 狀態 | 發生了什麼 |
|---|---|---|---|
| [行動] | [姓名] | 完成／未完成／放棄 | [一行] |

## 做得好的
- [主題] — [n] 人提出 — 「[代表性的原話]」

## 做得不好的
- [主題] — [n] 人提出 — 「[代表性的原話]」

## 根本原因
**[問題 1]**
- 為什麼？[回答] → 為什麼？[回答] → 為什麼？[回答] → 根本原因：[團隊能改變的東西]

## 下一個 [Sprint／專案] 的實驗
| 實驗 | 負責人 | 檢討日 | 怎麼知道有效 |
|---|---|---|---|
| [具體的改變] | [姓名] | [日期] | [看得到的訊號] |

## 暫時擱置
- [這次沒選的想法]
```

## 範例

**輸入：** 「平台團隊 Sprint 14 retro，6 個人，PM 是林怡伶。問卷回答：『Demo 很成功』（3）、『匯入功能用結對程式設計很有幫助』（2）、『最後一刻的範圍變更太多』（4）、『QA 週四才拿到 build，沒時間測』（3）、『站立會議開了 25 分鐘』。現場討論補充：story 都在最後 2 天才完成；有 2 個 story 因為臨時變更範圍而重做；規劃會議後的新需求都直接找工程師。上次 retro 的行動：『安琪建立 staging 環境』— 已完成，第 3 天起上線。」

**輸出：**

```markdown
# Retro — 平台團隊，Sprint 14

**格式：** 做得好／做得不好／下次試試
**參與者：** 6 人

## 上次 retro 的行動
| 行動 | 負責人 | 狀態 | 發生了什麼 |
|---|---|---|---|
| 建立 staging 環境 | 安琪 | 完成 | 第 3 天起上線 |

## 做得好的
- Sprint demo — 3 人提出 — 「Demo 很成功」
- 匯入功能的結對開發 — 2 人提出

## 做得不好的
- 臨時的範圍變更 — 4 人提出 — 「最後一刻的範圍變更太多」
- QA 在最後被壓縮 — 3 人提出 — 「QA 週四才拿到 build，沒時間測」
- 站立會議太長 — 1 人提出

## 根本原因
**QA 在最後被壓縮**
- 為什麼？build 週四才到 QA 手上 → 為什麼？story 都在最後 2 天才完成 → 為什麼？臨時的範圍變更讓 2 個 story 重做 → 為什麼？規劃會議後的需求直接找工程師 → 根本原因：沒有規範 Sprint 規劃後的變更怎麼處理。

## 下一個 Sprint 的實驗
| 實驗 | 負責人 | 檢討日 | 怎麼知道有效 |
|---|---|---|---|
| 規劃後的變更一律經過 PM，由 PM 拿掉另一項來交換 | 林怡伶（PM） | Sprint 15 retro | Sprint 中途重做的 story 為零 |
| QA 至少在 Sprint 結束前 2 天拿到 build | 安琪 | Sprint 15 retro | QA 回報有 2 天以上可以測試 |

## 暫時擱置
- 縮短站立會議（只有 1 人提出；如果再出現就重新討論）
```

## 寄出前檢查

- [ ] 列出任何新行動之前，上次 retro 的行動都已標上狀態。
- [ ] 實驗不超過 3 個，每個都有一位具名負責人、檢討日期和成功訊號。
- [ ] 每條根本原因的追問鏈都停在團隊能改變的東西，而不是某個人的名字。
- [ ] 主題的人數和輸入一致；沒有引用任何沒人說過的話。
- [ ] 除非輸入本來就有署名，否則個人意見都已匿名。

## 常見錯誤

- 以「加強溝通」作結。要寫出具體的改變：誰從什麼時候開始，做法有什麼不同。
- 寫出 10 個行動。團隊能完成的是 1 到 3 個；其餘只會消磨大家對 retro 的信任。
- 略過做得好的部分。它告訴團隊在改變時要保護什麼。