PM在敏捷開發下的反思：如何舉辦一場回顧檢討會（Retrospective）

　　回顧這幾年，發現許多團隊在導入敏捷時，往往把重點放在「如何快速交付」，卻忽略了敏捷精神中最核心的「持續改進」原則。而貫徹這個原則的關鍵，就在於每一場 Sprint 結束後所舉辦的「回顧檢討會（Retrospective）」。

　　常說敏捷開發並不是單純的工具或流程，它更是一種心態。在 Scrum 這個框架下，我們習慣了短週期迭代、快速試錯、快速學習。然而，如果只是埋頭苦幹，而不去回顧、反思，那麼再快的速度也可能只是在錯誤的道路上狂奔。回顧會議正是敏捷方法論中不可或缺的「停頓點」，它讓我們能夠跳脫日常的忙碌，從更宏觀的角度審視過去的 Sprint，找出做得好的地方，並思考如何優化流程、提升效率，為下一個 Sprint 注入更強的動力。

　　敏捷宣言第九原則，精闢地闡述了回顧會議的重要性：「團隊定期思考如何變得更有效，然後相對地調整方法。」這句話不僅是指導原則，更是團隊成長的基石。你可以將回顧會議視為品質管理 PDCA 循環中的「Check」步驟，兩者有異曲同工之妙，目的都是為了持續改進。

　　如果你所在的團隊正在實踐 Scrum，那麼每一個 Sprint 結束後，Scrum Guide 都明確要求舉辦 Retrospective，這是 Sprint Review 之後、下一次 Sprint Planning 之前的重要環節。會議的時長會根據 Sprint 的長度來決定，例如，一個為期兩週的 Sprint，通常會安排兩小時的回顧會議。

　　一場產品回顧檢討會如何規劃，才能夠真正地為團隊帶來價值呢？

誰應該參與回顧檢討會？

　　最理想的參與者是那些直接參與該 Sprint 產品交付的所有 Scrum Team 成員。這通常包括Product Owner、開發人員（涵蓋前端、後端、使用者介面和使用者體驗設計師…等）、Scrum Master。

　　為什麼是他們？因為回顧會議的本質是共同學習和改進。只有真正參與了開發過程的成員，才能夠從各自的視角，提出最真實、最深刻的觀察和體會。

　　然而，根據以下特定情境建議部分夥伴參與，例如：

• 非核心成員的參與

有時，會遇到團隊詢問是否應該邀請負責 Code Review 工程師、專案經理、主管、DevOps 人員參與。建議通常是持謹慎態度。如果這些角色的參與會讓團隊成員感到拘束，或他們的討論內容與 Sprint 的實際執行細節關聯性不高，那麼他們的缺席可能更有助於團隊坦誠的溝通。

e.g.，主管通常關注方向和目標，不太介入執行細節；DevOps 人員主要負責部署與維運，對具體的產品開發流程理解有限。我的原則是，讓那些能為討論帶來直接洞察力、並願意共同承擔改進行動的人參與。

• 確保全員參與

即使不是 Scrum Team 的核心成員，如果他們在該 Sprint 中對產品交付有直接影響，也可以考慮邀請他們以旁聽或限時分享的方式參與，但務必確保核心 Scrum Team 的討論空間和安全感。

回顧檢討會的進行方式與流程

　　既然確認會議的目的與參與者，接下來就深入探討如何有效率地執行一場回顧會議。

• Step 1：主持人選擇/職責

Scrum Master 是最適合的人選，因為他們負責確保 Scrum 框架的執行。但如果團隊沒有專職 Scrum Master、Product Owner或Senior Developer都可以輪流擔任。我甚至會強力鼓勵團隊成員輪流擔任主持人，這不僅是培養團隊領導力的好機會，也能帶來不同的視角和引導風格，豐富會議的內容。

一位優秀的主持人，需要具備以下幾項關鍵職責：

• 時間管理

回顧會議的時間應預先設定並嚴格遵守。例如，一個兩小時的會議，每個環節都應有明確的時間分配。主持人需適時提醒，確保討論不偏離主題，避免冗長或無效的對話。

• 氣氛掌控

回顧會議本質上是「檢討」，但絕不能變成「批鬥大會」。當討論變得緊張或個人化時，主持人需介入緩和氣氛，引導回歸正軌。這需要極高的情商和溝通技巧。

• 理解與共識

主持人需要主動澄清語意、歸納發言、甚至幫助表達不流暢的成員組織語言，確保所有與會者對討論內容有共同的理解。

• Step 2：型式風格

目的是為整場會議奠定一個安全、開放和建設性的基調。尤其當團隊成員變動頻繁或回顧會議不那麼頻繁舉行時，這一步驟更是不可或缺。

通常會引導團隊宣讀以下幾點，這些話語充滿了敏捷精神的核心價值：

• 無論我們在過去的 Sprint 中發現了什麼問題或不足，我們都應堅信，在當時所知、所擁有的技能和能力、以及可用的資源和客觀情況下，團隊中的每個人都已經竭盡全力。這是建立信任和安全感的基石。

• 將討論內容去個人化，避免互相指責或抱怨，專注於流程、工具或溝通模式的問題。

• 每人經驗和視角都是寶貴的，即使不是親身經歷或同意的觀點，也應給予尊重和傾聽。

• 回顧會議的目的是為了未來做得更好，而不是為了找出「戰犯」。

這些原則不僅僅是口號，它們是確保團隊成員能夠放心地分享、討論，並最終達成共識的基礎。

• Step 3：剖析 Sprint 「過去」

在確認團隊具備安全感後，即可進入回顧核心討論環節。通常會引導從三個維度進行思考：

• 哪些方面「做得很好」？

• 會請團隊成員在白板上列出所有他們認為在過去這個 Sprint 中值得肯定的地方。這是一個正面表述的環節，目的是肯定團隊的努力、識別成功模式、並提升士氣。
• e.g. 在開發【基礎設施資料建置與評鑑作業】時，可能有人會提出：「這次資料計算的速度比預期快很多！」或者在【工程管理整合資訊系統】中，有工程師會說：「這次跨部門溝通非常順暢，需求變動都能及時同步。」
• 正向的經驗是團隊寶貴的資產，值得我們思考如何將其複製到未來的 Sprint 中。

• 哪些方面「可以做得更好」？

• 這是回顧會議的重點，也是最容易陷入負面情緒的環節。因此，主持人需要使用「正面表述」。e.g. 各位除了做得好的地方，接下來我們來思考一下，有哪些方面，我們『可以做得更好』？
• 這個階段的目標是列出問題，而不是立即解決問題。若有人急著提出解決方案，可引導他們：「這個解法聽起來很棒！稍後在『下個行動』環節再深入討論它。」
• e.g. 在「物價調整指數系統」的開發中，可能有人會說：「這次流程的自動化程度可以再提升。」或「在某些特殊材料上的計算邏輯上，可以再花更多時間溝通。」

• 團隊可以嘗試改善的是什麼？

• 可列出所有可以改進的事項後，會引導團隊進行分類和整理。若提出的項目不多，可針對每一類進行深入討論，集思廣益，找出具體的改善方法。
• 討論過程中，應不斷提醒團隊：「如何」改善，而不是「誰」導致了問題。

• Step 4：Action Plan：反思轉化為行動

也是回顧會議精髓所在，衡量一場回顧會議是否有效的關鍵指標。如果沒有具體的行動計畫，那麼回顧會議就只是「抱怨大會」或「紙上談兵」。

確保每個被選中的改進事項都轉化為清晰、可衡量、可追蹤的行動計畫，包含以下要素：

• Accountable Person

每個行動都必須有明確的責任歸屬。這確保了改進措施不會流於形式，而是有人負責推動執行。

• 具體行動描述

行動計畫必須是可執行的具體步驟，而非模糊的概念。e.g. 不是「加強溝通」，而是「建立每日 15 分鐘的技術問題討論會」。

• 預計完成時間

為每個行動計畫設定一個合理的完成時程或里程碑。

• 整合至Nest Sprint追蹤

對於小型、能在下一個 Sprint 中完成的改進措施，建議將其作為獨立的任務納入下一個 Sprint 的待辦列表。這樣可以確保團隊在 Sprint 中為其分配時間和資源。

對於較大或需要長期持續的改進措施，我們會將其記錄在團隊的「持續改進清單」中，並在每次 Sprint Review 或下一次 Retrospective 中定期追蹤其進度。

進階技巧：讓回顧會議更具深度與趣味

　　在實踐中，也可透過進階技巧，讓回顧會議從「例行公事」轉變為「團隊成長的加速器」。

• 焦點討論法 (ORID)：深入問題的本質

職涯中多次運用 ORID (Objective, Reflective, Interpretive, Decisional) 方法引導團隊，效果非常顯著。ORID 提供了一套結構化的提問框架，幫助團隊從淺層的現象深入到問題的本質，並最終制定出有效的行動。

1. Objective

提問範例：「上個 Sprint，你看到了什麼？聽到了什麼？發生了什麼事？」

目的：讓團隊成員陳述純粹的客觀事實，不帶任何判斷或情緒。e.g. 「物價調整指數系統」的開發中，某工程師說：「上週五，我們的自動化測試流程跑了 3 小時，但其中有 50% 的案例失敗了。」

2. Reflective

提問範例：「針對這些事實，你當時有什麼樣的感受？是什麼讓你感到驚訝/沮喪/開心/鼓舞？」

目的：引導團隊成員表達他們的情緒和內在反應。有助於理解問題背後人性層面。e.g. 針對測試失敗，工程師會說：「我覺得很挫敗，因為我們花了很多時間在測試，但結果卻不如預期。」

3. Interpretive

提問範例：「為什麼你會有這些感覺？這件事對你來說有什麼重要意義？你從中領悟到什麼？」

目的：從中提取有價值的洞察，這是從「發生了什麼」到「為什麼會發生」的轉變。e.g. 「我覺得挫敗是因為這顯示我們對測試覆蓋率的評估不夠準確。我領悟到，我們需要更明確地定義『Definition of Done (DoD)』中關於測試的標準。」

4. Decisional

提問範例：「針對這些領悟，我們可以做些什麼？下一步的行動計畫是什麼？」

目的：從「為什麼會發生」到「我們該怎麼辦」的轉變。e.g. 「我們可以做的是，下個 Sprint 進行一次全員的測試策略討論，並更新我們的DoD，明確自動化測試的覆蓋率要求。」

　　ORID分層討論，能有效地引導團隊從表象深入到本質，確保最終行動計畫是基於深刻洞察的。

敏捷心態與持續學習

　　在敏捷實踐中深深體會到，Scrum 框架下的節奏確實非常快。作為PM必須在短時間內做出大量決策，並確保團隊的交付能符合市場和公部門客戶的實際需求。這其中，回顧會議扮演了極其重要的角色，它是我們「快速吸收、快速迭代、快速試錯」理念的重要體現。

　　職涯中踩過許多「地雷」。e.g. 沒有在 Sprint Planning 前與工程師充分討論技術細節，導致估時不準確、因為公部門需求的特殊性，過於追求功能完整而忽略了Minimum Viable Product, MVP的概念。這些問題的發現、反思與改進，都離不開每一次回顧會議的檢討與學習。

　　身為PM雖然大部分需求在事前已經確立，但在公部門專案中，難免會有突發的政策變動、Bug 修復或客戶提出的緊急需求。這時候，即使需要在 Sprint 過程中臨時抽換 User Story，也必須保持高度的彈性。及時向團隊和所有相關利害關係人同步變動，清晰解釋原因，並確保所有重要需求，無論是暫緩還是加速，都有被妥善安排或給予明確回應。這種透明度和預期管理，是建立信任的關鍵。

　　最後Retrospective不僅僅是一個 Scrum 事件，它更是團隊學習、成長和持續改進的生命線。深信精心策劃和引導每一場Retrospective，不僅能讓團隊更有效地工作，也能讓產品更貼近用戶的真實需求，最終為公部門帶來更大的實際價值。這是一場需要耐心、同理心、持續學習和不斷調整的旅程，但每一次的回顧與成長，都讓我堅信敏捷的價值，並持續為團隊注入前進的動力。

【參考資料】

• Agile Retrospectives中文版：這樣打造敏捷回顧會議，讓團隊從優秀邁向卓越 (作者： Esther Derby, Diana Larsen；出版日期：2022/08/30)
• Neuromagic - ニューロマジック, 敏捷開發中執行回顧會議的5種方法
• ProjectUp 專案管理生活思維, 談「回顧（Retrospective）」：團隊如何尋找下一步行動的改善機會
• 專案經理雜誌, 敏捷回顧會議，團隊處理關係的衷心時刻
• HPX-GOV 英國政府數位服務研究小組,  進行回顧會議 (Running retrospectives)

～～作者推薦～～

• 〔CPC課程〕
  • 敏捷管理實戰班
  • 深入淺出專案管理之敏捷式開發 Scrum