靈活回顧會議的套路與實踐分享

一、關于靈活回顧會議

　　實踐過靈活的人都知道，在靈活中會有很多的會議要開，比如計劃會議（Planning）、站立會議（Daily Scrum）、評審會議（Review）以及回顧會議（Retrospective）等。如果用幾個簡短的詞語來概括靈活的精髓，我想一定是：“小步疊代，快速回報，持續改進”，通過将大塊的整體需求拆分成疊代增量，每個疊代的成果對于使用者而言都是一個可用品，是以可以快速地得到回報，進而防止走偏。那麼，如何做到持續改進呢？這就涉及到今天談論的話題：“回顧會議”。

　　在身邊大部分實踐靈活的團隊裡，大家對于回歸會議其實都不是很重視，包括我自己前三年在M公司（某世界500強外企）的時候也是不重視的，總是認為疊代已經很緊了，幹嘛還要花時間去開那個會議，無非也就是讓大家休閑一下嘛，還不如出去找個農家樂團建一下來的實在。但是，如果我們有這種想法，其實是無法幫助團隊做到持續改進的。所謂持續改進，就是在每個疊代之後發現每個疊代整個團隊的痛點又或者說是槽點（對，回顧會議更像是團隊的吐槽大會，能夠将回顧會議變成吐槽大會也說明主持人主持的很成功），然後選出1~2個團隊認為最應該解決的槽點想一下怎麼應對，然後一起制定一個Solution把它變為一項機制在下個疊代中進行避免或解決，然後如此反複，每個疊代都解決一個槽點，這樣團隊就會變得越來越像一個卓越的團隊。正如回顧會議的一本經典圖書《靈活回顧-團隊從優秀到卓越之道》的名字一樣，做好回歸會議，真的會讓團隊從優秀變為卓越。

　　在此，也真心推薦一下這本《靈活回顧-團隊從優秀到卓越之道》，雖然這本書已經有一定年份了，但是姜還是老的辣，裡面的方法和套路是我們值得學習的，然後在實踐中應用他們，選出最合适自己的一部分套路，得出自己的一點心得，然後幫助團隊做到持續改進，就是足以自豪的地方了。

二、靈活回顧會議的那些套路

　　相信經曆過靈活回顧的朋友們都會對回顧會議有一個結構化的流程認知，這個流程大緻包括以下幾個内容：

　　（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環節）來在後續的疊代中貫徹執行，并且在下一次的回顧會議中來一起評價一下這些解決方案是否有效，如果大多數成員都覺得有效，那就證明我們花費的時間是有成果的。

四、小結

　　一個團隊總說他們現在太忙，沒有時間來開回顧會議，沒有時間讓自己變得更好——從未來的角度看，這就是一個比較短視的觀點。一個目光短淺的團隊不會花費60到120分鐘來尋找改進。相反，他們将那60到120分鐘裡可能開發出的一點點代碼看得更為有價值些。

　　很多時候，我們都會因為走得太快，低頭玩手機，而忘記了停下來“回顧”這一路經過了哪些風景又錯過了哪些人，我想對于靈活團隊來說，那應該是就是：

• For a better future;
• Learn from past;
• Take action in present;

　　願我們都能定期停下來看看來時的路！

附：腦圖分享

參考資料

Esther Derby / Diana Larsen，《

靈活回顧-團隊從優秀到卓越之道

》（推薦閱讀）

森林遊泳的魚，《

靈活回顧-團隊從優秀到卓越之道學習總結

》

劉恒，《

華為雲靈活回歸會議實踐分享

Unknown，《

靈活開發中回顧會議是什麼？為什麼總有人開不好回顧會議？

Ben Linders，《

從靈活回顧中收獲價值

Holger Paffrath，《

Agile Retrospective : Lessons Learned