正如 Norm Kerth 所说,“回顾会议”最初的定义是“一个为期三天的离位(offsite)会议”。从那时起,敏捷社区就开始这个实践并使其成为每个迭代的一部分。每个敏捷回顾分为五个阶段进行,但在时间方面并没有一个具体的指导。在 Rachel Davies 最近的《用回顾重构你的开发过程》一文中,她建议我们每个星期用 30 分钟的时间做回顾。我看到很多团队想使这个时间最小化,有的甚至只有 15 分钟。那么一个回顾会议到底要多长时间呢?
对于敏捷回顾,Esther Derby 和 Diana Larson 告诉我们:“每个回顾会议应该有以下几个阶段”:
- 准备
- 收集数据
- 达成共识
- 决定做什么
- 总结
对于每个阶段,他们都用了几个不同却通常行之有效的实践(例如,用三个问题“在这个迭代中,你认为不该做的事是什么?令人不快的事呢?令人愉悦的事呢?”来收集数据)。但完成这五个阶段需要一个小时(可能不会少于两个小时)。如果迭代周期是一到两个星期的话,那你想在每个迭代结束之前都花上两小时做回顾吗?
在 Rachel Davies 的文章中,她建议每星期 30 分钟:
时间方面的一个粗略计算是:团队每星期需要三十分钟的回顾时间,也就是每个月两小时,这就相当于使用一天的时间可以对几个月的工作进行回顾。
难道这暗示我们每个月做一次回顾就行?还是说对迭代周期只有一两个星期的团队,每个迭代应该用 30-60 分钟来做这件事呢?在这么短的回顾会议上,我们怎么来完成这五个阶段呢?
最终,很多团队采用 15-30 分钟完成五项内容中的几项,而不是全部。如果他们认为从某项中得到很少的价值,那么这次就放弃或以后再也不要它了。
所以,这方面有很多各式各样的建议和实践。什么是最有效的?你的经验是什么呢?你们做规律性回顾吗?如果有,是多长时间呢?你认为它们是有效的,还是在浪费时间?
评论