如何避免错误的回顾活动

作者 Mark Levison译者郑柯发布于 2008年6月6日上午2时40分

近来发表的关于敏捷回顾的众多文章，重点都放在诸如如何引导以及采取何种形式等这些基础知识之上。而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

标签： Management