Dreamhead觉得等待发布是件很爽的事。当然确实是很爽的事。不过，《 最后期限 》里面贝琳达这样描述电影里的巴顿将军：

    “片子开始的那一幕，巴顿‘指挥’战役的那一幕，我们那位年轻的朋友所说的那一幕：呵呵，巴顿在那一幕里根本连一条命令都没下过。他只是从望远镜里看着整个战役。德军坦克分队像他预料的那样穿过山谷，而他就看着那些坦克。在那儿，在第一辆坦克上，站着一位军官，手里拿着马鞭。巴顿盯着他，说道：‘隆美尔，我读过你的书。’他读过隆美尔的书，所以他很清楚隆美尔会怎么做。然后，战斗打响了。进攻，侧翼机动，佯装撤退，再次进攻，空中支援，后备队到达。巴顿只是看着，根本没有下达哪怕一条命令。”

如果一件事会成功，在最后一天之前它已注定会成功；如果它会失败，最后一天之前它已注定失败。所以我对这个“最后一天”没什么感觉。做一些和往常一样简单的事，让一些注定发生的事情发生而已。平常的一天而已。

重温在贝琳达的评论之前，一个颇有些代表性的项目经理是如何在记忆中构造巴顿将军的：

    “我想，我就像巴顿。我是说，项目经理就像是巴顿。必须这样。就像在电影的第一个战争场景，直接打击隆美尔那样。他就是策划整个战役的那个人，他指挥每一次炮击。”

    这个年轻人站了起来，在虚拟的战场上挥舞着手臂：“空中支援！他这样说，然后空中支援就来了。收到—收到—收到！轰隆！转向侧翼！这儿！那儿！左侧编队，进攻！进攻！现在撤下来，赶紧撤下来！快！现在等着，等着，等我的命令……就是现在！进攻，进攻，把所有的炮弹都扔给他们！右翼，切断他们的后续部队！是的，就是那儿，就是那儿。现在我要更多的轰炸机，把炸弹丢在中间。好了，现在该决个胜负了，后备队，上。后备队从左侧进攻，快。是的，就是那儿，就是那儿，敌人绝对不会想到。嘣！轰隆！把他们全干掉！耶！！”

5年前也许我也这样想。人们需要像贝琳达那样把自己累垮，然后学会用简单的方式获胜。

---

作者介绍
熊节是ThoughtWorks公司的咨询师，曾参与《重构：改善既有代码的设计（中文版）》、《J2EE核心模式（原书第2版）》、《Contributing to Eclipse中文版》等图书的翻译。目前正在从事Ruby on Rails的项目，并致力于敏捷方法与思想的推广。

最近很多人都问我，有没有适合的人可以推荐给他们公司，他们正在招人，面试了很多个，但有经验的开发人员太难找了。有一个朋友在问我要人的同时，他手下的一个开发人员反而问我有没有好的机会，他想跳槽。

不久前一份报告称，中国本地软件企业面临的最大问题之一，就是高级技术人才的缺乏。造成这种问题的原因，主要是由于本地软件企业的人才培养机制和管理机制的欠缺。人才大量涌入外资企业和频繁的流动，导致了各类有经验人才的欠缺。

每个人都会梦想自己的理想工作。做技术的开发人员要求的更是简单：一个能够不断学到新知识和新技能的职位，一个融洽的团队，一个舒适宽松的开发环境，一份成长的空间。而这些简单的需要，恰恰是许多公司所忽视的地方。这些东西，很多时候就是一个人决定离职的因素。

有的公司认为开发团队是成本中心，所以给他们买最便宜的桌椅——而恰恰是开发人员们一天都依赖于这样的桌椅为公司创造价值；有的公司觉得自己的一套软件不停的实施就能不停盈利——而开发人员最厌烦的就是做重复性工作；有的公司要求开发人员必须上班打卡——好的，那开发人员绝对不会晚下班一分钟。有的公司从来不举行内部的技术交流和培训活动——而开发人员希望的技术提高绝不仅仅是只靠读书能够完成的。

公司要依靠软件来盈利。而要开发一个成功的软件项目，人的作用是第一位的。而个人的力量相对于整个团队来说，又是微不足道的。稍微有点规模项目的成功都是集体努力的结果，而不是靠一两个英雄程序员能够完成的。为了能够保持一个稳定和高效的团队，建设一个吸引开发人员的环境和氛围是所有公司的管理人员们应该考虑的一件事。一个核心的产品开发人员离职，很可能使得当前的项目或订单陷入瘫痪，这目前已经成为了影响许多中小公司存亡的大事。

我所在的公司不仅仅以敏捷过程著称，同时，它以其特有的文化和团队氛围吸引了一大批高水平的开发人员。他们不仅仅是认同敏捷而聚在一起，更多的是，他们向往着这种平等、自由、轻松、快乐的空气。

人与团队

在公司一个典型的敏捷团队中，大致有四种不同角色：项目经理、业务分析师、开发工程师、测试工程师。同时，根据项目不同可能还需要：美术设计师、数据库工程师、系统工程师、交互设计师等不同人员。虽然在项目中不同的人需要确定一个角色，并担负相应的责任，但在公司内部，人与人之间是完全平等没有级别区分的。这种平等的文化，就使得人与人之间的交流不会因为等级差距而丧失。同时公司鼓励每个人向其感兴趣的其他领域发展，成为综合性人才。例如某个人现在是开发人员，但他也可以通过帮助项目经理做一些辅助工作，来学习项目管理方法，从而最终成为独当一面的项目经理。

项目成功的一个重要因素就是交流。保障团队内外顺利交流是项目经理的责任之一。公司鼓励员工之间交流看法和讨论问题。在公司内部，如果有闲暇时间，随时可安排一场讲座。这些讲座都是由员工自发组织和自愿开展，话题多种多样，不仅仅限于技术。经济、法律、业务知识等等，都是大家平时感兴趣的领域。在项目中，定期的Lunch Learning也是公司项目的一大特色。和客户一起围坐在餐桌前，边享受公司提供的午餐边讨论项目中的技术，团队的学习交流气氛自然会无限高涨。

除了自发的、自由的交流，还有一些约定的交流时间和形式，例如，每天的站立会议。你要说出昨天做了些什么，今天会做些什么，遇到了什么困难是否需要别人的帮助。站立会议鼓励每个人说出事情的真相。有了困难就大胆的向你最值得信任的同伴来寻求帮助，没有人会嘲笑你，也没有人会冷漠的不去理睬你的困境。一个自组织的团队，应当是一个温馨而又和谐的集体。每个人都会努力的帮助其他的人，帮他解决他的问题并从中积累更多的经验。
 


无论是在项目中还是在个人的发展过程中，回顾与总结都是一个必不可缺的步骤。公司内部任何事情告一段落的时候都会有一个总结活动。迭代总结，项目总结，发布总结，陪训总结等。在这段时间内什么做的好，什么做的不好，如何进行改进。任何的过程和成绩都不能是静止不变的。只有不断的反省和总结，才能够在未来的发展中进一步提高。项目团队一起召开总结会议活动，在这个活动中，任何人不能够对其他人进行指责和攻击，一切都应该以互相信任为基础，我们的目的是提高下次的工作效率和增强同伴的信心，而不是批斗和推卸责任。公司对员工的绩效考核，也是类似的由一起工作过的同伴来进行评价，360度全方位考核。这种定期的总结和回顾，提供给了员工与团队自我成长的机会。

除了内部的交流，公司还鼓励员工进行技术创新和参与其他社会活动，例如参与开源软件开发、撰写书籍、向杂志投稿、参加和举办技术社群活动等。这些对技术社区的贡献，不仅仅能够提高员工个人的能力，同时还展现了公司员工的整体能力和提升了公司的知名度。对公司和个人来说是双赢。

环境与工具

如果你有机会到我们的办公室，你就会发现，每一张墙都被占得满满的。墙上可能会贴满了各种颜色的小卡片，这些都是正在进行的项目的需求。每张卡片都是一条用户故事，开发人员根据用户故事实现系统功能。这种被贴在墙上的一目了然的管理方法叫做可视化管理。在公司内部，开发、招聘、销售等各种流程的状态都被一一列在墙上。一来可以作为工作的进展图公示于众，二来可以使每个感兴趣的人都可以随时提出他的想法或主意，集思广益，将工作做到最好。
 


公司采用大长桌作为开发用桌。座位之间没有隔板。一方面适合与敏捷开发中的结对编程实践，另一方面可以减少隔板带来的交流障碍。如果你到一个采用隔板的公司去走一圈，再来比较公司的工作环境，就会明显的感受到交流频度和广度的明显不同。公司提供给开发人员舒适的座椅，带有扶手并可以调节高度和后仰角度，以适合每个人不同的需要。如果中午工作累了，还可以躺在椅子上小憩一会养足精神以便下午更好的投入到工作中。
 


在项目中，必不可缺的交流工具是白板和纸。再没有比这更廉价和更好用的工具了。两个开发人员遇到了分歧，两人走到白板前写写画画，很快，一副清晰的系统脉络就出现在两人面前。分歧达成了一致，开发继续进行，而图像留在白板上，任何过路的程序员都可以驻足观看，如果感兴趣还可以问一问作者，更深入的探讨。在开发的过程中，随时遇到问题或需要记录的，都可以立即写在手头的白纸上，一些简单的算法草稿，也都是用白纸完成。这些白纸多是打印用过一面的纸张，环保而又经济。

我公司和其他大多数外企公司一样，为员工提供免费的饮料和零食。每天早上，公司的面包机都会工作个不停，烤面包的香气会和着咖啡的味道飘扬在空气中。午饭后，从冰箱中拿出一罐健怡可乐，冰凉爽口，喝下后休息一下就可以精神十足的开展下午的工作。下午四五点钟，正是开始感到饿的时候，到零食区找一块巧克力吃补充一下体力，顺便休息几分钟，活动一下筋骨。
 


公司还在办公室内放了一台电视机和一台PS2，午饭后和下班后，你可以和同事相约PK一场实况足球，既休息了神经，又和同事加深了感情。公司还经常组织各种体育活动。每周租一次羽毛球场，让长期在电脑前工作的员工运动运动，有助于身体健康。

以上这些是我公司在团队文化建设的一些做法，提出这些供大家参考，希望更多的公司管理人员，能够从中或多或少的汲取一些经验，将之用于提高公司开发人员的物理和人文环境。

改造公司的开发环境，可以先从很简单的做起，例如，在办公室的一角开辟一处饮食区，提供免费的饮料和食品；在走廊上挂一个白板，随时有人记录一些东西；为员工提供更舒适的座椅。这些东西花不了多少成本，但其收效是明显的。不论是技术部门还是其他部门，都会为公司这一点点人性化的举动感到高兴。有了高昂的士气，做事情自然也会更加积极高效。不需要公司一下子全部改变，但往往一点点的细节变化就能够获得全体人员的支持。虽然有些投资，但员工给公司的回报会更多。

无论是敏捷开发理论还是精益管理理论中，都提到团队的作用是最重要的。如果能够发挥人的能动作用，并良好的保持下去。我想，没有什么目标是我们完不成的。如果所有的公司都能够提供良好的环境给开发人员，那不仅仅是开发人员的的幸事，更是我们整个中国IT界的一大幸事了。

---

作者介绍
李默，ThoughtWorks公司咨询师、业务分析师，敏捷过程教练，BJUG(www.bjug.org)创始人之一。网名为“冰云”。目前主要专注于软件需求管理与市场营销的协作、产品交互设计、组织过程改进等方面的内容。

最近有人和我谈起他们的项目管理。他是一个项目经理，负责项目的进度跟踪和与客户的沟通。他能够很好的保持客户关系。他的团队中有一个年轻的程序员，工作充满热情，喜欢思考，喜欢用新技术，也很勇于指出问题。

有一天，这个年轻的程序员在客户处外勤，跟客户交流的时候，讨论到了系统某一块儿的功能。年轻的程序员基于他的工作热情，向客户提出，如果这么这么做，那可能会给你带来更好的功能。客户听了挺高兴，觉得可行，这小伙说的不错。于是就反映到了项目经理处，说这小伙干的不赖，表扬表扬。这项目经理听到客户的表扬，也附和的说，他确实很上进，回头我再给他当众表扬一下。

项目经理回到了公司，就把这程序员单独叫来聊了一下，他说，你给客户提建议，这样多思考挺好的，不过，咱们给客户开发，要一单一单的做。你说的那个功能我早就想到了，但我没提，主要是考虑这个功能实现起来很容易，我们可以放在下一期，我们引导客户一下，让他们提出，我们再把它说的复杂艰巨点，这样咱们很容易就能完成任务，下一期时间更充裕，而且还能收更多的钱。所以以后有想法咱们内部讨论，先别跟客户说。程序员点头称是。

这样的事情在很多公司都很常见。他们把客户视作敌方阵营，利用自己对IT知识优势了解，努力在一些地方上欺瞒和糊弄客户。

与客户成为敌对的关系，就难免要进行谈判。客户希望用低廉的价格买到他希望的功能，或者说，在一定价格内实现更多的功能。而公司希望提高价格，降低成本。两方表面上达成共识，实际上都在暗地博弈，要在边边角角上沾点小便宜。而这种博弈结果，就是双方都不能达到最好的情况。就像著名的囚徒困境，结局就是纳什均衡(Nash equilibrium)，或非合作均衡。

软件开发的最终目的是要给用户交付价值，要达到客户的商业目标，从而完成公司目标。而为了实现客户和公司的双赢，咨询公司采用了加深客户协作的方式来达成目标。咨询师会和客户一起工作，了解和认识客户，提出针对性的建议，帮助客户发现和识别业务价值，改进目前的系统。咨询师会站在和客户同一方的阵营，和客户一起思考、学习和成长。虽然说起来很粗泛，但我所认识的每个咨询师确实都在认认真真的为客户考虑。

另一个会产生非合作均衡现象的是按时收费的单价合同和固定价格固定范围合同的问题。一般PM书籍上都会讲FFP合同对买方的风险比较低，而单价合同对于买方风险可高可低，取决于内容和项目性质。

如果签订固定价格合同，通常的，由于价格固定，客户会倾向于在这个价格内挤入更多的需求，有些人甚至不顾质量而要求更多的特性，反正完成不了都是开发方的责任。而相对的，开发公司会希望在这里面减少成本，或者是人，或者是需求范围，甚至是不惜牺牲质量。最终两方博弈的结果就是项目出了问题。

这种情况下，更好的办法是单价合同，或者具体说，就是确定阶段时间内的开发力量，但不确定开发范围的收费方式。按照客户需求的优先级来开发，双方合作，尽最大的努力，频繁交付。这种做法的好处是，客户可以控制项目的长短。可以不停的做下去，也可以立即随时终止。由于双方的协作，开发公司也会按照自己的能力，尽最大可能来保证质量和进度。另一种改进过的单价合同，是基于开发方对项目的理解和估算，报出一个固定价格。在合作共赢的前提下，双方信任并接受这个契约。这种情况好像更加适合国内的甲方。

前些天，一个原来的同事电话我，她以前是负责销售的，现在自己开了家公司。她雇佣了一个公司给她开发软件，开发了两个多月了还没见到是什么样子。眼看就要到交付期限了，她想去看看，就问我应该怎么样去中期查验这软件。我告诉她，要怎么怎么样才能看出这系统到底能不能做完，怎么看出到底做的质量如何等等。

瞧瞧，怎么样，客户也不是很好糊弄的嘛。你糊弄客户，焉知客户不会另请人来对付你？所以，在商业的博弈中，合作才能双赢。这就是为什么客户协作 over 合同谈判的原因了。

---

作者介绍
李默，ThoughtWorks公司咨询师、业务分析师，敏捷过程教练，BJUG(www.bjug.org)创始人之一。网名为“冰云”。目前主要专注于软件需求管理与市场营销的协作、产品交互设计、组织过程改进等方面的内容。

来源：IT168

极限编程（XP）的创始人和“敏捷软件开发宣言”的执笔者之一，Ken Beck，一直是敏捷编程的倡导者，他认为敏捷编程可以缩短软件开发项目的开发周期。近日他参加了旧金山举行的Qcon大会，并接受了媒体的采访，谈论了敏捷开发的相关问题。
 
记者：你能谈论一下敏捷宣言和极限编程（XP）吗？
 
Ken Beck：在极限编程（XP）后面的基本设想是，肯定有一些对软件开发有帮助的敏捷行为。我曾经问过这个问题，“假若我们尽最大的热情来进行软件开发，会发生什么？”这就是“极限（Extreme）一词的由来。结果证明，如果你采取其中的一些做法，例如技术上的协作、测试，并比以前更加努力的推行这些做法，至少在一般的软件开发项目中你会获得比较好的结果。例如你的错误率会比较低，这意味着你可以更频繁的发布新版本软件。你能够以非常低的成本让项目启动进入最佳的可部署状态，与其他风格的开发模式相比，你获得了更低的开发成本和更短的开发周期。而且如果你将这种理念融入到后续的设计中，持续的对设计进行认真的投入，你可以在很长一段时间内以一种非常稳定的速率来继续部署新的功能。
 
这就是敏捷编程如何启动的方式，事实证明为了实现所有上述目标，无论是作为一个团队还是一个个体，你还必须学习许多新的社会技能：诚实、无私、有责任心。在获得一定的开发速度后，接下来的目标是，如果你想更快的进入下一步，你所要做的是能够更清晰和透明的交流正在进行的开发工作。
 
记者：你提到了推动敏捷编程发展的风格：可靠性、变化的低成本、增加的投资回报率。为什么软件开发市场正在从瀑布风格转向敏捷开发风格呢？或者现在是否只有一小部分开发者正在使用这个方法？
 
Ken Beck：是的，现在是只有一小部分开发者正在使用敏捷方法，但是我认为这一数字正在非常迅速的增长。我虽然没有明确的数字来证实我的观点，但是如果你关注一下敏捷开发者大会的增长，你会清晰的感觉到这一点。我认为现在推动敏捷开发的因素是这种开发风格更加贴近真实环境、更透明和更有责任感，如果你的开发周期比较短你会决定它就是你希望实现的开发方式。对于那些尊崇真实至上的软件开发，存在着巨大的潜在市场。
 
记者：为什么使用者还比较少？
 
Ken Beck：因为它存在的时间还不是很长。
 
记者：你今天早晨提到这个问题：用户不得不自己来确认你的软件是否可以正常使用。这本来是一件理所当然的事情，但是事实并非如此。为什么会出现这种情况？
 
Ken Beck：嗯，我认为造成这种现象的原因比较复杂，是技术和社会因素的综合原因导致了在已部署的软件中存在所有的缺陷。一部分原因是人们抱有软件天生就是不可靠的态度，客户习惯了这种状况。开发者习惯了接受这种观点。测试者也对此习惯了。我们只是觉得它像天气一样，对它无能为力，但这不是一个负责任的态度，因为实际上开发者有很多关于它的措施可以采取。从技术上来说，可以通过测试驱动开发、自动化集成测试、持续集成等手段；从社会学的角度来讲，端正自己的态度，不想推出具有缺陷的软件。以及加强开发团队成员之间的交流和关系等。
 
记者：你所熟悉的这些研究也说明了现在有如此众多失败的软件项目的原因。敏捷方法能拯救它们吗？还是只是一个临时的解决办法？
 
Ken Beck：敏捷方法是失败软件项目的救星吗？我认为许多软件项目依然会失败，问题是除非你非常深入的了解这些软件项目，你不知道会失败的是哪一个。那么敏捷方法是它的救星吗？不。我认为它依然会失败，因为好的想法并不一定在实践中产生好的结果。敏捷开发可以带给你的一件事情是：让这些项目失败的更快、损失的更少，因为你可以将时间和精力用于开始做下一件事情。
 
记者：对于极限编程，你提到隔几个星期进行一次迭代（iterations），而不是六个月到一年，你如何定义这个迭代周期，以及软件发布的周期？
 
Ken Beck：在极限编程中的基本周期，基本的计划周期是一个星期，这是非常合理的，因为它是根据人们工作的时间来定的。在每个星期结束的时候，这个软件应该比这一星期开始的时候具有更多的功能。
 
极限编程（XP）与其他敏捷方法相比如何？比如Scrum。
 
关于极限编程我比较喜欢的一件事情是其全面性。它从关于与好的软件开发一致的观点的全面讨论开始。介绍了一些基本原则，介绍了获得我们讨论的某种目标的具体的实践。因此我认为极限编程区别于其他方法的特点是它具有这种全面性。
 
记者：你能指出一个使用极限编程完成的比较突出的软件项目吗？
 
Ken Beck：例如Carfax。
 
记者：我们曾经听过“牛仔编程（cowboy coding）”的叫法，敏捷方法和牛仔编程有什么区别？
 
Ken Beck：我偶尔会体验一下牛仔编程方式，尽管它在我的工作中不占有重要地位。在牛仔编程中，你可以像一个勇士一样去编程，你会对自己的工作感到很满意，因为你认为这个世界上再没有别人可能作出和你的一样的东西。
 
极限编程风格的开发也是需要勇气的；这一点它与牛仔编程类似。但是牛仔编程是完全不透明的，而极限编程则是透明的。牛仔编程是一种个体行为，而极限编程是一种团队行为。不仅仅是程序员一起工作，还包括用户、管理者和测试者。因此我认为它们还是有差异的。
 
在极限编程风格中，早早结束编码是因为可以更快的看到真正的用户反馈，从而继续改进。一个牛仔式的程序员也会做同样的事情。或许你刚刚介绍了一半问题的定义，它们会说，“好的，我明白了”，然后就去开始编程。是的，这一点看上去和极限编程团队有些类似，但是两者实际上是不同的，因为牛仔式程序员已经结束了这次交谈，而XP团队则是才刚刚开始这次交谈。
 
记者：牛仔编程有成功的时候吗？
 
Ken Beck：当然，在短期内它具有巨大的风险和巨大的成本、巨大的隐形成本。我有过使用它的经历，但是它有时候会效果不错。
 
记者：有的软件项目是由分散在不同地区的团队成员在不同的时间来进行开发的，在这种情况下的开发情形如何？敏捷方法可以解决这个问题吗？
 
Ken Beck：是的，这就是我大多数时间的工作方式，因为我住在南俄勒冈州，出于生计，我的大部分时间仍在编程。因此我一直在进行着跨地区的开发工作。时区是一个挑战，但是最大的挑战是保持团队成员之间的关系。这是一件非常困难的事情。如果你能做到这一点，如果你的团队之间有良好的关系，那么你就能制定出技术的详细信息，例如谁什么时候进行了重构，谁加入了什么代码和已经作出的程序。
 
记者：对于Java和.Net，敏捷方法和极限编程适合吗？
 
Ken Beck：一个技术平台如果可以让你以较低的成本进行修改，它就更适合敏捷开发。你当然可以在Java和.Net中使用敏捷方法。
 
记者：在敏捷编程中有什么比较重要的事情吗？
 
Ken Beck：是的，那就是你在一个技术中需要的东西。在一个技术平台中它真的很有帮助。我的父亲一直在从事敏捷开发的技术方面工作，以汇编语言为微处理器编程。他使用自动化测试、增量设计，他频繁发布小版本，他写绝对可靠的代码。
 
记者：那么像AJAX、Ruby和PHP等脚本语言呢？它们适合敏捷编程吗？
 
Ken Beck：当然。举个例子说，Ruby来自于以人为中心的语言。你可以通过一种非常具有可维护性的风格编写Ruby代码，在很长时间内可以非常轻松的修改。我担心的是当你使用数据库的时候，这种修改可能会突然变得非常困难。
 
记者：和Ruby语言有关吗？
 
Ken Beck：一般来说是和关系数据库有关。但是敏捷社区正在推出解决这个问题的技术。厂商也正在让数据库接受增量修改。
 
记者：Web开发如何？它是否与敏捷开发特别适合？还是它只是另一个应用程序领域？
 
关于Web开发的最伟大的地方之一是其开发非常省钱。而且如果你一直在做部署的话，简单的把它放到一些服务器上就可以了。传统应用软件的刻录成光盘然后进行分发，部署的成本要大很多。

印第安人在赶了3天路后，会停下来小憩一天，因为他要等着自己的灵魂跟上来。敏捷开发在经历了一次迭代或者冲刺（Sprint）后，也需要休整，以等待团队的灵魂跟上来，这一过程被称之为“敏捷回顾（Agile Retrospectives）”。敏捷回顾与项目总结会议不同，它并非项目结束之后的盖棺论定，而是在项目过程中，通过回顾会议及时总结上一次迭代中的得与失，以期达到改进项目开发、团队合作等敏捷活动的目的。

如果将项目开发比作是一次征途，那么在项目中期的短期休整是很有必要的。然而这种休整并非是将团队成员集体拉出去腐败一次，或者到K厅去鬼哭狼嚎一番，以泄心中的郁闷，如此种种只能说是身体心灵的休息与放松。就像是运动员在比赛期间，队医的按摩、擦汗的毛巾、解渴的饮料。这些重要吗？当然重要，放松疲惫的身体与心灵，方能更好地走向更远的目标。但更重要的是灵魂的“反刍”，就像教练员针对运动员在上一局比赛的盘点与指导，指出选手以及对手的优与劣，从而制定出后面比赛的对策，方能把握取胜之钥。

敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。Scrum对于回顾有一个主要指导原则，这也是敏捷回顾的“最高指导原则”：
无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。

听起来，有些像一团和气的“和稀泥”做法，这样的原则会否让回顾会议的参与者一个个都变成好好先生呢？难道我们一定要善意地评价团队中的害群之马，对他们的过错视而不见，使其“逍遥法外”，并天真地以为我们的好心能够感化他们？难道我们要在项目开发中建立一个乌托邦式的大同世界，同薪同酬，为了团队利益而抹煞团队成员之间的个体差异。

坦白说，我反对在进行团队成员评价时，采用这么一条“最高指导原则”，但这样的看法已经偏离了攻击的靶子了。需要知道，“最高指导原则”是应用在敏捷回顾中，而敏捷回顾的最终目的是学习，而不是绩效评审活动[1]。

如果敏捷回顾没有确定这条“最高指导原则”，用来倡议团队成员信任自己的伙伴，就会让回顾会议成为互相攻讦、互相推诿的批斗大会，忘记了我们召开回顾会议的初衷。“最高指导原则”就是为回顾会议竖立一个标杆，那就是在项目开发中没有破坏者，没有替罪羊，没有关键人物，只有整个团队的利益。虽然某个人或许在上一次迭代中出现了错误，但我们会善意地相信此人之所以犯下错误，并非有意为之，或者消极怠工，而是囿于当时之识见、经验、技能。我们的回顾会议必须指明这些错误，并试图总结出最佳实践以避免在下一次迭代中犯下同样的错误，而“最高指导原则”则能够消除因为错误的指出而给成员带来的负疚感，消除同事之间可能因此出现的隔阂与误解。换句话说，回顾会议提出的所有批评都应该是“对事不对人”。

我曾经在一个项目的回顾会议上，听到了测试经理对于某开发小组产品质量的评价，认为该小组开发的模块出现了太多的bug。经过回顾会议的认真分析，最后得出的结论是该小组Leader迫于进度压力，因而盲目地追求开发进度，却忽略了保障代码质量的单元测试覆盖率。于是，我们仔细讨论了下一次Sprint的Sprint Backlog，根据团队成员的能力进行了合理的分配。果然，在下一次Sprint中，该小组开发的模块出现的bug率降低了差不多50%，即使bug总量并不大，这样的比例仍然是非常可观的。而且，由于项目组成员都明白回顾会议的原则，因此并没有产生团队成员之间的不快，开发人员和测试人员仍然能够合作得非常愉快。

在《Scrum Checklists》中，指明了Scrum回顾会议的议程：
1、在白板上写上主要指导原则；
2、在白板上画上一个至少三页纸连在一起长的时间轴；
3、在白板上写上“我们的成功经验是什么”；
4、在白板上写上“有什么能够改进”；
5、在白板上写上“谁负责”，然后分成两个区域——“团队”和“公司”。

从以上的步骤可以看出，敏捷回顾的主要工作就是明确目标、持续改进、处理问题。敏捷开发之所以采用迭代的方式，实际上是利用蚕食方式逐步完成开发任务。将一个宏伟的目标切割为一个个小目标，会给与团队成员更大的信心，并能够更加清晰地明确目标。而每次迭代后的回顾，则使得团队成员可以更加清晰地明确我们在这个征途中，已经走到了哪里，未来还有多远的路程，就像印第安人那样，等待自己的灵魂，否则就会不知身在何处了。

在项目中持续改进至关重要。所谓“取其精华，去其糟粕”，唯有如此方能够去芜存菁，提高敏捷团队的战斗力。每一个敏捷团队都不可能是十全十美的，要么是在技术上存在个体差异，要么就是缺乏足够的领域知识，或者，还未曾找到符合团队现状的开发方法（即使采用敏捷方法，也需要因地制宜，切忌生搬硬套。即使现在符合，也不等于永远符合，即使符合这个项目，却未必符合下一个项目。敏捷方法不可能放之四海而皆准）。即使这些均已具备，那么团队成员之间的磨合也并非一朝一夕之功。若没有持续改进，团队就会像生锈的刀刃，不仅会褪去摄人的光芒，还会逐渐钝化腐朽。

在项目过程中，有一个原则是处理问题越早，那么付出的代价与成本就越小。问题是，当我们在紧张的开发任务中，有时候很难发现这些错误，更加意识不到这些错误会带来严重的影响。通过回顾会议，利用团队成员互相善意地“敲击”对方，或者反复“锻炼”开发过程与方法，就能够让每一位成员都炼就“火眼金睛”。在会议中，我们经常会发现，一旦某个成员发现了一个问题，接踵而来的就是每个成员都会发现一大堆问题。

发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因、所属类别，并因此划定问题的“责任田”。我们要明确这些问题是团队内部的，还是由于外在因素导致的，也就是说要明确“责任田”的归属，指定处理人和处理时间。

此外，《敏捷回顾——让团队从优秀到卓越》一书的作者Esther Derby在接受InfoQ的采访时，还提到：“使用回顾来解决冲突问题。他们在每个迭代中都进行检视、实验，并构建解决冲突的技能和信心。随着时间推移，他们学会了如何处理每个团队都会发生的“平常的”冲突。当大家意见出现严重分歧时，他们有能力、也有信心在团队内部解决问题。而且更有利的是，由于他们可以在团队内部解决全部问题，他们的经理就可以花费更多的时间来消除组织中对团队造成的障碍。当然，这使得团队能够轻装上阵，以更加轻松的心态来开发软件。”[2]

现在，在你的项目团队经历了一次艰难的迭代之后，你需要休息一下以等待灵魂的到来么？那么，就请尝试一下敏捷回顾会议吧，或许你会从中得到意想不到的收获。

[1] Linda Rising，敏捷回顾活动“最高指导原则”答疑解惑
[2] Deborah Hartmann，图书节选：敏捷回顾——让团队从优秀到卓越

---

作者介绍
张逸具有多年的软件开发与设计经验，他是两届微软最有价值专家（MVP），著作/译作包括《软件设计精要与模式》、《WCF服务编程》。张逸熟悉C#，ASP.NET，WCF等技术，同时深谙面向对象领域的相关技术。目前，他主要从事 SOA企业信息解决方案的设计与研究，以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。