迭代回顾会议(Retrospective)

聚焦过程: 讨论对象是协作方式、流程与团队氛围,而非具体功能。
营造安全: 强调无指责的坦诚氛围,鼓励成员如实反映问题。
产出行动: 不止于吐槽,须形成明确的改进项并指定跟进人。
形式多样: 常用做得好/待改进/行动项等结构,也可用时间线、帆船等引导方法。

迭代回顾会议(Retrospective)是敏捷团队在一个迭代结束后举行的定期复盘活动。团队围绕过去一段时间的协作方式进行反思,识别值得保持的做法与需要改进的问题,并达成一到几项具体、可落地的改进行动。

概述

在 Scrum 中,它对应冲刺回顾(Sprint Retrospective)事件,是每个冲刺的收尾环节。与评审会议关注产品增量不同,回顾会议关注的是团队本身的过程、协作和工具。其理论根基是敏捷宣言所倡导的持续改进——团队定期审视自身,并据此调整行为。

回顾会议适用于任何采用迭代节奏的团队。为保证效果,改进行动通常数量不宜过多,以便在下个迭代切实落地并在下次回顾中检验成效,从而形成闭环。它与无指责复盘理念一致,都强调从问题中学习而非追责。

问:回顾会议和故障复盘是一回事吗?答:不完全相同。故障复盘针对某次具体事故,而迭代回顾是周期性的常规活动,覆盖整个迭代的协作与流程,二者都强调无指责地学习改进。

问:回顾会议流于形式怎么办?答:关键在于让改进行动真正被执行并复盘成效。若每次只讨论不落地,团队会逐渐失去参与热情,因此应控制行动数量、明确责任人并跟踪结果。