推薦序：給敏捷實踐者的回顧#

Scrum 共同創始人 Ken Schwaber 將每年生日的自我反思比喻為一次「個人的回顧（retrospective）」：回望過去、評估現況、設定下一年的方向。然而個人式回顧難以衡量成效，因為人生的目標與情境不斷變動。

若有清晰的目標、固定的節奏，再加上一位有經驗的引導者（facilitator），回顧就能更深入、產生更具體的下一步行動。

軟體開發中的 Scrum 正具備這些條件：

• 明確的目標：專案有目標，每個 Iteration 也有目標
• 固定的節奏：每 30 天為一個 Sprint，避免方向漂移
• 可衡量的領域：相較於人生整體，軟體交付有客觀的進度可判斷
• 群體反思：由於是團隊活動，每個成員都能貢獻觀點，揭露意料之外的問題

傳統的死亡行軍（death march）型專案缺乏「生日」般的反思時點。敏捷迭代為團隊提供了天然的中斷點，讓團隊能改善做事方式、調整對工作的感受。

序言：兩位「回顧女神」的二十年實踐#

本書的兩位作者 Esther Derby 與 Diana Larsen 累積了二十年回顧帶領與教學經驗，並在 2003 年於奧地利 Baden 舉辦的回顧引導者年會上，被同儕封為「回顧女神（Retrospective Goddesses）」的稱號。

什麼是「回顧」？#

回顧是團隊在完成一段工作後召開的特別會議，目的是檢視（inspect）並調整（adapt）他們的工作方法與團隊合作模式。

回顧與傳統做法的差異：

• 超越專案稽核：不是制式的檢查清單，也不是流於形式的專案結案
• 聚焦團隊本身：除了開發流程，更關注團隊本身與成員之間的議題
• 產生具體行動：促成全員學習、催化改變、產出可執行的下一步

團隊議題往往比技術議題更有挑戰，且更容易被忽略。

回顧帶來的成效#

作者觀察到團隊在回顧後於下個 Iteration 採取改進，產生具體成效：

• 生產力提升：加州某團隊改善單元測試（unit testing）的頻率與覆蓋率，提早發現缺陷，避免發版前的趕工
• 能力擴散：佛州某團隊透過配對排程（pairing schedule），消除「只有一人會整合資料庫」的瓶頸
• 品質提升：明尼蘇達州某團隊發現 Iteration 中與客戶接觸不足會造成需求遺漏，於是增加客戶參與，減少誤解與返工
• 產能擴大：紐約某團隊重新檢視優先級排序，將年度發版改為季度發版，每次只交付高價值的小功能集

倫敦某團隊在進行了一年的 Iteration 回顧後表示：「回顧讓我們的工作生活變得更好。」一位社工觀察某個團隊後甚至說，這個團隊處理衝突的能力比他認識的多數專業社工還要好。

導論：本書的適用場景與焦點#

你是誰？為什麼需要這本書？#

無論身份為何，只要你認為回顧能幫到團隊，本書都能提供可實作的方法：

• 團隊成員：感受到團隊的人際摩擦、優秀同事開始考慮離職，希望主動引入回顧改善現況
• 團隊負責人（team lead）：聽過回顧的好處，但從未實際嘗試，不知從何下手
• 資深引導者：已經帶領回顧數月，但團隊不再產出新點子，需要新方法重燃動力

短週期回顧為主軸#

本書聚焦於「短回顧」——在一週到一個月工作完成之後召開的回顧，而非傳統的長期專案回顧。

短回顧的特性：

• 適用於敏捷方法（如 Scrum、Crystal），這些方法本身內建「檢視與調整」週期
• 也適用於非敏捷的傳統迭代或增量式開發
• 適合人數少於十人、工作高度互相依賴的團隊
• 即使團隊不採用敏捷方法，仍可在月底或專案里程碑時召開回顧

為何在敏捷團隊中特別有效？#

回顧聚焦於「真實的問題」，並產出「團隊可以自行實施而不必等管理層批准」的解決方案。由於改變是團隊自己選擇的、而非由上而下強加，成員對改變的投入度更高。

本書內容架構#

• 介紹回顧的整體結構（structure）
• 走過完整的計畫、設計、帶領流程
• 提供大量可直接使用的活動（activity）與使用指引
• 分享真實的回顧故事
• 專章說明回顧引導者（retrospective leader）的角色
• 提供調整模板，讓基本結構可適用於三個月發版週期、年度專案，乃至團隊解散後的學習保留

作者相信，只要有合適的結構與工具，多數人都能有自信、有能力地帶領回顧，並協助團隊取得成果。