用在线游戏召开大型回顾会

敏捷回顾往往是在团队或者项目级别上进行的。那么假如有超过 50 个团队的参与，这样的回顾会议应该怎样开展呢？ Luke Hohmann 写了一篇名为《如何在跨多时区的几十个团队中做大型回顾》的博客，在这篇博客中他介绍了如何在大规模敏捷转型项目中召开大型回顾会议，以探讨团队做得好的地方和需要改进的地方。

InfoQ 采访了 Luke，并讨论了大型回顾会的组织、数据的分析以及这种回顾会中的活动跟踪。

InfoQ: 你在文章中讨论了如何召开有许多参与者参加的大型回顾会。**“大型”**意味着有多大呢？

Luke: 所谓“大型”回顾会，我指的是要有上百人参与，他们往往跨越多个地点和时区。用另一种说法来讲的话，“大型”意味着“要花很多钱才能把大家集中在一个房间里”。可扩展的企业级回顾会提供了一个解决方案，此方案可以在有多个团队参与的情况下提高企业效能。

InfoQ: 在你看来，大型回顾会与团队或项目级回顾会的区别在哪里？

Luke: 参与人数决定了你不能经济高效地召开传统式的回顾会。频率也是不同的——单个团队的回顾会一般在一个 Sprint 结束后，或者在一次产品交付之后进行。项目回顾会在项目结束的时候进行。而企业级回顾会的召开节奏取决于组织级阻碍的发现和移除。而且由于对于大型组织来讲移除组织级阻碍需要大量的时间和努力，所以虽然企业级回顾会能带来很大的影响，我们也倾向不要过于频繁地召开企业级的回顾会。

InfoQ: 你为什么会在大型回顾会中做快艇练习？什么使它比较合适呢？

Luke: 快艇是一个很好的回顾游戏。它被设计成一种用于发现阻碍的开放式的、发散性的过程。游戏没有预先设定有哪些阻碍。这也是一种极为巧妙的暗喻：团队使用过船只、热气球、赛车、飞机等等任何想要去提高速度的东西，但是也可能会遇到一些会让其变慢的东西。

InfoQ: 你在文章中提到，大型分布式团队不做回顾的原因在于，他们**“遇到了改进的限制”**。你能说得更清楚一些吗？

Luke: 让我们看看只有一个 Scrum 团队的小型创业公司。假设在回顾会中他们发现需要迁移源码管理系统。所有的决策者都在一起，所有受到该决策影响的人也都在一起，甚至连财务负责人也在。所以他们可以做这个决定。

那么在一个由 47 个 Scrum 团队（大约 300 名开发人员）组成的大型的成熟的开发组织里，这又会如何呢？假设其中 28 个团队感觉目前的源码管理系统有问题，并打算更换到新系统上。这不是一个团队级的决定，而是一个企业级的决定。让我们进一步假设：经过反思，组织决定更换源码管理系统。但是，更换源码管理系统涉及到几百名开发人员，这可不是一件轻易的事情：这是一个很大的工程，需要通盘计划并仔细管理。要确保版本历史不丢失，以便于修复产品 bug，除了类似的这种显而易见的技术问题之外，开发人员还需要接受新系统的培训、集成和自动化测试系统可能也需要调整，等等……

InfoQ: 你用在线游戏来做大型回顾会，这是为什么呢？

Luke: 在线游戏的成本比较低，也能比较快地得到结果，团队可以在方便的时间做回顾，并且能够提供更好的数据分析。有些人比较内向，还有些人愿意说出自己的心声，而不是在公司里随声附和，那这种在线的形式能够更好地获得和描述这些人的想法。

在线让每个团队都仍然是一个完整的团队——因为在一定程度上，团队是所有组织工程的基本单位。

在线也可以有多个引导师，以减少引导师的偏差，并进一步增强结果。

InfoQ: 你是如何分析多个团队的数据，以决定需要采取行动了？

Luke: 我们通常是这样分析数据的：

步骤 1：每个团队都玩一次游戏。

步骤 2：每个团队的结果都下载到一个集中的电子表格里。这很简单——引导师只要把游戏结果下载，并将其上传到一个共享的电子表格里。

步骤 3：按照“人”、“过程”、“技术”以及控制范围编码区分结果。尽管这更利于大团队开展这个游戏，但我们建议 2 到 3 人的小团队也这样区分结果，可以更加地快速、统一。

游戏中的每样物品都应加以编码区分——如果你使用的是快艇，那意味着所有的锚和螺旋桨都要这样做！

我们建议把所有事物编码区分为主要的“人”、“过程”、“技术”，以及（可选的）次要的“人”、“过程”、“技术”。例如，“我的 PO 不参加评审会议”应该将“人”作为主要编码，将“流程”作为次要编码；而“我们需要切换到 GitHub 上”只需将“技术”作为主要编码就可以了。

接下来我们推荐使用 Diana Larsen 的 Circles 和 Soups 分类系统来评估解决阻碍的控制级别。

• 团队级：这个级别的问题可以由团队来解决。例如，如果 PO 不参加评审会议，这应该在团队内部解决。
• 产品或群体级：这个级别的问题是团队不能解决的，而适合于产品或群体范围。
• 企业级：这个级别的问题需要企业级上的协调努力。例如，迁移到 GitHub 有可能影响到企业内的所有团队。因此它应该作为一个潜在的企业项目进行仔细地评估，并与其它高影响的项目做比较。

在线聊天记录对于发现潜在问题有巨大的价值。

我们常常做扩展分析，以发现在游戏过程中不知不觉产生的各种偏差。有些偏差会影响到你的结果：

积极性偏差是人们 [团队] 中普遍存在的一种趋势，尤其在那些具有高自尊的、认为自己具有积极特质而非消极特质的人群中更为明显。在团队被要求发现“螺旋桨”的时候容易发生积极性偏差。要捕获这一点，我们寻找螺旋桨或含有雄心壮志的聊天记录，如“我们可以做这个……”，或者规定性语言，如“我们应该做这个……”。

如果只有组织中的一小部分（例如 60 个团队中的 20 人）或者只有一类团队参与，会出现抽样偏差。你的目标应该是至少有 90% 的团队参与。

方法或问题偏差会不适当地引导参与者对问题的回答。通过保持开放性，_ 快艇 _ 等游戏将最小化方法和问题偏差。

我们希望大型分布式团队回顾的负责人在他们的研究报告中考虑任何潜在的偏差，并对其进行评估。

步骤 4：分析结果去发现模式。 [夏 1] 数字化结果的一个巨大的好处是可以用像 R 和 Qlikview 这样的复杂工具来分析数据。对于试图说服高层领导这个组织级范围的障碍来说，这样的可视化结果是非常有价值的！

步骤 5：模式转化为潜在项目。这个步骤可能需要一周左右——这是件好事！你正在寻找极具高影响力的机会。在这上面花费的时间将使你得到巨大的回报。

步骤 6：选择项目。项目数量少的话可以全部都做。如果有很多项目的话，我们可以用 _Buy a Feature_ 的方式来决定。

InfoQ: 你如何跟进从大型回顾会中产出的行动？

Luke: 我想，使用敏捷和精益看板的组织标明那些要移除已识别障碍的项目，并在实施过程中对整个公司保持这些项目的可见性，它们正在以此践行着透明的价值观。显而易见地是，在大多数情况下消除一个企业的障碍几乎总会改变个人和团队工作方式。

InfoQ: 除了回顾会以外，还有什么方法可以发现在组织中做得好的和需要改进的地方吗？你在什么时候会用这些方法呢？

Luke: 一些公司发现匿名调查有助于发现改进的机会。如果员工们仅仅不想彼此合作或者不想采纳敏捷的话，我会建议使用问卷调查而非 _ 快艇 _ 游戏。

查看英文原文： Huge Retrospectives with Online Games

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。