Scrum Master身上背负的一个很重要的职责就是让回顾会议开的成功，不然就有虎头蛇尾之嫌，更何谈good to great呢？

  长期以来我们的回顾会议都是这样进行的，到点了，大家拿着笔记本进入会议室，一番闲聊之后，主持人开始打开文档模板，简单的介绍一下会议的流程，然后简要的回顾一下这个冲刺我们都承诺了，实际作了什么，期间发生了什么。接下来顺着座位顺序，各自发感想。感想一般都是可以拿之前的拷贝。然后逼不得已的选一个root cause。结束。整个会议充斥着应付，所以更大程度上是一种休闲。

  问题在哪？没有惊喜。什么是惊喜？惊喜就是你浑浑噩噩的进入会议，你心中在背诵主持人的发言稿时，发现他早已将稿子撕毁改为即兴。其实，没有什么是惊喜，没有什么是即兴，一切都是提前安排好的，精心设计过的，只不过你不知道而只有一个人知道，那就是Scrum Master。

  我看过很多文章，都说可以让会议主持采取轮换制，我一向不赞同。很简单。会议主持是一个需要非常高的综合素质且长期专门思考并实践的活动。如果每个人都知道自己接下来会被轮流，那么他会懒于思考，就算是思考也是不系统的即时的，事后会被遗忘的，绝对达不到应有的效果。

  所以，我设计的回顾会议主流程没有什么大的变化，但是在细节上需要更加的开放且具有指导性。

  会议的开始是问每一个人这个冲刺什么事情让你印象最深或者最开心？什么事情最沮丧呢？在你最开心或者最沮丧的时候你想起了谁？你需要的肩膀有没有在你最痛苦的时候出现呢？这个肩膀够不够宽阔？这些问题都是希望大家能留意整个开发活动中自己所处的位置，明白自己是Unique的，是团队的主人。

  接下来，希望开发人员回顾一下测试在整个冲刺中作了哪些事情？BA作了哪些事情？文档作了哪些事情？哪些事情都你的工作产生了影响？什么影响？你是如何处理的？希望以后继续还是最好不要。。。通过这些问题，来促进大家平时多关心别人在做什么，我可以主动帮什么忙。。。。等等吧。

  在这些答案中，我们找寻哪些作的好，哪些作的不好，应该是相当容易的。就算这是nominal group的变种吧。

  有了这个基础，我们就可以利用鱼骨图进行root cause的分析。fishbone本身也是先发散后收敛的方法，也可以充分调动大家的积极性。网上资料太多，在这就不解释如何操作了。

  还是希望把整个回顾会议开的“有趣”一些。