scrum中的5個活動分別是：
-產品代辦事項列表梳理(product backlog)
-sprint計畫會議(sprint plan meeting)
-每日站會(scrum daily meeting)
-sprint 評審會(sprint review meeting)
-sprint 回顧會議(retrospective meeting)
回顧會議是scrum的幾個會議中相當重要的乙個會，但是在很多團隊中，retro的會議被無限期的延期。即使回顧會議如期舉行，也大多流於形式，回顧會議如何才能開好，是這五個活動中最需要花心思的，甚至scrum master需要根據團隊的狀態以及團隊融合的階段來設定回顧會議的過程。
老生常談，回顧會議是乙個糾偏的會，是乙個固本培元的會，放棄回顧會議雖然不能完全等同於讓團隊自然存活，但確實放棄了整個團隊一起總結->成長->總結的好機會。
我們經常看到一些團隊，一上來就由scrum master宣布，我們今天來開始回顧我們上個sprint中的工作，大家看看我們有什麼地方做的好，需要保持，有什麼地方做的不好需要改進，現在我們挨個發言。也有一些scrum master在和我聊他們的回顧會議所遇到的問題，他們覺得經常沒有什麼可以說的，所以他們由乙個sprint變成兩個sprint開一次，由兩個sprint變成三個sprint開一次，慢慢的，回顧會議就省了。
對於回顧會議的參與者，不同的組織範圍不同。我一直有一些自己的想法，我見過邀請一堆po pm 各種boss老闆的回顧會議，然後回顧會議開成了匯報會，各種祖國山河一片大好，問題一堆一堆得不到實質的處理。回顧會議是以人為本，以提高產能，提公升團隊工作效率以及團隊精神面貌為目的的會議。我認為從這個點出發確定出回顧會議與會人員的範圍。具體情況具體分析，不過我怎麼覺得也能寫篇文章來說，哎，這個點上我痛過。
在開發理念以及團隊管理上我是特別主張套路的人，套路一定是得人心的，一定是被證明過正確可行的，所以我們按套路來，
《agile retrospectives》把回顧會議分成了5個階段：
1. 準備
2. 資料收集
3. 產生見解
4. 確定改進項
5. 結束會議
我前面提到了，回顧會議是需要scrum master費心來設計過程的乙個會，雖然大的階段是固定的，但是根據團隊的階段，其實是需要在回顧會議裡安排很多細小的點來達到scrum master管理團隊的目的。
-第一階段-準備
1. 回顧會議的主持人會和scrum master討論乙個大家都感興趣的話題，放在會議的最開始大家討論一下，內容是sprint內大家都比較關心的事情。
2. 回顧會議主持人整理上次retro大家決定的改進項。
3. 回顧會議所需要的ppt,。
-第二階段-資料收集
資料收集相對比較複雜，我們會有四個方面的資訊來收集
1. 大家感興趣的話題 free style
目前我的團隊會找乙個團隊的同事來背誦敏捷宣言，然後背誦敏捷的5個價值觀（專注，勇氣，公開，尊重，承諾）。其實團隊在最開始三次回顧會議上是大家一起朗讀的，這個一起讀看似**的過程，逐步在消除團隊同事覺得一起讀很奇怪的感覺，「那個感覺很奇妙，有融入的感覺」，我的一位同事後來反饋給我說。
2. 用乙個詞來描繪大家在上個sprint中的心情
大家把乙個能描繪自己在上個sprint心情的詞寫再卡片上，然後每個人來解釋一下自己為什麼沮喪，高興，或者 …en 各種千奇百怪的心情。這個環節是想讓大家放飛自己，這樣的環節讓大家覺得回顧會議是乙個參與感很強的會，參會者來不只是「聽會」，作為主持人的你，除了控制時間外，盡量讓大家飛~~~
3.繪製大家在上個sprint的心情曲線
目前我們團隊乙個sprint是三周，大家去回憶自己在這三周裡的心情並在白板上繪製乙個心情曲線，其實這個過程依然是讓大家暢所欲言的過程，大家會描述自己在這個sprint中各個心情的拐點。這個環節的目的有兩個，第一：將大家的思緒帶到過去的三周中去，讓大家去回憶過去乙個sprint所經歷的事情。第二：團隊成員之間相互了解其他人在過去乙個sprint中的經歷， 並且了解團隊成員各自的點（生氣，高興），從而達到後期的有度有效溝通。第三：scrum master或者主持人已經可以在這個過程中拿到一些資料，更多的是團隊的士氣資料。
-第三階段-產生見解
什麼做的好，需要加強，什麼做的不好，需要改進
這個環節是回顧會議的核心，有很多的玩法，我想後面再起乙個專門的文章來整理一下，大家可以先參考傳統的做法：
傳統的做法是用貼紙的方式收集大家覺得團隊中好的以及不好的點，這個過程一定要背對背
對於收集上的的卡片我們首先進行分類
對於好的，我們進行整理歸類，並和之前好的以及不好的backlog進行比較，鼓勵整個團隊繼續保持。
對於不好的，我們也是在整理歸類後，選出來不超過2條進行改進，如果選的改進項太多，團隊往往無法是從，最終導致所有的改進全部失敗。
-第四階段-確定改進項
針對每個改進的點，我們要具體分析導致該問題的根本原因，然後根據根本原因提出改進措施。
找問題的根本原因用什麼方法呢？ 問度娘，用科學的方法找問題的根本原因哦。好多理論知識可以用的。
-第五階段-結束
好了，最後，讓我們結束這次回顧會議。
我一本的結束方法是感謝團隊中的乙個人，感謝的方式是在紙片上寫： 「感謝***在上個sprint中***************。某某人」
這句話在回顧會議中念出來，然後將紙片送給你所感謝的那個人。
這個環節要求只能感謝乙個人。
這個環節設計的好處是可以讓團隊之間相互信任，相互幫助。結束環節的內容也可以根據團隊狀況去設計，scrum master一定要用心去感受整個團隊的變化。
說在最後:
讓我們把改進項也加進下個sprint的story裡面一起跟蹤吧！
完結~~~
華為敏捷 DevOps實踐 如何開好站立會議
作為布道師和產品經理，出差各地接觸客戶是常態，經常和華為雲的客戶交流 布道 技術沙龍，但是線下交流，覆蓋的使用者總還是少數。n我希望可以和使用者持續交流華為在研發效能提公升上的思索和考慮。但理論總是美好的，現實卻是骨感的，很多華為雲 devcloud 的客戶特別想知道 how to，在這裡我分享一些...
華為敏捷 DevOps實踐 如何開好站立會議
作為布道師和產品經理，出差各地接觸客戶是常態，經常和華為雲的客戶交流 布道 技術沙龍，但是線下交流，覆蓋的使用者總還是少數。我希望可以和使用者持續交流華為在研發效能提公升上的思索和考慮。但理論總是美好的，現實卻是骨感的，很多華為雲 devcloud 的客戶特別想知道 how to，在這裡我分享一些非...
華為敏捷 DevOps實踐 如何開好站立會議
作為布道師和產品經理，出差各地接觸客戶是常態，經常和華為雲的客戶交流 布道 技術沙龍，但是線下交流，覆蓋的使用者總還是少數。我希望可以和使用者持續交流華為在研發效能提公升上的思索和考慮。但理論總是美好的，現實卻是骨感的，很多華為雲 devcloud 的客戶特別想知道 how to，在這裡我分享一些非...