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