回顧會議（retrospective meeting）是scrum中最有價值的會議之一，雖然這個會議很重要，但是在實際的工作中我們會發現往往最容易被砍掉的也是這個會議。
為什么這個會容易被砍掉呢？項目工作太多，大家太忙只是一個明面的借口，深層次的原因應該有如下幾個：

• 會議過程和形式太枯燥重復，沒有新意，讓人厭倦
• 會議產出的改進計劃不明確，不能落實，沒有跟蹤，更沒效果
• 團隊缺乏持續改進的意識，只是停留在埋頭處理手上的工作

如果你發現你們團隊大家對回顧會議不感冒，也許你們就有上面這些問題，本文的目的是介紹一下我個人常用的回顧會議套路，僅供參考。

又到了回顧會議時間，挺住！

回顧會議的目的

回顧會議是Scrum檢視與調整的一個重要的環節,在這個會議上，我們鼓勵團隊對自己的開發過程進行改進，并確定什么樣的調整可以使下一Sprint的效率更高、結果更令人滿意和更易于工作。
就像我們頻繁的迭代和交付是為了快速的獲得外部用戶的反饋，進而幫助我們做產品需求的調整一樣，每個迭代的回顧會議就是想更快的得到大家對團隊工作問題和改進點的反饋，幫助團隊內部的工作效能和能力成長的不斷改進。

回顧會議的過程和我常用的手段

回顧會議過程

《Agile Retrospectives》這本書中把回顧會議分成了5個階段：

1. 準備
2. 收集數據
3. 產生見解
4. 確定改進項
5. 結束會議

那我就按這幾個階段來講講我是怎么做的。

準備

準備階段其實是非常重要的，一些初次主持回顧會議的scrum master往往會忽視這個階段，一上來就讓大家寫小卡片，這樣不僅效果不好，更給人枯燥重復的感覺。

準備階段我往往會選擇做下面幾件事：

設定一個安全的環境

回顧會議不僅僅希望大家能參與進來，更重要的是能敞開心扉，大家沒有顧慮的把問題暴露出來，找到改進的辦法。但事實是肯定有人擔心回顧會議會成為一個批判會議，在認為這個會議的目的是找到這個迭代中犯錯的那個人，并把他拎出來痛批一頓，看以后還有誰敢再犯。如果這樣大家肯定會有所保留，擔心說錯話，會議上就找不到真正的問題。
一般我們會直接聲明這個會議的目的，絕對沒有想追究任何人的責任的意思。不僅如此，我們還需要在會議過程中避免討論任何個人責任的問題。

了解與會人的心態

這是個很有意思的事情。會議本來就令人沮喪，更何狀是回顧會議這種非時間工作內容的、錦上添花的會議。與會者都是帶著什么心態來參加的呢？這里有一種非常有意思的收集與會者心態的小活動，叫做“ESVP”：

ESVP

• Explorer （探索者）
• Shopper （推銷者）
• Vacationer （度假者）
• Prisoner （囚犯）

這四個角色代表了四種與會的心態，可以通過與會者不記名的統計（匿名的在貼紙上寫上代表自己真實心態的角色首字母）就能知道會議室里大家的實際情況。統計的結果不一定總讓人歡欣鼓舞，但這個小小的活動往往能有效的喚起大家內心的思考，很有價值。

激活大家的發言欲望

事實證明，一個會議上，如果一開始大家就可以不需要發言，只是聽，那么很大機會大家在整個會議上都將保持沉默，有沒什么想說的，盡管會議中后期你希望更多人參與發言。辦法是一開始就破冰。簡單常用的方法是讓大家按座位順序輪流用一個詞形容他/她對這個迭代的感受。只讓用一個詞說實話非常難，不過沒關系，這個時候大家就會開始腦子飛快的轉起來了，到底哪個詞比較合適。這樣不僅把大家帶到了回顧的思路里，更重要的是大家一開始就有機會開口表達自己的想法了。

把大家帶到這個迭代歷史的回憶中來

在開始收集數據之前，讓大家先回憶這個迭代到底發生了什么，這個至關重要，不然暴露的問題很可能變成天馬星空的抱怨。上面用一個詞描述這個迭代的感受是一個很好的方法，但除此之外還有心情曲線法也是很有意思的方式。方法很簡單，就是讓大家畫一條基于時間軸的心情曲線。如圖是一個團隊真實的曲線結果，每個人都不一樣，分享這個曲線的過程甚至能加強團隊成員的相互了解，加強信任感。

心情曲線

介紹會議基本規則

如果團隊有制定會議的基本原則的話，那我們需要在這個會議上同樣需要遵守，常見的比如不適用電腦，不在會議上打電話等等。
還有需要介紹本次會議時長和大概的議程（流程）安排，讓大家對會議過程和時間有預期。
當然這條是應該在最開始就介紹的，只是覺得沒有特色，所以我放到最后才寫，^_

收集數據

收集數據一般包含收集做的好的部分，做得不好的部分，有時還會創新想法部分。這個環節是回顧會議最具代表性的，發貼紙，然后大家各自寫，一個問題一張貼紙... 如下圖就是一個真實的例子：

好的和不好的

上面這個方式用得非常廣泛，就不多講了。除此之外還有一些變形的方式：

• 通過視覺化的、隱喻性的方法做引導，比如帆船回顧法
• 模擬論壇接力留言的方式，通過書寫來收集數據

帆船回顧法

產生見解

收集到了數據只是第一步，如果順利，到此為止我們就能收集到大量的、反應真實情況的好的和需要改進的點。接下來我們需要整理了。
先分類，因為大家是各自獨立寫的，所以肯定會有重復的，所以把同類的放到一起我們才能讓滿墻的紙片不那么凌亂。分類需要花一點時間，但這個過程也是剛好讓大家都了解其他人寫了什么的好機會，所以我往往會邀請組員上來和我一起來做分類，一個人做卡片宣讀，允許大家討論，一個人把相同意思的卡片貼到一起。
對做的好的部分，我們需要提出來鼓勵大家，希望我們能堅持下來，甚至做得更好。這個部分在實際操作中往往比較忽視，大家更愿意快點調到待改進部分。無論如何，如果發現團隊士氣低落，需要鼓勵的話，這時就是很好的機會，每個做得好的地方你都能有感而發。
對待改進的部分，這個是本次會議的核心內容，不過很不幸，往往團隊總結出來的待改進方面會比較多（>5個就算多吧），可會議時間有限，對這個部分，我們首先要做的就是確定優先級最高的核心問題（不超過3個）。確定的辦法最常用的就是投票，比如每人兩票。

確定改進項

當我們確定了待改進的重點之后，我們就需要討論得出針對這些問題的改進方案。
不過別急，不要這么快就跳到了改進方案上來，針對問題我們要先分析問題的根源，找到問題最根本的原因，我們再針對原因采取改進行動，這樣才能對問題做到根本的解決。

魚骨圖或5W的方法尋找問題根源

最常見的方法有魚骨圖法，如下圖，使用方法就不解釋了，大家自己google。

魚骨圖法

分組討論

討論尋找問題根源的的過程往往非常費時，這里常用的一個方式是把組員分組，每個小組專門討論一個問題，我們可以限時讓他們討論出問題的根源和推薦出改進計劃，這樣我們一個能節省時間，更有價值的是可以調動每一個成員的積極參與度。

SMART的改進計劃

一個老調重彈的就是所有的改進計劃都必須是SMART的，SMART原則也不介紹了。這點說得容易，但做起來往往困難很大，大家非常容易產出一些類似建議一樣的東西，完全沒辦法執行，這個要避免。

避免產出過多改進計劃

當然還有一個陷阱就是改進計劃過多，到時候團隊根本沒有時間完成這么多的改進計劃，這個也需要排優先級；還有超出團隊能力范圍的改進要避免，不然也沒法落實。

結束會議

結束會議如果有必要的話我們可以簡單對本次會議的組織做個總結建議，可以幫助我們提高下次回顧會議的組織能力。

但我最喜歡的結束會議的方式是讓大家每個人通過一張紙片的形式感謝團隊里的一個人，并附上理由。我覺得這是一個很好的激勵團隊更多合作和相互幫助的好辦法。寫好紙片之后，我會請大家當眾宣讀一下卡片內容，并親手交給自己感謝的人，紙片格式如下：

感激卡

需要注意的地方

1. 一般情況不建議團隊的經理參加回顧會議。這有悖于準備環節中提到的設立一個安全的環境，大家會擔心在會議上暴露團隊問題會對他們績效產生不好的影響。但也有一種情況我們需要經理在場，那就是團隊已經積累了很多非常嚴重的問題，但是經理可能都不大了解情況，大家都期盼的經理在場能聽到并推動解決這些問題。
2. 會議產生的改進計劃怎么有效的跟蹤？一般我們建議把這些action之間放到團隊下個迭代的工作列表中，和普通開發工作一樣對待跟蹤，只有這樣才能有效的使得改進落地。
3. 前后回顧會議產出相同或類似的改進計劃。這說明老問題一直沒有解決，有的時候會發現每次改進計劃都完成了，但是老問題仍然還在。一般如果想改進能力或是外部依賴的問題往往會導致這樣的情況，這些不像團隊自己的流程那樣能立竿見影，面對這樣的問題，團隊最好能計劃一些長期的（周期跨迭代的）改進計劃，下次回顧會議可以監控進展，而不是提重復的問題。
4. 如果需要，別忘了在回顧會議前面簡單過一下上次回顧會議產出的改進計劃完成情況。