跳转至

迭代评审会

什么是迭代评审会议

迭代评审会是基于迭代的例行会议,每个团队在每个迭代结束时检查增量以评估进度,然后为下一次迭代调整其工作优先级。在迭代评审期间,每个敏捷团队都会衡量其进展,向产品所有者和其他利益相关者展示工作故事以获得反馈。团队演示每个新故事、Spike 的产出和非功能要求 (NFR)。迭代审核的准备工作在迭代规划期间开始,团队开始考虑如何演示他们承诺的故事。"从头脑中开始"有助于迭代规划和对齐,促进在迭代执行之前更透彻地了解所需的功能。

迭代评审会提供了一种从团队的利益相关者收集反馈的机制。迭代审核的目的是通过向产品所有者和其他利益相关者展示工作情景来衡量团队的进度,以获得他们的反馈。迭代评审提供了三个重要功能:

  • 它为迭代时间框带来了结束,
  • 许多人为它提供了新的价值,
  • 为业务提供了新的价值。

为什么要召开迭代评审会议

迭代审核有以下几个目的:

  • 决策是否要发布产品。

  • 以“工作中”的软件度量产品进度,对于整个 产品来说,交付进度如何。

  • 获取干系人是否认为 Story 完成的反馈,如果觉得没有完成,则需要进一步听干系人的反馈。

  • 迭代审核会给团队一个压力:每两周要交付一定量的价值,并且能够理解干系人的需要。

那些人要参加迭代评审会议

产品负责人:邀请干系人并主持会议。

Scrum Master:协助产品负责人准备会议。

团队:对故事进行演示。

干系人:对故事进行验收,并给与反馈,做出是否可以上线的决策。

准备

评审会议之前,Scrum Master 要和产品负责人审核可以

  • 根据可以演示的用户故事拟定参会人员名单(提前一天准备)。以及演示时长,整个会议最多不超过 1 个小时。

  • 评审会议之前,团队需要1-2个小时准备在准生产环境上要演示的用户故事。如果准备时间过长,则取消对应故事的演示。这表明持续集成没有做好。

  • 在演示之前,最好和客户进行过确认,避免在评审会上引发讨论。

日程

迭代评审会议的日程

  • PO 介绍来宾。

  • PO 介绍迭代目标以及本次需要评审的用户故事。

  • 由团队成员准备演示的用户故事。

  • 听取干系人的反馈。

  • 做出是否可以上线的决策。

  • 听取下一个故事,直到所有本迭代交付的故事演示完成。

迭代评审会议可能会影响下个迭代的交付优先级,产品负责人和团队要及时确认迭代计划是否要进行变更。

注意事项

  • 推荐准生产环境进行演示,接下来的步骤可能就是发布(Release)。

  • 以故事为单位,仅演示完成的故事,不演示未完成(进行中)的故事。

  • 如果有应当参会的干系人因故没有参加,产品负责人要在评审会议之后跟踪后续的反馈。