3步开好回顾会 | IDCF-技术圈

了解敏捷的人应该对回顾会不陌生，回顾会是在SCRUM框架五个活动中的最后一个活动，但是在敏捷的实际应用中，回顾会并不只是会在应用SCRUM的团队中使用，在其他敏捷实践中也会引入回顾会作为反馈环节。

那么什么是回顾会呢？在SCRUM中，回顾会是来回顾当前迭代中的流程、工具、实践、沟通、环境、资源等方方面面，检视各个过程并提出改进项的活动。这个会议重点在于聚焦问题并持续改进。这个是一个最容易被忽略的会议，尤其是在开发压力比较大时，回顾会往往会是第一个被裁剪的过程。

一、为什么需要进行回顾？

孔子曰：吾日三省吾身。只有不断反思/回顾才能找到自己需要改进的地方并持续改进，在软件开发中也同样如此。敏捷体系是开源体系，没有终点；即没有最敏捷只有更敏捷。那么如何让我们的敏捷团队更加敏捷呢，回顾会是一个必不可少非常重要的会议。每个迭代中运行着相同的过程，这同时也意味着可能重复着同样的错误。可以说没有回顾就没有持续改进。如果你的团队在应用敏捷，在应用SCRUM框架，那么回顾会是持续改进的必要过程和活动。

二、回顾会应用怎么开？

这个问题对敏捷教练提出了比较高的要求，在回顾会上，尤其是在刚开始实践敏捷的团队回顾会上，团队往往不知道回顾会要做些什么。常见的误区就是会把回顾会理解为总结会或者反思会。此时，敏捷教练要给予正确的引导。

回顾会的流程比较简单，通常有以下几个议程：

2.1 会前准备

回顾会之前一定要收集足够的数据，包括迭代中故事完成度，燃尽图，速率图，每个故事耗时情况等，收集数据后需要向团队进行展示。其次，确定好要邀请的人员以及回顾形式和议程。回顾会的准备是非常重要的，准备是否会很大程度上决定能否开一个有效的回顾会。

2.2 会议主要议程

1）向团队展示度量数据，通过数据进行初步分析，鼓励团队参与讨论，是否有显而易见的重大问题，是否有特殊情况导致本迭代的数据问题。如果有重大问题，在回顾时作为重点进行回顾。

2）让团队成员各自总结需要继续保持的和需要改进的项，这里有很多方法，包括三栏式（Well, Less Well, Puzzle）、海星图（Start, Stop, Do Less, Do More, Keep）以及SSCC（Start, Stop, Continue, Change）等。

3）将大家的反馈进行分组，并针对需要改进的问题进行分析，这时也可以采用一些根因分析的工具，包括鱼骨图等，最后收敛出需要做的改进点。

4）针对改进点制定行动计划（Action）及负责人（Owner），并就行动计划在团队内达成一致。

2.3 结束会议

回顾会的结束，可以添加一些仪式感，比如由几个人说一下这个迭代中需要感谢的人，为他提供帮助的人，简单的表示感谢；然后由SM做一个简单的总结，对会上讨论达成一致的改进项、负责人和行动计划进行重申，最后需要对大家表示感谢后结束会议。

三、如何开好回顾会？

怎样使回顾会开得最有效果？可以将迭代中的问题全面暴露出来就是有效果的；可以将上个迭代重复发生的问题减少甚至避免就是有效果的；团队成员都认为每个迭代我们都在持续改进中，并且乐于每个迭代进行回顾改进就是有效果的。最后，只有回顾后贯彻执行持续改进才是最有效的。那么如何使回顾会有效果呢？

3.1 营造轻松的氛围

会议场地：大部分的回顾会都会选择在会议室进行。在工作单位中会议室确实是大家集体讨论事宜比较合适的场所，但是容易给大家一种紧张严肃的感觉，不利于团队成员畅所欲言。一般比较建议的咖啡间等等。
会议时间：一般回顾会会定在迭代最后一周的周五，迭代评审会之后。这个时间点一般迭代都已经完成，大家只剩下一些收尾的工作，会比较容易营造大家放松的气氛，团队不用去考虑仍未开发完的功能、未修复的bug等，团队更容易参与到回顾中。
参会人员：回顾会需要大家畅所欲言，针对相关问题进行解决方案和行动计划制定的活动，是团队内部自我改进的活动。由于领导层通常掌握着团队成员的绩效奖金等切身利益，如果有领导层的参与会容易大家感觉到紧张，以至于会报喜不报忧，没有办法持续改进。这时一般建议如果不是有非常严重且必须要领导解决的问题之外，不会建议领导层参会。对于产品经理是否应该参加回顾会的问题，产品经理是团队的一员，原则应该要参加回顾会，但是如果产品经理的在场会导致团队紧张或者不敢提出问题，那产品经理还是不建议参加会议的。
暖场：为了让大家放松下来，一般需要SM开场比如一个笑话，一个简单小游戏开场，让大家放松下来适应轻松的氛围；
开场：敏捷教练可以通过一些小技巧让大家快速思考起来，比如让团队成员用一句话、一个词或者一个水果来形容对当前迭代的感受，用简单的话来形容容易激发大脑的思考。一句话，一个词语而不是一段话，这时就会激发大家去动脑，从众多词语中选择一个最适合形容当前迭代的，这样做的主要目的就是让大家的思路先转起来。

3.2 提升团队成员的参与度

SCRUM非常重视个人，是以人为本的。在回顾会上，使得大家都参与讨论是非常重要的。下面有几个方法可以帮助团队增加参与度。

大家匿名写出需要改进的和需要继续保持的，这样可以保护大家避免因为写出不好的地方让大家感到尴尬。
每次会议的议程和展开方式可进行调整。如果每次回顾会的内容和方式都是相同的，大家会变得越来越形式化，觉得回顾会没有意义。每次调整暖场方式或者大家的参与方式，这样可以在保持新鲜感的同时提升大家的关注度。
鼓励发言，在感谢和感悟环节，鼓励大家表达自己的感悟以及对团队成员（某位成员）的感谢。这时需要鼓励大家发言，无论发言如何都要给以尊重和认可。如果没有人发言，前期建议可以通过抽签或者有趣的方式找到人来发言，慢慢增加大家参与度。

3.3 贯彻执行改进项

为了保证改进项能够顺利落实，需要选择对大家目前影响最大的，即优先级最高的，同时需要综合考虑改进项的成本和开销后选择。需要做的改进项建议一定要写入下个迭代的backlog中，方便跟进的同时也能使得改进项负责人认真对待。

四、回顾会重要注意点

加强重视度，不要让回顾会变成很少人员参加的可有可无的会议。有些团队的误区就在于每次回顾的重点都是相同的，这就使得团队认为每次回顾会的内容是相同的，可裁剪的。这时需要SM去引导团队聚焦当前迭代是否已贯彻执行上一迭代改进项，是否有新的需要改进的问题，以便持续改进。
避免天马行空的谈论不切实际、不可能完成或者不相关的话题。由于回顾会是比较轻松让大家畅所欲言的活动，这时很容易天马行空漫无目的的谈论，要及时将大家的讨论拉回到正确的思路上来。
避免对重大问题视而不见，回顾会上要敢于提出大家都认为是有问题，但是没有人敢于提出的问题。
避免团队成员陷入郁闷自责，这一点跟营造轻松的氛围和会议参与人员非常相关。此外要相信所有成员在现有条件下已经做出了最大的努力。
避免陷入相互指责，相互吐槽的境地。要通过回顾当前迭代的问题来改善后续迭代的情况。如果团队有追责文化，很容易出现这种情况，这时需要循序渐进的改变大家的思维定式，同时减少追责，增加鼓励和奖励机制。
回顾会上的改进项一定要贯彻执行，没有执行就等于没有改进，没有改进回顾会就失去了意义。
避免为了过程而过程，要每期制定回顾重点，避免形式主义。如果仅仅为了会议而进行会议，那比不开会议还要糟糕。

写在最后

回顾会不建议裁剪，只有持续回顾才能持续改进。在工作过程中，需要我们时不时的停下来回顾下，我们是否做了最好的方案，是否有更好的方案？如果对现状非常不满且急需改变，停下来回顾思考下，也许是个不错的开始。

IDCF DevOps黑客马拉松2020年再度开跑，北京站圆满结束（点击回顾）、深圳、上海报名通道已经开启！打造端到端的DevOps人才与教练，快扫码报名加入吧~