议程设计

·宣读敏捷回顾最高指导原则（3mins）

·回顾上个迭代行动计划项（5mins）

·头脑风暴我们这个迭代中都完成了哪些工作（10mins）

·分组（2mins）

·引导团队我们哪些事情觉得做的很好，哪些地方还可以做的更好（40mins）

·针对讨论的结果制定具体行动项（15mins）

·总结（5mins）

回顾会议过程

    第一次宣读敏捷回顾最高指导原则，大家可能觉得我们像小学生大声朗读课文一样，我认为这是一个很庄严的事情，非常有道理的一个指导原则，我把我对整个原则的理解给大家说明，并且采用了已离职同事的一些举例案例对大家进行了解释，也能够获得大家的点头认可。

    当我们回顾上个迭代我们做过的事情的时候大家说我们就做了大的功能模块，大家的都是一样的，我对大家的说法表示赞同，但是我通过提问的方式引导大家更多的说出了自己具体分工做的工作项，比如你完成这部分工作都有谁帮助你一起完成，你们具体是怎么分工的，期间遇到了什么问题，后来怎么解决了，这似乎打开了大家的话匣子，引导还是非常重要的。

    让大家在便签上记录下我们做的好的地方和可以做的更好的地方，但是忽略了一点就是没有明确让大家写几条自己最重要的进行分享，导致有的同事写的很少，有的则写的很多，我们在下一步分享自己的内容的时候导致写的非常多的同事说的也就特别多，时间花费也比较多，导致40分钟总时间显得比较局促，事先也没有规划好我们在这40分钟内做事的顺序，对时间把控也不是很好，导致这个环节占用太多时间后面时间就不够用。

    让大家讨论的过程中虽然通过引导的方式让大家知道自己应该写一些什么，但是组内的讨论几乎没有，继续引导大家想不想看一下其他同事是怎么评价的，有什么不同的看法，这个方法也勾起了几名同事的兴趣，展开了组内之间的讨论，还是实现没有约定讨论的时间，导致时间失控。

    讨论的期间尝试用聆听的方法去了解大家都在讨论的问题，由于先前的引导，大家的思路可能被我带入了，缺少发散性的思考，来来回回问题就是那几个，后面对于引导的方法还需要做一些优化，在聆听期间也感受到了一些大家真正的想法，会引导大家对于这些问题自己给出解决方案。

    最后我们针对大家的看法做了汇总，通过收敛的方式把做的好的地方总结为3个方面，可以做的更好的地方总结为3个方面。我把做的好地方通过跟我们以往的方法进行了对比，大家清楚的意识到我们采取这种方法确实能够提高我们的工作效率和工作质量，我相信大家已经体会到了敏捷给大家带来的优势，后期也会继续保持。重点在于分析那些我们可以做的更好的事情：自测怎么才能落实的更彻底；需求方面怎么能更加详细，减少需求的变更；会议太多，减少开会时间。

    自测落实的部分给大家引用了Scrum价值观中的尊重，提倡大家尊重团队其他成员的劳动成果，充分利用测试编写的测试用例，这些测试用例也是劳动成果，如果不好好加以利用也是对测试人员工作的不够尊重，换位思考一下，如果测试对开发同事的代码进行粗略的测试，等线上代码出问题可能问题还是在开发同事身上。这一点得到了大家的充分认可。

    需求方面给大家引用Scrum的拥抱变化和勇气，通过教导的方式给大家讲解了为什么会一直变化，不断的需求变化可以给我们带来什么好处，我们需要勇气去面对这部分变更，我的这部分工作还是比较满意的，大家也可以比较容易的理解这其中的奥秘，减少抱怨的情况，但是产品一些方面我们仍需要优化。

    针对会议太多，这方面应该是在以往的会议中我没有系统的规划每一个会议的各个环节，导致会议不够紧凑，效果就不是很明显，会让大家觉得开会是在浪费时间。在这个环节中我也用教练的方式给大家示范每个会议的用途，我们应该怎么提高开会的效率，每个会议应该有什么样的产出和目的。后面我会按照我们讨论的会议方法去进行会议。

这次回顾大家的收获

    首先这次会议之后是在ACSM培训之后的第一个回顾会，把培训中学到的一些方法得到了应用，事情也在逐渐朝着比较好的方向发展，这一点非常值得高兴，团队和我的互动沟通中也获得了很多新的知识和方法，我们针对可以做的更好的方面也制定出了两点具体的行动项：1.自测落实，尊重大家的劳动成果。起码进行冒烟测试，由测试和产品进行监督；2.需求评审会的优化，产品落实；3.管理系统中的一些前端样式规范，指定一个前端工程师落实。

    最后大家也互相发表了自己的意见，以后会议我们还会按照这种方式开下去，继续发现我们可以做的更好的地方，对于我们自认为做的还不错的地方继续保持，持续改进。由于前面提到的会议时间掌握的不好和一些为提前准备的事项，会议时间延迟了20分钟左右。