细说敏捷：敏捷四会之复盘会

前两篇文章，我们分享了敏捷四会中的计划会和每日站会，本文我们继续介绍在敏捷 Sprint 结束后会召开的敏捷复盘(Review)会议。

目的和作用

Sprint Review Meeting 作为一个Sprint迭代结束后召开的会议，主要目的其实是体现敏捷思想中的“和客户合作”，“快速反馈”，是敏捷小步快跑思想的重要体现。

具体来说，这个会议的目的，是向产品的业务团队、用户和利益干系人来展示当前 Sprint 的工作成果，听取他们对产品的反馈，确认当前产品的输出 增量（Increment） 是否符合预期，有无新的意见，便于后续 Sprint 的及时调整。

这也是敏捷区别于传统研发模式的一个显著区别，也就是在一个短周期的Sprint，就会通过这个会议的展示，和最终需求方及时确认进展，而不是像传统流程那样，直到经过一个长周期的完整研发流程后，才会把最终产品交付给用户进行确认。

所以，这个会议的作用，除了团队的成果交付，更主要的是通过对产品Increment的展示，获取外部业务方和其他干系人的反馈，便于及时调整。

误区

很多人把这个会议看作是Sprint团队内部，跟PO的一个交付确认会议，其实是不正确的。

它更多是基于和团队外部的沟通目的。

也因此，有些特殊状况下，某些Sprint这个会议也是可以不召开。比如：

Sprint的 Increment 产出并无可直接展示的比较明显的业务变更，更多是一些技术调整，架构层面的变化时，并无多少需要业务方确认的内容。
关键的业务方或利益干系人无法参加，不能匹配当前 Sprint的节奏。Sprint的结束时间比较固定，但关键利益干系人的时间如果无法匹配，那么这个会议可能会取消。这种情况下，后续Sprint 的复盘会时会包含当前sprint的相关输出展示
团队本身评估Sprint Goal就没有达成，关键的产出达不到预期时，自然也不适合跟外部进行产品展示。

参会人员

基于这个会议的目的，其实复盘会可能参与的人员会比较多，一般会包含下面这样一些角色：

Scrum Team 当然都是应该参加的，包括PO、SM、Dev Team
关键的利益干系人，通常指这个产品的投资人（产品总监/研发总监这样的角色）
团队成员的相关汇报对象，开发经理、测试经理、UE经理等
和Sprint产出相关的其他关键关联团队角色，比如有协作的其他Scrum团队关键成员（PO、SM），或者像安全、法务、质量、售后、售前、客服等。

复盘会一般都在Sprint结束的最后一天召开。而Scrum 团队中，PO作为和外部各种干系人的沟通渠道，会在会议召开前（通常提前1~2天）发出会议邀请，既告知相关人员当前Sprint的主要输入内容和范围，也便于确认会议与会人，并给团队预留一些复盘演示的必要准备时间。

会议流程

迭代最后一天，大家完成迭代工作，根据PO的会议邀请，参与Review Meeting。

会议的流程大致如下：

Scrum Master主持会议，一般会在开始欢迎参会的相关干系人，并简单介绍下参会的成员，如果Scrum团队有新成员加入，可能还会让新成员做个简单的自我介绍。如果相关人员都比较熟悉，就是个简单的开场白。
接下来，会由 PO 说明下当前这个Sprint增量的主要内容，也是接下来演示的主要功能范围。如果是间隔了多个sprint才召开的Review，这里通常会包含多个Sprint的内容。
然后就是演示环节，一般是PO 自己来进行演示说明，因为 PO 全程参与Sprint，对相关内容也比较熟悉。实际工作中，也可以是团队中比较熟悉相关功能的成员来进行演示，通常负责测试的同学执行这个演示会比较多。最好不要在演示过程中，频繁切换不同人员来进行演示。
下面这个环节，其实通常也会贯穿在演示过程中，就是干系人对产品实现上的一些反馈沟通，基于产品的目标和价值，包括下一Sprint的预期，对产品会有一些疑问或改进意见，团队可以就这些问题，和干系人进行直接的沟通和讨论。这部分其实占用了这个会议最主要的时间，气氛或融洽或激烈，但最终都会对形成一些原有需求的修订或新增。
所以在上一个环节的输出其实会产生一个更新的PBI清单，而这也会是后续Sprint的主要输入，是会后PO需要进一步梳理精炼的素材。
最后，SM进行会议总结，通常会汇总下讨论结果，包括确认后续要跟踪落实的需求和其他事项，如相关技术的调研攻关等。当然，这里的总结，其实也会提醒干系人散会，但对团队来说，也是提醒后续回顾会的召开（回顾会通常紧接复盘会召开）

复盘会一般控制在2小时内（针对2周的Sprint），SM在过程中要控制会议节奏，根据演示内容的多少，对一些过于发散和深入的讨论进行时间上的把控，比如另行预定专门的会议讨论等。

总结

那么总结下复盘会的关键事项：

首先这个会议是一个迭代结束后，获取迭代产出反馈的一个会议。是敏捷小步快跑思想的主要体现。但实际运作中，并不是一个必定会每个Sprint都会召开的一个会议。只是应尽可能不要间隔时间太长，给团队来根据干系人的反馈进行及时调整有灵活性。
这个会议并不是一个验收会，它并不是用于向PO确认Sprint Goal有没有达成的一个会。沟通反馈才是主要目的
会议的过程和产出，是敏捷迭代，产品演进的重要一环，是确定PBI，及时纠偏的重要过程，可以确保团队的工作和用户的期望是匹配的。
最后，这个会议也是Sprint中Dev Team和相关干系人直接沟通，感受压力和直面用户或老板们真实想法的唯一一个正式的窗口。对于避免团队闭门造车、想当然或工程师思维有重要意义。

以上就是关于Sprint Review Meeting相关召开要点的梳理和总结，欢迎关注秋草，持续带更多软件研发、测试、技术的深度梳理和思考。