scrum回顾_如何开好敏捷的回顾会

回顾会Retrospective Meeting 在Scrum里面是非常重要的会议，但是从笔者的经验来看，很多团队都开不好这个回顾会，或者感觉回顾会没什么效果，或者开来开去都不知道讲什么了，根据笔者的总结，大多数的团队都存在以下问题：

1. 回顾会效果不佳

很多团队在开始开回顾会的时候都是滔滔不绝的，一会儿说我们的质量不行，一个说我们的沟通不行，然后大家都畅所欲言的吐槽，吐完后，问题还是没有解决，甚至在开了几次的回顾会之后，大家都不想提了，因为都是老调重弹了。开了那么多次的回顾会，问题还是没有彻底解决。

2. 不知道如何开回顾会

尽管大部分的Scrum Master都接受过正规的敏捷培训或者野路子的培训，但是上完课后，一到实操的时候就不知道如何开回顾会了，因为Scrum里面对回顾会就是让组员给自己提问这三个问题，要知道我们大部分的攻城狮都是用代码来说话的，要说这些东西，难免没那么容易，或者讲多几次就不知道如何表达了。

3. 开回顾会的时候不知道讲什么

根据Scrum里面的流程，我们回顾会主要是讲下面几个的要点的东西，可是大家在开过几轮的回顾会之后，发觉好像没什么可讲的或者不知道讲什么了，因为该讲的都讲过了，主要原因还是效果不好，导致大家开回顾会都不知道讲什么了。

• 在sprint中哪些方面做得好？
• 哪些方面做得不好？
• 哪些方面需要改进？

4. 感觉回顾会可有可无

根据我这几年来的经验和业界的交流，很多的开不好回顾会的团队的一个特点是回顾会有时候会开，有时候不开，究竟什么时候开，不知道，全凭感觉，或者这周心情好，我们来开一次回顾会吧。有人请假了，就干脆不开吧，这周很忙，就算了，不开了吧；这周好像没什么事情发生，就不开了吧。好像大家都没提，就不开了吧。有没有很熟悉这些话语， 是吧，是不是团队也存在这样的问题。

其实原因很多，这里就不一一举例了，下面我们就来讲讲如何开好回顾会。

1. 详细清晰的流程。做过演讲和培训的人都知道，在准备讲课的时候，都会做好充分的准备，具体都会精确到分钟，如果是做演讲还会精确到秒的级别，具体有多少个步骤，每一个步骤都有详细的时长，我们开回顾会也是一样的，我们也需要有清晰的流程，这个回顾会我们有哪些步骤，每一个步骤用多长的时间，因为scrum 里面是有规定的，一般用时不超过1个小时。有了清晰的流程，开回顾会就会容易很多了，限于篇幅，大致的流程我会帖子文章最后。

2. 落实反馈环。在回顾会的时候，大家都会提出问题，并在会后提出解决办法，但是很多团队却忘记了检查这些问题是否被解决了。根据精益的持续改进原则，我们还应该在每次开回顾会的时候检查一下上次承诺解决的问题是否有解决掉，否则就会出现，开了回顾会也解决不了问题的现状。

3. 没有节奏感。SAFe里面的原则七就是Apply Cadency，说的是我们开PI Planning要有节奏性，不要一下子10周一个Planning, 一下子15周一个Planning,这样大家都不知道究竟说明什么开Planning。对于我们开回顾会也是一样的，Scrum Master应该定期的在每一个sprint结束的时候组织团队开回顾会，而不要时开时不开，这样团队会感觉开不开都无所谓了，久而久之就不开回顾会了。

4. 将解决方案落实到具体的个人。在开回顾会的时候，我们通常都会提出很多问题，大家也都能想到解决方案，可是为什么就很多问题依旧呢？举个例子，比如我们的pipeline经常红了，UT过不了，或者部署不了，那开回顾会的时候，大家都提到了这个问题，解决方案呢，就是大家以后要多留意一下这个东西。过了一段时间之后呢，这个问题依然存在，为什么，因为每个人都会以为隔壁那个同事会去解决，自己不用管，总有人去看的。碰到这种问题，最好的办法就是落实到人，比如，那就David去把控这个问题，如果再pipeline红了，没人管，就是David的问题了，这样把问题落实到具体的个人之后，这样的问题就迎刃而解了。可能你会说，那总是这个人的话，他也很累的，对于这种东西，我们通常的做法就是轮流来做，每个人做一个Sprint,到下一个sprint就是下一个同事。

下面就我的一份建议的开回顾会的流程。

SM总结这个sprint的大致状况 - 2 min

将上一次的take action的东西拿出来检查一下，看执行是否到位(2)

读一段团队的宣言 ( 仪式感还是要有的, 1 min)

感谢环节， 团队的每一个人找出一个在当前sprint里面你最想感谢他的人,并说明为什么你想感谢他(10 min, 只能有一个人，可以没有)

写字条，从3个方面回顾我们在sprint里面哪些做得好的地方，哪些做的不好的地方，哪些需要改进的地方(8分钟)

写完后，SM降字条进行归类，比如流程问题，质量问题，沟通问题(2)

SM来组织将每一个建议都过一遍，由写的那个人来表述为什么他提出这样的东西，通常的做法是先将好的过一遍，再过后面两种情况的纸条.(10min到15min)

讨论与投票， 团队对提出的问题进行投票，投票最高的列为下个sprint中要take action的事情.(5)

将投票出来的列表落实到个人身上，因为要落实到个人身上，执行力才高，落到团队身上是没有人去执行的。(5)

以上的流程大概50分钟，算上buffer的话，大概1个小时刚好.

敏捷是一门入门容易精通难的软件开发方法，无论是Scrum, XP 还是SAFe, 它都只是一套通用的流程与方法，并没有告诉我们为什么应该这样做，遇到问题如何去处理，我们还需要更多的思考为什么要这样做，这样我们才能提高我们的效率，而不是一味的follow.