回顧（retrospective）能幫助團隊持續改進——即便是優秀的團隊也不例外。本章先以一場一小時的 Iteration 回顧為例，觀察引導者（leader）的具體做法，然後拆解出可重用的流程框架。

一場一小時的回顧現場#

某個開發金融軟體的團隊，每兩週進行一次 Iteration 回顧，並由成員輪流帶領。本次由 Dana 主持。

開場與聚焦#

• 明確主題：團隊圍坐成半圓，Dana 宣布今天要聚焦在「開發流程」，原因是缺陷數正在上升
• 時間框（timebox）：4 PM 到 5 PM，一小時
• 快速 Check-In：請每位成員用一兩個字描述當下心情（puzzled、curious、bummed about the defects⋯⋯）
• 檢視工作協議（working agreements）：確認既有協議是否需要在本次會議中調整

蒐集資料#

Dana 指向一張顯示各功能與缺陷數的圖表，請大家：

• 在圖表旁貼上對應 Iteration 期間發生的「事件」便利貼
• 用橘色便利貼標記「感到沮喪（frustration）」的時點

一位成員觀察到，沮喪點與缺陷點並未重疊，這個意外的觀察成為後續討論的關鍵起點。

產生洞見#

• 給予 5 分鐘獨立思考並寫下觀察
• 將便利貼貼到白板上，再進行群聚（clustering）
• 最終形成四個群組：配對不一致、太趕無法做測試驅動開發（test-driven development，TDD）、程式碼異味（code smells）、遺留程式碼（legacy code）
• 全體一致同意「遺留程式碼」是缺陷的主要來源

決定行動#

• 快速腦力激盪 5 個可能的改善實驗
• 用點投票（dot vote），每人 2 點，選出優先方案
• 設計 15 分鐘的具體行動步驟：
  • 邀請 Support 團隊的 Sally 進行程式碼導覽（walk-through）
  • 為要修改的遺留程式碼撰寫單元測試
  • 邀請 Sally 每週和團隊配對 1 至 2 個早上

收尾#

• 確認衡量成功的指標：「下一次回顧時，這部分程式碼的缺陷數會減少」
• 指派下一次回顧的帶領者
• 感謝大家的投入並結束會議

回顧的五階段結構#

這個結構可以塞進一小時，也能擴展為三天的工作坊。新活動可以加入，但基本骨架要守住。

1. 設定場景（Set the Stage）
2. 蒐集資料（Gather Data）
3. 產生洞見（Generate Insights）
4. 決定行動（Decide What to Do）
5. 結束回顧（Close the Retrospective）

1. 設定場景：讓每個人都開口#

設定場景幫助大家聚焦於當下的工作，重申本次回顧的目標，並建立讓人願意討論議題的氛圍。

• 歡迎與感謝：對成員投入時間表達感謝
• 重申目的、目標、時長
• 讓每一個人開口說話

如果有人在開場時沒有說話，等於默許他在會議全程保持沉默。回顧的價值來自集體思考與學習，必須有每個人的參與。

• 避免冗長介紹：以十人團隊為例，每人講 3 分鐘，光介紹就花掉 30 分鐘。請大家用「一兩個字」描述對本次回顧的期待即可
• 概述本次流程：讓大家知道時間怎麼用，建立「這不是漫無目的的會議」的預期
• 建立或重申團隊價值與工作協議：

工作協議不是「我們重視所有人」這種高調空話，而是能實際幫助團隊談困難議題的具體規則，例如「會議期間手機靜音」。

• 協議由團隊共同維護：當團隊負責監督彼此時，引導者就能專注於 facilitation 本身

不要省略「設定場景」#

• 「節省」設定場景的時間，會在後面付出代價
• 沒有早早開口的人，可能整場都不會貢獻意見
• 不知道流程的人會難以聚焦，甚至帶偏討論方向

2. 蒐集資料：建立共同的視角#

即使是只有一週的 Iteration，少參與一天就等於錯過 20% 的事件。每個人觀點都不完整，蒐集資料是為了拼出共同的圖像。

客觀資料（hard data）#

• 事件：會議、決策點、團隊成員變動、里程碑、慶祝、新技術導入等
• 度量：燃盡圖（burndown chart）、速度（velocity）、缺陷數、完成的故事（stories）數、重構量、工時資料

感受資料（feelings）#

客觀事實只是資料的一半。感受揭示了「這些事實對成員為什麼重要」。

由於工程師通常不擅於談論感受，建議用迂迴的問法：

• 你什麼時候對上班感到興奮？什麼時候只覺得是「打卡上班」？什麼時候害怕進公司？
• Iteration 中的高點與低點是什麼？
• 你什麼時候感到「生氣／難過／意外」？

當情緒被刻意壓抑，它不會消失，而是轉入地下，消耗團隊的能量與動力，或在某個時刻爆發為衝突。

案例：一張藍點的便利貼#

Pat 的團隊用時間軸（timeline）回顧 30 天 Iteration，以綠點代表高點、藍點代表低點。一張卡片上有 9 個綠點和 1 個藍點，Carly 坦承藍點是她的：「我覺得我綁架了規劃會議。」結果其他成員紛紛表示有相同的擔憂——但因為沒人開口，問題就一直沒被處理。如果不是刻意關注感受，這場對話不會發生。

3. 產生洞見：問「為什麼？」#

這個階段才是真正開始問「Why?」並思考「下次該怎麼做不同？」的時候。

• 檢視貢獻成功的條件、互動與模式
• 探究失敗與不足
• 找出風險與意外的事件或結果

人很容易在問題浮現的當下立刻跳到解法。第一個想到的解法不一定是錯的，但通常不是最好的。

• 此階段的工作是「考慮其他可能、看因果、分析性思考」
• 也是讓團隊「一起思考」的時刻
• 沒有這個階段，後續制定的改善行動可能根本不會帶來正面影響

4. 決定行動：少而精#

• 通常每次 Iteration 只挑 1 至 2 項實驗或改進
• 太多初始項會壓垮團隊的改變能力
• 若團隊剛經歷過一次壓力大的改變，這次就選比較簡單的

行動可寫成故事卡（story card）或 backlog item，融入下一個 Iteration 的工作計畫中。將回顧排在 Iteration 規劃會議之前，並中間插入一段休息時間（至少是午餐），效果最好。

個人承諾很重要#

• 沒有個人簽名認領的任務，大家會以為「團隊會做」，結果沒人做
• 確保每項行動有具體的負責人

避免「一事無成」的回顧#

把問題歸因於外部團隊、等待別人改變，是徒勞的。最有力的起點永遠是「我們團隊本身」——即使無法直接控制，仍可以選擇如何回應。

• 把改善計畫和日常工作計畫切開的團隊，往往找不到時間做「額外」的工作
• 改變要在日常工作中發生，不是另開一張清單

5. 結束回顧：明確收尾#

不要讓會議的能量在拖沓中流失。

• 決定如何記錄學到的東西（海報、大型可視圖表、白板拍照、數位列印白板）
• 學習成果屬於團隊，不屬於教練、團隊負責人或回顧引導者
• 對 Iteration 中與回顧中所有人的努力表達感謝
• 留幾分鐘做一次「對回顧的回顧」：本次哪裡做得好？下次可以怎麼做不同？「檢視與調整」也適用於回顧本身

採用此結構的好處#

使用這套五階段結構，能幫助團隊：

• 理解不同觀點
• 遵循自然的思考順序
• 全面審視當前的方法與實務
• 讓討論走向自然該到的地方，而非預先決定結論
• 帶著具體的行動與實驗離開回顧

這套結構是經過驗證的「樣板」，下一章會走過完整的設計流程，讓你能依團隊狀況打造合身的回顧。