閱讀本文約花費: 20 (分鐘)

持续改进是敏捷的重要组成部分。无论一个敏捷团队今天多么出色，都要推动其团队成员去寻求未来变得更好的方法。而探索持续改进，正是迭代回顾会议的目的。

不幸的是，并非所有回顾会议都能实施得很好。许多团队往往很难开好回顾会议。在本文中，我将描述自己在回顾会议中看到的四个最常见问题，并提供解决问题的建议。

  问题1：人们不诚实或不值得信任 

对回顾会议最常见的抱怨之一是：人们没有提出真正的问题或人们不愿意承认他们的问题。如果人们不能在回顾会议上直言不讳，那么得到的评论也只能是“浪费时间”。

这或许是个真实存在的问题，但解决方案不是抛弃回顾会议，而是我们要关注如何让人们在回顾会议中变得更加诚实和开放。

您一定能采取一些措施来增强团队成员之间的诚实和互信。具体可以执行以下措施：

1）营造安全氛围

要营造安全氛围，因为只要缺乏安全感，人们就不会在回顾会议上畅所欲言。这就意味着——人们在回顾会议上说的话和发生的事都不会蔓延到会后，并且这一点已深入人心。

只要参加足够多的回顾会议，您就会偶尔看到情绪失控的情况，您还会听到不该重复出现的话语。在最近一次回顾会议上，就有一位程序员咆哮：“到底还要等多久，‘该死的DevOps组’才能执行部署工作？”。

他确实不应该那样说话。但换句话说，他能发泄出情绪，并且在发泄完后明白不能再这样与DevOps组说话，也是件好事。

我认为回顾会议上不应该说脏话，而我也确实听到过脏话。禁止说脏话，是营造安全氛围的要素之一。因此，要确保人们明白：他们不应再重复其不当言论，并且他们也不会因为自己曾说的话而受审判。

2）带头做到您想要的行为

既然想让别人说实话，当然您自己得先做到。如果您是Scrum Master或者敏捷教练，正试图让团队在回顾会议上变得更加开放，这一点尤其正确。

只要团队成员发现您不能直接明了地说出真话，他们就也会跟着犹豫不决。

3）要确保所有的批评都是建设性的

我认为没有人会喜欢挨批评——即使知道是为我们好，也仍然不会喜欢。我有一位编辑，会在我的博文被您看到前先阅读并进行排版。当打开她编辑的文档并看到她指出的错误时，我绝不会喜欢。但我会欣喜于她编辑工作对文章质量的提升。

我很欣赏她编辑工作中的一件事情，那就是她会在批评的同时给出建议。

没有建议的批评，就只是抱怨。要鼓励团队成员在要批评时给出建设性的批评。

4）履行承诺

要产生信任，就要履行您作出的所有承诺。无论是回顾会议上的承诺，还是任何其他时候的承诺，都应该做到。另外，也要确保其他人也同样做到。如果人们光说不做，那么回顾会议就会让人感觉毫无价值。

5）当犯错误时要勇于承认

“我错了！”“我犯了一个错误！”

我们很多人都难以说出任何一句这样的话。然而，对于其他人来说，听到它们往往又是如此重要。

如果您犯了错，就要承认。如果您建议调整团队的冲刺周期，然而两个冲刺后表明这是个坏主意。那就承认吧，放弃这个决定和继续前行。

我前面提到了带头做到您期望行为的重要性。在错了或者犯错误时勇于承认，就是这样做的一种重要方式。

  问题2：回顾会议很乏味

我喜欢听音乐。我喜欢各类音乐，我喜欢现场的和录制的音乐，但特别喜欢现场音乐会。

我19岁时曾和一个名叫黛娃的女孩约会，她妈妈拥有一家票务代理公司。在前互联网时代的日子里，她妈妈会买音乐会和其他现场演出会的票，然后转售出去，以赚取差价。

有时候，在演出会的当天晚上，她妈妈还会有几张票砸在手里。和黛娃约会的最大好处是：她妈妈有时会把这些没卖掉的票送给她。然后她就会和我一起去看音乐会。唯一比看现场音乐会更棒的事情，是能拿到免费票。

有一次，黛娃的妈妈给票让我们免费观看重金属乐队犹大圣徒（Judas Priest）的演出。我们俩都是这个乐队的粉丝。事实上，我们已经买票看过他们前一晚的演出。这就意味着我们会连续两晚观看犹大圣徒乐队的演出。

第一场演出棒极了。音乐会的大部分时间，我们都站着、高举双手和罗伯·哈尔福德一起唱。

第二晚的演出也……完全一样。我指的是，不仅乐队演奏了同样的歌曲，就连最细微之处也完全一摸一样。

在一首歌中，歌手罗伯·哈尔福德会走到舞台右侧，把脚放在喇叭上、前倾身体、握拳，然后把胳膊肘放在膝盖上、下巴放在拳头上。两个晚上，他都完全相同地走动和摆姿势。

整个音乐会都精心设计到了每个细枝末节，这就使得第二个晚上令人感觉极度无聊。

如果回顾会议每次都以同样的方式进行，那么就会发生同样的事情。

掌握几个您偏好的标准回顾会议实施方式是件好事，就像摇滚歌手可以有几个在每次音乐会上都重复的动作一样。但您不能指望每次都以完全相同的方式实施回顾时人们会保持同等投入。

有两种方法能改变您的回顾会议：改变您提出的问题，或改变您的提问方式。让我们来看看每种方式该怎么做。

1）改变您提出的问题

改变您在回顾会议中向团队成员提出的问题，是一种推陈出新的好方法。如果您以前一直在问“什么进展得顺利，什么进展得不顺利？”，那么可以把问题改为“我们应该开始做什么，停止做什么，继续做什么？”或者做任何其他调整。

更好的做法是，改变您提问的语境。TastyCupcakes网站（www.tastycupcakes.org）以提供独特的回顾会议游戏和活动而闻名。例如，网站把回顾会说成是航行，将常见的改进问题放进了船舶航行的语境中。参与者被要求识别帮助团队前往目的地的“帆”，以及阻碍团队行进速度的“锚”。

本质上讲，这只是以另一种形式来问团队“进展得顺利”和“进展得不顺利”。但在不同语境下提出这些问题（在本例中是航行），有时能有所帮助。

亚当·韦斯巴特（Adam Weisbart）提供的Recess（www.recesskit.com），是一种更简单的改善您回顾会议的方式。每个月，韦斯巴特都会给您寄一个箱子，里面装有您运作一个有趣而引人入胜的回顾会议所需的一切东西。他给过让团队想象自己正在进行火星之旅的箱子，也给过让团队想象自己正在消灭僵尸的箱子。

我知道这听起来很疯狂，但也确实管用！因为我发现人们开始期待回顾会议，更重要的是，他们会贯彻执行在Recess中创建的行动计划。

我喜欢把回顾会议的创意外包给韦斯巴特，让他每个月都为我想出一个新点子。然后，我会从他那里得到一个箱子，里面装有我需要的一切，甚至会有一本剧本——它能节省大量的准备时间，能让每个人都玩得很开心，并得到回顾成果。

如果有兴趣想试试看，我已经为您安排了首套七五折的折扣。只要使用这个链接购买，就能在结账时应用此折扣：https://RecessKit.com/mountaingoat

2）改变提问方式

与改变回顾会议的整体结构或语境相比，只是改变提问方式会没有那么吸引人了。设想一个，如果您的回顾会议，总是让Scrum Master询问每个人“下一个冲刺，我们应该做什么改变？”，会怎么样？

要改变提问方式——不再同时向所有人问这个问题，改为向每个人逐个提问并让其说出要改变什么。

我用简单的“要开始什么”、“要停止什么”和“要继续什么”形式，实施了很多次回顾会议。有很多改变提问方式的方法。首先，我可以要求每个人大声喊出“要开始什么”、“要停止什么”和“要继续什么”。其次，我可以问同样的问题，但要求每个人一次回答所有问题。再次，我还可以告诉团队，我们最近要开始做的事情很多而要停止做的事情很少，因此我会让每个人只给出一件要停止的事情。

改变问题、语境和提问方式，绝对有助于防止回顾会议变得像摇滚乐队那样枯燥乏味，因为摇滚乐队会编排好音乐会的每一个动作。

  问题3：回顾会议没有效果

这世界上已经有足够多的敏捷团队愿意证实回顾会议对他们的有效性。因此，如果觉得您的回顾会议没有效果，您就必须审视一下自己进行回顾会议的方式。

如果做得好，回顾会议是一种能有效识别和选择新方法的改进方式。

我真心认为对于这一点没什么可反驳的余地。然而，可能存在一种观点：对于某个既定团队，回顾会议的性价比不高。也就是说，回顾会议所带来的改进，还不足以证明其所花费时间的合理性。

这是极有可能的。但尽管遇到过很多向我宣称他们已经完美和不再需要回顾的团队，我还没有认同过哪个团队真是这样。所有这些团队都能继续改进。

举世最佳团队

但让我们考虑一个举世最佳团队的情况——他们已有奖杯和杂志封面故事来证明这一点。这个团队进行了一次回顾会议，但由于他们是如此惊人的出众，即使花一整天时间来召开回顾会议，会上团队成员们也只发现了一个改进项，能使其工作效率提高0.0001%。

回顾会议仍然有效果——发现了改进项，但却不划算。当然这是极其夸张的说法，因为所有团队都应该能够以更少的工作量来识别更显著的改进项。

现实的例子

然而，更现实的是，假设一个八人团队花了一个小时来进行回顾会议，这就投入了480分钟。无论他们识别了什么样的改进项，都必须能回报于为回顾会而专门省下来的那480分钟，这样回顾会议才会值得投入。

虽然听起来好像花了很多时间，但很多改进项都能轻易地回报此投入。例如，只要团队识别了一项改进项，能防止每次发生都要消耗一天或两天的错误沟通，就能使投入得到回报。

当团队变得非常优秀时，要关注改进识别上能得到多大程度的回报。

改善回顾会议的回报率

提高团队回顾会议回报率的一个简单方法是：考虑减少执行回顾会议的频次，特别是当团队执行的迭代为一周或两周时。

我知道自己会收到一些攻击此观点的邮件，但请先听我说完整。

前提是：您的团队厌恶回顾会议——我指的是“厌恶”。您已注意到团队成员甚至会为躲避回顾会议而特地在回顾会议那天安排了根管治疗——我指的是“专为躲避回顾会议而并不真正需要的根管治疗”。

团队意识到，只要迭代从两周改为四周，就能将回顾会议减少一半。因此团队选择把迭代改为四周，以便他们能进行更少的回顾会议。

或许有些牵强，但也确实可以这样解释其正确性：如果团队每四周一次迭代，并且每四周进行一次回顾是对的；那我们不妨讨论一下，为什么团队就不能这样——两周迭代允许每隔一个迭代做一次回顾，因为这仍然是每四周进行一次？

我认为应该允许他们这样做。

我并不鼓励这样做，因为大多数不想进行回顾的团队恰恰是最需要回顾的团队。但是，对于一个有着丰富敏捷经验、高度熟练的团队来说，我认为这是一种有效保持回顾会议的效果和成本效益的方法。

  问题4：回顾会议不适用于分布式团队

我们得面对现实：对于分布式团队来说，几乎所有事情都很难实施。我们不能因为事情难就不做。

是的，对于分布式团队来说，要实施好回顾会确实会更具挑战。但这恰恰可能意味着更应该做回顾。

您能做几件事情来开好回顾会议。

首先，我认为视频会议是开好分布式回顾会议的必要条件，绝对不要仅仅通过电话会议来做回顾。

其次，可以将任何一种协同编辑工具用于回顾会议。要鼓励所有与会者在工具中输入新的想法——这不应当只是Scrum Master或者其他会议引导者的责任。

第三，保持回顾会议简短而频繁。尽管我在前一节中说过“如果团队很棒，或许可以每个月而不是每两周做一次回顾”的话，但还是要尽量频繁。

长时间的会议从来都是无趣的，如果不能当面参加，就更令人痛苦不堪了。更糟糕的是，如果团队分布于遥远的不同时区，部分团队成员可能得加班到很晚才能参与会议。而远方城市的团队成员也不太可能会提出大问题，因为大问题只会让他们在办公室待到更晚。所以，简短的回顾会议会更好。

第四，要竭尽所能地把回顾会议开得有趣，对于远程会议更是如此。有一些常用实践方法，例如让每个人分享其对团队其他人的欣赏之处，可能会有助于此。如果有人总是把点心带到您召开回顾会议的办公室，那么请想方设法让其他城市的成员也能在回顾会议上拿到这些递送的零食。

第五，在分布式回顾会议上，可能值得额外花些时间来要求团队成员对已经达成一致的各类改进工作分配职责。

对于同处一地的团队，我通常不会这样做，因为他们会在迭代中讨论和协作解决问题。

但是对于分布式团队来说，改进工作更容易被忽略，所以值得花点时间来讨论每件改进工作该由哪些团队成员来负责。

最后，我有个您可能做不到但我仍然要提出的建议：偶尔让人们飞到一起。我不会只为召开回顾会议而让每个人都飞到一起。但由于回顾会议是迭代的最后一件事项，因此您可以让人们飞到一起来参加评审会议、回顾会议和计划会议。这绝对值得偶尔为之。

  您怎么认为？

您遇到过我描述的这四个问题吗？您是怎么处理的？您在回顾会议中还遇到过什么问题？您采取了什么措施来克服这些问题？请在下面的评论中分享您的想法。

原文链接：

https://www.mountaingoatsoftware.com/blog/overcoming-four-common-problems-with-retrospectives