团队组成（PO：1人；开发：6人；测试：2人）
一、 议程设计
目前团队采用固定2周作为一个Sprint进行迭代开发，所以我们回顾会议程设定为2小时的时间盒来对迭代进行复盘；
0）团队安全宣言和工作协议走查（5min）
只用5分钟左右，增加回顾会开始的仪式感；
1）迭代质量和进度回顾（15min）
团队当前迭代交付的需求数量，发现的BUG等级分布和数量以及燃尽图；了解当前迭代的质量，进度控制，整体交付质量情况；
2）收集信息（20min）
团队所有成员轮流发言，对本次迭代的感受以及做的好的地方，可以改进的地方进行阐述，并在Confluence上进行记录；
3）讨论发现并分析根因（40min）
团队成员对所有记录开始逐条分析并回顾各问题，并分析根因；
4）寻找改进措施（30min）
团队成员对所有根因进行寻求改进措施；
5）投票（10min）
团队投票确定下个迭代进行改进的Action，具体Owner，执行结果，最晚期限等；
二、引导过程
收集信息：引导团队从工具，工程实践，BUG的出现，团队配合，设计等角度进行回顾问题；使用开放性问题引导成员进行回顾；例如：这次迭代你觉得有那些事情你会在下个迭代接着这么做？你觉得那些事情你做了让你感觉难受，并下次不会采用这次相同的方法来做？团队自察后将问题记录在Confluence上，所有问题遵循SMART原则，不空洞，记录到具体的事情有利于后续分析和找原因；
分析根因：采用5Why方法和向内转原则，引导团队寻找深层次原因；
寻找改进措施：向内转原则，引导团队我们能做什么来避免下次出现此类问题的出现，可从工具改进，协作方法，文档格式改进等方面寻求改进；
三、成果
团队能从质量进度情况，回顾到迭代出现的问题；并通过问题寻找根本原因，从而大家头脑风暴具体措施；最重要的是团队向内转，找到自身能够做出的措施，而不是寻找外部原因；
通过最后投票环节，团队共同确定改进点以及Owner和时间，做到闭环；
四、自我反馈
1 自己的业务知识和工程实践，代码知识不够，往往不能协助团队找到根本原因；5Why寻求根因的方法使用也需要不断加强，一般在实践中问2-3次就找到了原因，但是根据后面改进的情况来看找到的并不是根本原因；
2 时间控制：遇到无法控制时间，超时讨论且无法收敛问题；后续需增加训练，使用定时器定时提醒，及时提醒团队专注问题本身，发散思考后收敛问题；
