敏捷回顾，你能跳过吗？

有时候，团队会考虑跳过一次回顾会议。例如，当他们感觉到时间压力，或者看不到回顾会议所带来的直接好处的时候。接下来，他们会问自己，是否必须继续做回顾？敏捷回顾可以帮助团队持续地学习和改进，即使是成熟的团队，也依然有继续做回顾的正当理由。

Dave Moran 提到，他最近听到这样一个问题，我们可以跳过敏捷回顾吗？当听到这一问题的时候，他建议：

反问这个团队，对于他们而言，敏捷意味着什么？而且在这种情况下，引导他们回到敏捷宣言是有帮助的。其中一条原则是这样写的：“每隔一定时间，团队就会思考怎么变得更高效，然后相应地调整优化团队行为。”

他的经验是，当组织采用敏捷时，其改进方式发生了变化：

对于团队而言，回顾是一个停下来思考和学习的机会。它是 Scrum 用于支持持续改进的一种关键机制，然而，对于许多非敏捷组织而言，它却是一个难以在实际应用中实现的概念。在非敏捷组织中，改进时断时续，通常表现为将统一指定的实践活动添加到开发过程，而该过程因为设计时涵盖了所有场景本就已经臃肿。

为什么要对“敏捷如何支持持续改进”这一问题进行解释？以及如何使用敏捷实践，如回顾，影响组织管理变革的方式？Dave 对这两个问题进行了回答：

对于涉及到传统任务和功能相结合的工作，我们希望去掉不必要的开销，并在保证质量的前提下，以一种简单、直接、有效的方法加快交付。如果要消除大部分组织（现今）认为有必要的开销，我们需要一些东西缓解其担忧。通过回顾进行持续改进，可以保证敏捷团队关心生产力和效率。回顾缓解了对于敏捷的担忧，并且与现有方法相比，它所提供的敏捷实现方式提高了效率——这一点是我们需要说明的。

在“永远不要低估持续改进的重要性”这篇博文中，James Harvey 对“为什么跳过回顾的团队面临生产力下降的风险”这一问题进行了解释：

以我的经验来看，敏捷团队会在收到一定的成效时跳过冲刺回顾会议，因为，“喂，我们的工作已经做的很好了，为什么还要找错误呢？”这是进入舒适区的风险变成现实的开始。如果没有做错任何事情，你会发现，团队将失去速度、效率和动力，继而基于工作可以毫不费力地完成这样一个假设而陷入一种低迷状态。

他的观点是，对于团队而言，继续做回顾是有价值的：

改进会面临更大的挑战，但改进成果所带来的回报也会极大地增加。

Brian Copeland 写了一篇名为 “ Agile vs Fragile：对回顾的期待”的博文，文中他描述了“Fragile”团队——“这些团队以敏捷作为蹩脚的项目交付活动的借口”——是如何看待回顾的：

这是一个许多团队都犯过错误的领域。由于没有理解回顾所带来的价值，所以他们不花时间进行回顾。他们觉得回顾浪费了可用于下一次开发冲刺的时间。

Fragile 团队会进行经验教训总结会议，但这只是因为敏捷指南上写着他们需要这么做。他们并没有认真对待这样一个会议，也很少会按照会议结果行事。会议变成“怪罪游戏（blame game）”，每个人都竭尽全力，以确保得出这样的结论：冲刺失败不是他们的过错；如果其他团队对于一些事情的做法有所不同，也许冲刺已经成功了。

Fragile 团队在回顾中出现的问题与那些团队采用敏捷的方式有关：

这些团队没有意识到的是，问题不是出于他们选择的方法，而是出于他们使用那个可以使他们成功的方法时所具有的纪律性。当团队采用一种方法，但又不完全接受该方法的原则，这导致了不可预见而又前后矛盾的结果。团队真得变成了 Fragile 团队。

在博文“敏捷开发的催化剂：冲刺回顾”中，Justin Carmony 阐述了其团队通过回顾所取得的成果。在文章的开始部分，他说明了团队在做回顾之前的状况：

（……）当我加入并开始管理 Deseret News 团队的时候，我们有自己的敏捷开发过程：冲刺、估算、站立会议及规划会议等。在大部分情况下，该过程都运作良好，但作为一个团队，我们在寻求下一个生产力水平时陷入了挣扎。由于总觉得漏掉了什么，所以我们进行了重新调整，包括由一周一冲刺变为两周一冲刺、哪一天举行会议及谁在做什么等等。不管做什么，我们都觉得只是为调整而调整，始终没能达到下一个生产力水平。

他们在冲刺规划会议中引入了冲刺回顾：

在两周一次的冲刺规划会议中，我们继续在回顾中反思上次冲刺。（……）只是列出什么进展顺利，什么进展不顺利，以及我们想改变什么。我们会对照上次冲刺的清单，查看在那些原计划做出改变的方面做得如何，以此确保我们已经按计划行事。一周又一周地，我们留出时间修正这一过程，并查看有什么想要改变。

在做完 10 次回顾之后，他们看到了回顾在生产力、工作方式和交付期限等三个方面的成果：

作为一个团队，我们的速度提高了一倍。

在过程开始阶段，我们着手处理诸如待办事项这样的大问题以及缺少定义的任务。一旦这些问题解决，我们就将注意力转移到其它可以促进该过程发展的事情上。然而，如果我们没有定期地迭代这一过程，就可能永远不会注意到这些需要改变的事情。

我们不只是速度提升了：在按期完成任务方面，我们也已经做得更好。我们可以更自信地决定功能。当新功能出现，我们可以估计其对于最后期限的影响，并决定采取什么样的行动方针。

他建议：“如果你还没有开始做回顾，那么现在就开始做。如果已经在做了，那么现在开始与他人分享这一过程”：

我坚信，回顾可以真正地释放敏捷开发的潜力：我们从过程调整走到了过程迭代。使我陷入困境的是，从前每次听到人们谈论敏捷过程的时候，我都没有听说过关于做“回顾”的任何事。我听说过估算、待办事项、冲刺及速度，但敏捷的核心原则，这一可以将整个敏捷过程提升到下一个水平的催化剂，似乎从来没有引起我的注意。

查看英文原文：**** Agile Retrospectives, Can You Skip Them?