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

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

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

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

二、回顾会应用怎么开?

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

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

2.1 会前准备

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

image.png

2.2 会议主要议程

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

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

image.png

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

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

2.3 结束会议

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

三、如何开好回顾会?

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

3.1 营造轻松的氛围

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

3.2 提升团队成员的参与度

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

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

3.3 贯彻执行改进项

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

四、回顾会重要注意点

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

写在最后

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

作者:IDCF社区FDCC认证学员 魏祖迎

想要提升敏捷DevOps技能,来场DevOps黑客马拉松!
想要寻找第二增长曲线实现创新增速,来场DevOps黑客马拉松!
2021年4月24-25日,IDCF DevOps黑客马拉松走进天府之国-成都
关注公众号回复“黑马”加入吧~~可自己报名,也可公司组团参加哦!


用户bPcN1SC
149 声望55 粉丝