回顧會議（retrospective meeting）是scrum中最有價值的會議之一矮锈，雖然這個會議很重要把将，但是在實際的工作中我們會發(fā)現(xiàn)往往最容易被砍掉的也是這個會議。
為什么這個會容易被砍掉呢凿叠？項目工作太多程腹，大家太忙只是一個明面的借口，深層次的原因應(yīng)該有如下幾個：
- 會議過程和形式太枯燥重復(fù)焕数，沒有新意纱昧，讓人厭倦
- 會議產(chǎn)出的改進計劃不明確，不能落實堡赔，沒有跟蹤识脆，更沒效果
- 團隊缺乏持續(xù)改進的意識，只是停留在埋頭處理手上的工作
如果你發(fā)現(xiàn)你們團隊大家對回顧會議不感冒，也許你們就有上面這些問題灼捂，本文的目的是介紹一下我個人常用的回顧會議套路离例，僅供參考。
回顧會議的目的
回顧會議是Scrum檢視與調(diào)整的一個重要的環(huán)節(jié),在這個會議上的猛，我們鼓勵團隊對自己的開發(fā)過程進行改進耀盗，并確定什么樣的調(diào)整可以使下一Sprint的效率更高、結(jié)果更令人滿意和更易于工作卦尊。
就像我們頻繁的迭代和交付是為了快速的獲得外部用戶的反饋叛拷，進而幫助我們做產(chǎn)品需求的調(diào)整一樣，每個迭代的回顧會議就是想更快的得到大家對團隊工作問題和改進點的反饋岂却，幫助團隊內(nèi)部的工作效能和能力成長的不斷改進忿薇。
回顧會議的過程和我常用的手段
《Agile Retrospectives》這本書中把回顧會議分成了5個階段：
- 準備
- 收集數(shù)據(jù)
- 產(chǎn)生見解
- 確定改進項
- 結(jié)束會議
那我就按這幾個階段來講講我是怎么做的。
準備
準備階段其實是非常重要的躏哩，一些初次主持回顧會議的scrum master往往會忽視這個階段署浩，一上來就讓大家寫小卡片，這樣不僅效果不好扫尺，更給人枯燥重復(fù)的感覺筋栋。
準備階段我往往會選擇做下面幾件事：
設(shè)定一個安全的環(huán)境
回顧會議不僅僅希望大家能參與進來，更重要的是能敞開心扉正驻，大家沒有顧慮的把問題暴露出來二汛，找到改進的辦法。但事實是肯定有人擔(dān)心回顧會議會成為一個批判會議拨拓，在認為這個會議的目的是找到這個迭代中犯錯的那個人，并把他拎出來痛批一頓氓栈，看以后還有誰敢再犯渣磷。如果這樣大家肯定會有所保留，擔(dān)心說錯話授瘦，會議上就找不到真正的問題醋界。
一般我們會直接聲明這個會議的目的，絕對沒有想追究任何人的責(zé)任的意思提完。不僅如此形纺，我們還需要在會議過程中避免討論任何個人責(zé)任的問題。
了解與會人的心態(tài)
這是個很有意思的事情徒欣。會議本來就令人沮喪逐样，更何狀是回顧會議這種非時間工作內(nèi)容的、錦上添花的會議。與會者都是帶著什么心態(tài)來參加的呢脂新？這里有一種非常有意思的收集與會者心態(tài)的小活動挪捕，叫做“ESVP”：
- Explorer （探索者）
- Shopper （推銷者）
- Vacationer （度假者）
- Prisoner （囚犯）
這四個角色代表了四種與會的心態(tài)，可以通過與會者不記名的統(tǒng)計（匿名的在貼紙上寫上代表自己真實心態(tài)的角色首字母）就能知道會議室里大家的實際情況争便。統(tǒng)計的結(jié)果不一定總讓人歡欣鼓舞级零，但這個小小的活動往往能有效的喚起大家內(nèi)心的思考，很有價值滞乙。
激活大家的發(fā)言欲望
事實證明奏纪，一個會議上，如果一開始大家就可以不需要發(fā)言斩启，只是聽序调，那么很大機會大家在整個會議上都將保持沉默，有沒什么想說的浇垦，盡管會議中后期你希望更多人參與發(fā)言炕置。辦法是一開始就破冰。簡單常用的方法是讓大家按座位順序輪流用一個詞形容他/她對這個迭代的感受男韧。只讓用一個詞說實話非常難朴摊，不過沒關(guān)系，這個時候大家就會開始腦子飛快的轉(zhuǎn)起來了此虑，到底哪個詞比較合適甚纲。這樣不僅把大家?guī)У搅嘶仡櫟乃悸防铮匾氖谴蠹乙婚_始就有機會開口表達自己的想法了朦前。
把大家?guī)У竭@個迭代歷史的回憶中來
在開始收集數(shù)據(jù)之前介杆，讓大家先回憶這個迭代到底發(fā)生了什么，這個至關(guān)重要韭寸，不然暴露的問題很可能變成天馬星空的抱怨春哨。上面用一個詞描述這個迭代的感受是一個很好的方法，但除此之外還有心情曲線法也是很有意思的方式恩伺。方法很簡單赴背，就是讓大家畫一條基于時間軸的心情曲線。如圖是一個團隊真實的曲線結(jié)果晶渠，每個人都不一樣凰荚，分享這個曲線的過程甚至能加強團隊成員的相互了解，加強信任感褒脯。
當(dāng)然還有一些常用的手段是把團隊的看板或是燃盡圖都帶到會議室里來便瑟，這就要看有沒有了。
介紹會議基本規(guī)則
如果團隊有制定會議的基本原則的話番川，那我們需要在這個會議上同樣需要遵守到涂，常見的比如不適用電腦脊框，不在會議上打電話等等。
還有需要介紹本次會議時長和大概的議程（流程）安排养盗，讓大家對會議過程和時間有預(yù)期缚陷。
當(dāng)然這條是應(yīng)該在最開始就介紹的，只是覺得沒有特色往核，所以我放到最后才寫箫爷，_
收集數(shù)據(jù)
收集數(shù)據(jù)一般包含收集做的好的部分，做得不好的部分聂儒，有時還會創(chuàng)新想法部分虎锚。這個環(huán)節(jié)是回顧會議最具代表性的，發(fā)貼紙衩婚，然后大家各自寫窜护，一個問題一張貼紙... 如下圖就是一個真實的例子：
上面這個方式用得非常廣泛，就不多講了非春。除此之外還有一些變形的方式：
- 通過視覺化的柱徙、隱喻性的方法做引導(dǎo)，比如帆船回顧法
- 模擬論壇接力留言的方式奇昙，通過書寫來收集數(shù)據(jù)
產(chǎn)生見解
收集到了數(shù)據(jù)只是第一步护侮，如果順利，到此為止我們就能收集到大量的储耐、反應(yīng)真實情況的好的和需要改進的點羊初。接下來我們需要整理了。
先分類什湘，因為大家是各自獨立寫的长赞，所以肯定會有重復(fù)的，所以把同類的放到一起我們才能讓滿墻的紙片不那么凌亂闽撤。分類需要花一點時間得哆，但這個過程也是剛好讓大家都了解其他人寫了什么的好機會，所以我往往會邀請組員上來和我一起來做分類哟旗，一個人做卡片宣讀柳恐，允許大家討論，一個人把相同意思的卡片貼到一起热幔。
對做的好的部分，我們需要提出來鼓勵大家讼庇，希望我們能堅持下來绎巨，甚至做得更好。這個部分在實際操作中往往比較忽視蠕啄，大家更愿意快點調(diào)到待改進部分场勤。無論如何戈锻，如果發(fā)現(xiàn)團隊士氣低落，需要鼓勵的話和媳，這時就是很好的機會格遭，每個做得好的地方你都能有感而發(fā)。
對待改進的部分留瞳，這個是本次會議的核心內(nèi)容拒迅，不過很不幸，往往團隊總結(jié)出來的待改進方面會比較多（>5個就算多吧）她倘，可會議時間有限璧微，對這個部分，我們首先要做的就是確定優(yōu)先級最高的核心問題（不超過3個）硬梁。確定的辦法最常用的就是投票前硫，比如每人兩票。
確定改進項
當(dāng)我們確定了待改進的重點之后荧止，我們就需要討論得出針對這些問題的改進方案屹电。
不過別急，不要這么快就跳到了改進方案上來跃巡，針對問題我們要先分析問題的根源危号，找到問題最根本的原因，我們再針對原因采取改進行動瓷炮，這樣才能對問題做到根本的解決葱色。
魚骨圖或5W的方法尋找問題根源
最常見的方法有魚骨圖法，如下圖娘香，使用方法就不解釋了苍狰，大家自己google。
還有一個理論就是5個WHY烘绽，也是一個很好用的方法淋昭。
分組討論
討論尋找問題根源的的過程往往非常費時，這里常用的一個方式是把組員分組安接，每個小組專門討論一個問題翔忽，我們可以限時讓他們討論出問題的根源和推薦出改進計劃，這樣我們一個能節(jié)省時間盏檐，更有價值的是可以調(diào)動每一個成員的積極參與度歇式。
SMART的改進計劃
一個老調(diào)重彈的就是所有的改進計劃都必須是SMART的，SMART原則也不介紹了胡野。這點說得容易材失，但做起來往往困難很大，大家非常容易產(chǎn)出一些類似建議一樣的東西硫豆，完全沒辦法執(zhí)行龙巨，這個要避免笼呆。
避免產(chǎn)出過多改進計劃
當(dāng)然還有一個陷阱就是改進計劃過多，到時候團隊根本沒有時間完成這么多的改進計劃旨别，這個也需要排優(yōu)先級诗赌；還有超出團隊能力范圍的改進要避免，不然也沒法落實秸弛。
結(jié)束會議
結(jié)束會議如果有必要的話我們可以簡單對本次會議的組織做個總結(jié)建議铭若，可以幫助我們提高下次回顧會議的組織能力。
但我最喜歡的結(jié)束會議的方式是讓大家每個人通過一張紙片的形式感謝團隊里的一個人胆屿，并附上理由奥喻。我覺得這是一個很好的激勵團隊更多合作和相互幫助的好辦法。寫好紙片之后非迹，我會請大家當(dāng)眾宣讀一下卡片內(nèi)容环鲤，并親手交給自己感謝的人，紙片格式如下：
需要注意的地方
- 一般情況不建議團隊的經(jīng)理參加回顧會議憎兽。這有悖于準備環(huán)節(jié)中提到的設(shè)立一個安全的環(huán)境冷离，大家會擔(dān)心在會議上暴露團隊問題會對他們績效產(chǎn)生不好的影響。但也有一種情況我們需要經(jīng)理在場纯命，那就是團隊已經(jīng)積累了很多非常嚴重的問題西剥，但是經(jīng)理可能都不大了解情況，大家都期盼的經(jīng)理在場能聽到并推動解決這些問題亿汞。
- 會議產(chǎn)生的改進計劃怎么有效的跟蹤瞭空？一般我們建議把這些action之間放到團隊下個迭代的工作列表中，和普通開發(fā)工作一樣對待跟蹤疗我，只有這樣才能有效的使得改進落地咆畏。
- 前后回顧會議產(chǎn)出相同或類似的改進計劃。這說明老問題一直沒有解決吴裤，有的時候會發(fā)現(xiàn)每次改進計劃都完成了旧找，但是老問題仍然還在。一般如果想改進能力或是外部依賴的問題往往會導(dǎo)致這樣的情況麦牺，這些不像團隊自己的流程那樣能立竿見影钮蛛，面對這樣的問題，團隊最好能計劃一些長期的（周期跨迭代的）改進計劃剖膳，下次回顧會議可以監(jiān)控進展魏颓，而不是提重復(fù)的問題。
- 如果需要吱晒，別忘了在回顧會議前面簡單過一下上次回顧會議產(chǎn)出的改進計劃完成情況甸饱。
