有效Scrum评审会

Posted 2021-04-25 浮云之空

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了有效Scrum评审会相关的知识，希望对你有一定的参考价值。

有效的Scrum在一个Sprint结束之后，就需要进行另一个重要仪式--Scrum评审会（Sprint Review Meeting）了。关于评审会，我们首先来看看Scrum指南是如何定义的。

评审会包括什么

Scrum指南意见

Scrum指南定义，评审会在一个Sprint结束的时候进行，参会人员包括Scrum团队和PO邀请的利益相关方代表，会议的内容可以包括：

检视当前Sprint的工作成果，哪些完成，哪些没有完成；
开发团队讨论哪些方面做得好，遇到了哪些问题，问题是如何解决的；（侧重于产品，而非流程方面）
演示已经完成的产品增量，并回答相关问题；
检视市场或者产品使用的潜在变化，并结合当前的进度，思考和调整产品待办列表及其优先级；
检视时间、预算、潜在生产力和市场，思考产品下一个版本计划。

可以看出，Scrum指南中给出的评审会的内容是比较宽泛的。最重要的内容，除了“展示”一个Sprint的成果外，是基于最新的状态，调整产品待办列表和下一个Sprint的内容。这正反映了Sprint的“调整(Adapt)”这个基石的精神。

常规实践

在实践中，基于我的观察，评审会更多的关注在这些地方：

Sprint的总体完成情况，是否完成了预期的计划；
新功能演示，以可运行软件的方式展示这个Sprint带来的增量功能；
Sprint已完成和未完成项目的回顾，以便各方了解当前产品的最新状态；
收集与会各方在会议过程中对于产品，特别是对新功能反馈；

也就是说，实践中的操作更倾向于对一个结束的Sprint的“验收”活动，而对于产品待办列表和下个Sprint的思考大多数是在“内心”进行的，而并非作为会议上讨论的话题，并最终反应到接下来的新的Scrum计划会。

看起来，Scrum评审会并没有太多的坑，但如何做到目标明确，把信息有效地传达给与会各方也并不是那么理所当然的事情，尤其是在一个规模较大的团队和项目情况相对较复杂的情况下。以下总结一下我在实践中遇到的情况和所采用的方法。

一个评审会组织方法总结

团队与项目情况

当面临一个具有以下特征的Scrum团队的时候，我们会发现Scrum评审会将会显得不再那么轻松：

Scrum团队规模上人数有12人以上
团队的项目既包括新功能开发，又有已有产品功能缺陷（bug）修复
团队项目实际包括6个以上子领域，各个子领域人员有一定的专有特性（并非所有人员通用）
团队的Sprint待办列表通常数量有30~60个
团队项目的新版本需要协同各个子领域
团队是跨国团队，尤其是PM/PO需要远程联络

这是我曾面临的Scrum团队，我知道这样的团队其实有更好的组织方式，那么在团队取得组织改进之前，Scrum评审会如何有效进行呢？

以下总结了一个摸索出来的相对有效的组织方法。

目标原则

首先，还是总结一下我们团队关于Scrum评审会希望达到的目标：

首先是增加透明度。我们希望把一个完成的Sprint对于产品所产生的增量全部暴露出来，这包括新功能和一些缺陷的修复；
我们还是希望展示与（开发团队）的能力，需要向PO等表现不偷懒的倾向。因此一些任务也希望展现出来。
我们希望第一时间获得关于产品改动的反馈；
暴露不能预期完成计划的潜在问题；

基于以上目标的考虑，下面是我们采用的组织方式介绍。

一个大团队的评审会

根据上面介绍的团队与项目情况，我们采用的评审会方式为：

Wiki页面+JIRA电子看板：wiki用于管理会议内容，JIRA用于同步展示当前Sprint的所有内容；
Wiki的内容包括：

Sprint的总体状态介绍：总体上是否达成了Sprint的所有目标，我们也会汇总数量和Story Point（我们用于评估任务大小的值）2个方面的数据，Story Point以JIRA的燃尽图截图展示。
Sprint“目标”评审：这里会使用一个表格把Sprint计划中的所有“目标”任务列出，并逐条查看它们的状态，并提示接下来是否需要演示其改动。
Sprint研究工作评审：由于我们实际工作中，常有一个预先“研究”任务，它们的目的是搞清楚需要完成的目标，以便更好地评估它。而这些工作时常占用一定的时间，同时也常是下一步工作的方向，所以我们也单独在wiki里面展示出来。我们会像对待“目标”一样来单独列出，也是为了避免冲淡“目标”。
Sprint细节评审：这一步，我们会跳转到JIRA中，直接评审当前Sprint的所有任务。对于我们这样的大Scrum团队，这一步其实是最繁琐和挑战的，后面会单独总结我们的操作方法。
Sprint演示：这一步就是团队代表会演示预选的功能，通常是产品的增量新功能，有时候也可以是演示团队的某个较大的研究成果。Sprint一般是整个评审会的高潮，也是引发最多反馈和问题的环节。但从实践中也发现，做演示的人其实还是需要有一定的演示技巧，例如，我们其实需要避免把演示变成一般的产品使用培训，避免不必要的内容。如何展示新功能的同时，巧妙展示其吸引人的价值需要一定的技巧，就需要团队培养这种能力。
Sprint启示：这是一个我曾经在评审会上尝试的内容，是从Scrum master的视角来发现这个Sprint所展现的好的敏捷、协作等积极的关键词，并配上一段相关的名人名言，以供整个团队意识到，也算对团队的认可和鼓励。比如我们曾经使用的关键词有：变化、价值、协调、合作等，配图效果如：
下个Sprint重点目标计划：考虑到跨国团队，不是所有成员都会参加接下来Sprint的计划会，我们也在评审会最后，简单介绍一下，下一个Sprint计划的主要目标方向。一方面让各方有个大概的目标，另一方如果某一方有其他建议也可以及时提出。

Sprint细节评审

关于Sprint的细节是否需要参与评审，也是我们的一个考虑，这里暂且不论。我们目前按照需要评审的话，如果把30~60个之多的问题有效的评审呢？我们的做法是分状态，分类型，分领域评审。

具体做法是：

首先，我们只评审已完成项目，并通过过滤器辅助进行分类评审。我们会通过JIRA的过滤器，预设了一组任务类型过滤器，一组子领域过滤器，比如，我们就使用了"重点"、"研究"，“缺陷”，“任务”和“DevOps”5个任务类型过滤器。子领域过滤器就是为每个主要领域设置的快速过滤器。这里需要注意的一点就是，各个过滤器的设置应该是“完全而不重复”的。这时候可以根据情况选择具体操作：

对于任务数量不是特别多的情况下，使用任务类型来分类评审各个任务基本够用了。评审任务的过程，我们主要是介绍这个问题是什么，结果后的结果是什么样，一般会结合任务后面的测试结果截图来快速评审。
任务数量特别多的Sprint，如50个以上的话，可以组合使用主要子领域过滤器来组织评审。比如，“缺陷”+A领域，“缺陷”+B领域这样做下去，直到把所有“缺陷”评审完，再继续下一个类别+子领域。

其中，“重点”与wiki中的“目标”是重叠的，所以一般跳过就可以，而我们细节评审的重点一般是“缺陷”, 尤其是一些解决现有客户问题的缺陷，整个团队需要知晓。对于“任务”类型的任务较多的时候，我们也会选择性跳过一些细节工作，只需评审工作量较大和影响较大的任务。总之，这个方法是通过2个维度分类，来使得较多的任务得以相对条理地展现，其中也结合实际情况具有一定的灵活性的操作。

其次，细节评审的最后，我们也会快速地评审哪些计划了的而没有完成的任务。一般不应该太多。这既是对整体状态的认知，也是对未完成任务的一个警示，要么计划做得不够好，要么是团队资源问题，总之是一次暴露问题的机会。

总结与思考

Scrum实践中，关于评审会本身的问题似乎并强烈，但是它本身却会暴露其他问题。比如Scrum计划不能被如期完成，演示效果不够精彩，反馈不够活跃和有效等。对于较大团队和较复杂项目来说，如何让评审会展示好重点，覆盖面够大，引发足够的反馈，并及时暴露风险与问题，实现一个有效评审会，需要团队探索适合自己的模式。而其中，透明、检视与调整是贯穿其中的指导方法。