原创：【Scrum实战】七、迭代评审会

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

对于长度为一个月的Sprint来说，评审会议时间最长不超过4小时。对于较短的Sprint来说，会议时间通常会缩短。ScrumMaster要确保会议举行，并且每个参会者都明白会议的目的。ScrumMaster教导每位参会者遵守时间盒的规则。

Sprint评审会议包含以下内容：

• 产品负责人邀请Scrum团队和主要的利益攸关者参加会议；
• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
• 开发团队讨论在Sprint期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；
• 开发团队演示“完成”的工作并解答关于所交付增量的问题；
• 产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的完成日期(如果有需要的话)；
• 参会的所有人就下一步的工作进行探讨，这样，Sprint评审会议就能够为接下了的Sprint计划会议提供有价值的输入信息；
• 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；同时，
• 为下个预期产品版本的发布评审时间表、预算、潜力和市场。

Sprint评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个Sprint的产品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。

以上是官方的定义，我们公司的做法与上述内容基本一致，但是有些细节会有些调整：

1. 与会人员
   与会人员我们也是会邀请整个Scrum团队和主要利益攸关者，但是在实际情况中，利益攸关者基本都是领导或者客户，所以大部分情况下参会人员都是Scrum团队成员。

2. PO总结完成情况
   PO在评审会上会首先综述一下迭代目标的整体完成情况，因为参会人员基本就是Scrum团队，大家对完成情况都比较熟悉，所以PO只是大概说明下，不会展开说。
   这个流程一般3分钟以内完成。

3. 迭代成果演示
   在我们公司，演示的工作一般由测试人员完成，因为敏捷实践的早期，大家一致觉得测试人员是对最终交付物最熟悉的，所以就“自组织”的把这个工作安排给测试人员了，这个决定也就一直沿用至今了。但是我个人觉得，从一专多能的角度来看，这个演示的工作最好Scrum团队中的每个人都可以来做。
   在演示期间，如果大家觉得我们的交付物有一些有待改进的地方，Scrum Master会给参会的每个人发一些便签纸，大家先把这些问题一一记下来，等演示工作完毕以后，再统一提问。
   这个流程一般15分钟左右。

4. 演示问题讨论并排定优先级
   在迭代增量演示完毕以后，PO收集大家的反馈便签，一一朗读、确认，参会的人员也可以一起讨论，讨论完成后，PO按照莫斯科法则（MoSCoW），对大家反馈的意见和建议，分别排入到Must、Should、Could和Would Not四个状态中，PO在评审会结束后，会挑选一些Must和Should状态下的任务，排入下一迭代。
   这个流程比较耗时，而且有些需求如果涉及到其他团队，可能会上还不能给出明确结果，还需要会后再讨论。我们公司的这个流程一般在1小时左右，但是耗时波动会比较大，主要跟需求、技术的复杂程度都有关。

我们公司的评审会主要就是以上流程，关于The Scrum Guide中提到的：

• 开发团队讨论在Sprint期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的；

这个问题我们是在回顾会分析的。

• 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；同时，
• 为下个预期产品版本的发布评审时间表、预算、潜力和市场。

这个问题我们一直都没有涉及，没有涉及的原因有两点：

1. 参会的人员主要是Scrum团队的成员，如果在这个会议上讨论太多产品的问题（如竞品分析、预算、市场等），很多人是没有这个概念的，而且有些研发人员，说着说着就会讨论起技术问题了……
2. 我们公司主要做的是外包项目，一般客户想要啥我们就要做啥，预算是多少我们也都不知道，市场咋样可能连我们的PO都不完全清楚，更说不上我们去评审最有价值的东西了，所以把这个流程加上，就会显得很尴尬。

因为我们公司的回顾会流程比The Scrum Guide定义的流程少了3步，所以我们的耗时也比官方的建议时间少一些，我们2周的迭代，一般1~1.5小时就能开完了，比官方的建议时间少了半小时。

以上就是我们公司Scrum评审会的做法，如果大家有更好的组织形式，欢迎留言讨论。