迭代評審會議是在每次迭代結束時給項目組內外部的相關人員展示本次迭代完成的功能，以獲得相關人員對軟件的反饋意見。這是客戶、最終用戶、管理者等對項目組完成的功能進行反饋的一個渠道。如何召開一個成功的迭代評審會議呢？我根據對多次迭代評審會議的觀察，總結了如下
1 雞類角色與豬類角色都要參與迭代評審會議；
以下兩類人員都應該參與：
- 項目組的所有成員，包括PO，SM，開發和測試人員；
- 項目組外部的其他利益相關者，包括客戶、最終用戶、管理者等；
上述兩類角色都是必須的。只有項目組成員參與的sprint review會議不能獲得充分的反饋意見，會議的價值會大打折扣。
2 選擇合適的演示操作人員；
強烈建議由PO進行演示操作，一是讓PO實際操作、感受一下軟件，便於提出更多的功能改進建議，二是PO展示時是關注完成了什麼，而不是怎麼做的，關注於業務，而非技術。三是迭代策劃會議不是給PO彙報需求完成情況，而是整個團隊的成員給項目組內外部的人員展示需求完成情況。也可以在會議上，讓用戶試用一下軟件。
PO不應該只是在迭代評審會議上才看到完成的軟件功能，在每天的站立會議之前應該都檢查過功能是否滿足了需求。
3 事先準備演示環境與演示數據，不準備PPT；
演示環境，演示的數據需要提前準備好，以提高會議的效率。由於是多個人參加的會議，一旦出現演示環境準備不充分的話，會導致大量的時間浪費。
如果前期做過功能測試，則演示的環境可以基於測試環境進行準備。
迭代策劃會議只看Demo，不看報告，所以不需要準備PPT。
4 要給所有人重申一下本次迭代的目標；
有的人知道本次迭代的目標，有的人可能已經忘記了迭代目標，有的項目組外部的人可能不知道本次迭代的目標，通過重申迭代目標，讓大家更加聚焦於目標來評審進展與功能的完成情況。
為了確保迭代評審會議的成功，需要主持人事先聲明會議紀律，如：
- 提醒各位與會人員不要跑題；
- 不要指責別人
- 提出一個問題的同時要給出一個建議的解決方案；
- 不展示如何做的；
- 不要在一個話題上花費太多時間；
等等。
6 指定記錄員；
記錄員需要記錄大家對需求的反饋意見，便於將來吸收到Product backlog和sprint backlog中。
7 對照sprint backlog演示完成的故事；
本次迭代該完成的story都定義在sprint backlog中了，在演示時，應該對照本次迭代的sprint backlog進行演示，歷史已經完成的story如果在本次迭代中沒有修改可以不展示。迭代評審會議是演示完成的需求，而不是解釋完成的需求，要demo，而不是僅僅宣稱完成了哪些需求。
8 演示的功能應該滿足DoD；
沒有完成的功能，沒有達到DoD標準的功能不演示，便於大家客觀瞭解現狀。
DoD是迭代策劃會議上定義的需求或任務的完成標準，如：
- 開發完成了；
- 測試完成了；
- 集成完成了；
- 該寫的文檔完成了；
- PO認可了。
對沒有達到DoD標準的功能做估計通常都是樂觀的。
DoD可以根據不同類的任務定義不同準則，比如如果某個任務是開發原型，則僅需要達到可演示的程度即可，而不追求可用或好用的目標。
如果迭代策劃會議的時間充足，經過PO的認可，可以演示非完成的功能或原型，以便於獲得其他利益相關方的反饋。
9 利益相關方要反饋意見；
與會的所有人員都可以反饋意見。項目組成員、PO、測試人員、客戶、最終用戶、高層管理者都應該積極反饋意見：認可或不認可，改進建議，需求變更，缺陷等都可以。記錄員負責記錄問題，PO負責根據大家的反饋整理修訂product backlog.
演示會上也可能發現程序的錯誤，會後要對這些錯誤進行原因分析，識別改進點。
10 會議上不討論如何解決問題，只討論是否是一個問題；
不討論如何做的，只展示做成了什麼樣，應該做成什麼樣。聚焦於需求是否達到了客戶的預期，而不是解決方案。有分歧的議題，難以短期內達成一致的議題，可以暫時擱置，另行開會討論。不要在細節方面花費太多的時間，每個議題限制討論的時間；
閱讀更多 程序猿的內心獨白 的文章
