如何避免错误的回顾活动

近来发表的关于敏捷回顾的众多文章，重点都放在诸如如何引导以及采取何种形式等这些基础知识之上。而 Patrick Kau 则从相反的角度出发，他提出了敏捷回顾可能被错误执行的一些方式，并就如何避免这些问题给出了自己的建议。

他指出了目前发现的一些问题：

• 只说不做——团队发现同样的问题一再发生，而且也没有投入力气去解决这些问题。
• 只做不说——与上一个相反，有些团队过于关注一些具体的行动，而没有从全局的角度考虑问题。结果可能他们解决的问题并非当初所愿。
• 形式过于重复——如果反复采用同样的形式，最后团队会变得厌倦，并且在回顾会议中走神。
• 利害冲突——当利益相关者充当推动者的角色时，有些人会只关注自己发现的问题，而不是由团队提出来的议题。
• 控制谈话——推动者会掌控会议，从而剥夺团队的权力。
• 推动者事前不做准备——如果推动者事前不做准备，不考虑下面这些因素：听众的目标、要回溯多长时间、准备时间线、撰写提纲、邀请合适的人，那么回顾就无法达成团队的需要。
• 不靠谱的行动规划——没有经验的推动者控制力不强，有时会让团队创建过于宽泛、难以达成的行动计划，而这些行动在一个 sprint 之内根本无法完成。

那我们该如何解决这些问题呢？Patrick 提供了一些建议。说到“控制谈话”和“利害冲突”，他推荐这样的做法：

……重点要放在流程，而不是内容之上。你的目标是保证每个人都有机会发言，说出自己的想法，形成共识，并为最终决议的形成贡献自己的力量。不要去强制推行你认为的最佳方案，……要让大家知道，当你发言时，你所表达的只是个人观点。要让团队有这样的权力：通过一种机制，当他们觉得对话被你所控制的时候，能够反馈给你他们的感觉。

为了让回顾的形式更加丰富多彩，《Agile Retrospectives：Making Good Teams Great》这本书中提出了一些建议，并获得很多方面的认可。此外， Nathan Henkel 还建议：

……要从细节入手。问类似这样的问题：“我记得你当时打算用表格查找技术来提升性能，效果怎么样？”类似“咱们这次哪些做得不错？”这样的问题会让大家摸不着头脑。

关于如何产生可以完成的后续行动， Sumeet Moghe 有些想法：

• 用 SMART 原则来指导后续行动（Specific——明确的，Measurable——可测量的，Achievable——可完成的，Relevant——相关的，Time Boxed——有时间限制的）。
• 不要自己承担推进后续行动的义务。
• 当复查后续行动时，要让所有者给出更新的想法，再看看团队是否满意……
• 要提醒团队：改进是大家的共同目标，彼此都要负责。

最后， Bas Vodde 提出：将大型长期任务拆分为小的、可控制的目标的方式，可供借鉴：

我让团队将所有的后续行动都按照特定的格式来整理，包含两项：长期的目标，可以在验收测试层面实现测试的自动化；眼下的行动，Pete 会用 Fit 来自动化一个测试。 这种形式可以让团队为每个后续行动都考虑其长期目标。这样还可以帮助他们创建具体的行动，来让团队朝着长期目标更近一步。眼下的行动必须是在下一个 sprint 中就可以实施的，而且必须是团队自己就可以完成的工作。

查看英文原文： Retrospective Failures and How to Avoid Them