细说敏捷：敏捷四会之回顾会

请添加图片描述

在前面的分享中，我们已经梳理了计划会、每日站会和复盘会的召开要点，本篇我们再对Scrum敏捷四大仪式中的最后一个会议仪式 - 迭代回顾会 进行探讨

回顾会的目的和作用

回顾会因为和复盘会一般都放在迭代的最后一天，而且通常安排是相邻在一起的会议，所以很多时候大家会错误地认为这两个会议是同一个敏捷仪式，把这两个会等同起来。

这个其实是对复盘和回顾这两个不同仪式的错误认识。这两个会议，作用、目的，包括会议的参与人员其实都有明显不同，所以，不能因为这两个仪式时间上比较连贯，就想当然地认为它们是同一个会议。

复盘会的主要目的是通过对迭代交付物的演示，及时收集产品干系人的反馈和意见，以便确认阶段交付符合预期并对后续迭代进行及时调整。着眼点是面向外部的反馈收集，针对产品本身

而回顾会的着眼点在团队内部的回顾总结，针对流程和团队协作。

所以回顾会的目的是在迭代结束后，再回过头检视迭代的运作，从中总结经验，汲取教训。

而通过召开回顾会，能产生以下作用：

团队在通过多个迭代去实现产品愿景的同时，也会定期地检视迭代的运作，发现问题，总结经验，及时改进，持续提升。
团队成员通过回顾会这个窗口，有一个相对正式和公开的平台，都可以提出对团队运作方式的建议或发现可能的问题。
回顾会也是增进团队凝聚力的一个重要仪式，是团队成员间互相肯定或开诚布公交换意见的一个渠道。

总之，回顾会可以看作是团队内部的一个闭门会议，是团队自我更新和优化的一个仪式。

回顾会中的不同角色

所以基于上面的目的，这个会议也不应该和复盘会作为同一个会议召开。

不同角色参与会议的角色其实也都有所区别：

必须参加：作为一个团队内部的总结会议，面向的是团队自身的改进，所以Dev Team和Scrum Master是必须要参与会议的。
尽量参加：PO虽然也是团队一份子，但PO的职责更多还是面向产品本身，而且基本不直接参与产品研发本身。所以PO在团队回顾这点上，不是必须要参加；但是作为团队的重要成员，很多情况下，有些意见和改进举措也是需要PO提出或参与的，因此PO是尽可能参加。
避免参加：而把回顾会和复盘会分开的一个重要原因，其实就是作为团队内部的改进会议，为了让团队成员能够更直接地表达意见，参与复盘会议的一些利益干系人，比如用户、经理层等，最好是避免参会。当然有些特殊情况下，比如产生重大分歧、产品目标有重大风险等情况下，可能也会请关键的干系人参与回顾。（当然，老板非要参加一般也没法拒绝）

请添加图片描述

会议流程

回顾会通常建议是尽可能线下召开，而因为团队都比较熟悉，又是迭代结束，气氛尽快可能营造得轻松些，准备些小零食，小礼品有助于帮助会议达到更好效果。

会议大体流程如下：

请添加图片描述

首先当然还是Scrum Master来主持会议。在进行回顾之前，通常还要做些准备。比如收集迭代过程中的相关数据，比如burn-down燃尽图，团队的速率图。以及在以前迭代回顾会上的跟踪项，目前的状态，这些都在在召开会议开始阶段，让团队总体做个了解。当然然对于比较新的团队，还要介绍下回顾会的规则。要用到的配套工具比如卡片、投票贴纸等。
下一个环节，是收集团队对迭代运作的建议，也就是团队成员各自把自己对当前迭代的观察结果写下来，哪些方面做得好，应该保持：哪些方面还不够好，可以改进，包括如果想单独感谢谁都可以写到不同颜色的贴纸上。大家都写完以后，将相关贴纸贴到准备好的白板上对应区域中，而在意见收集完以后，大家可以集中到白板前，由SM或者团队任意一个成员，大声地复述每一个贴纸卡片的内容。这个过程其实相当于团队一起重温迭代运作的过程。
在读完大家所有的意见之后，会进入投票环节。比如每人都可以规定有3票，然后针对这些意见，每人投出自己觉得最值得在下一个迭代采取行动的3条意见。
完成投票以后，统计得票最多的意见，比如每人三票，那么最后就选出得票最多的三条意见，作为需要在下一个迭代采取行动的待办项。
确定待办项后，团队还要共同针对对应的事项，讨论具体的措施内容，确定如何来进行改进和提升。
上面讨论产生的结果，要明确到可实施的具体行动，指定对应的负责人。这些要作为下一个迭代的任务安排，纳入迭代看板进行任务跟踪。

通过上面这个会议流程，达到团队自我持续更新和改进提升的目的。这里一个非常重要的核心就是成员应该开诚布公，需要大家真正从团队本身的提升为出发点来进行回顾。