敏捷开发：如何通过回顾保持学习状态

　　英文原文： How To: Live and Learn with Retrospectives

　　软件开发不是孤独的追击，它需要同其他开发者和其他部门协作。大多数组织建立的软件生命周期没有涉及到如何进行这些交互。现实是许多团队的过程并不符合他们的要求或没有得到一贯地遵循。当发生这种情况时，很容易让人产生抱怨情绪，如果你已经有了改进的想法却又无从下手，也会让人感到沮丧。本文提供了一个工具，可以帮助你的团队基于其日常经验进行过程改进。回顾是工具，团队可以利用它来产生积极的变化：从遵循过程到驾驭过程。

　　回顾是会议，让整个团队都参与到检查过去的事件过程中，并对就今后如何更高效的工作进行头脑风暴。团队根据获得教训制定对应措施，并应用于自身。本文旨在说明为推动你的团队进行回顾，你需要做些什么。

　　背景

　　术语“回顾”是由Norman Kerth在其著作《项目回顾：团队审查手册》[1]中创造的。书中描述了如何推动团队在项目结束时举行三天脱岗会议（off-site meetings），以总结经验教训。这种回顾是一种履行后检查（post-implementation review）——有时称为验尸（post-mortems）！等到项目结束时才开始总结经验教训是一件憾事。在2001年，极限编程团队将回顾纳入迭代周期[2]。回顾被加入到另一种敏捷方法 —— Scrum[3]中。并且，在项目生命周期内举行多次简短的“心跳”回顾，是现今采用敏捷方法团队普遍的做法，这使得他们能够在项目进行期间就能收集和总结其开发过程的经验教训，而不是等到项目结束后。

　　从经验中学习

　　没有经过反省的经验仅仅是数据而已。退一步说，反省我们的经验是我们日常生活中学习和转变的方式。举一个简单的例子，如果我在开车上班途中碰到了严重堵车，我会考虑换一条路径，甚至用其他方式赶到办公室。经过几次试验后，我会习惯于一个新的路径。

　　如果人们不愿意做那些注定要重复的工作，说明他们并不是真正地在工作（有些疯狂的定义）。虽然回顾始于回首往事，但这样做的原因是为了改变我们未来的行事方法 —— 回顾是在进行长远地转变。有时候，我们必须重新思考我们的做法，而不是试图以加快现有过程。

　　回顾还能改善团队沟通。有一个古老的格言“共享的问题就是减半的问题（a problem shared is a problem halved）”。把我们的经验复述给朋友和同事是我们日常生活中都做过的事情。在团队的成果中，没有人知道完整故事的始末。完整的故事只能通过整理个体经验来了解。通过探讨如何从不同的视角感知同一事件，团队成员能够更好的了解对方，并调整了团队中人们的需求。

　　化解定时炸弹

　　让我们看看如何举行一次有效的回顾。当团队一直受到压力或面临严重困难时，人们的脾气可能变大了，而且团队成员间的关系可能已经出了问题。指望通过把团队集中在房间里一起讨论近来发生的事情简直就是奇迹，这有点不切实际。像任何富有成果的会议一样，回顾需要明确的议程和主持人去保持会议平稳进行。如果没有这些措施，会谈很可能会充满批评和指责。这只会使进入房间的每个人发泄他们的不满情绪，不可能解决任何问题的，甚至还可能使问题加重。

　　回顾采用精心设计的结构来消除分歧，将重点转移到学习和借鉴已有经验上。基本技巧是放慢谈话节奏，在完全探究大家对事件的不同看法之后，再下结论。

　　基本指令

　　检查过去的事件但不评判发生了什么，这更容易使我们转而问：下次是否可以做得更好? 关键是要采用系统思考的角度。为了对此有所帮助，应维持如下假设：问题出在系统创建期间而非个人，这是Norm Kerth所宣称的回顾基本指令，它是所有回顾的基本原则。

基本指令：不管我们发现了什么，我们必须明白并真正相信，在给定时间、其自身的技能和能力、可用资源及最近状态的前提下，每个人都尽力做到了最好。

　　该基本指令的意图经常被误解。显然，有时候人们乱作一团时 —— 或许他们不知道有更好做法，或许他们真的很懒或很残忍。但是在回顾过程中我们的焦点单单是做出改进，因而我们用该基本指令来帮助我们保持在处于有建设性的方式之中。至于个人的拙劣表现则最好交由管理者或人力资源（HR）部来处理，基本指令将这种交流设定在回顾的范围之外。

　　基本规则入门

　　为了有效进行回顾，需要有人推动会议。主持人应努力营造一种气氛，使团队成员对谈话感到轻松。

　　设置基本规则和回顾目标有助于回顾顺利进行。还有一些明显地规则是适用于大多数有成效的会议的，比如设置手机为静音状态。那么我们还需要为回顾增加些什么特别地规则呢？听取每个人的意见是很重要的，因此一个重要的基本规则是“不要打断”，如果在某个激动的瞬间该规则受到了忽视，那么你可以尝试使用“说话棒” —— 某一时间只有一个人可以说话，即持有说话棒令牌的人（令牌不一定非是一根棒子，它可以是办公室的任何东西，如杯子。我所工作过团队用的是一个毛绒玩具，它比杯子更适合在屋里扔来扔去）。

　　一旦会议基本规则建立起来了，就应该把规则写到活动挂图纸（flipchart paper）上，并张贴在人人都能看见的墙上。如果人们开始忘记基本规则了，那么主持人的工作就是提醒大家。例如，如果有人在会议室接听了电话，主持人应该和气地引导其离开，这样他的谈话内容不会干扰到回顾。

　　安全检查

　　另一项重要的基本规则是可选的，即在回顾中参与练习。有些人在小组讨论中可能感到不自在或被揭发了，如果你想让他们在回顾中作出贡献的话，不要在他们的感觉上再雪上加霜是很重要的。当一个团队做最初几次回顾时，执行“安全检查”是很有用的，以了解谁能轻松的对待谈话。来一个匿名投票可以做到这一点，匿名投票要求每个人说明他们多想在回顾中发言，在小纸片上写下范围从1到5的一个数字（1表示“不可能分享我的观点”，5表示“完全可以公开谈论”），主持人收集并统计这些选票，将结果张贴在房间的活动挂图（flipchart）上。此举目的是让与会者认识到，房间里人们相互信任程度是不同的，让主持人评估在随后的讨论中采用何种形势。如果个人的信任程度比较低，让人们在更小的组里工作，并做更多的练习（人们可以匿名的写出评论）是有效的做法。

　　动作回放

　　运动员利用动作回放来分析自己的动作并寻求改进。在回顾里与之等价的是时间线（Timeline）。

　　首先为团队建立一个空间，将过去的事件按发生顺序张贴出来；从左至右，从过去到现在。每个团队成员用彩色便签（或索引卡）加入时间线。主持人为每种颜色的卡片定义一重含义。例如，粉红——消极事件，黄——中性事件，绿——积极事件。用颜色有助于在这一系列事件中显示出图案。会议的这一部分通常进行地很快，因为团队成员是并行建立一个共同的图案。

　　创建时间线的练习有几个服务宗旨——帮助团队记住都发生了什么事情，为团队的每个人提供机会以张贴要谈论的话题，并试图将讨论定位在实际事件而非大概的预感上。事件时间线是一个短暂的中间成果，以帮助提醒团队都发生了什么事情，但它通常不作为回顾的最终产出。

　　总结教训

　　一旦对事件达成了一致的观点，团队就可以开始总结教训了。让团队按时间线从开始走到结束，其目的是确定：“什么是行之有效的，我们要记住?”，“下次有什么不同做法?” ，“什么还仍然困扰着我们?”。

　　主持人阅读在时间线上的每个注解，并邀请他们作出评论。团队既要找出好的经验和也要总结坏的教训。这个阶段提醒团队是很重要的，我们的想法是要为未来的行动计划找出具体的解决方案。

　　作为主持人，尝试抄写下写字板（或其他看得见的空间）上交流内容的摘要信息，但需与团队一起检查你所抄写的东西是否准确代表了原意。记下原始表达观点有助于显示一个人的关切已经受到了聆听。

　　根据我的经验，开发者倾向于抽象地谈论一些事情——产生无确实证据的观点。作为主持人，深层挖掘、检查假设和推论（请开发者提供具体的例子来支持其所提出的观点）都是很重要的。

　　行动计划

　　通常，大多问题被确定但还不能立即采取行动。团队在开始计划行动前必须先发现问题。团队必须用现实的思维模式而非想象的思维模式。在迭代结束回顾中，不超过3至5项行动将是一个合理的限度。

　　在设置任何新的行动之前，团队应该检查在以前的回顾中是否有出色的行动。如果有，值得探讨一下该行动为什么及是否需要重塑。有时人们确定行动时野心太大，需要减小他们所能实际实现的事情的范围。对每一项行动，尝试从下一步目标（可能是一小步）中分离出长远目标。团队甚至可能决定试试水，把采用新的工作方法改进流程作为实验，在下一次回顾时检验其效力。区分短期修改和解决根源问题也很重要。团队应该需要两种类型的行动，有本书提供了好的模式，用以区分行动的类型，它是Edward De Bono所著的“六双行动鞋”[4]。

　　每次行动都需要一个负责人负责交付，找个哥们儿并与其一起工作，以确保在下一次回顾之前完成行动，可能是一个好主意。有些行动可能是团队外界的直接势力范围，需要管理层支持。为获得支持，团队可能需要出售这些问题！在这种情况下，你的第一个行动是搜集证据，以帮助团队说服老板行动起来。

　　包装

　　在结束回顾之前，主持人需要明确会议将会有怎样的产出。团队可以在其工作区的墙纸墙上展示其行动。或者可以用数码相机记录下写字板纸/白板上的内容，照片可以上传到一个文件共享空间或传送到团队的wiki上。在使产出在组织范围内可见之前，主持人需要与团队一起检查公布该产出是否令人不自在。

　　完善回顾

　　进行回顾有利于磨练你的主持技巧——回顾需要准备和全程跟随。主持人应该预先做完时间的分配工作并不时地改变练习。Esther Derby 和 Diana Larsen所著的“敏捷回顾”是新练习好的资料来源。它给出了一个粗的时间分配指导——团队每周需要30分钟回顾时间，按此计算，每月需要2小时、几个月需要一整天进行回顾。

　　此外，为规划时间和形式，主持人还需要审查：谁应该来？在哪里举行会议？何时举行会议？当一个团队开始回顾，他们会发现他们团队内部付出了大量的行动。一旦团队有自己的房子，通常将与其他团队交互，扩大邀请名单以包括团队之外的人员以获取更广的视角，这样做是有价值的。

　　作为团队领导或经理，当你有观点和看法想与大家分享的时，有时难以发挥中立调解者的角色。如果你与其他使用回顾的团队并肩工作，那么团队间可以互相推动。

　　作为标准做法，在我的回顾结束时，我从参与者那儿收集了“投入时间回报”率，如果你正在尝试在组织内建立一个主持人团队，那么收集这些参与者反馈很可能将有助于新的主持人理解他们所做的事情。

　　找到合适的会议场所能产生的效果有很大不同. 挑选一处远离你正常工作区的会议室可以避免人们在回顾到一半又转回到工作上。尽可能设法避免会议室的布局——围坐在一个大桌子周围立刻会给团队成员之间设置巨大的障碍——取而代之，你可以把几个椅子布置成半圆形。你还需要一下检查室内，至少要有两米长的干净墙壁或白板。当一个地点被登记用作回顾时，检查那儿有无空间能将纸挂在墙上是很重要的。有时我被安排在一个有大量墙纸、书架和古董书画的会议室主持回顾，只好利用门、窗或在桌子的尽头搞一个临时的张贴空间。

　　至于时间，当工作在一个迭代计划周期内，你需要在下一个跌代计划之前举行回顾。但是如果接连举行回顾与计划会议将使每个人疲惫不堪，因此试着将这两个会议分成上下午，甚至单独一天。

　　最后一句话

　　I有时我被一些想了解更多关于回顾的人问到这样的问题，“你能举例说明回顾能产生巨大的成果吗?”。我已认识到这个问题类似于“你能不能讲讲这种疾病是如何由正规的治疗方法治愈的?”

　　我曾工作过一些团队，他们长期进行正规的心跳回顾已经使其发生了很大的变化，但这种改变是逐步的而缓慢的，他们并没有制造头条新闻。例如，我曾工作过的一个团队，有一个关于在计划产品开发跌代期间如何处理业务变更的问题。我们花了几个月的时间才为每个人建立了计划，但是如果没有回顾过程可能需要更多的时间。

　　定期回顾和定期实践的能力是他们避免了重大问题的发生，所以没有战争故事或神奇的转变是应该的！拥抱回顾有助于一个团队以合适的步调来调整他们的过程。

　　作者简介

　　Rachel Davies是一个独立敏捷教练，位于在英国。 Rachel经常出席行业会议，她是敏捷联盟的理事。 欲与之联系，可以访问她的网站 。

　　参考资料

　　1. “项目回顾：团队审查手册 ”,Norman L. Kerth. Dorset House著。ISBN:0-932633-44-7

　　2. “适应：XP风格 ”xp2001会议文件，Chris Collins 和 Roy Miller著，Rolemodel Software

　　3. “使用Scrum管理敏捷项目 ”，Ken Schwaber著。微软出版社，2004年。ISBN:978-0735619937

　　4. “六双行动鞋 ” Edward De Bono HarperCollins著，1993。ISBN:978-0006379546

　　5. “敏捷回顾：使好团队变得卓越 ” Esther Derby 和 Diana Larsen著。Pragmatic Programmers，2006。ISBN:0-9776166-4-9