Agile Retrospective

　　相信经历过敏捷回顾的朋友们都会对回顾会议有一个结构化的流程认知，这个流程大致包括以下几个内容：

预设会议基调

　　回顾会议一开始并不是直入主题，而是要让团队成员抛开迭代开发中的苦闷，休闲一下放松心情，特别是营造一个良好的便于讨论问题的氛围很重要，能够让人人都发言是重点。主持人（一般是SM，Scrum Master）会在此期间重申回顾会议的目的和此次会议的目标。

收集数据

　　一个迭代中发生的事件很多，一个人（即使是Leader或SM或PO）不可能了解完这些所有的事件，因此需要从所有团队成员那里收集这些数据（一般指事件），让这些数据绘制成一幅共享图，记录所有发生过的事件。这些事件中有的是值得高兴的，有的是令人苦闷的，找到这些苦闷的并试着去解决它就是关键。

决定做什么

　　记得彼得德鲁克在《卓有成效的管理者》中建议“一次只做一件事”，同理，一个迭代的时间有限，团队成员的精力也有限，我们需要在收集到的数据中选出1~2个优先级最高的，对后续迭代价值最大的事情进行解决，产出能产生积极效果的行动方案。

激发灵感产生见解

        找到了那些令人苦闷的事情，这时就该问“为什么”和开始考虑解决这些问题的方法了。大多数人的思维是：一旦出现问题，人们容易一下就跳到解决方案上，最初想到的解决方案可能是对的，但大多数情况下都不一定是对的，往往是治标不治本，因为并没有找到其根本原因。因此，在这一步骤中，我们往往会通过一些方法究其根本原因。

总结结尾

        所有好事都有个尽头，回归会议也不例外，该结束时就结束，这时可以感谢每个人在迭代开发和回顾活动中的努力，以此作为回归会议的结尾。

敏捷回顾会议的一些实践总结

在这几年实践敏捷的过程中，发现自己一直开不好回顾会议，因为这个会议真的很难，但也在不断的学习和被领导指点的过程中有了一点自己的实践总结。

设定一个安全的吐槽环境

        虽然敏捷强调自组织和扁平化，但是并不代表大家都能敞开心扉，因此在经历一个迭代之后，让大家都能敞开心扉的聊一会天，吐一下槽，得到迭代开发中最真实的感受很重要。但是，不是所有人都能说出来，可能并不是他不想说，而是你创造的环境并不让他觉得安全。因此，我一般都会选择在迭代的最后一天下午进行回顾会议，这天下午不安排什么工作，大家休闲一下，进行两个小时的回顾会议。会议地点我一般会选择一个宽敞一点的会议室，然后提前买好零食和饮料（公费报销，一般也就30块左右），关好会议室的门，给大家一种关起门来high的感觉，团队成员的防备心就会减弱，有利于敞开心扉吐槽大会。

 安全的划水环境必备—零食与饮料

　　此外，回顾会议不是“批评与自我批评”，更不是“问责和处罚”，要以一种休闲且认真（是不是很矛盾）的心态主持这个会议，否则即使团队成员人人都开口说话了，但仍然达不到想要的效果。最好的效果就是，要让团队成员觉得在回顾会议上没有领导，啥都可以说，反正回顾会议一结束，说过的话大家就都忽略了。

激发团队成员的发言欲望

        有了安全的吐槽环境，但还是有可能一些同事由于性格原因（虽然大多时候都是闷骚）不愿意多说话，这时候就需要主持人通过一些小桥段或者小游戏让他们多说话。这时我一般会采用一些小游戏来暖场，比如我会准备一些打印好的纸条，里面写着“在Sprint 3，我最想感谢______，因为________________________”，然后给大家5分钟时间，每个人完成这个纸条来写下他最想感谢的人，并说明不少于10个字的原因。5分钟之后，不少人写完了，这时我会告知大家被感谢的次数最多的人会请在场的同事一人一杯奶茶。然后，这时就可以安排成员们一个一个上来说了，现场氛围一下就可以达到火热化，每个人都在计算着自己被感谢了几次，最终某个成员被感谢了多次，被迫请了奶茶。最后，我也准备了一个道具“荣誉证书”，送给了这位被迫请奶茶的同事聊以慰藉。

　　激发团队成员放松下来开口说话的方式有很多，必要的暖场活动也是需要的，毕竟，有些时候仪式感还是很重要的，不要觉得麻烦就不去弄，你的心思最终都会被团队成员看在眼里的。

　　最后，为了回顾会议能够高效进行，除了要暖场保证会议在一个较为轻松的氛围中进行，同时还得约定一些“协议”。比如，我会要求团队在回顾会议期间尽量不玩手机，如果有人违反这个协议，那就会罚款5元加入团队的公款账户或者请某人喝一杯奶茶之类的约定，这样下来，大家都会集中于回顾会议本身而非三心两意。

收集数据时一定要落实到具体事件

        在收集数据时大多数时候采用的一般都是“高兴-悲伤”或者“愤怒-悲伤-高兴”法，要求团队成员使用不同颜色的贴纸或卡片来描述他们在迭代中不同时间段的情绪感受，但是大多数时候团队成员都只会描述一个简短的说明语句而并非具体的事件。例如，成员A会说我悲伤的是代码质量差，这就是一个非常笼统的说明，而并非一个具体的事件。而我们在主持收集数据活动的时候，一定要引导成员落实到具体的事件中去，即到底是什么事件让你感到悲伤？因为如果不定位到事件，后续无法准确的去挖根本原因。这里需要注意的是：在描述事件时，一定是描述事件的现象，而非描述事件的解决方案（虽然程序员大多都喜欢提前解决问题，跳入实现细节中去）。

　　其次，在大家发表做的好的和做的不好的时候，应该特别注意“对事不对人”的原则。举个例子，我们可以说“代码评审不充分，所以代码缺陷较高”，不能说“某某某评审不认真”，当然夸人帅还是可以的哈。如果违反了这个原则，主持人（比如Scrum Master）一定得记得纠正和防止走偏。

　　最后，对于Scrum Master或者Product Owner，最好在最后再发言，以避免对团队成员产生一定程度的干扰。

一次只优化一个问题

       收集完数据之后，通过将各个成员的数据进行分类，然后汇集所有成员进行探讨，找出其中的一项（建议一项，毕竟人的精力有限，事实证明，多了你也实践不好）作为后面分析原因和找出解决方案的项。很多时候，很多团队往往希望尽可能多的在一次回顾会议上想要解决团队成员提出的多个问题，但事实证明，那是不现实的，最后往往一件事都没做好，因为看到事情多，所以没有分析到根本原因，导致问题重复出现。

一定要探求根本原因

        在《敏捷回顾-团队从优秀到卓越之道》一书中，对于产生见解并寻找问题原因这个步骤例举了很多的方法，但最为有效也最为常用的只有5个Why或者鱼骨图法，我一般都用5个Why法。

　　所谓5个Why就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因。虽为5个为什么，但使用时不限定只做“5次为什么的探讨”，主要是必须找到根本原因为止，有时可能只要3次，有时也许要10次，如古话所言：打破砂锅问到底。

5个Why法的关键所在：鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱，从结果着手，沿着因果关系链条，顺藤摸瓜，直至找出原有问题的根本原因。

　　在实践5个Why的过程中，需要注意的是：

• 如果给出的原因多于一个，那么试着找出所有原因的根源；

• 分析完成后，要从最后一个为什么开始反推“问题的现象”，确认反向逻辑也是正确的；

　　下图是一个5 Why分析的运用形势图，来源于互联网：　　

持之以恒贯彻执行

        “没有做到真正地贯彻执行”是回顾会议存在的最大问题，也是我碰到过的很多团队都存在的问题。一旦分析到了根本原因，我们需要制定出解决方法，通常我们会通过制定团队规则（比如没有经过自测并完成测试用例优先级为2的代码不能提交测试环境等）或者增加Backlog Task（比如为所有backlog增加Code Review环节）来在后续的迭代中贯彻执行，并且在下一次的回顾会议中来一起评价一下这些解决方案是否有效，如果大多数成员都觉得有效，那就证明我们花费的时间是有成果的。

小结

        一个团队总说他们现在太忙，没有时间来开回顾会议，没有时间让自己变得更好—从未来的角度看，这就是一个非常短视的观点。在《高效能人士的七个习惯》一书中，Stephen Covey 使用伐木工人花费数天时间用锯条砍伐一棵树来做类比。最终，锯条变钝了。但是，由于目光短浅，伐木工人永远不会停下来磨锯。一个同样目光短浅的团队也不会花费60到120分钟来寻找改进。相反，他们将那60到120分钟里可能开发出的一点点代码看得更为有价值些。

　　很多时候，我们都会因为走得太快，低头玩手机，而忘记了停下来“回顾”这一路的初心，我想对于敏捷团队来说，那应该是就是：

• For a better future;

• Learn from past;

• Take action in present;

　　愿我们都能定期停下来看看来时的路！

附脑图分享：

参考资料：

Esther Derby / Diana Larsen，《敏捷回顾-团队从优秀到卓越之道》（★★★）

森林游泳的鱼，《敏捷回顾-团队从优秀到卓越之道学习总结》

刘恒，《华为云敏捷回归会议实践分享》

Unknown，《敏捷开发中回顾会议是什么？为什么总有人开不好回顾会议？》

Ben Linders，《从敏捷回顾中收获价值》

Holger Paffrath，《Agile Retrospective : Lessons Learned》