怎么开好团队回顾会议（retrospective）

回顾会议（retrospective meeting）是scrum中最有价值的会议之一，虽然这个会议很重要，但是在实际的工作中我们会发现往往最容易被砍掉的也是这个会议。
为什么这个会容易被砍掉呢？项目工作太多，大家太忙只是一个明面的借口，深层次的原因应该有如下几个：

• 会议过程和形式太枯燥重复，没有新意，让人厌倦
• 会议产出的改进计划不明确，不能落实，没有跟踪，更没效果
• 团队缺乏持续改进的意识，只是停留在埋头处理手上的工作

如果你发现你们团队大家对回顾会议不感冒，也许你们就有上面这些问题，本文的目的是介绍一下我个人常用的回顾会议套路，仅供参考。

回顾会议的目的

回顾会议是Scrum检视与调整的一个重要的环节,在这个会议上，我们鼓励团队对自己的开发过程进行改进，并确定什么样的调整可以使下一Sprint的效率更高、结果更令人满意和更易于工作。
就像我们频繁的迭代和交付是为了快速的获得外部用户的反馈，进而帮助我们做产品需求的调整一样，每个迭代的回顾会议就是想更快的得到大家对团队工作问题和改进点的反馈，帮助团队内部的工作效能和能力成长的不断改进。

回顾会议的过程和我常用的手段

《Agile Retrospectives》这本书中把回顾会议分成了5个阶段：

1. 准备
2. 收集数据
3. 产生见解
4. 确定改进项
5. 结束会议

那我就按这几个阶段来讲讲我是怎么做的。

准备

准备阶段其实是非常重要的，一些初次主持回顾会议的scrum master往往会忽视这个阶段，一上来就让大家写小卡片，这样不仅效果不好，更给人枯燥重复的感觉。

准备阶段我往往会选择做下面几件事：

设定一个安全的环境

回顾会议不仅仅希望大家能参与进来，更重要的是能敞开心扉，大家没有顾虑的把问题暴露出来，找到改进的办法。但事实是肯定有人担心回顾会议会成为一个批判会议，在认为这个会议的目的是找到这个迭代中犯错的那个人，并把他拎出来痛批一顿，看以后还有谁敢再犯。如果这样大家肯定会有所保留，担心说错话，会议上就找不到真正的问题。
一般我们会直接声明这个会议的目的，绝对没有想追究任何人的责任的意思。不仅如此，我们还需要在会议过程中避免讨论任何个人责任的问题。

了解与会人的心态

这是个很有意思的事情。会议本来就令人沮丧，更何状是回顾会议这种非时间工作内容的、锦上添花的会议。与会者都是带着什么心态来参加的呢？这里有一种非常有意思的收集与会者心态的小活动，叫做“ESVP”：

• Explorer （探索者）
• Shopper （推销者）
• Vacationer （度假者）
• Prisoner （囚犯）

这四个角色代表了四种与会的心态，可以通过与会者不记名的统计（匿名的在贴纸上写上代表自己真实心态的角色首字母）就能知道会议室里大家的实际情况。统计的结果不一定总让人欢欣鼓舞，但这个小小的活动往往能有效的唤起大家内心的思考，很有价值。

激活大家的发言欲望

事实证明，一个会议上，如果一开始大家就可以不需要发言，只是听，那么很大机会大家在整个会议上都将保持沉默，有没什么想说的，尽管会议中后期你希望更多人参与发言。办法是一开始就破冰。简单常用的方法是让大家按座位顺序轮流用一个词形容他/她对这个迭代的感受。只让用一个词说实话非常难，不过没关系，这个时候大家就会开始脑子飞快的转起来了，到底哪个词比较合适。这样不仅把大家带到了回顾的思路里，更重要的是大家一开始就有机会开口表达自己的想法了。

把大家带到这个迭代历史的回忆中来

在开始收集数据之前，让大家先回忆这个迭代到底发生了什么，这个至关重要，不然暴露的问题很可能变成天马星空的抱怨。上面用一个词描述这个迭代的感受是一个很好的方法，但除此之外还有心情曲线法也是很有意思的方式。方法很简单，就是让大家画一条基于时间轴的心情曲线。如图是一个团队真实的曲线结果，每个人都不一样，分享这个曲线的过程甚至能加强团队成员的相互了解，加强信任感。

介绍会议基本规则

如果团队有制定会议的基本原则的话，那我们需要在这个会议上同样需要遵守，常见的比如不适用电脑，不在会议上打电话等等。
还有需要介绍本次会议时长和大概的议程（流程）安排，让大家对会议过程和时间有预期。
当然这条是应该在最开始就介绍的，只是觉得没有特色，所以我放到最后才写，^_

收集数据

收集数据一般包含收集做的好的部分，做得不好的部分，有时还会创新想法部分。这个环节是回顾会议最具代表性的，发贴纸，然后大家各自写，一个问题一张贴纸... 如下图就是一个真实的例子：

上面这个方式用得非常广泛，就不多讲了。除此之外还有一些变形的方式：

• 通过视觉化的、隐喻性的方法做引导，比如帆船回顾法
• 模拟论坛接力留言的方式，通过书写来收集数据

产生见解

收集到了数据只是第一步，如果顺利，到此为止我们就能收集到大量的、反应真实情况的好的和需要改进的点。接下来我们需要整理了。
先分类，因为大家是各自独立写的，所以肯定会有重复的，所以把同类的放到一起我们才能让满墙的纸片不那么凌乱。分类需要花一点时间，但这个过程也是刚好让大家都了解其他人写了什么的好机会，所以我往往会邀请组员上来和我一起来做分类，一个人做卡片宣读，允许大家讨论，一个人把相同意思的卡片贴到一起。
对做的好的部分，我们需要提出来鼓励大家，希望我们能坚持下来，甚至做得更好。这个部分在实际操作中往往比较忽视，大家更愿意快点调到待改进部分。无论如何，如果发现团队士气低落，需要鼓励的话，这时就是很好的机会，每个做得好的地方你都能有感而发。
对待改进的部分，这个是本次会议的核心内容，不过很不幸，往往团队总结出来的待改进方面会比较多（>5个就算多吧），可会议时间有限，对这个部分，我们首先要做的就是确定优先级最高的核心问题（不超过3个）。确定的办法最常用的就是投票，比如每人两票。

确定改进项

当我们确定了待改进的重点之后，我们就需要讨论得出针对这些问题的改进方案。
不过别急，不要这么快就跳到了改进方案上来，针对问题我们要先分析问题的根源，找到问题最根本的原因，我们再针对原因采取改进行动，这样才能对问题做到根本的解决。

鱼骨图或5W的方法寻找问题根源

最常见的方法有鱼骨图法，如下图，使用方法就不解释了，大家自己google。

分组讨论

讨论寻找问题根源的的过程往往非常费时，这里常用的一个方式是把组员分组，每个小组专门讨论一个问题，我们可以限时让他们讨论出问题的根源和推荐出改进计划，这样我们一个能节省时间，更有价值的是可以调动每一个成员的积极参与度。

SMART的改进计划

一个老调重弹的就是所有的改进计划都必须是SMART的，SMART原则也不介绍了。这点说得容易，但做起来往往困难很大，大家非常容易产出一些类似建议一样的东西，完全没办法执行，这个要避免。

避免产出过多改进计划

当然还有一个陷阱就是改进计划过多，到时候团队根本没有时间完成这么多的改进计划，这个也需要排优先级；还有超出团队能力范围的改进要避免，不然也没法落实。

结束会议

结束会议如果有必要的话我们可以简单对本次会议的组织做个总结建议，可以帮助我们提高下次回顾会议的组织能力。

但我最喜欢的结束会议的方式是让大家每个人通过一张纸片的形式感谢团队里的一个人，并附上理由。我觉得这是一个很好的激励团队更多合作和相互帮助的好办法。写好纸片之后，我会请大家当众宣读一下卡片内容，并亲手交给自己感谢的人，纸片格式如下：

需要注意的地方

1. 一般情况不建议团队的经理参加回顾会议。这有悖于准备环节中提到的设立一个安全的环境，大家会担心在会议上暴露团队问题会对他们绩效产生不好的影响。但也有一种情况我们需要经理在场，那就是团队已经积累了很多非常严重的问题，但是经理可能都不大了解情况，大家都期盼的经理在场能听到并推动解决这些问题。
2. 会议产生的改进计划怎么有效的跟踪？一般我们建议把这些action之间放到团队下个迭代的工作列表中，和普通开发工作一样对待跟踪，只有这样才能有效的使得改进落地。
3. 前后回顾会议产出相同或类似的改进计划。这说明老问题一直没有解决，有的时候会发现每次改进计划都完成了，但是老问题仍然还在。一般如果想改进能力或是外部依赖的问题往往会导致这样的情况，这些不像团队自己的流程那样能立竿见影，面对这样的问题，团队最好能计划一些长期的（周期跨迭代的）改进计划，下次回顾会议可以监控进展，而不是提重复的问题。
4. 如果需要，别忘了在回顾会议前面简单过一下上次回顾会议产出的改进计划完成情况。