0. 前言

按照The Scrum Guide的定义（这里是中文版：Scrum指南中文版（The Scrum Guide）），迭代评审会是在Sprint快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表的一个会议。在Sprint评审会议中，Scrum团队和利益攸关者协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。

那么如何召开一个成功的迭代评审会议呢？根据对多次迭代评审会议的观察，总结如下：

评审会流程

1. 鸡类角色与猪类角色都要参与迭代评审会议

以下两类人员都应该参与：

• 项目组的所有成员，包括PO、SM、开发和测试人员。
• 项目组外部的其他利益相关者，包括客户、最终用户、管理者等。

上述两类角色都是必须的。只让项目组成员参与的迭代评审会议不能获得充分的反馈意见，会让会议的价值大打折扣。

2. 选择合适的演示操作人员

强烈建议由PO进行演示操作，一是让PO实际操作、感受一下软件，便于提出更多的功能改进建议，二是PO展示时，关注完成了什么，而不是怎么做的，关注于业务，而非技术。三是迭代评审会议不是给PO汇报需求完成情况，而是整个团队的成员给项目组内外部的人员展示需求完成情况，也可以在会议上，让用户试用一下软件。

PO不应该只是在迭代评审会议上才看到完成的软件功能，在每天的站立会议之前应该都检查过功能是否满足了客户的需求。

3. 事先准备演示环境与演示数据，不准备PPT

演示环境，演示的数据需要提前准备好，以提高会议的效率。由于是多个人参加的会议，一旦出现演示环境准备不充分的情况，会导致大量的时间浪费。

如果前期做过功能测试，则演示的环境可以基于测试环境进行准备。

迭代评审会议只看Demo，不看报告，所以不需要准备PPT。

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

有的人知道本次迭代的目标，有的人可能已经忘记了迭代目标，有的项目组外部的人可能不知道本次迭代的目标，通过重申迭代目标，让大家更加聚焦于目标来评审进展与功能的完成情况。

5. 要提前声明会议规则

为了确保迭代评审会议的成功，需要主持人事先声明会议规则，如：

• 提醒各位与会人员不要跑题
• 不要指责别人
• 提出一个问题的同时要给出一个建议的解决方案
• 不展示如何做的
• 不要在一个话题上花费太多时间
• 等等……（这里提示一点，最好让参会成员共同制定这个会议规则）

6. 不要在演示过程中讨论问题

为了保证演示人按照流程完整演示Demo，参会人员在演示过程中不可以互相讨论问题，如果有没看懂的步骤或流程，可以适当向演示人提问，但是不可以就流程和步骤进行讨论，如果觉得步骤和流程有问题的，可以先记到便签纸上，等演示完成后，集中讨论。

7. 对照Sprint Backlog演示完成的故事

本次迭代该完成的story都定义在Sprint Backlog中了，在演示时，应该对照本次迭代的Sprint Backlog进行演示，历史已经完成的story如果在本次迭代中没有修改可以不展示。

迭代评审会议是演示完成的需求，而不是解释完成的需求，要Demo，而不是仅仅宣称完成了哪些需求。

8. 演示的功能应该满足DoD

没有完成的功能，没有达到DoD标准的功能不演示，便于大家客观了解现状。

DoD是迭代计划会议上定义的故事或任务的完成标准，如：

• 开发完成
• PO认可
• 相关文档完成
• 集成完成
• 测试完成
• 等等……

DoD可以根据不同类的任务定义不同准则，比如如果某个任务是开发原型，则仅需要达到可演示的程度即可，而不追求可用或好用的目标。理论上DoD由团队共同制定，但同时也要参考公司的一些规章制度，比如必须通过Sonar的代码扫描，单测覆盖率必须达到多少比率等等。

如果迭代评审会议的时间充足，经过PO的认可，可以演示非完成的功能或原型，以便于获得其他利益相关方的反馈。

9. 利益相关方要反馈意见

与会的所有人员都可以反馈意见。项目组成员、PO、测试人员、客户、最终用户、高层管理者都应该积极反馈意见：

• 认可或不认可；
• 改进建议；
• 需求变更；
• 缺陷；
• 等等……

都可以。SM会前要准备好便签，方便大家记录问题，PO负责根据大家的反馈整理修订Product Backlog。

演示会上也可能发现程序的错误，会后要对这些错误进行原因分析，识别改进点。

10. 会议上不讨论如何解决问题，只讨论是否是问题

不讨论如何做的，只展示做成了什么样，应该做成什么样。聚焦于需求是否达到了客户的预期，而不是解决方案。有分歧的议题，难以短期内达成一致的议题，可以暂时搁置，另行开会讨论。不要在细节方面花费太多的时间，每个议题限制讨论的时间。