了解敏捷的人應該對回顧會不陌生，回顧會是在SCRUM框架五個活動中的最后一個活動，但是在敏捷的實際應用中，回顧會并不只是會在應用SCRUM的團隊中使用，在其他敏捷實踐中也會引入回顧會作為反饋環節。

那么什么是回顧會呢？在SCRUM中，回顧會是來回顧當前迭代中的流程、工具、實踐、溝通、環境、資源等方方面面，檢視各個過程并提出改進項的活動。這個會議重點在于聚焦問題并持續改進。這個是一個最容易被忽略的會議，尤其是在開發壓力比較大時，回顧會往往會是第一個被裁剪的過程。

一、為什么需要進行回顧？

孔子曰：吾日三省吾身。只有不斷反思/回顧才能找到自己需要改進的地方并持續改進，在軟件開發中也同樣如此。敏捷體系是開源體系，沒有終點；即沒有最敏捷只有更敏捷。那么如何讓我們的敏捷團隊更加敏捷呢，回顧會是一個必不可少非常重要的會議。每個迭代中運行著相同的過程，這同時也意味著可能重復著同樣的錯誤。可以說沒有回顧就沒有持續改進。如果你的團隊在應用敏捷，在應用SCRUM框架，那么回顧會是持續改進的必要過程和活動。

二、回顧會應用怎么開？

這個問題對敏捷教練提出了比較高的要求，在回顧會上，尤其是在剛開始實踐敏捷的團隊回顧會上，團隊往往不知道回顧會要做些什么。常見的誤區就是會把回顧會理解為總結會或者反思會。此時，敏捷教練要給予正確的引導。

回顧會的流程比較簡單，通常有以下幾個議程：

2.1 會前準備

回顧會之前一定要收集足夠的數據，包括迭代中故事完成度，燃盡圖，速率圖，每個故事耗時情況等，收集數據后需要向團隊進行展示。其次，確定好要邀請的人員以及回顧形式和議程。回顧會的準備是非常重要的，準備是否會很大程度上決定能否開一個有效的回顧會。

2.2 會議主要議程

1)向團隊展示度量數據，通過數據進行初步分析，鼓勵團隊參與討論，是否有顯而易見的重大問題，是否有特殊情況導致本迭代的數據問題。如果有重大問題，在回顧時作為重點進行回顧。

2)讓團隊成員各自總結需要繼續保持的和需要改進的項，這里有很多方法，包括三欄式(Well, Less Well, Puzzle)、海星圖(Start, Stop, Do Less, Do More, Keep)以及SSCC(Start, Stop, Continue, Change)等。

3)將大家的反饋進行分組，并針對需要改進的問題進行分析，這時也可以采用一些根因分析的工具，包括魚骨圖等，最后收斂出需要做的改進點。

4)針對改進點制定行動計劃(Action)及負責人(Owner)，并就行動計劃在團隊內達成一致。

2.3 結束會議

回顧會的結束，可以添加一些儀式感，比如由幾個人說一下這個迭代中需要感謝的人，為他提供幫助的人，簡單的表示感謝；然后由SM做一個簡單的總結，對會上討論達成一致的改進項、負責人和行動計劃進行重申，最后需要對大家表示感謝后結束會議。

三、如何開好回顧會？

怎樣使回顧會開得最有效果？可以將迭代中的問題全面暴露出來就是有效果的；可以將上個迭代重復發生的問題減少甚至避免就是有效果的；團隊成員都認為每個迭代我們都在持續改進中，并且樂于每個迭代進行回顧改進就是有效果的。最后，只有回顧后貫徹執行持續改進才是最有效的。那么如何使回顧會有效果呢？

3.1 營造輕松的氛圍

• 會議場地：大部分的回顧會都會選擇在會議室進行。在工作單位中會議室確實是大家集體討論事宜比較合適的場所，但是容易給大家一種緊張嚴肅的感覺，不利于團隊成員暢所欲言。一般比較建議的咖啡間等等。
• 會議時間：一般回顧會會定在迭代最后一周的周五，迭代評審會之后。這個時間點一般迭代都已經完成，大家只剩下一些收尾的工作，會比較容易營造大家放松的氣氛，團隊不用去考慮仍未開發完的功能、未修復的bug等，團隊更容易參與到回顧中。
• 參會人員：回顧會需要大家暢所欲言，針對相關問題進行解決方案和行動計劃制定的活動，是團隊內部自我改進的活動。由于領導層通常掌握著團隊成員的績效獎金等切身利益，如果有領導層的參與會容易大家感覺到緊張，以至于會報喜不報憂，沒有辦法持續改進。這時一般建議如果不是有非常嚴重且必須要領導解決的問題之外，不會建議領導層參會。對于產品經理是否應該參加回顧會的問題，產品經理是團隊的一員，原則應該要參加回顧會，但是如果產品經理的在場會導致團隊緊張或者不敢提出問題，那產品經理還是不建議參加會議的。
• 暖場：為了讓大家放松下來，一般需要SM開場比如一個笑話，一個簡單小游戲開場，讓大家放松下來適應輕松的氛圍；
• 開場：敏捷教練可以通過一些小技巧讓大家快速思考起來，比如讓團隊成員用一句話、一個詞或者一個水果來形容對當前迭代的感受，用簡單的話來形容容易激發大腦的思考。一句話，一個詞語而不是一段話，這時就會激發大家去動腦，從眾多詞語中選擇一個最適合形容當前迭代的，這樣做的主要目的就是讓大家的思路先轉起來。

3.2 提升團隊成員的參與度

SCRUM非常重視個人，是以人為本的。在回顧會上，使得大家都參與討論是非常重要的。下面有幾個方法可以幫助團隊增加參與度。

• 大家匿名寫出需要改進的和需要繼續保持的，這樣可以保護大家避免因為寫出不好的地方讓大家感到尷尬。
• 每次會議的議程和展開方式可進行調整。如果每次回顧會的內容和方式都是相同的，大家會變得越來越形式化，覺得回顧會沒有意義。每次調整暖場方式或者大家的參與方式，這樣可以在保持新鮮感的同時提升大家的關注度。
• 鼓勵發言，在感謝和感悟環節，鼓勵大家表達自己的感悟以及對團隊成員(某位成員)的感謝。這時需要鼓勵大家發言，無論發言如何都要給以尊重和認可。如果沒有人發言，前期建議可以通過抽簽或者有趣的方式找到人來發言，慢慢增加大家參與度。

3.3 貫徹執行改進項

為了保證改進項能夠順利落實，需要選擇對大家目前影響最大的，即優先級最高的，同時需要綜合考慮改進項的成本和開銷后選擇。需要做的改進項建議一定要寫入下個迭代的backlog中，方便跟進的同時也能使得改進項負責人認真對待。

四、回顧會重要注意點

• 加強重視度，不要讓回顧會變成很少人員參加的可有可無的會議。有些團隊的誤區就在于每次回顧的重點都是相同的，這就使得團隊認為每次回顧會的內容是相同的，可裁剪的。這時需要SM去引導團隊聚焦當前迭代是否已貫徹執行上一迭代改進項，是否有新的需要改進的問題，以便持續改進。
• 避免天馬行空的談論不切實際、不可能完成或者不相關的話題。由于回顧會是比較輕松讓大家暢所欲言的活動，這時很容易天馬行空漫無目的的談論，要及時將大家的討論拉回到正確的思路上來。
• 避免對重大問題視而不見，回顧會上要敢于提出大家都認為是有問題，但是沒有人敢于提出的問題。
• 避免團隊成員陷入郁悶自責，這一點跟營造輕松的氛圍和會議參與人員非常相關。此外要相信所有成員在現有條件下已經做出了最大的努力。
• 避免陷入相互指責，相互吐槽的境地。要通過回顧當前迭代的問題來改善后續迭代的情況。如果團隊有追責文化，很容易出現這種情況，這時需要循序漸進的改變大家的思維定式，同時減少追責，增加鼓勵和獎勵機制。
• 回顧會上的改進項一定要貫徹執行，沒有執行就等于沒有改進，沒有改進回顧會就失去了意義。
• 避免為了過程而過程，要每期制定回顧重點，避免形式主義。如果僅僅為了會議而進行會議，那比不開會議還要糟糕。

寫在最后

回顧會不建議裁剪，只有持續回顧才能持續改進。在工作過程中，需要我們時不時的停下來回顧下，我們是否做了最好的方案，是否有更好的方案？如果對現狀非常不滿且急需改變，停下來回顧思考下，也許是個不錯的開始。

＋“CH050791”后 回“冬哥”，可入qun交流~

總結

以上是生活随笔為你收集整理的scrum回顾_3步开好回顾会 | IDCF FDCC认证学员作品的全部內容，希望文章能夠幫你解決所遇到的問題。

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