8 个技巧助你改进敏捷回顾会议

我经常认为回顾（retrospective）应该被称为展望（prospective），因为这个词语关注的是未来，而不是过去。回顾本身实际上是展望未来：它是一个空间，我们可以在这里提出问题：“根据我们现在的了解，为了改善我们自己和客户的生活，我们需要尝试的下一个实验是什么？”

回顾会议应该是什么样的？

产品开发中有两个重要的循环：一个循环产生期望的可交付成果。另一个循环是我们审视我们的工作方式——不仅为了避免重蹈覆辙，而且还要确定如何放大我们做得好的地方——并设计一个实验，将其纳入下一个生产循环，以改进我们的团队取悦客户的方式。这是此图右侧的循环

当回顾会议崩溃时

在参加各个团队的迭代回顾会议时，我看到了与持续改进相关的普遍不满情绪。

一位工程师直言不讳地说：“[我们的]持续改进感觉就像我们一直在失败。”

团队讨论了哪些方面做得好，重申了哪些方面做得不好（可能已经感觉他们一直在失败），互相点头，然后长叹一口气。然后，一位工程师（已经要参加另一个会议迟到了）最终总结了会议：“好吧，让我们尽量不要在冲刺的最后一天提交所有代码。” 没有机会放大优点，因为根本没有讨论优点。

实际上，以下是回顾会议给人的感觉

反模式是回顾会议变成令人恐惧的环节，我们回顾上一次迭代，列出两栏——哪些方面做得好，哪些方面做得不好——然后迅速为下一次迭代提出一些解决方案。其中没有涉及科学方法。没有数据收集和研究，没有假设，也没有深入思考。结果呢？你没有得到一个实验或一个潜在的改进来纳入下一次迭代。

改进回顾会议的 8 个技巧

1. 放大优点！与其关注哪些方面做得不好，为什么不从让每个人先说一件积极的事情开始回顾会议呢？
2. 不要急于求成。深入思考问题，而不是试图立即解决问题，可能是一个更好的选择。
3. 如果回顾会议没有让你对实验感到兴奋，也许你不应该在下一次迭代中尝试它。
4. 如果你没有分析如何改进，（5 个为什么、力场分析、影响绘图或鱼骨图），你可能太快地得出解决方案了。
5. 改变你的方法。如果每次进行回顾会议时，你都问：“哪些方面做得好，哪些方面做得不好？” 然后对任一列中的首要事项进行投票，你的团队很快就会感到厌烦。Retromat 是一个很棒的免费回顾工具，可以帮助你改变方法。
6. 在每次回顾会议结束时，征求对回顾会议本身的反馈。这可能看起来有点元，但它有效：不断改进回顾会议就是递归地改进团队。
7. 消除障碍。询问你如何帮助团队寻找改进，并准备好对任何反馈采取行动。
8. 没有“迭代警察”。根据需要休息一下。从分析中得出假设并提出实验涉及创造力，而且可能很费力。偶尔，团队可以一起出去享用一顿美好的回顾午餐。

本文的灵感来自 回顾反模式：持续改进不应该感觉像一直在失败，发布于 Podojo.com。

[请参阅我们的相关报道，如何为 DevOps 转型建立商业案例。]