一个好的迭代评审会通过展示和验证迭代的成果，让团队和产品负责人、客户等相关者达成共识，并获得反馈和建议。它能够增强团队的自信和成就感，激发团队的创新和改进意识。以及调整产品愿景和需求优先级，根据市场变化和用户需求制定未来的适应性。
那么要如何开好一个迭代评审会？围绕这个问题，本文将分享三部分内容：迭代评审会的主要内容、开好迭代评审会的3个关键步骤、评审会与回顾会的区别。
一、迭代评审会内容包括哪些？
1、迭代评审会的目的及召开时间
Sprint （迭代评审会）在 Sprint （迭代）快结束时举行 ，这个事件主要是让开发团队展示他们在迭代中取得的成就，并根据 DoD（完成的定义）和验收标准验证增量。而这些增量应该是：已经开发、测试完成、经过整合的和已经记录的。
2、迭代评审会议的形式
迭代评审会议不是一个进度汇报会议，所以不推荐大家使用PPT。这是一个非正式会议，演示增量的目的是为了获取反馈，提出意见和促进合作。根据完成情况和迭代期间产品待办列表的变化，团队和利益相关方一起讨论接下来可能要做的事情，未来有可能迎接哪些新的机会/挑战。
3、迭代评审会的建议时长
迭代评审会也有时间盒的限制，对于长度为一个月的迭代来说，评审会议时间最长不超过 4 小时。同样的，2周的迭代，评审会时长不超过2小时，一周开一次的话，不超过1小时。Scrum 要让团队遵守时间盒的规则，让每个参会者都明白会议的目的，保证会议高效举行。
4、迭代评审会的参与者
迭代评审会的参会者包括 Scrum 团队和 Product Owner （产品负责人）邀请的主要利益相关者，比如：在产品生产、销售、使用、服务等场景下与产品的相关人员，包含市场营销人员，客户服务人员，质量人员，中高层管理者等等。
5、迭代评审会的误区
迭代评审会很常见的一个误区就是，把它当成让 Product Owner 接受开发团队交付的会议，这很容易变成相互责备的场景，违背了 Scrum“适应”的原则，大家要记住，演示的目的是，在团队和利益相关者之间进行有关如何使产品更有价值的对话！
二、开好迭代评审会的3个关键步骤
在 PingCode 产品团队中，我们会让迭代评审会议保持一个轻松的氛围，在会议上，每个成员轮流演示新功能、进行提问和反馈。团队成员一起分享工作成果是建立成就感的关键部分。需要强调的是，在迭代评审开始之前，团队对于“完成”的定义至关重要。
第 1 步：定义“完成”
在 PingCode 项目管理产品中，将任务从「进行中」拖动到「完成」意味着又一个工作顺利完成。敏捷卡片在看板上快速流动，代表着团队正在持续完成计划中的工作。
敏捷团队需要良好的计划、对“完成”的明确定义和专注的执行，才能顺利完成所有工作。这些事项通常在迭代计划期间进行准备，但是要成功地完成迭代工作和迭代评审，需要做的不仅仅是计划，团队也需要培养一种清晰的文化，了解如何交付工作以及“完成”的明确定义。
交付文化
高效的团队会为每个项目准备清晰的工作流程和团队研发文化。建议使用下面这些问题来评估团队的工作流程，并确保对团队带来正向的作用：
- Product Owner 、Scrum Master 和研发团队在迭代开始之前是否已经明确定义了用户故事？
- 每个人都理解并践行团队的研发价值观和文化吗？
- 是否了解代码审查、自动化测试和持续集成的明确定义和要求， 并鼓励可持续的敏捷开发？
- 团队完成一个用户故事后，是否会出现很多缺陷或问题？换句话说，研发完成是否意味着用户故事真正完成？
团队对于质量的要求和完成的定义应该比每个用户故事、研发任务和缺陷更重要。这种文化反映了团队如何处理问题和交付产品。
在每个工作项上定义“完成”
对“完成”的明确定义有助于团队专注于工作项的最终实现效果。当 Product Owner 将用户故事添加到团队的 Product Backlog （产品待办事项）中时，定义验收标准是确认交付目标的关键部分。
在 PingCode 团队中，团队清晰地记录用户故事验收标准，并创建相关联的测试用例进行详细说明。这样，整个团队对每个工作项的交付标准都有清晰的认知。
- 验收标准：产品经理用来确认用户故事的实施与执行是否达到可以交付给用户的标准。
- 测试用例：测试团队记录详细、集中的功能步骤描述，使开发人员能够编写更好的功能代码和自动化测试。
在研发过程中，明确每一个工作项的内容可以让迭代更成功地交付。使用 PingCode 可以快速灵活地配置自定义字段，对工作进行更详细的描述说明。管理员只需点击工作项上的「配置工作项」按钮就可以对详细信息进行配置。
第 2 步：更好地团队协作
我们的核心价值观之一是“团队协作”，迭代评审会是展示团队和每个成员在迭代期间取得的成就的好时机。我们通常在周五下午组织演示会议，以便让大家在周末之前放松下来。迭代评审并不等于迭代回顾，所以要确保在回顾会之前及时组织迭代评审。评审会议通常由 Product Owner、Scrum Master、研发团队、利益相关方组成，同时也欢迎外部成员参与进来。迭代评审的时长建议在一个小时左右。
持续地迭代评审可以保证团队的健康和士气，有助于团队建设。迭代评审不是汇报性质的工作，而是整个团队的协作活动，团队成员在会议中演示他们的工作、提出问题并获得反馈。
如果迭代评审没有成为整个团队带来积极的效果，可能表明以下几种情况：
- 团队承担了过量的工作，在迭代期间没有完成；
- 累积了很多技术债务，影响了迭代的演示效果；
- 没有对功能进行可持续研发，导致将新的缺陷和问题引入代码库；
- 团队没有对研发流程进行持续优化；
- 产品经理在迭代中改变优先级，因此影响了研发团队工作节奏；
每个团队有时都会遇到有问题或失败的迭代。我们需要在迭代回顾中花点时间总结影响因素，并制定相应的计划来改进下一个迭代。
第 3 步：远程团队的迭代会议——跨地域进行演示
拥有远程分布式团队的公司，在跨地域进行敏捷工作中会遇到一些特殊的挑战。就像 PingCode 团队的成员遍布在不同城市：北京、上海、深圳、西安等，虽然团队是分布式的，但迭代评审仍然是我们团队研发文化中不可或缺的一部分。团队成员会创建视频会议并在 PingCode 知识库页面上分享，供整个团队查看。
这种视频会议的方式可以让每个人都能了解最新的开发进度。远程参与迭代评审会议可以从两方面增强团队工作能力：
- 产品理解：整个团队都能了解用户故事的目的、理由和实现标准。确保每个人对产品有着深入的理解。
- 团队建设：视频会议在整个团队中建立了更多的联系。每位成员都可以看到产品各个方面的相关执行人。虽然工作地域不同，这种实时的交流方式使我们成为一个更紧密、更有凝聚力的群体。
三、迭代评审会和回顾会的区别
对于刚接触迭代评审的团队来说，很容易将迭代评审和回顾会议混为一谈。实际上，迭代评审和迭代回顾是互相独立的敏捷实践方式，回顾是改进团队工作流程的总结会议，团队也需要其它的时间来分享迭代成果，增强工作成就感。迭代评审会议正是达成这个目的的最佳实践方式。
以上就是关于如何开好敏捷迭代评审会的主要内容，希望对你有所帮助。
