Sprint Retrospective - 回顧的重要性

在Scrum中，每一個Sprint結束的時候會有兩個會議（Sprint Review/Demo和Sprint Retrospective回顧）。這兩個會議是對過去的一個Sprint的一個總結，其中Review/Demo是檢查過去一個Sprint的產出（What），主要是PO根據先前的計劃來檢查Team在過去一個Sprint的工做成果，包括一些Demo，以及未完成部分的總結和分析；而Retrospective則是回顧過去一個Sprint整個Team的運做模式，有什麼好的和很差的實踐，怎樣在將來的Sprint作的更好，強調How。

Sprint Retrospective（回顧）

Sprint Retrospective會議主要是整個Team討論過去的一個Sprint的運做，如何改進使Team更良好的運做。討論的內容能夠是任何有關Team建設的問題，包括工做流程、團隊實踐、團隊內部/外部溝通、團隊氣氛以及相關工具的使用等等。

Scrum並非一種方法，而是給軟件開發流程提供了一種框架，在整個框架下，不一樣的項目、團隊須要根據具體條件，適時調整實踐方法。而Retrospective會議正是一個Scrum團隊自我調整的機會。

會議的參加者包括整個Scrum團隊、Scrum Master和Product Owner。會議由Scrum Master主持，通常如下邊兩個問題開始：

1.       過去的一個Sprint裏，咱們有哪些好的方面？

2.       過去一個Sprint存在哪些問題？

整個Team就這兩個問題進行公開討論，方式也能夠是多樣的。能夠你們一塊兒討論，Scrum Master在討論過程當中將你們的觀點記錄在白板上；也可讓Team每一個成員在便籤紙上寫下本身的答案，能夠要求每一個問題至少寫三點，而後每一個人把本身的答案貼在白板上，並給出相關解釋。

討論完畢後，對討論結果進行分類。對於好的方便，在下個Sprint繼續保持併發揚；對於存在的問題，列出Action Point去解決問題。列出的Action Point也會在下個Sprint的backlog中體現出來，而且是高優先級的項目。

在現有的項目管理工具裏，我發現如今只有項目加項目管理產品特別強調了這塊，有個單獨的模塊來負責管理【迭代回顧】。