---

name: retro-analysis language: zh-TW description: "分析迭代交付資料，產出結構化的回顧簡報。當被要求開回顧會、分析迭代資料、準備回顧簡報，或把迭代指標轉成討論提示時使用。產出基於資料的回顧簡報：完成情況統計、規律分析、開始 / 停止 / 繼續的討論提示，以及下個迭代的一個具體實驗。專案或活動的覆盤請使用 cn-fupan。"

retro-analysis 的繁體中文翻譯，英文版本為規範版本。

迭代回顧分析

生成一份基於資料的回顧簡報，把事實和感受分開，讓團隊把回顧時間花在解決方案上，而不是爭論發生了什麼。

所需輸入

如未提供，請向使用者詢問：

• 迭代任務：計劃的與完成的
• 順延的任務及原因（如知道）
• 關閉後又重新開啟的任務（品質訊號）
• 任何故障或計劃外的工作（範圍蔓延訊號）
• 迭代速率與歷史平均對比（趨勢背景）

流程

1. 計算：完成率、順延率、計劃外工作佔比
2. 識別規律：哪類任務最容易順延？哪些造成了阻礙？
3. 記錄資料中可見的流程或溝通斷點
4. 基於資料準備 3 條"開始 / 停止 / 繼續"提示：不是通用的，而是針對這個迭代
5. 針對最大的摩擦點，為下個迭代建議 1 個具體實驗
6. 驗證：確認每條提示都針對這個迭代（不是迴圈使用的通用提示），建議的實驗具體、可衡量

輸出結構

第 [編號] 個迭代回顧簡報

數字一覽：

• 計劃：[n] 個任務 | 完成：[n] | 順延：[n] | 完成率：[%]
• 計劃外工作：[n] 個任務（佔容量的 [%]）
• 速率：[點數]，平均為 [平均值]

資料說明了什麼： [基於上面數字的 2 到 3 條觀察]

討論提示：

• 開始：[基於這個迭代資料的具體提示]
• 停止：[基於這個迭代資料的具體提示]
• 繼續：[基於這個迭代資料的具體提示]

下個迭代的建議實驗： [一個具體、可測試的流程改變，附具體的成功指標]

延伸材料

這個技能附帶支援檔案，可用時請使用：

• references/root-cause-vs-symptom.md：能帶來改變的回顧：根本原因與症狀。在產出時應用它；它包含上面方法摘要壓縮掉的校準和判斷。
• templates/retro-board.md：可填寫的成果模板，品質關卡寫在裡面。當使用者想自己完成文件而不是生成時提供。

評分量表（0 到 40）

交付前給這個技能的任何產出打分；32 分以上才算可以交付。

維度	0	5	10
資料依據	數字缺失或錯誤；觀察是沒有可追溯來源的意見	核心比率計算正確，但觀察只是複述數字，沒有規律分析（任務型別、歷史對比）	每條觀察都追溯到計算出的數字，順延按型別或原因拆分，速率與歷史趨勢而不只是平均值對比
不指責個人	簡報點名或暗示個人、某個職能是原因（"測試漏掉了"）	措辭中性，但框架仍指向努力程度或是否盡責，而不是系統條件	失敗模式被重新表述為資料真正支援的流程、覆蓋或排期規律：抱有防禦心的讀者也找不到針對自己的內容
提示的針對性	開始 / 停止 / 繼續是迴圈使用的通用類別（"加強溝通"）	提示提到了這個迭代，但停留在類別層面：沒有數字，沒有點出具體行為	每條提示都與這個迭代的資料緊密相連，點出一個具體行為，並以開啟討論而不是規定答案的方式表述
實驗品質	沒有實驗，或把跨季度的計劃包裝成實驗	有一個具體改變，但成功無法衡量，或下次回顧時無法評估	一個在單個迭代內可測試的流程改變，有明確的成功指標和失敗的代價，下次回顧時可以檢查

品質檢查

• 每條開始 / 停止 / 繼續提示都點出具體行為，而不是模糊的類別
• 建議的實驗在一個迭代內可測試
• 順延分析找出了任務型別或原因，而不只是數量
• 資料觀察不指責個人，只描述規律
• 結合背景提到速率趨勢（是一次性的還是規律？）

反模式

• 不要在回顧簡報中指責個人：觀察必須描述規律，而不是人
• 不要寫成模糊類別的開始 / 停止 / 繼續提示：每條都必須點出具體行為
• 不要建議一個迭代內完成不了的實驗：只做小而可測試的實驗
• 不要在找出根本原因類別之前，把順延任務當作速率問題
• 不要每個迭代都用同樣的回顧形式：變換形式，避免參與疲勞

示例觸發語

• “辦一次回顧會議。”
• “分析這個衝刺的數據。”
• “準備回顧會議的資料。”
• “把衝刺指標變成討論題目。”