這篇的主角，衝剌回顧會議，與之前提到的衝剌審視會議，都會在 Sprint 的最後一天召開。 一般來說，它經常會在緊接著 Sprint Review 結束後，Scrum Master 等到 PO 及關係人離開後，才會讓團隊安心地進行這個會議。

衝剌回顧會議

口語上又稱 Retro 或是自省會議，英文為 Sprint Retrospective，它是為了幫助團隊持續進行檢驗及調整而設計的，這是一段專門留給團隊的時間，上篇文章 <衝剌審視會議> ，其討論主題的關注點是在「產品」中，而此篇的衝剌回顧會議，則是聚焦在團隊的開發流程、溝通方式、以及每個 Sprint 過程中大家所發現的問題之上，目的是集思廣義，針對同樣一再發生的問題，找出可以行動的項目，在執行下個 Sprint 時得以做出調整，讓團隊愈來愈好、不再同一地方跌倒好幾次，進而期望能夠帶動團隊績效感、以及提升幸褔進步感。

與傳統專案管理檢討報告的差別

傳統專案管理的流程裡也有類似的環節，在專案的結案階段，除了要產出最終產品／服務之外，還會將整個專案做一次通盤的覆盤檢討，進行整理出專案經驗的傳承報告，以產出所謂的「組織流程資產」。它們立意很好，但問題在於時間點，是在專案要結束的時候才召開些所謂的事後檢討或經驗總結，這很容易變成是批鬥大會，且討論出來的結果，幾乎都會是一份羅列各種需要加強及如何加強的「冗長」清單，並且幾乎都會是沒什麼實操性的相似陳述，例如：

又一次，我們還是人力、時間不夠無法做到覆蓋率夠高的測試，所以我們需要更多的 QT 測試人力

→ 是的沒錯，但 QT 人力就是只有少數的 Function Team，不是說加就能加（站在老闆角度，要能夠在「效益」上有量化証明，才會願意養更多的長期人力）

為了修 Bug 延誤開發時程，經常導致 milestone 常常 Delay、人員經常性的加班，所以我們要能夠維護高品質的程式嗎

→ 是的沒錯， 政治非常正確，但要「如何」做到，且這些「如何」的手段、方法，是不是有真的有經過幾次試煉後明確有效，若沒效，應該要趕緊試其他新方法

有沒有發現，這種抱怨式的陳述，問題都在於沒有「可行性」以及缺少了「用時間來驗証是否可行或需要換個方式」。另一方面，案子都到即將要結束了才來做羅列，很多曾經發生的事情其實已經忘的差不多了，就算大家開個會，洋洋灑灑寫下來的也都會是一組「模糊的抽象概念」，不是那麼具體，歷歷在目。

傳統方式還有一個我認為不太好的地方，那就是產出的成果是落落長的待改進處清單，冗長到不知該從何處著手，容易讓團隊產生沮喪與無力倦怠感。

Scrum 短頻次、定期回顧的好處

其實只要將傳統回顧的方式調整一下，將週期縮短，不是在最後，而是在每個 Sprint 要結束時就舉行衝剌回顧會議，如此一來，能夠寫下來的項目大家一定是記憶猶新，且不管羅列下來的有多少項目，由團隊一次只選出 1-2 項改進之處，想好對策，並於下個 Sprint 中執行，這種不求多但求漸進式改進的方式，能讓團隊保持希望，並想嘗試看看改進是否有效，待下次的 Sprint Retro 時，一起來檢驗，有效就繼續保持，無效就換個方法，繼續嘗試。

如此一來就能夠有效地利用自省會議，持續改進夥伴們的工作方式，如此，團隊便會有強烈的責任感以及克服後感受到自身成長的意識。

Sprint 異常終止時更需要回顧

之前的文章提到過，在 Scrum 中，管理層、PO 與團隊需有個基本的協議，就是盡可能不在 Sprint 的進行中增加需求。但有時候也會出點狀況，導致整個 Sprint 必需結束（通常是商業上發生了什麼劇烈變動），遇到這種狀況，產品負責人可以向團隊請求 Sprint 異常終止。

若你的團隊真的發生了這種事，那麼在處理完相關事情後，立即召開自省會議就很重要了。由於這種狀況很少見，整個過程一定有哪裡出了問題，試圖找出這些問題、反省並擬定可改善的行動，團隊成員必定都能夠從中學到許多東西。