采访及书评 -- 回顾手册

Patrick Kua 最近写了一本书，名叫《回顾手册：敏捷项目向导》。在这本书中，Pat 总结了他过去几年在真正的敏捷团队中做回顾的经验。电子版在 LeanPub 出售。LeanPub 同时还提供了免费样章。

作者在书中介绍了一些如何准备回顾会议的宝贵建议，他详实描述了为了保证参与者交流顺畅，应该如何有效控制时间、使用合适的材料、布置会场。

书中有一章专门讲怎样组织分布式回顾，这部分内容对离岸 / 分布式团队很有借鉴意义。它推荐在每个地点都使用视频接入，并通过多个引导者（facilitator）和各种在线工具在各地之间共享信息。书中还提到了在多文化背景下会遭遇到的一些社交方面的挑战，也针对这些问题提供了建议。

敏捷团队或许会因为一再使用同一种回顾方式而感到厌倦。书中的一些小贴士可以保证回顾会议常开常新：人们可以每次问一些不同的问题，或者改变一下环境，让大家保持新鲜感，积极参与。

全书共分 10 章

• 回顾的基石
• 准备回顾
• 引导回顾
• 首次引导小贴士
• 分布式回顾
• 其他回顾形式
• 回顾之后
• 常见的回顾坏味道
• 回顾保鲜
• 尾声

Patrick Kua 最近接受了 InfoQ 编辑 Anand Vishwanath 的采访

InfoQ：你可否跟我们的读者简单介绍下自己？

Pat：没问题。我在日常工作中扮演的是技术领导的角色，我的团队都用了很多敏捷实践。我在敏捷环境中工作大概有十年了，经历了各种环境，各种不同的“敏捷”风格。我也辅导培训过很多团队和组织，对学习和持续改进背后的理念特别感兴趣，所以把回顾当作一项核心敏捷实践。

InfoQ：是什么促使你写一本回顾方面的书的？

Pat：在我做敏捷开发，做讲师，做教练的那些年里，我参加或者引导过不计其数的回顾。有些人引导的时候，会一再重复某种模式，或好或坏。我也跟很多人聊过，他们觉得从回顾中看不到任何好处。究其原因，常常是或者准备不充分，或者引导者经验不足，或者是形式重复枯燥。虽然很多敏捷实践都容易出现类似的“初学者行为”，我还是对回顾的话题兴趣最大。

我觉得回顾是敏捷实践中极重要的一项，因为它体现出了敏捷宣言中列出的“响应变化”和“探寻更好的软件开发方法”的原则。而且，如果回顾做得好的话，它可以创造出立足点给一些站得住脚的改变。

InfoQ：这本书和其他有关回顾的书有什么不同？

Pat：讲回顾的书只有另外两本，我现在还会把它们推荐给别人看，因为它们做入门指导是非常棒的，而且书里面还提供了丰富的练习，团队可以吸收借鉴到自己的环境。

《回顾手册》这本书的重点是帮助团队让回顾变得更加高效。我见过许多团队在同样的问题上陷足泥潭，这本书可以帮助解决这些问题。我会把引导者的经验分享出来，让读者可以深入了解其他团队准备、运行、引导回顾的不同方式，书中列举的小技巧也有助于让回顾变得焕然一新。

我知道，很多团队所处的环境离敏捷方法所推崇的小团队、同地开发相距甚远，他们很希望了解怎么调整回顾形式，让它能在分布式团队或者大型团队中运作。这类问题在 Retrospectives 邮件组中经常出现，在我们公司内部的邮件组中出现得更加频繁。我希望能够给大家提供一个资源，在这里能够读到所有的推荐方案、技巧、工具，帮助各种回顾“形式”的顺利开展。

InfoQ：在你引导回顾的时候，遇到过什么普遍性的问题么？

Pat： 问题有很多啊。我遇到过的一个最大的问题是团队找不到独立的引导者，只能从团队里面找一个人出来引导回顾。这就会有潜在的利益冲突，因为引导者不再保持中立了。一方面来看，从团队中选人出来引导也是有好处的，因为引导者会对话题有足够的了解，能够问出比较尖锐的问题；但从另一方面看，大多数人在引导的时候都无法把自己的观点分离出来，所以谈话总是带有偏见的——这是我的亲身体会。

我也曾见过团队中的引导者大多数时候都是由比较权威的角色担任（如团队领导，项目经理，Scrum Master 等等）。因为这种关系的存在，团队有时候就不能畅所欲言，或者有意回避某个有争议的话题，避免挑战处于权威地位的人。

引导回顾时的另一个常见问题是引导者没有接受过良好的训练：谈话会被中途切断；问题可能没有得到回答；人们会说“做了再看”吧，可做的时候就脱离了当时的上下文，于是便得到了一个不一样的结果。幸运的是，引导的技巧比比皆是，相关的书籍也是随处可见。从团队中选引导者带来的问题，也可以通过各成员轮换的方式得到解决。但我还要强调一下，保证引导者具有良好的引导技巧，这件事情还是很重要的。

InfoQ：你在回顾中观察到的常见的坏味道有哪些？

Pat：常见的坏味道包括准备不足、一种活动一再重复、在重要话题上讨论不充分。

当我们看到引导者在回顾现场花时间布置会场，分发材料──笔和贴纸，我们就是知道他 / 她犯了准备不足的毛病了。很多人都没意识到，回顾会议跟其他会议一样，都是需要提前做准备的──比如整理材料和布置房间，在会议开始以后就要把精力从流程本身转移到谈话上。开始之前的准备工作会花些精力，但它会有所回报的。我自己倾向于在回顾之前花至少半个小时做准备工作。

如果一种活动一再重复，回顾就会变得枯燥乏味。稍稍改变点形式，或者改几个问题，就会出现意料之外的效果，因为这时候团队就会从另一个角度来看待当前的上下文了。另外两本回顾的书提供了大量的可选方案和资料，敏捷回顾维基百科上也有许多可以参考的点子。

我也见到过有的团队常常没怎么花时间讨论问题根源，就匆匆得出解决方案。没有完整了解事情真相之前，行动往往与事无益。所以大家还是应该在讨论不同方案的不同影响之前，先多花点时间收集事实，然后再去讨论孰优孰劣。

InfoQ：你对那些刚开始引导回顾的人有什么建议么？

Pat: 书里有整整一章是为这部分读者写的。我觉得从个人角度来讲有很多事情可以做，首先，如果对引导这件事情没什么概念的话，先去参加一下培训，或者至少读一本引导技巧相关的书。在工具箱里面多放几件引导工具，为应对各种场景做好准备。另外还可以去当一个旁观者，仔细观察其他人怎么做，问他们为什么这么做。旁观其他引导者跟结对编程很类似，双方都可以从角色互换中收益。你可以看到怎样做有效果，怎样做没效果，可以深入了解其他人在不同情况下的处理方式。当你问其他引导者为什么这样做的时候，也可以帮助对方把思考过程清晰地整理出来，这一点往往是他们从前没意识到的，在讨论过程中对方也会有很大收获。 作者简介

作者简介

Patrick Kua在 ThoughtWorks 工作，富有激情与活力，是一名通才型专家，不喜欢被束缚。他一直在带领技术团队，常常培训团队和组织实施敏捷和精益方法，偶尔也会引导人们走出逆境。Patrick 热衷于学习和持续改进，也会帮助他人燃起学习和持续改进的激情。

评论者简介

Anand Vishwanath（Twitter 帐号为 @anand003）是一名敏捷教练和项目经理。他 2002 年以 Java 和.NET 程序员的身份，在 ThoughtWorks 开始了职业生涯。Anand 为各个国家的客户提供敏捷咨询和实施服务。他也在

个人博客上记录实战经验。