敏捷/Scrum回顾的技巧与窍门

作者 Mark Levison 译者 金毅 发布于 2010年12月25日

领域

过程 & 实践

主题

团队协作 ,

分布式团队 ,

协作 ,

敏捷技术 ,

团队工作 ,

Scrum ,

持续改进 ,

回顾 ,

敏捷

分享到

回顾和反馈环在任何成功的敏捷/Scrum实施中都占据着重要地位。它们是我们用于帮助团队进行改进的工具。然而在仅仅两天的敏捷介绍课程中，它们常常被一笔带过。由于时间限制，培训师们（包括我自己）常常匆匆过一下这个话题，粗略描述一个回顾的简单方式。问题在于，简单的回顾方式往往让人感觉无聊，久而久之，大家就没兴趣参与了。

Brian Lawrence介绍了一种相对稳妥的回顾方式，这种方式对于一个规模较大的或者之前没有协作经验的团队比较有效。他会为团队提供一些规格为3x5的索引卡或记事贴，甚至可以为不同类型分配不同颜色。他让大家用20分钟时间在卡片上写出做得好的方面，再用20分钟时间写些需要改进的事情。随后主持人会把这些卡片分类并贴在墙上。接下来的时间，由团队来决定哪些是可以去做的。

Jimmy Bosse认为，回顾非常重要，所以不管发生什么，回顾都必不可少。他解释道，回顾会赋予团队改变和进步的力量，如果不进行回顾，问题和缺陷滋生蔓延，屡治屡犯，团队成员间互相指责，而不是集中关注如何改进当前的状况。

Yves Hanoulle回应道：

我认为“永不停止回顾”的说法是错误的。
“永远不”和“永远"都不是敏捷词汇。千万别用它们。

我认为当团队想要不再做回顾时，他们可以分析一下根本原因，看看这一意愿背后到底是什么。

有人曾经问Doug Shimp：回顾会议中使用的便签记录是否该公开贴出来呢？他答道，分享团队目标的达成情况和学到的东西，显然胜于贴便签。即使这样，他依然建议谨慎处理，因为脱离上下文地进行某些改进，可能会导致人员纠纷。

考虑到教练不可能无处不在， Jason Little打算设立一个专门用来进行回顾的房间。他想要：

• 有很多空位子的，舒适的大房间。
• 某个区域张贴着下列信息：“回顾的价值，会议形式的样例以及开始回顾之前所要完成的工作的清单的样例”
• 一个篮子做“回顾工具箱”，里面放着敏捷教练所提供的：记事贴、记号笔和介绍各种技术的宣传册。

Jason的会议议程样例：

1. 确定一个重点
2. 提出议程并审议
3. 针对关注点，用头脑风暴法收集做得好的方面及不好的方面
4. 用头脑风暴法收集要中止/开始做的事情
5. 制定行动计划
6. 把提到做得好的方面和不好的方面的记事贴收集起来以便以后重用

在 敏捷回顾Wiki中还有很多不是很出名的回顾活动，包括:

• 回顾的6顶思考帽(6 Thinking Hats Retrospective)
• 蜘蛛网敏捷回顾(Pillars Of Agile Spiderweb Retrospective)
• 赞扬式的回顾(Appreciative Retrospective)
• 5大问题(Top 5)
• 行动计划(Plan of Action)
• 打圈儿交流(Start, Stop, Continue, More of, Less of Wheel)
• 一对多(Each One Meets All)
• 迎难而上(The Complexity Retrospective)
• 力场分析法(Force Field Analysis)
• 番茄技术(Pomodoro Retrospective)
• 回顾之回顾(Retrospective Surgery)
• 提问式回顾(Questions Retrospective)

Christopher Avery就写到过回顾所带来的微妙效应：

1. 回顾为团队提供了一个机会： 让大家能够作为一个团队，聆听来自每个人的声音、整合大家的想法并达成向下一个阶段迈进的共识。
2. “尾声：当有些东西在思想或感情上依然没有结束时，就很难有新的开始。”

这位作者写到了如何组织好团队进行回顾的基本窍门。在把焦点转向需要改进的事情之前，我会先强调先前Sprint/迭代中那些做得不错的地方（指出好的方面，并表示感谢）。通过这种方法，我们振奋了团队的情绪。这样，我们就能在一个斗志高昂的氛围中讨论如何处理可能发生的困难。另外，我相信这也是为接下来的迭代制定小的SMART目标，并且落实到团队的关键所在。如果不这样做，就不会有改进，而团队成员也会由于没有任何进步，而对回顾失去兴趣。

在ScrumDesk博客上，大家在讨论使用快艇互动游戏(Speed Boat Innovation Game)来进行回顾：

游戏规则是画一条有一对锚和引擎的船。船要以某个所关注的领域命名（尤其是当你想要分析很多问题时）。

你让团队成员写下是什么降低了船速（一个想法一张卡片），随后把卡片钉在锚上。再让团队成员写出可以提升船速的方法，随后把卡片钉在引擎上。接下来，你就可以运用敏捷/Scrum中针对回顾的分组、分类抑或各种你所知道的类似方法来做了。

我们在会议期间画了两艘船。大家畅所欲言，提了很多想法，并且大家提出的很多可能/预期的解决方案当即就被管理人员采纳执行。

最后Matthew Bussa 提供了一些技巧和窍门：

• 别泄气！开始的几次回顾会议耗时会比较长，但过一段时间就会缩短的。
• 要让这成为团队成员提出他们担忧和解决方案的一种途径，但要避免只谈论消极的方面。来谈谈做得好的地方和如何持续吧！
• 行动项：这非常重要，可以反应出回顾是否有效。我们需要制定出可度量的行动项，分配到人，最重要的是要在下一个回顾中跟踪它的状态。如果这些行动项在团队的控制范畴之内，那么就尽一切可能尽快完成。
• 把你的行动项数量控制在3到5个之间，挑选优先级最高的那些。相较于20多个行动项，3到5个更容易让人记住并完成。
• 给你的回顾活动变变花样！这会让会议有新鲜感，避免墨守成规。看看这本书《敏捷回顾：从优秀到卓越》。
• 谨记要尽可能掌握好活动时间，珍惜每个团队成员的时间。

相关的话题，InfoQ上还曾发表过：成功敏捷回顾的关键因素：做好准备、积极参与，回顾之回顾。

译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。