回顾（review）是敏捷开发中的一个必不可少的实践，也是把整个敏捷开发过程连接成一个闭环的关键节点，本文将阐述我们是如何做敏捷回顾的。
敏捷回顾最高指导原则
无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。
敏捷回顾的目标
发现问题，持续改进。
敏捷回顾常碰到的问题唉，又要开总结会了…每次时间都那么长问题讨论来讨论去就那几个，没啥新意都不记得这段时间做过啥了新迭代KO，总结放在一天时间太紧我们敏捷回顾会议内容
1.产品数据
目的：通过分析用户数据来看我们的产品设计是否赢得了用户的认可
做法：收集前一迭代上线后的相关产品数据，如新功能使用日UV、PV等，当然如果发布后第二天召开回顾会议，可能不能马上收集到相关数据，也可以分析上上迭代的新功能使用情况。
2.项目质量
目的：通过项目过程数据来看质量
做法：分别从冒烟测试通过率、bug分析、集成测试方面来衡量项目质量，找到做的好与不好的原因。bug分析可以通过QC导出统计报表，从多维度进行分析，bug等级，引入层级等方面，如下图：
图1：缺陷引入层级统计
集成测试可以通过集成测试框架如Hudson，主要关注单元测试覆盖率，通过率以及注释率等指标，如下图：
图2：集成测试情况
3.各抒己见
目的：总结项目中做的好的，不好的
做法：从KEEP（做的好的，要保持的），CHANGE（做的不好的，需要改进的），TRY（可以尝试的）三个方面进行总结。首先回顾下上次总结会议列出来的CHANGE和TRY事项，看看前一迭代做的怎么样；接着总结前一迭代的情况（每个团队成员在回顾会议前都先想好，写到便签条上，防止说的时候人云亦云），将每个人说的汇总，并由大家投票列出哪些可以在下一迭代中改进以及尝试，列出具体的action，建议不要多余三项，否则太发散什么都做不好。如下图：
4.个人总结
目的：督促项目成员自己做总结，看有哪些收获和遗憾，不仅要项目成功，成员也有要有所成长，也便于项目经理后续的任务安排有所侧重
做法：成员轮流发言，总结自己在前一项目中的收获和遗憾，尽量具体，收获指的是工程师在技术方面学到了些什么，总结了才会有成长，遗憾则指的是项目启动时给自己设定的目标或计划没有完成的。
以上就是我们敏捷回顾中的4个部分，在组织会议上可以适当采取轮流主持，以及准备些水果、零食，利于大家保持放松，经过前一个迭代的紧张开发和测试，通过敏捷回顾稍作休息，整装待发。