让敏捷回顾产生的行动得以实施

敏捷回顾帮助团队找到并实施行动从而持续地改进。我们有不同的方法来跟进行动，也有不同的方法来分析行动是否会导致更好的团队表现和是否会为客户带来更多的价值。

在“回顾的价值”博客里面，Lonnie Weaver-Johnson 探究了一些关于团队取消回顾的原因，并提供了一些从回顾中获取更多价值的技巧。取消回顾的原因之一是回顾所产生的行动没有被执行：

另一个忽略回顾的普遍原因是没有行动跟进。尽管之前讨论了很多行动，但团队没有看到任何变化，所以他们取消了回顾，不愿意再参加。毕竟，有多少次你们的人事部门开展了公司级别的调查，而后来却从不发布结果，或者更糟糕的是他们从来没有基于调查展开过行动。人们不愿意花费时间为没有结果的事情提供信息。

Lonnie 提供了一些确保行动被执行的技巧：

如果 Scrum Master 期望人们花费时间参与回顾并敞开心扉，我们最好用行动来展示。从团队已经选取的应该被优先改正的行动项目里面挑选出一小部分。并在回顾结束的时候向团队汇总介绍一下谁正在执行哪些行动。然后，Scrum Master 应该在下一个迭代周期里的每日会议结束前，提出几次那些行动项目。Scrum Master 应该询问这些回顾行动项目的进展情况，而且在每日会议结束时主动汇报那些分配给 Scrum Master 自己的行动进展。

Corinna Baldauf 发布了一篇博客，是关于“回顾疲劳？如何提高行动项目的跟进”。她解释了为什么执行回顾行动是重要的：

主要观点就是检查和 _ 适配 _，例如改变一些东西。如果从来没有几个回顾行动项目被最终实现和见效，这会让人沮丧。最终将导致回顾疲劳，从而团队不愿意再参加到回顾中，因为“有什么意义呢？什么都不会改变！”

她在博客中描述了几个可能导致行动没有结果的原因。其中之一是应该采取行动的人缺乏意愿。Corrina 提供了一些解决这个问题的主意：

有些情况下，任务是被故意“忘记”的，因为责任人不愿意做。这在一些对抗性任务上显得尤为严重，例如让你“和 Brony 团队谈一下，他们晚提交的代码是如何对我们的部署和测试进度产生危害的”。那些常常容易被忘记。下面的方法可能有帮助：

• 设定最终期限——不给“ 我明天会做”留有余地。最好是在日历中建立一个条目。
• 其他人可以代替或者提供帮助吗？
• 提前商谈对抗性问题以及如何处理关键性对抗。
• 额外方案：开展一次公司范围的沟通培训。

那么，你对自己的进展满意吗？或者空气中弥漫着“浪费时间“的感觉？ 如果是这样，开始把行动项目都写下来，每天或者在下一次回顾中检查它们。可以从一个努力保持板（Try-Keep-Board ）开始。

Chris Smith 在她的博客“建立确实可行的回顾行动”里描述了在项目中如何利用回顾行动来改变进度：

回顾只有在激起改进措施的时候才有价值。有时候，尽管一个团队已经确定了关于它们的项目、流程或者代码库中需要改进的地方，但是他们决定了的纠正措施可能没有明显的效果。例如，一个团队可能想引入一个每周的客户支持轮班制度，因为整个组感觉日常工作被所收到的客户支持请求妨碍了。在第一周，这个轮班制度被采用和遵守，所以事情看上去开始好转。然而一周之后，这个轮班制度很可能被遗忘，从而导致老问题又回来了。

通过引入一个人工方法可以让回顾行动效果明显，来看看 Chris 的解释：

… 如果用一个明显的记号来每天提醒大家：这个行动是存在的而且是大家都同意了的，那么客户支持的轮班制度更有可能会得以牢固地确立。在我的团队里面，我们在值班人员的桌子上放置一个大的妖魔图片。当有支持请求的时候，大家就不会再争论谁应该负责去处理请求。

我们如何才能知道回顾所带来的行动已经带来了有价值的变化呢？Matt Wrye 写了篇博客“敏捷回顾 = 反思”，他在其中描述了敏捷和精益的学习周期：

我所学到的精益准则之一是通过“学习 - 应用 - 反思”（Learn-Apply-Reflect）来创建一个学习型的组织。这个准则有助于提高反思的重要性。许多人和组织很善于学习新事物，然后尽力把学到的应用到工作上。然而大部分人和组织却忘记反思。在反思这一步骤中，学习和应用一起使得我们理解哪些学到的东西可以最好地被应用到组织中去。哪些奏效？哪些没用？哪些应该被保持？哪些应该被改变？

对回顾行动的结果进行反思，可以帮助团队微调利用回顾进行持续改进的方法：

敏捷利用计划好的回顾，通常每周一次，找个时间把团队集合在一起讨论哪些是奏效的，而且应该被继续的。同时，哪些方面有问题，需要被改变或者放弃。

敏捷团队从这一周学到了经验和教训，把它们应用到工作中去并且在一周后安排一次反思。敏捷方法论对培养一个学习型组织发挥着巨大的作用。

Mohit Jain 在“反思回顾”中描述一个团队如何能衡量他们的表现，并获得洞察回顾行动的影响：

为了避免主观或定性的评论，我建议团队采用一个评级系统，其中他们给一个从 1（最低）到 10（最高）的分数。在本次调查结束时，你的团队将为一次迭代得到一个记分卡，在那里很容易找出表现最好和最差的领域。

经过小组对较弱领域达成一致，他们可以使用回顾找到改进的措施。通过频繁地衡量它们的表现，团队可以看到回顾行动是否在帮助他们改善:

分数可以给你的团队一个结构化的方法用来满足和讨论，但是，作为一个 ScrumMaster，同样重要的是你要定期监测从这些会议中产生的价值。对于这一点，我建议你维护一份趋势报告，记录所有迭代得分的比较。

通过分析跟踪记分卡上的在几个迭代的进展，你应该能够识别出：

• 谷：那些一直被打低分或一直处于下降趋势的问题。
• 停滞期：那些已经稳定下来，但是还没有到达“绿灯区”的问题。这可能表明一个接近停滞或冷漠的变化正在你的团队里酝酿。
• 峰：随着时间的推移，你团队的各个方面都在不断地提高，或者让自己在“绿灯区”持续了相当长的时间。

你是如何跟进回顾行动的呢？

原文英文链接： Kanban’s service orientation agenda

感谢杨赛对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。