如何有效进行回顾会议（上）？

在 Scrum 团队中，回顾会议可能大家都在做，但要怎样才能做好回顾会议呢？

一、消除误解

首先我们要来为回顾会议正名：

1.回顾会议就是专案事后分析吗？

虽然这样问，大家一定会回答不是，但我们的小科普还是要继续的。传统项目管理 会通过专案事后分析来进行系统改进，但这并不代表回顾会议就等同于专案事后分析。两者具体有什么区别呢？

• 发生阶段不同：回顾会议鼓励在整个项目过程中通过 Sprint 的方式进行，因此我们通常是在每一 Sprint 结束时进行回顾会议；专案事后分析则是在项目完成或终止后进行。

• 关注点不同：回顾会议关注于在项目过程中不断改善，是短周期的反馈；专案事后分析则是总结本次项目过程的经验教训，在下次项目中进行改善，是长周期的反馈。

• 产出物不同：回顾会议产出的是执行路径；专案事后分析产出的是文档。

2.回顾会议就是评审会议吗？

同样，答案是否定的。很多人不习惯将产品改进与流程改进分开进行，所以会将两者合在一起进行。

Sprint 评审会议为开发团队、产品负责人、Scrum Master、利益相关者提供了一个来对产品进行检查并做出改进决策的机会；而回顾会议是关于团队和流程改进的，主要用来检查团队如何完成工作、做出决策、成员如何进行沟通的。

3.一直是相同的议程？

我们在进行回顾会议的时候，不必拘泥于一种既定的流程，因为这种流程会逐渐演变为流于形式，回顾的效果也就大大降低。在下面也会提供回顾会议的组织形式，不要再让团队成员在回顾会议上习惯性地重复啦！

二、有效回顾会议的必备要素

1.不去过多地责备

“无论我们发现了什么，我们都理解并真正相信，考虑到他们当时所知道的、他们的技能和能力、可用的资源以及手头的情况，每个人都做了他们所能做的最好的工作。”这句话其实并不是说大家都是无可指责的，在过多的责备中，我们可能逐渐变得关注于某个人的行为而不是整个团队的行为。

举个例子：在一个 Sprint 中，团队发现了一个 Bug。其中一名团队成员急于修复和部署，虽然这个问题解决了，但也产生了一个新的、更大的问题。 

在这种情况下，我们过多地去追究他个人的原因，反而有可能忽视团队的一些不规范的地方，如没有检查“完成”的定义、没有运行单元测试等等。在这种环境下，团队成员更有可能感觉自己受到攻击而不是承认解决了最初的问题。因此，他们不太可能从批评中学到任何东西，最重要的是，他们可能会错过深入研究系统性问题的机会。

三、回顾形式

1.故事奥斯卡回顾会

在白板上绘制一个方框，在框中将用户故事故事分成几种类型：最佳故事、最令人郁闷的故事以及最令人惊讶的故事。团队在回顾会议上来通过便利贴将上个 Sprint 中完成的用户故事贴在相应的框中。如果每种类型中有很多用户故事被提名，那大家再集体在这些用户故事中选出最佳/最令人郁闷/最令人惊讶的用户故事。

2.帆船回顾会

在这个回顾会上，我们乘坐的是一艘即将登上岛屿的小船，在这个过程中，我们会遇到很多推动和阻碍的因素：

• 船：项目团队；

• 岛屿：Sprint 目标；

• 顺风：推动我们的 Sprint 顺利进行的因素；

• 船锚：阻碍我们 Sprint 实现的因素；

• 礁石：已经识别的潜在风险。

那在这个回顾会中，每个人都要来分析在这个 Sprint 中，我们的顺风、船锚和礁石是什么，以及接下来为了避开礁石、提前收好船锚，我们要做出哪些努力和计划。

有了这些小技巧，我们就可以尝试开启一个崭新的回顾会议啦，接下来我们还会有更多关于回顾会议的方法，持续关注我们吧！