即使每個 Iteration 都做回顧，發版（release）與專案結束（project end）時仍值得另外召開回顧。Iteration 回顧聚焦團隊本身，而發版／專案回顧帶入更廣的視角——納入跨組織的角色，產生組織層級的學習。

名詞校準#

不同公司對「iteration」「release」「project」有不同用法，先校準定義。

• Iteration：1 週至 30 天的開發週期。團隊承諾一個目標並交付小而完整的可運作軟體（測試、文件、整合都做完）。Scrum 中稱為 Sprint。
• Release：Iteration 累積出的可用程式碼準備給其他人使用。對象可能是內部測試組、Beta 用戶、內外部正式客戶。
• Project：可包含一次或多次 Release。專案結束通常意味資金中止、團隊解散。

為發版／專案回顧做準備#

把邀請延伸到團隊之外#

發版回顧應納入專案社群——所有對成果有貢獻、但不在核心團隊的人。

• 三個任務：決定邀請誰、發出邀請、教育新參與者
• 建議邀請：管理階層、客戶、Beta 測試者、產品負責人、部署團隊、測試組、行銷、技術支援、help desk、營運、行政支援、專案經理
• 專案結束時：再加上贊助者與其他管理利害關係人（如產品開發工程管理、program management）

案例：HR 與 Facilities 的學習#

某發版回顧邀請了人資 Pat 與設施 Ron。Pat 才意識到「發版中要每個成員寫 26 頁績效考核」會讓 coach 失能整整一個月；Ron 看見「機台搬移」對團隊的緊迫性。團隊也學到要更早通知支援單位、給更長的 lead time。

平衡「包容」與「成果」#

• 50 至 100 人的跨部門回顧需要的是與「回顧」不同的流程
• 200 人專案只來 20 人，散播洞見、達成共識本身就是另一個專案
• 取捨原則：若大型跨部門回顧成效堪憂，寧可只做團隊回顧

邀請函要點#

別只發一張普通會議通知。明寫目標、日期、時間、需要做的準備、聯絡人。

範例：「我們完成第一次發版了，是時候檢視我們對研發工作的學習。4/5（8:30–4:00）發版回顧，提供午餐。流程是有結構的、各段相連，請預留整天參加。本次主軸是改善跨部門溝通與協作。請回想過去三個月並帶上能幫助大家回憶的素材。」

半天參加（drop in / drop out）會打斷流程。整天到場是必要前提，因為各階段是連動的。

事前指導主管#

對部屬有評估或考核權的人（功能主管、專案經理、總監、研發主管）都帶有一種權力，成員會自動對其讓步。事前個別與每位主管見面，討論其在討論中的角色，請對方刻意收斂，並事先設好「你太搶話」的暗號。

事前訪談 / 問卷#

為發版／專案回顧做更深的準備。用簡短訪談或問卷收集大家對專案的感受。

事前訪談的四項好處：

• 啟動反思：問題本身就讓人開始回想經驗
• 提供背景：讓你了解脈絡、人物、立場
• 設定基調：問題開放好奇 → 回顧氛圍開放好奇；問題封閉找錯 → 回顧變成指責
• 量身設計：知道議題後可選對應活動。例如某次訪談發現「開發者與管理層彼此不信任」是反覆主題，引導者就加入幫助開發者向主管表達擔憂的活動

候選問題清單#

挑 5 至 6 題，組成有邏輯流動的訪談或問卷。先自己回答一遍，確保問題不至於模糊到無法作答：

• 你認為這場回顧必須提到的 3 至 5 個議題是？
• 對你個人、對未來發版、對組織，這場回顧最佳的可能成果是什麼？
• 為了達成上述成果，回顧期間或之後需要發生什麼？
• 回顧本次發版，你心目中的高峰時刻是什麼？為什麼？是什麼讓它難忘？
• 你最看重自己對本次發版的什麼貢獻？最看重別人的什麼貢獻？
• 對這場回顧你有什麼疑問？
• 我還該問什麼？你會怎麼回答？

有些參與者會以為「我寫過了 / 講過了，不必在回顧再提」。要明確告訴他們：議題的擁有者是當事人本人，引導者要靠他們在現場提出。

處理敏感議題的承諾#

• 訪談或問卷收到的資訊用於「設計流程」，承諾保密就要做到
• 若計畫在回顧中總結分享，事先說明，並保護當事人身份

納入跨組織觀點#

五階段在發版回顧中的差異#

控制 vs. 影響#

在發版／專案回顧中，許多問題的解法不在會議室裡。要區分「直接控制」與「能影響」的議題。

• 控制：團隊可自行決定的（每日技術決策、工作協議）
• 影響：透過接觸到能控制的人，去教育與說服他們（教 Facilities 部門了解 team room 需求、讓主管看見政策的真實成本）

有效的提案不是「告訴別人該怎麼做」，而是描述問題、提出可能解法、邀請對方共同解決，並說明對方能得到什麼。

行動仍要落地#

即使議題跨組織，仍要產出個人發展與團隊改進的具體行動。挑「會議結束前可完成」的小行動——行動會帶出更多行動。

行動計畫的準則#

• 每個行動步驟都要有動詞——沒動詞就不是行動
• 每個行動都要一個負責人——一人承諾推動
• 小步快走：以一週內可完成為目標
• 設截止日：開放結束的任務通常永遠不會結束
• 通過 SMART 檢查：Specific、Measurable、Achievable、Relevant、Timely
• 定義「完成」的條件，以及如何向團隊回報

報告由團隊負責#

大型回顧的買單者往往要求書面報告。報告應由「團隊」產出，不是引導者。在收尾階段決定誰來寫——若引導者代寫，會稀釋團隊的擁有感。

帶領發版／專案回顧#

Coach 與 team lead 可帶 Iteration 回顧；但發版／專案回顧時，所有團隊成員都有故事要說，必須是「參與者」而非「引導者」。請別組的 lead 或外部 facilitator 來帶。

• 偶一為之者：找 mentor 一起設計、商議
• 經常要帶：投資自我訓練

與 Iteration 回顧的差異#

管理活動#

• 大多 Iteration 用的活動可沿用
• 訣竅：用小組討論而非整個大團體討論——人多就無法真正對話

管理動態#

大團體中行為樣貌相同，但放大效果更強——出問題時惡化更快、爆炸力更大。引導者必須緊盯流程與動態，工作協議要嚴守，干擾行為要及時點名。

• 留意 side conversations：大型場合中尤其重要。可能代表隱藏資訊、派系、或有人在搞破壞
• 介入示範：「我注意到你們在私下對話，是這個房間其他人也需要知道的資訊嗎？」常常一句就解決
• 不要重提小學記憶：不要要求「你笑什麼念出來給大家聽」、不要強迫分享紙條

管理時間#

大型回顧中每件事都更花時間：debrief、轉場、休息、小組報告。結構不變，但人多事雜，特別在有衝突或失敗的場合，留更多時間並考慮請有經驗的 facilitator。

• 每 90 至 120 分鐘安排正式休息
• 在自然的停頓點休息，比定時休息更好
• 開場先說會休息的節奏，請大家有需要時提出

全天回顧的設計範例#

某團隊完成第 24 次 1 週 Iteration，提前交付產品還拿到獎金。引導者規劃了一場全天的專案回顧：

• 目標：從核心團隊外的觀點學習、建立在成功上、保持動能
• 參與者：核心團隊、客戶、外部測試組、營運支援、技術文件，共 20 人
• 時長：全天
• 場地：公司訓練中心的大型訓練室（容納 50 人，家具可移動）
• 佈置：圍圈座椅，後續分小組

各階段活動選擇：

• Set the Stage：Focus On / Focus Off + Working Agreements（許多人首次參加，不同團體沒有共同協議）
• Gather Data：Timeline with Swim Lanes（重建發版時序並顯示各部門視角）+ Color Code Dots（顯示各事件的感受）
• Generate Insights：Patterns and Shifts → Locate Strengths → Identify Themes
• Decide What to Do：Retrospective Planning Game
• Close：+/Delta（改進回顧本身）+ Appreciations（感謝核心內外的貢獻）

在每個結束點都做回顧#

即使有 Iteration 回顧，發版／專案結束時的回顧仍值得花時間。長視角會讓人看見不同議題、學到不同教訓——即使團隊解散，學習也會被成員帶到下個專案。

想深入了解專案結束式回顧，可參閱 Norm Kerth 的 Project Retrospectives: A Handbook for Team Reviews。也可加入 retrospective 電子郵件討論群。

發版／專案回顧能挖出阻礙團隊的組織因素、政策、程序——這些需要跨領域協作才能解決。沒有更廣的視角，問題就會被隱藏，或被歸咎到錯誤的源頭。

在每個結束點都做回顧。團隊與組織會在反思中學習與改進。