01

—

關于敏捷回顧會議

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

Scrum 迭代框架圖

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

敏捷回顧-團隊從優秀到卓越之道

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

02

—

敏捷回顧會議的那些套路

Agile Retrospective

　　相信經歷過敏捷回顧的朋友們都會對回顧會議有一個結構化的流程認知，這個流程大致包括以下幾個內容：

預設會議基調

　　回顧會議一開始并不是直入主題，而是要讓團隊成員拋開迭代開發中的苦悶，休閑一下放松心情，特別是營造一個良好的便于討論問題的氛圍很重要，能夠讓人人都發言是重點。主持人（一般是SM，Scrum Master）會在此期間重申回顧會議的目的和此次會議的目標。

收集數據

　　一個迭代中發生的事件很多，一個人（即使是Leader或SM或PO）不可能了解完這些所有的事件，因此需要從所有團隊成員那里收集這些數據（一般指事件），讓這些數據繪制成一幅共享圖，記錄所有發生過的事件。這些事件中有的是值得高興的，有的是令人苦悶的，找到這些苦悶的并試著去解決它就是關鍵。

決定做什么

　　記得彼得德魯克在《卓有成效的管理者》中建議“一次只做一件事”，同理，一個迭代的時間有限，團隊成員的精力也有限，我們需要在收集到的數據中選出1~2個優先級最高的，對后續迭代價值最大的事情進行解決，產出能產生積極效果的行動方案。

激發靈感產生見解

????????找到了那些令人苦悶的事情，這時就該問“為什么”和開始考慮解決這些問題的方法了。大多數人的思維是：一旦出現問題，人們容易一下就跳到解決方案上，最初想到的解決方案可能是對的，但大多數情況下都不一定是對的，往往是治標不治本，因為并沒有找到其根本原因。因此，在這一步驟中，我們往往會通過一些方法究其根本原因。

總結結尾

????????所有好事都有個盡頭，回歸會議也不例外，該結束時就結束，這時可以感謝每個人在迭代開發和回顧活動中的努力，以此作為回歸會議的結尾。

03

—

敏捷回顧會議的一些實踐總結

在這幾年實踐敏捷的過程中，發現自己一直開不好回顧會議，因為這個會議真的很難，但也在不斷的學習和被領導指點的過程中有了一點自己的實踐總結。

設定一個安全的吐槽環境

????????雖然敏捷強調自組織和扁平化，但是并不代表大家都能敞開心扉，因此在經歷一個迭代之后，讓大家都能敞開心扉的聊一會天，吐一下槽，得到迭代開發中最真實的感受很重要。但是，不是所有人都能說出來，可能并不是他不想說，而是你創造的環境并不讓他覺得安全。因此，我一般都會選擇在迭代的最后一天下午進行回顧會議，這天下午不安排什么工作，大家休閑一下，進行兩個小時的回顧會議。會議地點我一般會選擇一個寬敞一點的會議室，然后提前買好零食和飲料（公費報銷，一般也就30塊左右），關好會議室的門，給大家一種關起門來high的感覺，團隊成員的防備心就會減弱，有利于敞開心扉吐槽大會。

?安全的劃水環境必備—零食與飲料

　　此外，回顧會議不是“批評與自我批評”，更不是“問責和處罰”，要以一種休閑且認真（是不是很矛盾）的心態主持這個會議，否則即使團隊成員人人都開口說話了，但仍然達不到想要的效果。最好的效果就是，要讓團隊成員覺得在回顧會議上沒有領導，啥都可以說，反正回顧會議一結束，說過的話大家就都忽略了。

激發團隊成員的發言欲望

????????有了安全的吐槽環境，但還是有可能一些同事由于性格原因（雖然大多時候都是悶騷）不愿意多說話，這時候就需要主持人通過一些小橋段或者小游戲讓他們多說話。這時我一般會采用一些小游戲來暖場，比如我會準備一些打印好的紙條，里面寫著“在Sprint 3，我最想感謝______，因為________________________”，然后給大家5分鐘時間，每個人完成這個紙條來寫下他最想感謝的人，并說明不少于10個字的原因。5分鐘之后，不少人寫完了，這時我會告知大家被感謝的次數最多的人會請在場的同事一人一杯奶茶。然后，這時就可以安排成員們一個一個上來說了，現場氛圍一下就可以達到火熱化，每個人都在計算著自己被感謝了幾次，最終某個成員被感謝了多次，被迫請了奶茶。最后，我也準備了一個道具“榮譽證書”，送給了這位被迫請奶茶的同事聊以慰藉。

　　激發團隊成員放松下來開口說話的方式有很多，必要的暖場活動也是需要的，畢竟，有些時候儀式感還是很重要的，不要覺得麻煩就不去弄，你的心思最終都會被團隊成員看在眼里的。

　　最后，為了回顧會議能夠高效進行，除了要暖場保證會議在一個較為輕松的氛圍中進行，同時還得約定一些“協議”。比如，我會要求團隊在回顧會議期間盡量不玩手機，如果有人違反這個協議，那就會罰款5元加入團隊的公款賬戶或者請某人喝一杯奶茶之類的約定，這樣下來，大家都會集中于回顧會議本身而非三心兩意。

收集數據時一定要落實到具體事件

????????在收集數據時大多數時候采用的一般都是“高興-悲傷”或者“憤怒-悲傷-高興”法，要求團隊成員使用不同顏色的貼紙或卡片來描述他們在迭代中不同時間段的情緒感受，但是大多數時候團隊成員都只會描述一個簡短的說明語句而并非具體的事件。例如，成員A會說我悲傷的是代碼質量差，這就是一個非?；\統的說明，而并非一個具體的事件。而我們在主持收集數據活動的時候，一定要引導成員落實到具體的事件中去，即到底是什么事件讓你感到悲傷？因為如果不定位到事件，后續無法準確的去挖根本原因。這里需要注意的是：在描述事件時，一定是描述事件的現象，而非描述事件的解決方案（雖然程序員大多都喜歡提前解決問題，跳入實現細節中去）。

?

　　其次，在大家發表做的好的和做的不好的時候，應該特別注意“對事不對人”的原則。舉個例子，我們可以說“代碼評審不充分，所以代碼缺陷較高”，不能說“某某某評審不認真”，當然夸人帥還是可以的哈。如果違反了這個原則，主持人（比如Scrum Master）一定得記得糾正和防止走偏。

　　最后，對于Scrum Master或者Product Owner，最好在最后再發言，以避免對團隊成員產生一定程度的干擾。

一次只優化一個問題

???????收集完數據之后，通過將各個成員的數據進行分類，然后匯集所有成員進行探討，找出其中的一項（建議一項，畢竟人的精力有限，事實證明，多了你也實踐不好）作為后面分析原因和找出解決方案的項。很多時候，很多團隊往往希望盡可能多的在一次回顧會議上想要解決團隊成員提出的多個問題，但事實證明，那是不現實的，最后往往一件事都沒做好，因為看到事情多，所以沒有分析到根本原因，導致問題重復出現。

一定要探求根本原因

????????在《敏捷回顧-團隊從優秀到卓越之道》一書中，對于產生見解并尋找問題原因這個步驟例舉了很多的方法，但最為有效也最為常用的只有5個Why或者魚骨圖法，我一般都用5個Why法。

　　所謂5個Why就是對一個問題點連續以5個“為什么”來自問，以追究其根本原因。雖為5個為什么，但使用時不限定只做“5次為什么的探討”，主要是必須找到根本原因為止，有時可能只要3次，有時也許要10次，如古話所言：打破砂鍋問到底。

5個Why法的關鍵所在：鼓勵解決問題的人要努力避開主觀或自負的假設和邏輯陷阱，從結果著手，沿著因果關系鏈條，順藤摸瓜，直至找出原有問題的根本原因。

　　在實踐5個Why的過程中，需要注意的是：

• 如果給出的原因多于一個，那么試著找出所有原因的根源；

• 分析完成后，要從最后一個為什么開始反推“問題的現象”，確認反向邏輯也是正確的；

　　下圖是一個5 Why分析的運用形勢圖，來源于互聯網：　　

持之以恒貫徹執行

????????“沒有做到真正地貫徹執行”是回顧會議存在的最大問題，也是我碰到過的很多團隊都存在的問題。一旦分析到了根本原因，我們需要制定出解決方法，通常我們會通過制定團隊規則（比如沒有經過自測并完成測試用例優先級為2的代碼不能提交測試環境等）或者增加Backlog Task（比如為所有backlog增加Code Review環節）來在后續的迭代中貫徹執行，并且在下一次的回顧會議中來一起評價一下這些解決方案是否有效，如果大多數成員都覺得有效，那就證明我們花費的時間是有成果的。

04

—

小結

????????一個團隊總說他們現在太忙，沒有時間來開回顧會議，沒有時間讓自己變得更好—從未來的角度看，這就是一個非常短視的觀點。在《高效能人士的七個習慣》一書中，Stephen Covey 使用伐木工人花費數天時間用鋸條砍伐一棵樹來做類比。最終，鋸條變鈍了。但是，由于目光短淺，伐木工人永遠不會停下來磨鋸。一個同樣目光短淺的團隊也不會花費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》

恰童鞋騷年，風華也許不再正茂，但卻仍想揮斥方遒。

本公眾號會長期關注和分享.NET Core，Microservice，Docker，Kubernetes，CI（持續集成）等技術內容文章，還會與你分享個人生活成長的點滴及各類好書的讀書筆記，希望能對你有所幫助，一起成長！

點個【在看】，和更多人一起分享！

總結

以上是生活随笔為你收集整理的敏捷回顾会议的套路与实践分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。