我的敏捷回顾会议

今天跟小伙伴们讨论了项目复盘的相关问题，我倒是觉得，在敏捷活动中的回顾会议是很有趣的，甚至说是很有效的。一次有趣的敏捷回顾会议不但可以对团队做有效的改进，而且效果不亚于一次团建活动。

回顾会议有多重要，对敏捷有接触的同学肯定很清楚，这里就不多做描述了。但是，我们首先我们要明确一个事情，回顾会绝不是找后帐，也绝不是要追责，也不是为了决定谁应该拿到更多的项目奖金而举行，那我们就聚焦于一个事情——我们如何能做的更好。所以我们在回顾会上做的绝对不是总结汇报大会那种领导的滔滔不绝，也绝对不是流水账式的把过去的事再复述一遍，也不是吐槽大会，我们需要的是激发大家的灵感，让大家思维碰撞起来。

有一本书对我影响比较大，由Esther Derby和Diana Larsen合著的《敏捷回顾——团队从优秀到卓越之道》，书中大致上给大家介绍了一个回顾会议的五段式套路，或者一个开会的框架，预设会议基调、收集数据、激发灵感、决定做什么、结束会议这五段，有兴趣的同学可以去找来这本书看看。

首先，我们先解决一下，谁跟这会有关

我的观点是，在敏捷转型过程中，或成型期，应该有某个人来组织和发起这样的会议，而成熟的敏捷团队，这种会议是自发的，可能也会有各汇总小的回顾会议。这个人可以是ScrumMaster，也可以是PMO。但是我认为，不应该是某个领导，我甚至都不认为所谓的领导应该参加这个会议。领导的参加会让这个会变味（这是一个很痛的领悟）。另外就是，我觉得职能经理（很多运行敏捷的公司也是矩阵式的），或者所谓的外部专家，也不应该参加这个会议，因为这个会议的内容跟他没有关系，他不能参与到这个会议中的任何议题和决议中去。作为敏捷团队的所有成员，注意是所有，甚至包括跟团队协同合作的客户代表，都应该出席这个会议，团队成员可能有着不同的职能，能够更全面，更具体。

其次，我们来解决一下要为会议准备哪些东西

1、一个舒适的，不受外界打扰的地方

开会得有场地，这个场地也是有讲究的，我认为开回顾会议最理想的场地是咖啡厅，不是会议室。当然了，这过于理想了，我一般会准备一些零食、饮料放在会议室中座位安排的松散一些……怎么描述呢，小时候在学校开过茶话会吧，照那个布置就差不多了。大概是这样的：

（网络图片，如有侵权请联系我）

2、一块白板或者能写字的墙

我们要激发灵感，收集想法，这些是必不可少的。重点是，这个板或者墙要足够的大，大到能容纳入会各位全部的想法。

3、一些便利贴和一些白板笔

大家的想法怎么收集呢，白板笔配便利贴再好不过了，这里做个广告……一定要3M的Post-it，我用过的最好的便利贴，没有之一，足够大，颜色足够多，最重要的是，他贴上不容易往下掉~~

4、一个说人话的主持人

就两个原则，其一、这个主持人要对这个项目足够的熟悉；其二、这个主持人有能力引导会议走向且要说人话（官话套话婚礼主持免谈），最好是团队中的某个人，或者是轮流来主持这个会议。但是在团队没有将回顾形成习惯的时候，PMO或者ScrumMaster应该承担起这个职责来。

5、一些过程数据

任何的回顾不能基于事实说话，那都是耍流氓，耍流氓的会议是不会有任何结果的。数据也会对预设会议的基调起到关键性的作用。因为敏捷项目有自己的特点，通常来说，我们会把燃尽图和迭代看板生成的一些数据，比如说，故事停留时间，速率，缺陷停留时间等这些反应价值流动的数据和偏差（与前一个迭代相比的）收集上来备用，也可以把这些数据形成图表，bia在会议地点的墙上。

6、一份会议规约

让大家都在统一的规则下工作，明确会议的目的，并在会议开始的时候由主持人公开宣读给大家，如果有必要的话，打印出来让大家钱数，大概是这样的：

所有的这些规定，只要是有利于我们发现自己，改进自己，保障这个会议顺利进行的，都可以往里写，而且，我个人的观点，会议组织者有义务让这个会议有一个轻松的氛围。

7、一个可爱的邀请

不是通知，一定是邀请，甚至是我觉得，从仪式感上来说，发一个邀请函或者是邀请函邮件也是应该的，这会让整个团队有一种被尊重的感觉。

好了，这些我们都准备好了，开会！

关于这个会议时间的长短，有很多种说法，很多书上说是不要超过2个小时，我倒是认为，能解决问题，刚刚好就好，不能太短也不能太长，这个问题跟团队的风格有关系，甚至说我们要不要当它是个会呢，这得大家在自己的团队内摸索、思考。

那我们就来解决这个会怎么开的问题。

通常来说，我们在敏捷开发中会有一些隐喻，就是把在开发活动中的一些不太好描述的东西给具象化，其中回顾会议中的隐喻是很多很多的，我比较喜欢也用的比较多的，叫帆船回顾（Sailboat retrospective），是一种激发团队思维和碰撞想法的很有用的工具。

首先我们会在墙上画一个这种东西，看图（我说吧，这个墙或者白板得足够大）

（我画是实在太丑了，所以引用一下国外大神的）

在这张图上，我们要关注几个事：

1、风：也就是动力，是我们在过去推动者团队向目标彼岸航行的事或行为

2、锚（其实还有大石头什么的）：也就是阻力，是我们在过去阻碍团队向目标彼岸航行的事或行为

3、暗礁和海盗：在未来的路上，有哪些能阻碍我们的人或者是事（明眼的就能看出来，这是风险~）

会议开始后，宣读完了会议规则，展示了准备的数据之后，我们要发给团队便利贴，问大家这三个问题，我们的风、锚、暗礁和海盗都是什么，让大家把想法都写下来，贴在相应的位置，那结果大概是这样的

去掉了重复的之后，我们就要处理这些信息了

首先是风，所有的风我们是都可以保留下来的，但是我们需要所有的团队成员认同这些风，我的做法是，会让写出便签的人简单说明一下写这个便签的原因，然后让大家认同的表决，如果有某一位同志不认同，那也说明理由或者提问，所有同意的都可以回答，然后再表决。3轮之后，如果还有人不认同，那这条风就不能采纳。

然后就是锚，通常我的做法是这样的：我会先定义一个程度分数1-10，请写出这个事情的同事描述一下这个问题，并给出一个分数，然后类似于风，举手表决，不同意的说明理由，最后要统一2件事，这个锚成立否，程度分数是多少，于是我们对锚有了一个排序。

最后是礁石和海盗，与锚类似，最后我们也会得到一个包含排序的一堆礁石和海盗。

拿到了这些信息之后，我们要做一件事，这就是“决定做什么”。通常一个团队不可能一次性的把这些问题都解决掉，所以我们才会对这些锚和礁石什么的进行排序，我们捡迫切的，重要的，写出故事或者措施，滚到将来的迭代中去。当然了，这不是某个人的行为，是整个团队的行为。

那吃饱喝足了，事也办了，会议是要有结论的对吧，那我们的会议结论是什么呢？

1、你会有一个最佳实践的列表（风）

2、你会有几个改进故事会滚动到将来的迭代（锚）

3、团队会有一些关切和聚焦，且应该是有措施的，甚至是会有一些寻求帮助的东西（海盗和礁石）

4、最后有一条很关键，要有一个结论，结论的内容是我们的过去一个迭代是不是成功的，我们离目标的距离是越来越近了还是越来越远了

最后！没错，还没完！

给团队成员一个机会，表达在过去团队中帮助过自助机的人表示感谢，甚至可以设计一个感谢卡，传递感恩，凝聚团队力量。

回顾往往都不完美，贵在我们会不断的回顾，敏捷就是一个持续学习持续精进的过程，敏捷不是一成不变的，也不是有一定的形式的，每个团队的方法都不太一样，还是希望自己能找到合适自己的方法。