使用大型敏捷回顾改善项目

  • Ben Linders
  • 侯伯薇

2013 年 5 月 27 日

话题:文化 & 方法

回顾能够帮助团队了解并改善他们的工作方式。你能对回顾进行扩展,使其可以适用于大型项目或者多个团队参与的项目吗? 几位敏捷教练已经做到了这一点,他们使用了回顾和开放空间(open space)技术。让我们来看一下他们是如何做的。

在博文如何做大型回顾中,敏捷和精益教练 Henrik Kniberg 介绍了它在 Spotify 做过的一次大型回顾:

这次回顾的目标是要收集从一个大型项目中学到的内容,那个项目涉及到几十个团队,进行了半年多。团队在项目中已经做了 sprint 回顾,但是我们还是感觉需要把这个大团队聚在一起,并看下全局的情况。

回顾帮助 Spotify 深入了解他们所学到的知识,为改善定义的建议,以及发现的“神秘情况”。问题需要在之后进一步确定。Henrik 描述了这种大型回顾和一次 sprint 的回顾之间的区别。

这个事件要求更高,因为我们在屋子中集中了很多人,并且期望具体、可执行的输出。Norm Kerth 关于项目回顾的经典著作对如何做这件工作提供了很多有用的想法。

之前,InfoQ 曾经在《scaling agile at Spotify: an interview with Henkrik Kniberg》一文中叙述了 Spotify 采纳敏捷的情况。Spotify 的敏捷教练 Joakim Sunde 在博文《在 Spotify 实施大型回顾》中描述了如何在 Spotify 完成大型回顾的细节。回顾被分割成三个部分: 过去(项目所反映的)、现在(对相关话题的讨论)和将来(按优先级排序以及展现关键信息)。

在过去部分,回顾的参与者会检查项目是如何做的,并将项目的时间线可视化:

我们的首席产品官首先对期望的项目结果给出了自己的看法,从不同团队之间改善了的合作,到实际的交付物,还有项目成本,像挫折、技术债务和替换成本等。他以活动挂图的形式来展现这些内容,每个人都可以在那天之内添加他们自己的东西。

在回顾之前我们都接到一个作业,收集与项目相关的内容。(……)我们使用这些挂图,并把见解、对事件的记忆、感觉、挑战等等都写在便签上,从而在墙上准备好的纸上构建出时间线。

基于时间线,他们会询问参与者对项目的感觉如何,以及他们认为项目成功的程度如何。便签被用来收集信息,并让每个人都看见。

为了探究展现的情况,参与者在午餐时间准备的主题会被收集在一个时间矩阵图上,并使用开放空间的方法来讨论。

每个阶段的目标是,产生一些见解和建议,说明将来应该继续做哪些工作,应该以不同的方式做哪些工作。我们会鼓励主题发起人确保在阶段过程中收集了那些内容。如果我们此时此地遇到一些重要但无法解决的事情,就会标记为“神秘事件”。

开放空间阶段(见解、建议和神秘事件)的结果会展现给小组成员。我们会对问题进行清理,重复的会被删除,并且会把问题清晰地写下来,从而参与者可以对问题进行点投票(dot votes):

所有人会在大屋子中再次集合,那里会有一个人形看板展现每个活动挂图,有人会大声读出那些记录。我们还对拥有几个黑点和几个绿点的一些笔记做简短的讨论,从而更好地理解为什么人们对这些内容有如此不同的看法。

这是回顾中他们叫做“将来”的部分,其中参与者会记录下他们在回顾中获得的主要收获,并和大家分享他们学到的知识。

在博文如何引导大型回顾中,敏捷变革代理人(agile change agent)Rob van Lanen 描述了他是如何和一大组人做回顾的。他首先说明了每个阶段的目标,然后加以介绍:

让每个人都简要地介绍,然后“签到”。如果人们在会议开始的时候发言了,那么在会议中间就更可能会发言。

参与者会把他们自己组织成关于各种话题的小组,然后请求定义能够讨论的主题。

在我们的案例中,我请他们对过去一年间最重要的五点排序并达成一致,每个记录在一张便签上。

每组都有一位引导师,他会为该组向所有参会者说明主题。主题会被收集在一起,删除重复的内容,然后投票:

请每个人各自投票(在便签上),在各个项目上显示票数。告诉他们总共可投票数(可能甚至是他们能够在一个项目上所能够放置的最大数量)以明确限制。我选择私人投票,那和公开的点数投票相比会有更小的影响。在后面的方法中,先投票的人会形成一种趋势,之后的投票者可能会跟着走。我想要避免这种情况。

胜出的主题会在“鱼缸(fishbowl)”阶段(来自于开放空间的一种技术)讨论,然后会定义动作并达成一致意见:

在我们的案例中,我们想要重新回顾去年的重点话题。我们讨论了达到这个目标的措施。作为引导者,你的角色是始终让大家看到。如果人们有时很难创建可实施的任务,那么你可能会总结、使其敏捷并提出强有力的问题。

和一大组人做回顾的解决方案是“回顾之回顾”。Paulo Caroli 在他的博客“回顾之回顾”中描述了如何做。他首先说明了在项目级别对回顾的需求:

团队会从回顾这种敏捷实践中获得很好的价值。但是改善是在团队层级上做出的。总体项目没有关注持续改进。有时,一个团队回顾中的动作点(action point)依赖于其他团队。还有时,两个团队回顾的动作点会截然相反。

为了给大型项目团队做回顾,他们引入了一种与 scrum 之 scrum 类似的技术:

回顾之回顾(简称 RoR)会议会在每个单独团队的回顾之后进行。参与者(所有团队以及项目的代表)会在一起讨论什么进展得良好,什么应该在项目层级上做改善。RoR 的关注点在于改善总体上的项目输出,而不是在于单独团队的绩效。

Paulo 认为回顾之回顾的一些好处有:

快速接触到所有团队——所有经理和利益相关者都能够看到每个单独团队的首要项目。

关注与改善——对单独团队和项目层级都是一样。

所有经理(……)会周期性地对项目的总体目标进行讨论,并加以实施。

任何单个团队的问题都会让所有团队都听到。

查看英文原文:Using Large Agile Retrospectives to Improve Projects
文化 & 方法