敏捷宣言第9個敏捷原則是「團隊定期思考如何變得更有效，然後相對地調整方法。」由於 Agile 強調持續改進的重要性，所以對 Scrum 團隊來說，定期進行 Sprint Retrospective 是 Agile 開發實踐中最重要的項目之一。

什麼是回顧會議 (Sprint Retrospective)？

Retrospective 是讓團隊回想上個 sprint ，並為下一個 sprint 制定改善計畫的機會。這是團隊改進的機會，確保所有團隊成員都應該參加。

其實跟 PDCA 的「Check」很像，一個是品質管理、目標管理，一個是團隊改善，但兩者其實是相似的思維脈絡，這樣敘述對於沒有跑過 Agile 的人來說會不會比較好懂。

Retrospective 發生在 Sprint Reviewing 之後和下一次 Sprint Planning 之前。Retrospective 長短取決於 Sprint 長短，為期1個月的 Sprint 則 Retrospective 最多3個小時。我們 Sprint 為期2週 ，Retrospective 大約2個小時。

(圖片取自Scrum.org)

該如何進行回顧會議 (Sprint Retrospective)呢？

一、確保團隊都清楚以下規則和思維：

保持積極不斷改進的精神，充分告知團隊盡情分享任何你認為有助於團隊改進的東西。

1. 不要把這個會議內容個人化

2. 以開放的心態傾聽，每個人分享的經歷都是有價值的，即使不是你所分享的

3. 設定這次會議要討論的範圍，提醒團隊我們要往回走多遠。是最近的 Sprint 嗎？是整個產品嗎？是去年的開發過程嗎？

4. 鼓勵團隊接受改善的心態，不以責備為目的，以找到改進機會為主

二、在 Retrospective 期間，團隊主要討論3個部分：

1. 在 Sprint 進展良好的是什麼？

2. 在 Sprint 可以改善的地方？

3. 在下一個 Sprint 團隊可以嘗試改善的是什麼？

第一場回顧會議 (Sprint Retrospective)

參與第一場回顧會議時，團隊會比較放不開，主持人也需要經驗才能順利引導團隊進行，先提供基礎版步驟，進階版在最下面：

一、創建一個簡短列表，請團隊列出哪些工作做得好、哪些需要改善

可以在白板用便條紙建立，或者你們家便條紙是 3M 那也可在牆上。記得在會議結束後馬上記錄起來，以便日後參考。

二、根據團隊的重要對列表進行優先排序

這時候可能會發現一些共同的項目，可以把他們組合在一起。

三、針對改進列表的前2項項目，討論改進的方法

關注於後續如何改善，而不是針對過去、人。若團隊有餘裕的話，可以把改進列表所有項目討論完。

四、制訂行動計畫

在會議結束後，團隊應該已經有一些想嘗試的行動，並且有明確的行動者來解決須改善的項目。

五、嚴格執行 #4（這才是最重要的！）

當團隊每次都會靠北一樣的問題，但又沒人嘗試改善時，是多麼令人沮喪。為了避免原地踏步甚至退步，確保團隊都清楚下一步該做什麼，行動者需一直追蹤須改善的項目。

(Photo by Hugo Rocha on Unsplash)

進階-焦點討論法 (ORID)

我們總監曾利用 ORID 變形，引導我們進行多場 Retrospective 以及公司讀書會。台灣高智商的行政院的數位政務委員唐鳳，也透過 ORID 應對公關和網路問答。

Video by Audrey Tang

ORID 是用對的順序，問對的問題，來節省至少 1/3 的溝通時間。共有4個步驟，按以下順序進行：

一、Objective：觀察外在客觀事實

（一）你看到了什麼？聽到什麼？記得什麼？

（二）發生什麼事情了？

二、Reflective：重視內在感受、反應

（一）有什麼讓你很感動/驚訝/有趣/難過/沮喪/開心/鼓舞？（感受通常難以具體表達，可以提供多一點形容詞引導團隊說出感受）

（二）有什麼令你印象深刻的地方？

（三）什麼是比較困難/容易的？

三、Interpretive：詮釋感受的意義、解釋

（一）為什麼你會有這些感覺？感受發生的時間點是？

（二）引發你想到什麼？有什麼重要領悟嗎？

（三）為什麼這件事你覺得很重要？

四、Decisional：找出決定、行動

（一）有什麼我們可以改變的地方？

（二）接下來的行動/計畫會是什麼？

進階-Speed Boat（or Sailboat）

是我喜歡的 Retrospective 可視化技巧，起源於 Luke Hohmann 的《Innovation Games》。這種技巧是使用帆船作為團隊的隱喻，運用帆船/快艇會遇到的各種情況，幫助團隊具象化什麼事情會讓團隊慢下來，什麼事情會推動前進。

(Photo by davidemanske.com)

Speed Boat 有各種版本，有拖住船的錨、看到的島嶼等，選擇適合團隊狀況的項目就好，不一定要多。重點是讓團隊清楚知道每個項目的意思，思考與表達為什麼是放在這個分類。有些分類不容易分得清楚（Sun/Engine、Wind/Rocks），可以先從簡單的分類進行。

- Sun 太陽：什麼是我們在上個 Sprint 中做得好的地方？

- Wind 風：什麼不利於我們的工作，是我們需要減少的？

- Engine 引擎：是什麼動力讓我們可以保持下去？

- Risks/Jaws 暗礁/鯊魚：未來有什麼風險？

- Rocks 石頭：我們這個 Sprint 遇到什麼阻礙？

請團隊在便利貼上寫下每個項目的回顧內容，等到所有人都寫完後，每個人輪流上去畫船和貼便利貼，並說明自己的回顧內容（也可以主持人把船畫好，一個分類團隊回顧完成後，再進行下一個分類）。好的部分持續保持，不好的部分討論改善方法。

本文轉貼自：Jolin Tsai（原文連結）

本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。