迭代評審會議是在每次迭代結束時給項目組內(nèi)外部的相關人員展示本次迭代完成的功能，以獲得相關人員對軟件的反饋意見。這是客戶、終端用戶、管理者等對項目組完成的功能進行反饋的一個渠道。如何召開一個成功的迭代評審會議呢？任老師根據(jù)對多次迭代評審會議的觀察，總結如下：

以下兩類人員都應該參與：

·項目組的所有成員，包括PO、SM、開發(fā)和測試人員。

·項目組外部的其他利益相關者，包括客戶、最終用戶、管理者等。

上述兩類角色都是必須的。只讓項目組成員參與的sprint review會議不能獲得充分的反饋意見，會讓會議的價值大打折扣。 

2、選擇合適的演示操作人員

強烈建議由PO進行演示操作，一是讓PO實際操作、感受一下軟件，便于提出更多的功能改進建議，二是PO展示時，關注完成了什么，而不是怎么做的，關注于業(yè)務，而非技術。三是迭代策劃會議不是給PO匯報需求完成情況，而是整個團隊的成員給項目組內(nèi)外部的人員展示需求完成情況。也可以在會議上，讓用戶試用一下軟件。

PO不應該只是在迭代評審會議上才看到完成的軟件功能，在每天的站立會議之前應該都檢查過功能是否滿足了客戶的需求。    

3、事先準備演示環(huán)境與演示數(shù)據(jù)，不準備PPT

演示環(huán)境，演示的數(shù)據(jù)需要提前準備好，以提高會議的效率。由于是多個人參加的會議，一旦出現(xiàn)演示環(huán)境準備不充分的情況，會導致大量的時間浪費。

如果前期做過功能測試，則演示的環(huán)境可以基于測試環(huán)境進行準備。

迭代策劃會議只看Demo，不看報告，所以不需要準備PPT。

4、要向所有人重申一下本次迭代的目標

有的人知道本次迭代的目標，有的人可能已經(jīng)忘記了迭代目標，有的項目組外部的人可能不知道本次迭代的目標，通過重申迭代目標，讓大家更加聚焦于目標來評審進展與功能的完成情況。

5、要提前聲明會議紀律

為了確保迭代評審會議的成功，需要主持人事先聲明會議紀律，如：

·提醒各位與會人員不要跑題

·不要指責別人

·提出一個問題的同時要給出一個建議的解決方案

·不展示如何做的

·不要在一個話題上花費太多時間......

6、指定記錄員

記錄員需要記錄大家對需求的反饋意見，便于將來吸收到Product backlog和sprint backlog中。

7、對照sprint backlog演示完成的故事

本次迭代該完成的story都定義在sprint backlog中了，在演示時，應該對照本次迭代的sprint backlog進行演示，歷史已經(jīng)完成的story如果在本次迭代中沒有修改可以不展示。迭代評審會議是演示完成的需求，而不是解釋完成的需求，要Demo，而不是僅僅宣稱完成了哪些需求。

1. 演示的功能應該滿足DoD

   沒有完成的功能，沒有達到DoD標準的功能不演示，便于大家客觀了解現(xiàn)狀。

   DoD是迭代策劃會議上定義的需求或任務的完成標準，如：

·開發(fā)完成了

·PO認可了

·該寫的文檔完成了

·集成完成了

·測試完成了

對沒有達到DoD標準的功能做估計通常都是樂觀的。

DoD可以根據(jù)不同類的任務定義不同準則，比如如果某個任務是開發(fā)原型，則僅需要達到可演示的程度即可，而不追求可用或好用的目標。

如果迭代策劃會議的時間充足，經(jīng)過PO的認可，可以演示非完成的功能或原型，以便于獲得其他利益相關方的反饋。

9、利益相關方要反饋意見

與會的所有人員都可以反饋意見。項目組成員、PO、測試人員、客戶、最終用戶、高層管理者都應該積極反饋意見；認可或不認可，改進建議，需求變更，缺陷等都可以。記錄員負責記錄問題，PO負責根據(jù)大家的反饋整理修訂product backlog。

演示會上也可能發(fā)現(xiàn)程序的錯誤，會后要對這些錯誤進行原因分析，識別改進點。

10、會議上不討論如何解決問題，只討論是否是一個問題

不討論如何做的，只展示做成了什么樣，應該做成什么樣。聚焦于需求是否達到了客戶的預期，而不是解決方案。有分歧的議題，難以短期內(nèi)達成一致的議題，可以暫時擱置，另行開會討論。不要在細節(jié)方面花費太多的時間，每個議題限制討論的時間。