做敏捷两年，最不该省的是回顾

做敏捷两年，最不该省的是回顾

去年年底，我在一个两百人规模的产品研发团队做敏捷成熟度评估，结果让我沉默了很久。各项数据都挺漂亮：需求吞吐量稳定、迭代交付准时率超过85%、测试自动化覆盖率也在持续提升。但有一个指标低得离谱，改进项闭环率只有12%。也就是说，团队在回顾会议上提出的改进计划，十件事里有将近九件最终不了了之。

我找了五个 Scrum Master 分别聊，得到的回答出奇一致：“迭代太赶了，哪有时间跟那些改进项？”“大家觉得回顾就是走个形式，说完了就完了。”“有时候连着两三个迭代都提同样的问题，后来就不想提了。”

这些回答让我意识到一件事：一个团队开始省掉回顾，往往不是因为不认可它的价值，而是因为他们从来没体验过真正有价值的回顾。做了两年敏捷，该踩的坑基本踩了一遍，该磨合的也都磨合得差不多了。到这个阶段，真正拉开团队差距的，不是站会开得多标准，不是看板维护得多漂亮，而是你有没有把“停下来思考”这件事认真当回事。

所以我想用这篇文章说清楚一件事：做敏捷两年之后，你最不该省掉的环节就是回顾。省掉它，你省掉的不是一小时，而是整个团队持续进化的能力。

一、两年是个分水岭：为什么这个时候回顾最容易出问题

我见过很多团队在导入敏捷的第一年，回顾环节执行得非常认真。Scrum Master 提前准备好引导框架，每个人轮流发言，白板上贴满便利贴，最后愉快地列出三五条改进计划。那时候团队有新鲜感，有热情，有用不完的劲儿。

但到了第二年，情况急转直下。

1. 仪式感消退，形式感膨胀

第一年的回顾之所以有效，很大程度上是因为团队在“学习如何做回顾”。这种学习过程本身制造了专注度和投入感。到了第二年，大家已经熟悉了套路，先开个场，抛个“安全声明”，然后用“开始做/停止做/继续做”三板斧收一圈反馈，最后投个票，散会。

问题出在哪里？形式还在，但思考没有了。团队成员不再为“我们到底哪里可以做得更好”进行深度讨论，而是机械地完成动作。一个 Scrum Master 跟我说过一句很扎心的话：“我现在开回顾就像放录音，每个人说的话我都能提前猜到。”

2. 疲劳感累积，“老问题”无人愿碰

任何一个团队做了两年产品，都会积累一批“老问题”。比如“联调环境不稳定”“需求评审粒度不够”“前后端接口文档更新不及时”，这些问题也许在第一年就被反复提出过，但始终没有被彻底解决。

当同样的问题第三次、第五次出现在回顾板上时，团队成员会产生强烈的无力感。这种无力感会迅速转化为对回顾本身的质疑：“说来说去不还是这些破事儿？有什么好说的？”于是团队达成了一个心照不宣的默契，与其把老问题再翻出来难受一次，不如快速走完流程，把时间省下来写代码。

3. 效率焦虑取代了改进意识

两年的产品通常已经进入快速迭代和业务压力叠加的阶段。需求方催得紧，线上问题要随时响应，技术债开始冒头，团队被“交付速度”这条绳子勒得喘不过气来。

在这个背景下，回顾变成了最容易“被牺牲”的环节。因为它不直接产出代码，不直接修复缺陷，不直接回应业务方的催促。一个 Tech Lead 的逻辑听起来很合理：“我们这迭代已经延期了两天，回顾那一个半小时不如让大家补一下进度。”

这个逻辑的危险之处在于，它用战术上的忙碌掩盖了战略上的懒惰。如果你不拿出时间反思“为什么我们又延期了两天”，那下一个迭代你大概率还会延期。

两年是个微妙的时间点。团队不再是新手，流程已经跑通了，交付也能稳定产出。但恰恰是这种“能跑就行”的状态，最容易让人放弃主动进化。而回顾，恰恰是主动进化唯一的制度性保障。

二、省掉回顾，你实际上省掉了什么

如果想说服一个团队不要在回顾上偷懒，最笨的办法是搬出 Scrum Guide 说“这是框架要求”。有点经验的做法是让他们看清楚：你省掉的这一小时，代价远比你想象的大。

1. 你省掉了唯一的系统性反思窗口

一个迭代通常持续两周。十四天里，团队每天都在接收信息、做出判断、处理异常、做出妥协。什么是临时的权宜之计、什么是值得沉淀的经验、什么是不该重复的错误，这些东西如果不被刻意提炼，就会像沙子一样从指缝里漏掉。

回顾是唯一一个以“从经验中学习”为唯一目的的正式场合。站会偏执行同步，评审偏成果验收，只有回顾是把镜头拉远，让团队看全局。省掉它，意味着你的团队永远在“做事”，从来没在“学做事”。

我观察过一个团队，他们连续三个迭代都在和同一个第三方接口的文档问题较劲。第一次出问题是开发理解错了字段含义，第二次出问题是接口版本更新没通知到位，第三次出问题是测试用例没覆盖新字段。三次事故，根因各不相同，但共同点是前一次出事后团队没有认真复盘，没有形成“对接第三方接口的标准动作”。如果他们愿意花四十五分钟把第一个迭代的踩坑经验好好整理一下，后面两次事故完全可以避免。

2. 你省掉了团队信任建设的低风险场景

一个好的回顾，不只是产出改进项，它还在产出一个更重要的东西，团队的心理安全感。当团队成员敢在会上说“这个迭代我犯了一个很蠢的错误，原因是……”，并且得到的回应是“我们一起看看怎么防住它”而不是“你怎么搞的”，信任就在增长。

这个信任不会凭空产生。它需要一次次安全的、低风险的对话来积累。回顾恰好提供了这样的场景：不涉及绩效评估、不涉及晋升答辩、不涉及责任追究，只关乎“我们怎么一起变得更好”。

当团队省掉回顾的时候，他们省掉的不仅是讨论问题的机会，更是建立信任的机会。而一个缺乏信任的团队，沟通成本会直线上升。你觉得省掉一小时很划算，但接下来你可能要多花三小时去处理因为信任缺失导致的扯皮、推诿和信息隐瞒。

3. 你省掉了隐性问题浮现的唯一通道

燃尽图、速率、吞吐量这些硬指标只能告诉你“发生了什么”，很难告诉你“为什么发生”以及“大家的感受如何”。而这些软信息恰恰是防止团队崩溃的关键。

我服务过的一个团队，连续四个迭代速率都在稳定提升，从数据上看一切向好。但他们的 Scrum Master 在一次一对一沟通中发现，有三名核心开发已经濒临离职边缘，原因是对技术方向的分歧长期得不到正面讨论。这个分歧从来没有在任何一次回顾中被提出来，因为这个团队已经把回顾省成了一个五分钟的过场。

硬数据会欺骗你，但持续的深度对话不会。回顾是让那些不会出现在看板上、不会体现在燃尽图里的“暗流”浮出水面的唯一制度化通道。

三、三个最常见的“省回顾”理由，以及为什么它们站不住脚

在这一节，我想逐一回应那些我实际听过的、用来为“省掉回顾”辩护的理由。它们每一个听起来都有道理，但每一个都经不起推敲。

1. “太忙了，没时间”，最容易被理解也最危险的理由

这是出现频率最高的理由，也是最具欺骗性的理由。它的逻辑结构是这样的：我们有很多重要的事情要做，回顾不是“直接生产类”活动，所以当时间不够用时，回顾理所应当被牺牲。

这个逻辑的错误在于它把时间和价值的关系搞反了。回顾不是消耗你的时间，而是在保护你的时间不被持续浪费。

举一个 PingCode 客户的真实数据。一个一百二十人的研发团队，在连续六个迭代里记录了回顾产出的改进项及其效果。他们发现：每投入一小时在高质量的回顾上，平均能在下一个迭代节约四点三小时的返工和沟通成本。具体怎么节约的？比如有一次他们回顾发现“需求评审阶段前端参与太晚”，于是调整了评审流程，提前半天拉前端介入。就这一个改动，让那个迭代减少了三次因前后端理解不一致导致的返工，合计节约了超过十八个开发人时。

所以当你说“没时间做回顾”的时候，你真正在说的是“我没时间预防火灾，我只能不停地救火。”

2. “提了也改不了，改了也坚持不下去”，把执行问题归咎于机制问题

这个理由我特别想展开讲，因为它触及了敏捷实践中一个很深的痛点。

很多团队把“改进项无法落地”归因于“回顾没用”，这个归因是错的。改进项无法落地，问题通常不在回顾环节本身，而在三个地方：

第一，改进项太大太模糊。“提高代码质量”，这不是改进项，这是一个愿望。好的改进项应该满足两个条件：一是一个迭代内可以完成，二是完成与否可以被明确验证。比如“引入 SonarQube 扫描并设定质量阈，本迭代将技术债控制在新增零增长”，这才是一个可执行的改进项。

第二，改进项没有人认领。回顾会上大家群情激昂地说“我们要解决某某问题”，但没有人说“我来负责推进这件事”。没有 Owner 的改进项，就跟没有责任人的任务一样，注定石沉大海。

第三，下一个迭代没有为改进项留出空间。迭代计划把开发任务排得满满当当，然后又期望大家“顺便”把改进项做了，这不现实。改进项必须被当作迭代待办事项的一部分来管理，享有和功能开发同等的优先级。

这三点都属于“回顾的后续管理”问题，不是回顾本身的问题。你因为执行没做好而把整个环节砍掉，相当于因为汽车没保养好而决定以后不买车。

3. “团队已经很默契了，不需要走这个形式”，把默契当成万能的

“我们团队合作两年了，有什么问题直接说就行，不用非得坐到会议室里搞个正式回顾。”这句话我听过不下二十次，每次听完我都会问一句：“所以你们直接说了吗？”

多数时候得到的回答是沉默或者尴尬的笑。

这里有个认知偏差需要纠正：团队成员之间的日常沟通和结构化回顾，解决的是完全不同层面的问题。日常沟通解决的是“这件事怎么做”，回顾解决的是“为什么这件事我们这么做会出问题”。前者是操作层面的对齐，后者是模式层面的反思。它们根本就不是一回事。

而且，越是默契的团队，越容易掉进一个陷阱：因为默契，所以很多潜在分歧被礼貌地回避了。大家不想打破和谐的气氛，于是那些本该被讨论的问题，技术选型的疑虑、流程设计的异议、协作方式的摩擦，就被悄悄埋了起来。直到某一天某个事件引爆，才发现裂痕其实早就在那里了。

回顾的价值之一，恰恰是提供了一个“可以安全地打破默契”的场域。它让你可以把平时不好意思说的话，在一个制度性的框架下说出来。

四、什么样的回顾不会被“省掉”，从形式到实质的重建

说完了“为什么不能省”，接下来我想讲更具操作性的一面：怎么把一个快被团队放弃的回顾，重新变回他们舍不得省的那个环节。

我先给出一个核心判断：大部分团队厌倦回顾，不是因为回顾本身有问题，而是因为他们做的回顾太无聊、太无效、太像完成任务。一个团队愿意持续投入的回顾，必须同时满足三个条件，有安全感、有产出感、有掌控感。下面逐一拆解。

1. 安全感：让团队敢说真话，而不是说“正确的话”

安全感是回顾的基石，没有它，一切都白搭。我见过最灾难的回顾现场是这样的：产品负责人在场，Scrum Master 问“这个迭代大家觉得哪里可以改进”，全场安静了四十秒，然后一个开发说“我觉得都挺好的，大家辛苦了”，其他人纷纷附和。会议十五分钟结束。

这根本不是回顾，这是表演。

建立安全感需要几个具体动作：

• 明确“免责声明”并真正遵守它。每次回顾开始前，Scrum Master 或引导者要清晰说明：这个会上讨论的任何问题、提出的任何失误，都不会被用作绩效考核的依据。更重要的是，管理者在会后真的不能拿这些信息去追责。一次失信，安全感就会崩塌。
• 管理者先暴露自己的不足。如果 Tech Lead 或团队负责人能先说“这个迭代我在某件事上决策慢了，导致大家多花了半天时间”，其他人就会觉得“原来这里是可以坦诚的”。
• 引导方式要从“追责”转向“追因”。不要说“为什么这个缺陷没测出来”，而要说“这个缺陷逃逸到线上的路径是什么，我们怎么在链路里加一道拦截”。核心是讨论系统怎么改进，而不是判断谁做错了。

2. 产出感：让团队看到“回顾是真的有用的”

如果每次回顾提出的改进项都不了了之，团队自然没有动力参与下一次。这是一个非常朴素的心理机制，“我说了也没用，那我干嘛还要说？”

打破这个循环的关键，是让改进项的管理可视化、可追踪、可庆祝。

在 PingCode 的 Scrum 项目模板里，每个迭代的回顾改进项可以直接创建为工作项，关联到下一个迭代的待办列表中。这意味着改进项和功能需求、技术任务放在同一个看板上，有相同的可见度和追踪机制。

我观察到一个很有趣的变化：当改进项和开发任务并列在看板上时，团队成员对它的态度会从“额外的负担”变成“本迭代应该完成的工作”。一个改进项从“创建”到“完成”的流转，带来的心理满足感不亚于交付了一个功能。

另外，有一个小技巧特别有效：在每个迭代的评审会上，花三分钟展示上一个迭代改进项的完成情况。让所有人都看到“我们上次提的那个问题，这次真的被解决了”。这种正向反馈是维持团队参与感最强大的燃料。

3. 掌控感：让团队自己决定“怎么回顾”

两年之后，团队对千篇一律的回顾形式已经免疫了。如果每次都是“开始做/停止做/继续做”那一套，大家的注意力自然会涣散。

一个很有效的策略是让团队轮值负责回顾的设计和引导。这个月 Scrum Master 设计，下个月转给前端开发，再下个月转给测试工程师。每个人对回顾的理解不同，带来的切入角度也会不同。

我见过一个测试工程师设计的回顾，他用了一个叫“时间线回溯”的方法：打开迭代的提交记录和缺陷记录，按时间顺序投影到屏幕上，让团队一起看“这个迭代我们是怎么一步一步走过来的”。哪几天节奏很好，哪几天突然紧张，哪几天出现了意料之外的阻塞，全部可视化地呈现在大家面前。那场回顾的信息密度，超过了之前三次例行回顾的总和。

让团队拥有对回顾的掌控感，他们才会把回顾当成“自己的事”而不是“框架要我做的事”。

说到这里，我必须澄清一个常见误解。很多团队以为“换个花样的回顾形式”就能解决问题，搞了一堆花哨的破冰游戏和脑洞工具，结果换汤不换药。形式只是载体，安全感、产出感、掌控感才是内核。先解决这三个感，再谈用什么形式，顺序不能反。

1. 回顾引导轮值制度，每个迭代由不同成员负责设计议程
2. 改进项可视化上墙，与迭代待办列表并列展示
3. 管理者率先暴露问题，带头打破“只说好的”的惯性
4. 每个迭代评审会预留改进项展示环节，强化正向反馈回路
5. 设定改进项的SMART标准：具体、可衡量、一个迭代内可完成、与团队痛点相关、有明确截止点

五、数据不会说谎：从PingCode的客户观察看回顾质量与团队效能的关系

作为长期服务中大型研发团队的协作工具，PingCode 积累了大量可供分析的行为数据。虽然不是严谨的学术研究，但这些数据确实揭示了一些值得关注的模式。

在 PingCode 服务的一百人以上组织中，我们按照回顾相关动作的完整性将团队分为三组：

第一组：完整回顾团队。每个迭代记录了回顾会议纪要、产出了至少一条改进项、改进项被创建为工作项并关联到下一个迭代，且最终有明确的完成或关闭记录。这类团队约占总量的三成出头。

第二组：走过场团队。有回顾会议记录但内容极简（通常不到三行），改进项模糊或缺席，或有改进项但从未被关联到后续迭代。这类团队占比最高，约四成半。

第三组：几乎不做回顾的团队。Sprint 周期内无任何回顾活动记录。占比约两成有余。

当我们在控制团队规模和行业属性后对比这三组团队的项目交付数据时，以下差异具有统计显著性：

• 需求吞吐量的稳定性。完整回顾团队的迭代间吞吐量波动系数为 0.18，而过场团队为 0.34，几乎不做回顾的团队为 0.47。波动系数越小，说明团队交付节奏越稳定。回顾做得好的团队，不会出现“这个迭代拼命赶完一堆需求，下个迭代突然大幅度下滑”的过山车现象。
• 线上缺陷逃逸率。完整回顾团队平均为 2.8%，几乎不做回顾的团队为 9.6%。这组数据让我尤其在意，因为逃逸率直接关乎产品质量和用户口碑。
• 需求澄清返工比例。指“因需求理解偏差导致开发成果需返工的需求占比”。完整回顾团队为 6.2%，几乎不做回顾的团队高达 21.4%。回顾能把那些模糊地带和沟通断层反复暴露出来，从而推动团队在前端评审环节做得更细致。
• 团队成员留存意愿。这个数据来自 PingCode 内置的团队健康度调查模块。完整回顾团队中“我愿意继续留在这个团队工作”的评分均值为四点一分（五分制），而几乎不做回顾的团队仅二点八分。

这些数据并不完美，相关性不等于因果性，可能存在某种自选择效应，本身就更有纪律性的团队更倾向于认真做回顾。但当一个模式在不同行业、不同规模的数十个团队中反复出现时，它至少说明了一件事：认真做回顾的团队在多个维度上表现更好，而且这种好不是偶然的。

六、不同阶段团队的行动建议和取舍

写到这里，一些读者可能会有一个合理的担忧：“你一直在说回顾很重要，但我们团队现在连迭代节奏都还没稳住，每个迭代都在拼命赶交付，哪还有精力搞你说的那种高质量回顾？”

这个担忧完全合理。不同阶段的团队，对回顾的投入程度应该有差异化的预期。我不主张所有团队都拿出一小时做深度回顾，但我主张任何阶段的团队都不要把回顾完全砍掉。

1. 交付压力极重型团队：保住“最小可行回顾”

适用特征：每个迭代延期风险高、线上问题频发、团队长期处于高压状态。

这类团队确实很难匀出整块时间做回顾。但正因为交付压力大，才更需要一个极简的复盘机制来阻止问题持续恶化。

建议动作：十五分钟站会式回顾。在迭代最后一天的站会上延长十分钟，每人回答两个问题：“这个迭代我学到的一个东西是什么？”“下次迭代我想改的一个动作是什么？”不需要白板，不需要便利贴，不需要投票。但需要有人记下来，哪怕只记一句话。哪怕只产生一条改进项，把它写在下个迭代计划的第一行。

核心原则：可以缩减形式，不能取消环节。可以压缩时间，不能放弃记录。

2. 节奏稳定但瓶颈明显型团队：聚焦“瓶颈深挖式回顾”

适用特征：交付基本按时、流程能跑通，但总有一两个环节反复拖后腿，比如测试总是最后一个迭代日还在赶工、或者联调阶段永远鸡飞狗跳。

这类团队不需要在回顾里面面俱到，而应该把九成精力集中在一个瓶颈问题上深挖。

建议动作：单议题深度回顾。开场直接抛出问题，“这个迭代联调阶段又延期了一天半，我们今天只聊这一件事，把它聊透。”然后用时间线回溯或者“五个为什么”追问法，一步步追溯到根因。产出的改进项可以只有一条，但这一条必须被当作下个迭代的头等改进任务来推进。

核心原则：一次只解决一个问题，但一定要把这个问题彻底解决。

3. 成熟稳定型团队：升级回顾的层级和视野

适用特征：交付稳、质量好、流程顺畅，团队合作两年以上，基本没有明显卡顿点。

这类团队的回顾如果还停留在“这个迭代出了什么小问题”的层面，确实会让人提不起劲。因为它们已经很少出“小问题”了。

建议动作：将回顾从“操作层”升级到“策略层”。讨论的话题可以变成：“我们的技术债务积累速度是否在加快？需不需要调整重构策略？”“我们的架构在下一个季度能支撑业务预期的增长吗？”“团队成员的成长速度有没有被重复性任务拖慢？”

这个层级的回顾，时间可能需要拉长到两小时甚至半天，频率可以从每个迭代一次调整到每两三个迭代一次，但强度要上来。它更像是一次小型的战略研讨会，而不是日常复盘。

核心原则：当操作层面没有问题时，就把镜头拉远，讨论长期价值。

七、回顾的边界：不该让回顾承担的东西

在强调回顾的重要性之余，我也想明确说出它的边界。因为把回顾过度神圣化或者让它承担不该承担的功能，同样会让这个环节变形走样。

回顾不应该承担以下功能：

第一，绩效评估或能力考核的素材来源。一旦团队成员感知到回顾中的发言会影响他们的绩效评分或晋升前景，就不可能再有坦诚的讨论。这一点没有商量余地。管理者如果做不到把回顾和绩效彻底切割，那就不要开回顾，因为开了也是假的。

第二，解决团队深层矛盾和人际冲突的主战场。回顾可以发现团队在协作层面的摩擦，但它不擅长解决深度的信任危机或长期积累的人际矛盾。如果有两个核心成员之间已经有了严重的隔阂，回顾不是处理这个问题的合适场所。这些问题需要一对一的沟通或者专门的冲突调解。

第三，替代日常反馈和即时沟通。如果一个问题是可以在发生的当天就解决、就沟通的，就不要非要留到两周后的回顾会上再来提。回顾处理的是“模式”和“系统”，即时反馈处理的是“个案”。如果团队日常沟通不畅，回顾质量也会被拖垮。

把这些不该由回顾承担的东西清理出去，反而能让回顾变得轻盈、聚焦、有效。

八、如何判断你的回顾正在走向形式化，几个值得警惕的信号

最后，我想列出一组我实际观察到的危险信号。如果你的团队出现了以下情形中的三个以上，那就是时候重新审视你们的回顾了。

• 连续三个迭代的改进项内容高度雷同，几乎没有新的话题被提出
• 团队里总有一两个人从不发言，或者总是最先发言的永远是固定的那一两个人
• 回顾时间持续缩短，从一小时到四十五分钟到半小时到“今天大家没什么要说的吧那咱们就到这儿”
• 改进项永远停在“提出来”这一步，从来没有被分配、被跟踪、被完成
• 有人在站会上小声说“今天又要回顾了，好烦”，并且周围有人会意地笑
• Scrum Master 已经连续两个迭代没提前准备回顾的引导议程，完全即兴发挥
• 回顾结束后的感觉是“终于熬完了”而不是“有几个点让我挺有启发的”

如果你的团队中了三条以上，不需要慌张，但需要行动。不要让回顾变成自己骗自己的仪式。要么认真做，要么暂停一两轮让大家重新感受到“没有回顾是什么滋味”，然后再带着新的理解重启。

回到标题的那个判断，我自己越来越坚信：做敏捷两年之后，回顾是区分一个团队是“真正的敏捷”还是“名义上的敏捷”最核心的试金石。

你可以把站会缩短到十分钟以内，你可以把评审和回顾合并到一起开，你可以把迭代周期从两周拉长到三周，这些调整都可能是有道理的。但你不能把“团队定期停下来、认真思考、决定一件事然后真的去改”这个动作砍掉。砍掉它，你就从敏捷退化成了“快速交付的瀑布”。

一个做了两年敏捷的团队，如果回顾环节依然是它最不愿意省、最舍不得省、最认真投入的环节，那这个团队大概率走得比同行更远。不是因为回顾本身有多神奇，而是因为愿意持续反思和改进的团队，在任何一种开发方法论下都不会差。

如果你读到了这里，不妨在下一个迭代开始前做一件事：花十五分钟，和团队一起回答一个问题，“我们上次回顾提出的那个改进项，现在怎么样了？”如果答案令你不满意甚至有点心虚，那就对了。那就是你应该开始行动的地方。