如果有人問“計劃會、每日站會、回顧會中只能留一個，你會留哪個”，我一定會選回顧會。計劃會和每日站會的目標是保證項目進度，而回顧會的目標是改進項目組。
我們的流程特點
從流程來說，回顧會非常簡單：定期地把大家聚到一起，或三言兩語地吐一番槽，或七嘴八舌地甩一通鍋，然後就各回各家各找各媽。但是顯然，這種回顧會對項目組的成長沒有什麼幫助。
甩鍋一時爽……然而解決不了任何實際問題
從流程來說，我們項目組的回顧會有幾個不同之處。
首先，我們項目組召開回顧會的第一件事，就是檢查上次會議的後續任務的落地情況——有時甚至要檢查上上次會議的成果，因爲一次回顧會的“決議”有時需要好幾個迭代週期才能真正開花結果。畢竟，回顧是爲了改進，改進絕不能停留在會議室、也不能停留在會議紀要上，而一定要有能落地的方案、要有方案的落地結果。否則，除了吐槽一時爽之外，回顧會開了也是白開。
這跟巡視組的“回頭看”、“回馬槍”是一個道理
其次，與自願發言或者主持人點名發言不同，我們的回顧會要求每個人必須發言。發言的內容麼，不外乎至少要說三個“做的比較好應該繼續堅持的點”以及三個“做得不太好需要改變的點”這種。其實每個人都對必須發言這點是剛開始時的無奈之舉，因爲無論是自願發言還是點名發言，都存在大家沒有準備而隨便說幾句的問題。但是在推行一段時間以後，項目組每個人都會在日常工作中就留心哪些地方有問題、哪些事情挺不錯，也會在日常工作中思考應當怎樣改進和提高。只有這樣，回顧會上纔有得可說，不至於被主持人“還有沒”“就這些”“還有吧你再想想”追問得啞口無言。
有些項目組的回顧會要求參會者把“做得好的地方”和“做得不太好的地方”先寫在紙條上，然後逐一翻紙條來討論。這樣做當然無可厚非，不過我還是更傾向於公開發言的形式。第一，寫在紙條上的內容通常都很簡練，討論時往往需要作者站出來做詳細說明。這樣一來，紙條就失去了它的匿名作用，與公開發言沒有差別了。第二，公開發言有助於培養團隊內開誠佈公的交流氛圍。就解決問題而言，最好的方式不是在回顧會上去反思、總結、改進，而是在問題發生時就發現、提出和解決它。如果內部都不能開誠佈公的交流、而要靠小紙條這種方式來提意見，那這羣人還能稱作是一個團隊嗎？第三，公開發言對程序員是個不小的鍛鍊。程序員們總是有意無意地忽略表達與溝通的技巧——例如提出問題、列舉事例、凝練論點、論述證明、總結髮言，等等，以至於當在面試、晉升、技術分享、甚至是甩鍋或者撩妹時，程序員們往往表現得張口結舌或者語無倫次，導致整個羣體都被貼上了“木訥”“不好溝通”的標籤。在回顧會上公開陳述自己的觀點，無論對個人的表達能力還是對團隊的溝通方式來說，都是很好的提高方式。
因爲會上必須發言，所以我在回顧會前就會準備好發言提綱。這是我雲筆記裏記錄的一篇提綱。
最後， 與個人發言一樣，回顧會一定要有總結。這個總結，不僅是把參會者的發言複述一遍，更要把其中的最核心、最重要的意見和建議轉化爲可行的流程、舉措，並指定負責人、以便於在下一個迭代週期內開始推動落實。這個事情說起來簡單做起來難。爲什麼簡單呢？因爲辦法總比問題多，回顧會上提出來的每個問題都能找出至少10種解決辦法來。爲什麼難呢？因爲我們必須從這10多種解決辦法中，找到一個能夠與項目組現行流程相契合的、在現行流程下最可行的方法來。
爲什麼強調現行流程呢？如果每一次回顧會都要在現行流程之外增加流程，很顯然，日常工作流程會飛速膨脹，管理成本急劇上升，工作效率則會急劇下降。最後的結果一定是工作流程被丟到一邊，大家怎麼方便怎麼來了。這樣一來，回顧會的努力就完全成了水中撈月了。當然，有時回顧會也會刪減工作流程，但這終歸沒有跳出對現行流程進行調整的五指山。
但是修改現有流程其實非常困難：不管是否合理、是否高效，現行工作流程一般是項目組成員在長時間的磨合、積累之後自發形成的，也是項目組成員非常熟悉和認可的。要想對它做出改變，就像要挪動一張桌子、在牆上開一扇窗戶一樣困難。這項工作不僅要求良好的流程設計——既能達到目標，又簡便易行，還要求有力的推行、越挫越勇的毅力和長期的耐心。沒錯，即使簡便易行，也要長期的、在挫折和阻力中，耐心地、一點一點地推動改變發生。
流程變更有點像火車並軌
我們的回顧成果
我們項目組就曾用這樣的方式把代碼評審加入到了敏捷開發的流程中來。
衆所周知，代碼評審是提高代碼質量和編程能力的一個非常好的舉措。我們項目組在調研了一些工具之後，也嘗試着把它加入到我們的迭代流程中來。
最開始的方式是組織代碼評審會，大家坐到會議室中一起看代碼。但這樣的評審會存在明顯的弊端，在之後的回顧會上就被取消了，取而代之的是每個人在日常工作中自己去做評審。但這樣也行不通。我們在回顧會上再一次討論後，決定每個人都要在週二和週四的下午優先對其他成員的代碼進行評審。這個法子收到了比較不錯的成效，但還有一些不足。我們在又一次的回顧總結後，確定了每週二下午做開放式評審、每週四下午做迴歸評審的代碼評審流程。再後來，我們還對代碼評審結果做了量化分析……這樣經過了若干次回顧會的討論總結和若干個迭代週期的嘗試推行，我們項目組才找到了適合自己的代碼評審的方式。
這是在推行代碼評審的過程中，我們的一次回顧會上的討論記錄
回顧會的“軟條件”
不過，除了合理的流程之外，要想讓回顧會發揮它應用的作用，還需要一些“軟條件”。
首先，一定要建立起開誠佈公的溝通氛圍。回顧會的目標是改進團隊的工作方式、讓團隊更愉快的合作、讓團隊成員更順心的工作。回顧會絕不能用來追責、甩鍋，這種事情只會讓與會者越發地離心離德，讓以後的合作由目標導向變成甩鍋導向，最後無論要做什麼事情都舉步維艱，效率和成績更是無從談起。
岔開說一句，追責、甩鍋這種情況在回顧會上也許比較少見，而在覆盤會上更加常見。畢竟，一般都是出了問題纔會開復盤會，而一般思維裏，出了問題總要有人來負責和背鍋。但是我認爲，無論是回顧會還是覆盤會，都應該着眼於未來而不是過去。過去已經過去，tomorrow is another day.
合作，而非對立，是teamwork的先決條件。
其次，開會一定要有會議紀要。紀要是會議的靈魂，任何不記錄會議紀要的會議都是浪費時間。回顧會的會議紀要和其它會議的沒什麼兩樣，核心都在於後續任務以及任務負責人。有了這樣的會議紀要，我們才能檢查此前的任務有沒有落地、落地的效果如何。這裏可以給有道雲筆記打個廣告：它的會議紀要模板就挺不錯的。
再岔開說一句，怎樣組織一個高效的會議其實也是一門不大不小的學問。例如會前分發會議材料、會上記錄會議紀要、會後跟進後續任務等工作，有時只是舉手之勞，卻能避免開一個會浪費十幾個人的時間。
這是有道雲筆記提供的會議紀要模板
最後，回顧會的主持人需要了解和使用一些引導大家開口的小技巧。有時，參會者的發言太過簡練或者膚淺；有時，主持人知道——或者認爲——參會者還有某些事情可以發言說一說；有時，主持人希望參會者能往某個方向多聊幾句。這些情況下，主持人都會、也應該用一點小技巧來推動或引導參會者繼續發言。例如，我們的回顧會主持人總會不停的追問“還有麼”“就這些”“你再想想”，“逼”得參會者不斷地去想、不斷地去說。他的這點小技巧、小心思，也算是我們項目組的回顧總結會的一個小特色了。
組織會議和主持會議一樣，是有技巧的