敏捷回顧會議的套路與實踐分享
一、關於敏捷回顧會議
實踐過敏捷的人都知道，在敏捷中會有很多的會議要開，比如計劃會議（Planning）、站立會議（Daily Scrum）、評審會議（Review）以及回顧會議（Retrospective）等。如果用幾個簡短的詞語來概括敏捷的精髓，我想一定是：“小步迭代，快速反饋，持續改進”，通過將大塊的整體需求拆分成迭代增量，每個迭代的成果對於使用者而言都是一個可用品，因此可以快速地得到反饋，從而防止走偏。那麼，如何做到持續改進呢？這就涉及到今天談論的話題：“回顧會議”。
Scrum 迭代框架圖
在身邊大部分實踐敏捷的團隊裡，大家對於迴歸會議其實都不是很重視，包括我自己前三年在M公司（某世界500強外企）的時候也是不重視的，總是認為迭代已經很緊了，幹嘛還要花時間去開那個會議，無非也就是讓大家休閒一下嘛，還不如出去找個農家樂團建一下來的實在。但是，如果我們有這種想法，其實是無法幫助團隊做到持續改進的。所謂持續改進，就是在每個迭代之後發現每個迭代整個團隊的痛點又或者說是槽點（對，回顧會議更像是團隊的吐槽大會，能夠將回顧會議變成吐槽大會也說明主持人主持的很成功），然後選出1~2個團隊認為最應該解決的槽點想一下怎麼應對，然後一起制定一個Solution把它變為一項機制在下個迭代中進行避免或解決，然後如此反覆，每個迭代都解決一個槽點，這樣團隊就會變得越來越像一個卓越的團隊。正如回顧會議的一本經典圖書《敏捷回顧-團隊從優秀到卓越之道》的名字一樣，做好迴歸會議，真的會讓團隊從優秀變為卓越。
敏捷回顧-團隊從優秀到卓越之道
在此，也真心推薦一下這本《敏捷回顧-團隊從優秀到卓越之道》，雖然這本書已經有一定年份了，但是薑還是老的辣，裡面的方法和套路是我們值得學習的，然後在實踐中應用他們，選出最合適自己的一部分套路，得出自己的一點心得，然後幫助團隊做到持續改進，就是足以自豪的地方了。
二、敏捷回顧會議的那些套路
Agile Retrospective
相信經歷過敏捷回顧的朋友們都會對回顧會議有一個結構化的流程認知，這個流程大致包括以下幾個內容：
（1）預設會議基調
回顧會議一開始並不是直入主題，而是要讓團隊成員拋開迭代開發中的苦悶，休閒一下放鬆心情，特別是營造一個良好的便於討論問題的氛圍很重要，能夠讓人人都發言是重點。主持人（一般是SM，Scrum Master）會在此期間重申回顧會議的目的和此次會議的目標。
（2）收集資料
一個迭代中發生的事件很多，一個人（即使是Leader或SM或PO）不可能瞭解完這些所有的事件，因此需要從所有團隊成員那裡收集這些資料（一般指事件），讓這些資料繪製成一幅共享圖，記錄所有發生過的事件。這些事件中有的是值得高興的，有的是令人苦悶的，找到這些苦悶的並試著去解決它就是關鍵。
（3）決定做什麼
記得彼得德魯克在《卓有成效的管理者》中建議“一次只做一件事”，同理，一個迭代的時間有限，團隊成員的精力也有限，我們需要在收集到的資料中選出1~2個優先順序最高的，對後續迭代價值最大的事情進行解決，產出能產生積極效果的行動方案。
（4）激發靈感產生見解
找到了那些令人苦悶的事情，這時就該問“為什麼”和開始考慮解決這些問題的方法了。大多數人的思維是：一旦出現問題，人們容易一下就跳到解決方案上，最初想到的解決方案可能是對的，但大多數情況下都不一定是對的，往往是治標不治本，因為並沒有找到其根本原因。因此，在這一步驟中，我們往往會通過一些方法究其根本原因。
（5）總結結尾
所有好事都有個盡頭，迴歸會議也不例外，該結束時就結束，這時可以感謝每個人在迭代開發和回顧活動中的努力，以此作為迴歸會議的結尾。
三、敏捷回顧會議的一點實踐
在這幾年實踐敏捷的過程中，發現自己一直開不好回顧會議，因為這個會議真的很難，但也在不斷的學習和被領導指點的過程中有了一點自己的實踐心得。
（1）設定一個安全的吐槽環境
雖然敏捷強調自組織和扁平化，但是並不代表大家都能敞開心扉，因此在經歷一個迭代之後，讓大家都能敞開心扉的聊一會天，吐一下槽，得到迭代開發中最真實的感受很重要。但是，不是所有人都能說出來，可能並不是他不想說，而是你創造的環境並不讓他覺得安全。因此，我一般都會選擇在迭代的最後一天下午進行回顧會議，這天下午不安排什麼工作，大家休閒一下，進行兩個小時的回顧會議。會議地點我一般會選擇一個寬敞一點的會議室，然後提前買好零食和飲料（公費報銷，一般也就30塊左右），關好會議室的門，給大家一種關起門來high的感覺，團隊成員的防備心就會減弱，有利於敞開心扉吐槽大會。
安全的划水環境必備—零食與飲料
此外，回顧會議不是“批評與自我批評”，更不是“問責和處罰”，要以一種休閒且認真（是不是很矛盾）的心態主持這個會議，否則即使團隊成員人人都開口說話了，但仍然達不到想要的效果。最好的效果就是，要讓團隊成員覺得在回顧會議上沒有領導，啥都可以說，反正回顧會議一結束，說過的話大家就都忽略了。
（2）激發團隊成員發言的慾望
有了安全的吐槽環境，但還是有可能一些同事由於性格原因（雖然大多時候都是悶騷）不願意多說話，這時候就需要主持人通過一些小橋段或者小遊戲讓他們多說話。這時我一般會採用一些小遊戲來暖場，比如我會準備一些列印好的紙條，裡面寫著“在Sprint 3，我最想感謝______，因為________________________”，然後給大家5分鐘時間，每個人完成這個紙條來寫下他最想感謝的人，並說明不少於10個字的原因。5分鐘之後，不少人寫完了，這時我會告知大家被感謝的次數最多的人會請在場的同事一人一杯奶茶。然後，這時就可以安排成員們一個一個上來說了，現場氛圍一下就可以達到火熱化，每個人都在計算著自己被感謝了幾次，最終某個成員被感謝了多次，被迫請了奶茶。最後，我也準備了一個道具“榮譽證書”，送給了這位被迫請奶茶的同事聊以慰藉。
暖場小道具
激發團隊成員放鬆下來開口說話的方式有很多，必要的暖場活動也是需要的，畢竟，有些時候儀式感還是很重要的，不要覺得麻煩就不去弄，你的心思最終都會被團隊成員看在眼裡的。
最後，為了回顧會議能夠高效進行，除了要暖場保證會議在一個較為輕鬆的氛圍中進行，同時還得約定一些“協議”。比如，我會要求團隊在回顧會議期間儘量不玩手機，如果有人違反這個協議，那就會罰款5元加入團隊的公款賬戶或者請某人喝一杯奶茶之類的約定，這樣下來，大家都會集中於回顧會議本身而非三心兩意。
（3）收集資料一定要落實到具體事件
在收集資料時大多數時候採用的一般都是“高興-悲傷”或者“憤怒-悲傷-高興”法，要求團隊成員使用不同顏色的貼紙或卡片來描述他們在迭代中不同時間段的情緒感受，但是大多數時候團隊成員都只會描述一個簡短的說明語句而並非具體的事件。例如，成員A會說我悲傷的是程式碼質量差，這就是一個非常籠統的說明，而並非一個具體的事件。而我們在主持收集資料活動的時候，一定要引導成員落實到具體的事件中去，即到底是什麼事件讓你感到悲傷？因為如果不定位到事件，後續無法準確的去挖根本原因。這裡需要注意的是：在描述事件時，一定是描述事件的現象，而非描述事件的解決方案（雖然程式設計師大多都喜歡提前解決問題，跳入實現細節中去）。
其次，在大家發表做的好的和做的不好的時候，應該特別注意“對事不對人”的原則。舉個例子，我們可以說“程式碼評審不充分，所以程式碼缺陷較高”，不能說“某某某評審不認真”，當然夸人帥還是可以的哈。如果違反了這個原則，主持人（比如Scrum Master）一定得記得糾正和防止走偏。
最後，對於Scrum Master或者Product Owner，最好在最後再發言，以避免對團隊成員產生一定程度的干擾。
（4）“一次只做一件事”
收集完資料之後，通過將各個成員的資料進行分類，然後彙集所有成員進行探討，找出其中的一項（建議一項，畢竟人的精力有限，事實證明，多了你也實踐不好）作為後面分析原因和找出解決方案的項。很多時候，很多團隊往往希望儘可能多的在一次回顧會議上想要解決團隊成員提出的多個問題，但事實證明，那是不現實的，最後往往一件事都沒做好，因為看到事情多，所以沒有分析到根本原因，導致問題重複出現。
（5）一定要探求根本原因
在《敏捷回顧-團隊從優秀到卓越之道》一書中，對於產生見解並尋找問題原因這個步驟例舉了很多的方法，但最為有效也最為常用的只有5個Why或者魚骨圖法，我一般都用5個Why法。
所謂5個Why就是對一個問題點連續以5個“為什麼”來自問，以追究其根本原因。雖為5個為什麼，但使用時不限定只做“5次為什麼的探討”，主要是必須找到根本原因為止，有時可能只要3次，有時也許要10次，如古話所言：打破砂鍋問到底。
5個Why法的關鍵所在：鼓勵解決問題的人要努力避開主觀或自負的假設和邏輯陷阱，從結果著手，沿著因果關係鏈條，順藤摸瓜，直至找出原有問題的根本原因。
在實踐5個Why的過程中，需要注意的是：
- 如果給出的原因多於一個，那麼試著找出所有原因的根源；
- 分析完成後，要從最後一個為什麼開始反推“問題的現象”，確認反向邏輯也是正確的；
下圖是一個5 Why分析的運用形勢圖，來源於網際網路：
（6）持之以恆貫徹執行
“沒有做到真正地貫徹執行”是回顧會議存在的最大問題，也是我碰到過的很多團隊都存在的問題。一旦分析到了根本原因，我們需要制定出解決方法，通常我們會通過制定團隊規則（比如沒有經過自測並完成測試用例優先順序為2的程式碼不能提交測試環境等）或者增加Backlog Task（比如為所有backlog增加Code Review環節）來在後續的迭代中貫徹執行，並且在下一次的回顧會議中來一起評價一下這些解決方案是否有效，如果大多數成員都覺得有效，那就證明我們花費的時間是有成果的。
四、小結
一個團隊總說他們現在太忙，沒有時間來開回顧會議，沒有時間讓自己變得更好——從未來的角度看，這就是一個非常短視的觀點。在《高效能人士的七個習慣》一書中，Stephen Covey使用伐木工人花費數天時間用鋸條砍伐一棵樹來做類比。最終，鋸條變鈍了。但是，由於目光短淺，伐木工人永遠不會停下來磨鋸。一個同樣目光短淺的團隊也不會花費60到120分鐘來尋找改進。相反，他們將那60到120分鐘裡可能開發出的一點點程式碼看得更為有價值些。
很多時候，我們都會因為走得太快，低頭玩手機，而忘記了停下來“回顧”這一路的初心，我想對於敏捷團隊來說，那應該是就是：
-
Fora better future;
-
Learn from past;
-
Take action in present;
願我們都能定期停下來看看來時的路！
附：腦圖分享
參考資料
Esther Derby/Diana Larsen，《敏捷回顧-團隊從優秀到卓越之道》（★★★）
森林游泳的魚，《敏捷回顧-團隊從優秀到卓越之道學習總結》
劉恆，《華為雲敏捷迴歸會議實踐分享》
Unknown，《敏捷開發中回顧會議是什麼？為什麼總有人開不好回顧會議？》
Ben Linders，《從敏捷回顧中收穫價值》
Holger Paffrath，《Agile Retrospective : Lessons Learned》
作者：周旭龍
出處：https://www.cnblogs.com/edisonchou/p/edc-agile-retrospective-meeting-practise.html
您的資助是我最大的動力！
金額隨意,歡迎來賞！
付款後有任何問題請給我留言。
如果，您希望更容易地發現我的新部落格，不妨點選一下綠色通道的【關注我】。(●'◡'●)
如果你覺得本篇文章對你有所幫助，請給予我更多的鼓勵，求打 付款後有任何問題請給我留言!!!因為，我的寫作熱情也離不開您的肯定支援，感謝您的閱讀，我是【Jack_孟】！