回顾之回顾

当你的所有团队都使用敏捷、忙于实施本地改进之时，在过去被称作“IT”或者“系统开发”的更大范围的组织中，会发生什么？一位大型敏捷项目组的教练分享了一个策略，他们打算让更大范围的团队社区发现趋势并从所有这些知识中获益。ThoughtWorks 公司的 Paulo Carol 将其称作“回顾之回顾”（ Retrospective of Retrospectives ）。其中有些取舍需要权衡，大型项目向来如此。

反馈是敏捷软件开发方法的一个基石。它是团队定期采取的重要间歇，用以进行“检查和调整”，留意他们的流程和产品中的警示并做出反应，发现那些在急促的交付过程中可能被疏忽的机会。ThoughtWorks 公司的 Paulo Carol 的项目有着十几个 15 人的团队，他在其中注意到，团队层面上发生改善的同时，整个项目组却逐渐丧失了对持续改善的关注。

有些时候，一个团队的回顾产生的行动计划依赖于其他团队；还有些时候，两个团队回顾产生的行动计划互相矛盾。

项目组面对的另一个挑战是，项目组层面的管理层没有渠道去了解问题和改善。“项目组经理（和其他人）想要参加每个团队的回顾会议，可同时参加多个会议根本就是不可能的。”

Caroli 的解决方法借用了 Scrum of Scrums 的智慧：回顾之回顾，简称 RoR。

就像每日 Scrum 被扩展成了 Scrum of Scrums……我提出了大型敏捷团队开展回顾之回顾的想法。…RoR 的语境是：“我们作为一个团队（整个项目组团队），需要做什么去改善项目整体产出呢？”

RoR 的参加者包括所有团队和项目组的代表，包含了每个团队的经理，和该团队的另一个成员（此人不是必须的，可以轮流担任）。他的起步指南没有指出产品管理部门的参与，但这可能是被所使用的角色名称掩盖了。该会议从每个团队回顾中的最高 5 个要点开始，对去除重复项之后的结果进行投票表决（想必是为了决定讨论的先后次序）。

这里我们撞上了大型项目中进退维谷的局面：是的，让经理们亲自走访所有团队十分困难，所以，由团队来见经理。这样的多对多会议很可能变得大大超过敏捷所推荐的小组人员规模，而与通常的回顾会议相比，需要更多促进措施来弥补会议中亲密感的缺失。

Caroli 记录的关键效益包括：

• 所有经理和利益相关方都知道了每个单独团队的优先工作和行动项。
• 仅需一个会议即可。
• 共同的目标：所有参加者定期对项目整体目标进行讨论和行动。
• 每个人都能让其他人听到：任何团队内部的问题都会被所有团队了解到。

这一清单产生了个问题：在这里，回顾会议的保密性又如何确保呢？采用这一体制，在团队层面上必须设定期望值，让大家了解它可能影响到未来团队回顾会议上的互动。知道非团队成员（不在团队语境中）会得知讨论结果，团队成员是否还愿意探究敏感课题呢？可能在一个高度互信、高度诚实的组织中，这一体制的效益大过其风险。

查看英文原文： Retrospective of Retrospectives