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

回顾能够帮助团队了解并改善他们的工作方式。你能对回顾进行扩展，使其可以适用于大型项目或者多个团队参与的项目吗？ 几位敏捷教练已经做到了这一点，他们使用了回顾和开放空间（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