Scrum管理最佳实践 – 回顾会议，你开对了么？

Posted 2021-04-25 飒飒的不惑之年

        Retrospective meeting是在Scrum开发方式中是最容易被忽略或者敷衍过去的会议。为什么？这是一个总结回顾会议，说难听了就是批斗大会。而大部分团队成员都不愿意直视自己的问题，而且缺乏持续改进的勇气和动力。然而在敏捷团队中最需要的恰恰是这样的行为，来总结经验教训，寻求改进方案。所以Retrospective meeting不但不可忽视，而且非常重要。让我们来看看往常容易在这个会议上遇到的问题吧。

情景一：成员一在描述过去一个sprint做的不好的地方时这样说：

这个sprint有个feature没能按时完成，主要有些细节问题没有得到客户确认，所以延误了

解决方案：下次要积极的和客户沟通，争取早点确认需求。

是不是似曾相识的问题？好像和团队成员没多大关系，主要是客户不配合啊。如果客户就是不积极回应，你再积极有什么用呢？我们往往会遇到这种干着急没办法的情况，这时候的积极性并非只是积极的和客户沟通，更多的是想到替代的方案。比如和PM说明这个问题请求帮助，选择Backlog中可以开始的其他任务，使用“我可以怎样做”而不是“这不是我的错。。。”

情景二：成员二在描述过去一个sprint做的好的地方这样说：

我遇到一个非常复杂的问题，但是我积极的和国外的高级工程师沟通，所以问题很快就解决了。

        要想把回顾会议的作用最大化的发挥出来，就要注意信息的采集方法以及对待这种会议的态度和方式。

一：高效的信息采集方法：

1.   对于成立没多久的团队，要成员说出自己做的好的地方和坏的地方可能会比较困难，可以让别人帮你说出你的问题和优势。比如：花10分钟时间，让坐在你左边的人说出你做的好的地方，右边的说出你做的不好的地方，各讲三点，然后你自己总结一下再表达出来。大部分人在说别人的问题时能比较直接的指出问题所在，这样回顾信息质量较高，而且也会让大家在工作中不要只关注自己的工作，加强团队意识。

2.   如果面对面的沟通会让彼此感觉尴尬，写信也是一个非常好的实践。花10分钟时间，让大家匿名写出哪些人和事做的不好，哪些做的好。然后再让当事人对这些事做一些扩展的描述，大家再引入自己的观点讨论如何改进。

      以上两种方式都可以让回顾会议的内容更加丰富，但是主持人一定要注意把握时间，不然信息量太大，不好总结。一般来讲，信息收集10分钟，当事人发表信息30分钟，讨论总结20分钟。

二：保持责任心和关注度：

1.     每个人要对自己表达的好的和坏的信息富有责任心，如果没有这份责任心，你提供的信息都只是废话而已。所以应该让每个Action Plan都有相关的负责人，在下个Sprint中关注action的有效性并在下次回顾会议中提出意见。

2.     我们经常会遇到这样的场景，要开回顾会议了，工程师们最后一分钟工程师才从座位上站起来冲向会议室，可以肯定的是他没有时间考虑在会议上要表达的信息，而且也没有关注上一个sprint总结过的信息，这样的情况下得到回顾信息都是临时想到的，价值不高。不妨把会议时间提前10分钟，演示上一个Sprint回顾的信息，让大家安静的坐在那里，好好想想要表达的内容，而不是敷衍了事。

3.     回顾会议一般会持续一个小时，难免会有成员开小差。主持人可以不按照顺序要求大家提供回顾信息，而且要对上一个发表信息的人的观点提出自己的意见和建议。这样可以保持大家的关注度，而不是你讲你的，我想我的。

4.     每次会议选择应该不同的人做会议记录，并且把会议记录发布到大家都可以看到的地方。Scrum Master应该公开评价每次的回顾会议的信息的有效性，建立强烈的荣辱心，使人人会想到“这是我总结出来的经验教训”“这是我提出来的观点”，从而关注对这些经验教训带来的后续影响。

        

         好的敏捷开发方式，绝对会让每天的8小时工作时间被充分的利用，所以不要忽视这些会议，有句话说的好“不要只是低头走路，还应该抬头看路”，这些会议给你一个抬头看路的机会，如果不好好把握，你可能一直在原地打转而浑然不知。希望我提供的这些方法和实践会让你们的回顾会议更加高效，在软件开发的路上越走越宽。