其實個人以為，回顧會議在scrum所有的events中是最重要的一個

正如上圖所示，我們可以看到在整個scrum的價值流上，每個會議都有不同的對應意義：

planning meeting用來將目標分解並給團隊，standupmeeting 則用來對team每天的工作進行跟蹤，review meeting則是檢視和調整目標，以適應當前的工作狀態，而retrospective meeting則是team用來進行持續改進的一個過程。

所以從敏捷的核心價值–持續改進來說，回顧會議也是相當重要的一個環節。

關於回顧會議的意義，內容等，筆者在這裡就不在多說了，因為很多文章和書籍都已經講述了這個會議的重要性。那麼在這裡，筆者希望從個人的經驗來闡述一些點，能夠更好的進行回顧會議，從而讓這個會議更好的為團隊持續改進而服務。

1. 回顧會議不僅僅是回顧，更重要的是著眼於未來

很多團隊在召開回顧會議的時候，更容易把它變成一個lession learn,找出做的不好的地方，然後總結經驗等。這樣做並沒有什麼不好，但是要注意的是，回顧會議更注重的是在下一個迭代我們要如何做才能做的更好，而不僅僅是總結以前失敗的經驗教訓。團隊要帶有一定的目的性，就是在回顧會議上要形成真正的“決議”，這些“決議”能夠對即將到來的迭代有更好的正面促進作用。這樣才能使得回顧會議真正的成為一個不斷推進團隊進步的催化劑。

2. 回顧會議不能解決所有事情，它應該注重在最迫切的一些需求上

筆者在輔導過的一些團隊中，往往在回顧會議上，大家打開了話匣子，氣氛非常熱烈，也有很多中肯的建議和看法，但是，我們要知道，一個迭代只有1-2個小時的回顧會議，實際上是解決不了很多的事情的，所以教練在這裡要輔導團隊，把視野看的更高遠一些，讓團隊成員的思路更high level一些，找出2,3個點用來讓團隊在下個迭代做的更好，這樣也可以更好的集中團隊資源來進行一些改進。

3. talk is cheap, show me the action

回顧會議很容易轉變成吐槽大會，因為團隊會在開發過程中發現很多問題，但是有一些問題卻不是團隊自己能夠處理或者搞定的，或者大家只是提出問題，並沒有提出解決方法等，這樣長期下來，回顧會議就會變成一種形式主義，大家的參與度也不會很高。所以團隊要在每個迭代會議之後，列出一些迫切要解決的問題，並且提出一些切實可行的解決方案，並且指定owner,這樣來保證在下個迭代，這些方案能夠執行並起到效果。同時如果是團隊無法解決的問題，也要記錄下來，反饋出去，找相關負責人，看看能否儘快解決。

當然了，要做好回顧會議還需要很多工作要做，這裡我只是提出了一些自己在這方面的一些經驗之談，如果大家有興趣，我們還可以進一步的討論這個話題。
最後一句話送給那些總是說太忙了，無法參加或者召開回顧會議的人們：

是的，他們是太忙了沒有時間，他們總是忙於把時間用來生產錯誤的產品上。。。