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

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

一、消除误解

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

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

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

发生阶段不同：回顾会议鼓励在整个项目过程中通过Sprint的方式进行，因此我们通常是在每一Sprint结束时进行回顾会议；专案事后分析则是在项目完成或终止后进行。
关注点不同：回顾会议关注于在项目过程中不断改善，是短周期的反馈；专案事后分析则是总结本次项目过程的经验教训，在下次项目中进行改善，是长周期的反馈。
产出物 不同：回顾会议产出的是执行路径；专案事后分析产出的是文档。

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

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

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

3.一直是相同的议程？

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

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

1.不去过多地责备

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

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

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