回顾之回顾-优快云博客

本文链接：https://blog.youkuaiyun.com/cpongo4/article/details/89113225

在大型敏捷项目中，为了确保各个团队之间的有效沟通和持续改进，ThoughtWorks公司的Paulo Caroli提出了一种名为“回顾之回顾”(RoR)的方法。这种方法允许不同团队共享各自回顾会议中的关键点，并通过集体讨论的方式确定整个项目的改进方向。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

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

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

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

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

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

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

Caroli记录的关键效益包括：