敏捷实践之回顾会议Retro

本文是个人总结摘记，部分文字摘自其他大神博文等，如有雷同，未列参考文献，请见谅；

定义

团队专注于交付目标，埋头干活的同时，也要懂得停下来总结过去，并更好地抬头看路。

• Retro是Retrospective的简写，即回顾会议，大家坐在一起，对过去的这段时间里，Team的工作状态（团队合作，技术实践，团队氛围等）做一个总结，它有一点基本思想：对事不对人，大家思想自由Open。

• 回顾会议能够总结过去，发现改进点，鼓舞士气，使团队在接下来的迭代或Release更有效且高效地交付价值做的好的方面继续保持及加强，做的欠佳的方面一起讨论改进措施，并尽全力落实。Retro让团队在实践中摸索出适合团队的最佳实践，引导团队和个人不断自我完善，追求卓越。

形式

• 会议的参加者包括整个Scrum团队、Scrum Master和Product Owner。会议由Scrum Master主持;

1 正式会议开始前

确认构建安全的环境。

• 就是每个人都是觉得当前的会议是可以自由发表意见的，而不是因为某些人（比如说不友善的Leader）而不敢发表意见。开始前每个人对安全系数打分，1~10分，如果平均分数偏低（比如低于6分），需要将Leader从会议中"驱赶出去"，直到大家觉得安全了才好。

• 如果跟客户关系融洽且相对容易参与进来，可以将客户Involve进来，然后一起构建一个安全的环境（有可能因为大家的打分较低，客户不得不“出场”，所以客户参与不是必须的）。

了解与会人的心态

• 这里有一种非常有意思的收集与会者心态的小活动，叫做“ESVP”：Explorer （探索者），Shopper （推销者），Vacationer （度假者），Prisoner （囚犯），就能知道会议室里大家的实际情况。统计的结果不一定总让人欢欣鼓舞，但这个小小的活动往往能有效的唤起大家内心的思考，很有价值；

激活大家的发言欲望

• 简单常用的方法是让大家按座位顺序轮流用一个词形容他/她对这个迭代的感受。只让用一个词说实话非常难；

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

• 就是让大家画一条基于时间轴的心情曲线。如图是一个团队真实的曲线结果，每个人都不一样，分享这个曲线的过程甚至能加强团队成员的相互了解，加强信任感。

2 写卡

• 建立几项总结指标（Well, Less Well，Suggestion，Action），每个人对前三项提出自己的看法。第四项是综合所有前三项的结果总结出来后面要做的事情。

• 使用Sticker纸片，最好是用马克笔写（这样一张Sticker就不能泛泛无边的写），一张Sticke写上一个点的内容即可。 编写Sticker内容的时间控制在5分钟以内，每个人自己将Sticker按照分栏贴好，然后Facilitator（通常是PM或BA）开始带着大家过每一栏的Sticker，对Less Well栏中，将同一类的问题归纳起来；

3 自有发言

• 如果Less Well栏中的分类比较多的话，大家可以根据分类的结果进行挨个投票，选举出本次retro最希望讨论和解决的问题，然后大家针对投票的前三位进行轮流发言，指出问题，发布自己的看法；

• 然后整个Team就这三个问题进行公开讨论，方式也可以是多样的。可以大家一起讨论，Scrum Master在讨论过程中将大家的观点记录在白板上；

• 讨论完毕后，对讨论结果进行分类。对于好的方便，在下个Sprint继续保持并发扬；对于存在的问题，列出Action Point去解决问题。列出的Action Point也会在下个Sprint的backlog中体现出来，并且是高优先级的项目。

4 产生actions

• Scrum Master根据大家的发言，总结一些actions，将Action栏中的Sticker指派Owner，并落实。

• 说得天花乱坠，没有行动，犹如竹篮打水。Retro这个环节最核心的产出物是Action，团队共同一致商量出来的措施，有没有效果就在于行动了，所以Action分配了Owner之后，一定要跟踪这些Action有没有落实执行。一方面，需要Owner拥有高度的责任心和执行力，尽职将这些Action落实执行。

5 结束会议

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

要点

• 一旦总结下来的，team leader一定要带领team尽可能落实，而不是只记在那里没人看，那样就失去了意义。

• 不引起任何变化的Retrospective只是浪费时间。retro主持人确保会议内容是积极的和有产出的；

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