【IT168 技术文章】

    使用 Java 语言所进行的面向对象编程变得空前普及。它使软件开发发生了某种程度的变革。但最近的研究表明，有半数软件开发项目滞后，而三分之一的项目超出了预算。问题不在于技术；而是开发软件所使用的方法。所谓的“灵活”方法，与诸如 Java 之类的面向对象语言的能力和灵活性结合在一起，或许刚好就是答案。最流行的灵活方法称作极端编程（Extreme Programming），或简称 XP，但许多人并不真正了解它。对软件开发项目使用 XP 可以大大提高成功的机会。由 Roy Miller 撰写的这个新专栏从重访他受欢迎的文章“XP 精华”开始，将消除谣言和误解，帮助您理解 XP，并解释为什么它这么重要。

    自从我和 Chris Collins 共同编写“XP distilled”以来已有一年了，那以后发生了很大的变化。极端编程（XP）有些成熟了，而且与以前相比，更多人在他们的组织中实现它。尽管 XP 得到了发展并由此产生了各种议论，但对于 XP 是什么和不是什么还是有许多混淆和争论。不必惊讶，甚至微软也把其最新的操作系统贴上“Windows XP”的标签，这更增加了人们的疑惑。

    我从事软件行业中的某些工作已有大约十年了。在此期间，我从未看到或使用过象 XP 那样令我兴奋的软件开发方法。我相信这是一种自然的编程方法 — 当人们开始使用时，可能并不是每个人都能感觉到自然。但如果有机会使用它，您就会惊讶于您以前怎么会使用任何其它方法进行工作的。

    当然，XP 并不是开发优秀软件的唯一方法，但我深信两点：

    . XP 运用到实践中的原则是正确的原则。

    . 我从未使用过象 XP 那样将软件开发的所有部分结合起来的软件开发方法。

    所以，如果您还不了解它，那么我将怀着极大的热情介绍 XP。最后，我希望您也会被它所吸引 — 但并不是因为高明的市场营销。我认为让其他人信服 XP 的非常好的方法是据实演示 XP，然后让他们自己决定 XP 方法是否比他们正使用的方法更好。

    业务问题

    在发表“XP 精华”的那一年，企业管理面临的最大问题（IT 业内和业外）一直未改变过：企业领导人如何利用他们的 IT 资产和能力获得竞争优势？在许多情况下，我们讨论的这些“资产和能力”与软件和开发软件有关。那是问题的症结所在。

    50 多年来程序员一直在艰苦地编写代码。这期间，写出的代码“堆积如山” — 有些很好，但大多数很糟糕。平均起来很糟糕的原因很简单：传统的软件开发方法会导致项目的失败。最糟糕的是拥有满腔热情、努力工作的优秀人员看到他们大量的项目都失败了。在“XP 精华”中，我们给出了有关项目成功的一些数字。图 1 显示了 2000 Group CHAOS Report 中更新的一些数字。（顺便提一下，我的编辑问我是否介意定义一下“CHAOS”。我回答说，我不会介意，但 Standish Group 拒绝透露缩写词的含义。正如我告诉编辑的那样 — 不，我没骗您。您可以在参考资料的 Keeping CHAOS quiet 中读到有关的介绍。）

    图 1. 软件项目过去和现在的成功和失败

    我在一本软件杂志的文章中第一次看到与此类似的图。作者将该图称作“项目显示稳步的提高（Projects Show Steady Improvement）”，而且他们说明，1994 年只有 16% 的项目成功了，而在 2000 年有 28% 的项目成功了。尽管 28% 当然要比 16% 好，但是结果还是非常糟糕的。正如我以前说过的，如果您使用标准软件开发方法，那么即使开发 Java 应用程序，也要做好失望的准备。尽管自 1994 第一次发布 CHAOS Report 以来，已有了一些提高，但几乎四分之三的项目还是失败了。难怪公司领导人不愿在软件项目上进行投资。

    为什么这些数字这么糟糕？有多少人问此问题，可能就有多少种观点，但我认为有几个主要原因：

    . 人们不相信他们有问题。

    . 人们知道有问题，但是担心采用其它方法来解决此问题可能会带来风险。

    . 人们知道有问题，也愿意设法解决它，但误解了设法解决的问题。

    . 人们知道有问题，愿意设法解决它，也理解该问题，但受现状约束。

    让我们简要讨论这三个原因。

    不相信他们有问题

    人们总是喜欢自欺欺人。公司和项目的领导人也不例外。软件开发项目正逐渐消耗着企业资产，而每个人还确信一切进展顺利 — 或至少它们看上去如此，这是非常可能的。我在前面提到的数字已很明显地指出组织中的软件开发不顺利。当然也有例外，但许多组织对他们自己存在的问题一片茫然。

    在您的组织中，IT 团队和“业务人员”之间的关系是否很僵？组织中的企业领导人是否说过这样的话：“如果技术真的是这样好的话，为什么我从 IT 团队听到的只是‘不’呢？”如果是这样，那么您就有问题要解决了。如果您不解决，那么“惯性”或许会使您可以暂时继续工作，但失败已隐约可见了。

    知道存在问题，但担心解决它会带来风险

    更为常见的是，组织中有才能和观察敏锐的人意识到他们目前的软件开发方法不起作用。他们只是担心尝试采用使情况好转的其它方法可能会带来风险。这可以理解。尝试新事物需要勇气，而且通常要冒一些风险。而在我们急功近利的文化中，对您的职业生涯来说，失败会产生不利影响，或者甚至是致命的。

    由于成功的机会渺茫，大多数人就采用阻力最小的捷径。这种方法在短期内可能会保护所从事的工作，但它仅仅推迟了问题的出现，并使之更复杂。如果等待时间太长，小的问题也会变得难以克服。最终将没有方法激励人们变得勇敢，去冒更多风险，但本专栏及相关论坛中的思想可能帮助您使组织中的人（包括您自己）战胜对失败的恐惧。

    知道存在问题，也愿意设法解决它，但误解了要解决的问题

    有时人们知道他们有问题，而且愿意设法解决它，即使那意味要尝试新事物。但他们尝试解决错误的问题。例如，他们设法解决生产问题，假设（或许是无意的）开发软件就象在装配线上生产产品。让装配线上的工人不按照装配的有效次序和方法进行操作，这样做毫无意义。软件之所以不同是因为它是新生事物。Jim Highsmith 在 XP2002 的演讲 Agile Methodologies: Problems, Principles, and Practices（请参阅参考资料）中，描述了软件中优化和探索之间的区别。软件中，我们通常探索新领域，并做一些以前未做过的事情。这使软件开发成为需要不同解决方案的完全不同的一类问题。

    如果您设法使软件开发过程过度“机械化”或过多控制此过程，那么您将对此失去控制。我希望本专栏即将发表的文章会有助于清晰地阐明您正试图解决的软件开发问题。

    知道存在问题，也愿意设法解决它，但受现状约束

    最后，人们可能知道存在问题，愿意去解决它，也理解了正设法解决的问题，但在组织中却无法执行。这个问题很令人沮丧，而且解决起来也很困难，但未必不可能。遗憾的是，解决它需要的勇气却不是大多数人所能拥有的。有时为了进行变革，您不得不去冒犯某些人。我知道说比做容易，但如果您是一个组织中的成员，该组织的领导层拒绝解决危害组织健康发展的问题，那么您可以做如下选择：要么全力以赴设法进行变革，要么在该组织不堪自身重负而关门大吉之前离开。本专栏中的这篇文章及以后的文章会向您提供一些好的意见，以帮助您克服通常阻碍组织内新事物（特别是 XP）发展的阻力。

    一个解决方案：灵活方法

    在某种程度上，“极端编程”这个名称就不太适宜。大多数人听到 XP 时，可能会想到极限运动，或 Microsoft 的操作系统。这个名称背后的思想是软件开发的非常好的实践，例如编写单元测试和代码复查。为什么不能一直执行这些实践呢？当您这样做时，它们就变成类似测试驱动的开发（Test-Driven Development）和结对编程（Pair Programming）之类的概念，大多数人认为相当极端。那就是这个名字的由来。它与苏打、蹦极或比尔·盖茨无关。

    可能是为了防止对该名称不合适和目光短浅的批评，那些认为象 XP 之类的方法很好的人，已开始将这样的方法称作灵活（agile）方法。您会听到将 Crystal Method、适应性软件开发（Adaptive Software Development）和（目前最流行的）XP 称为灵活方法。所有这些过程都有这样一个事实，即需要人们共同合作来开发软件。成功的软件过程必须充分发挥人们的长处，而尽量避免他们的缺点。依我看来，XP 做得最好的地方在于它解决了如何互补影响涉及到的人员的所有力量，而且当团队中的程序员编写代码时，帮助他们完成正确的事情。它还让他们在大部分时间内编写代码，而这正是他们喜欢做的。

    不管您把您的方法称作灵活的还是其它，这都不重要 — 结果最重要。目的是均衡所有的力量以有效地开发软件。依我看来，这个方法始终需要真诚。它要求人们遵守基本的承诺，这样您就不会在持续的压力下屈服、退出，去采用旧方法完成任务。这还要用到技巧。

    与大多数人所说的相反，我认为不是每个程序员都会在 XP 团队中受益。XP 方法需要太多始终如一的真诚和谦虚。程序员在学校中往往不可能学到这些，而且大多数的企业环境也不鼓励这样做。软件是由人类开发的。我们都有弱点，并且我们都有许多相同的弱点。我们需要使人类还原本色的方法，一种使人们难以出差错的方法。我认为 XP 是我见到过的任何方法中这一点做得最好的方法。

    XP 的价值

    正如我在“XP 精华”中所说的，XP 规定了一组核心价值和实践，可以让软件开发人员发挥他们的专长：编写代码。XP 消除了大多数重量级过程中不必要的东西，它们减慢开发速度、耗费开发人员的精力（例如甘特图、状态报告，以及大量的需求文档等），从而偏离目标。Kent Beck 在他的书 Extreme Programming Explained: Embrace Change（请参阅参考资料）中概述了 XP 的核心价值。这些价值在去年没有发生实际的更改。我仍用这种方法概述了这些价值：

    . 交流：项目的问题往往可以追溯到某人在某一时刻没有和其他人一起商量某些重要问题上。使用 XP，不交流几乎不可能。

    . 简单性：XP 建议：在对于过程和编写代码起作用的方面，总是做最简单的事情。按照 Kent 的说法，“XP 就是打赌。它打赌今天最好做些简单的事，而不是做些较复杂但可能永远也不会用到的事。”

    . 反馈：及早和经常从客户、团队和实际最终用户获得具体反馈意见，这提供了更多为您工作方向“掌舵”的机会。反馈可以让您把握住正确的方向，少走弯路。

    . 勇气：勇气存在于其它三个价值的环境中。它们相互支持。相信开发过程中的具体反馈比预先知道每件事更有价值，需要一定的勇气。当需要与团队中的其他人交流，而此时可能会暴露您的无知时，需要有勇气。使系统保持简单，把明天的决定留到明天做，也需要勇气。而如果没有简单的系统、没有不断的交流来扩展知识以及没有掌握方向所依赖的反馈，勇敢也就失去了依靠。

    在我与其他人为在意大利撒丁岛召开的 XP2001 会议而合著的论文中，我建议在上面的列表中加上“自省”。但当在那儿演讲此论文时，我意识到自省实际上不仅仅是实践。坚持学习作为另一个价值被包含进来，这个强大的候选选项是以 Joshua Kerievsky 的一篇论文（请参阅参考资料）为基础的。在该论文中，他谈到对于一个健康的 XP 团队来说，持续学习（Continuous Learning）是如何成为必要条件的。我同意。我不知道添加另一种价值需要 XP 从业者提供什么样的支持，但我认为它很有意义。

    修订版的需要

    当我第一次读到 Extreme Programming Explained 时，我很兴奋，几乎爱不释手。我所见过的大多数企业环境中的软件开发方法和 Kent 描述的使人耳目一新的方法之间竟存在如此巨大差异，我为此震惊。但我在内心还是有点怀疑，书中留下了对项目业务方面有些过多的想像，这在接受时会产生问题。我被一种无法抗拒的思想给震住了，即 XP 不仅仅是关于编程的。

    幸运的是，在有关 XP“12 个实践”的 XP 社区、因特网新闻组以及其它论坛中都有重点讨论。人们正意识到 XP 的第一个发行版似乎过分强调了软件开发的编程方面，而影响了其它方面，并且业务方面不是象它应有的那样十分完善。基本原则是好的，但是完成软件开发还要包含一些更多的实践。在已修改的实践列表（包含 19 个实践，而不是 12 个）中隐含了这样的认识：即 XP 实际上不仅是关于编程的。它是关于为了生产优秀软件所需创建的某种组织性变革。这个方法当然需要严明的编码纪律和高超的编码技能，但它还需要团队中每个人在思考创建软件的方法上有重大转变。这是指团队中的每个人，包括用户、业务分析员以及决策者。新的实践在这一点上绝对清楚，并主要集中在建立可一直生产优秀软件的团队上。事实上，它强调了团队是 XP 世界发生变革背后的主要驱动力。Kent Beck 在以 One Team 为主题的论文草稿中说道：

    Extreme Programming Explained 中最严重的错误是隐含的假设，即您的技术团队只为一个客户提供服务。

    在同一篇论文的后面，他说道：

    就象“客户以同一种声音告知团队”中的那样，使用“团队”一词时，就会提到程序员，这使得在 XP Explained（以及随后的论文和交谈）中，这个问题变得复杂了。这个用法总是困扰我，但我不知道对此该做什么。

    新的实践和集中于一个团队的方针设法解决那个问题。以对软件开发带来组织性变革为目标的任何方法都必须弥合 IT 团队和业务团队之间的裂缝。存在裂缝的最主要原因之一首先是因为创建软件涉及的人员不属于一个团队。那么这样一个团队看上去会象什么呢？在同一篇论文中，Kent 使用了一个三条腿的凳子作为比喻。开发团队是程序员，而业务（或客户）团队是分析员、用户、测试员等等。第三条腿是管理团队，它由回答如下问题的人员组成：

    . 项目如何开始？
    . 如何增加、减少或终止投资？
    . 如何解决业务和开发团队不能解决的争论？
    . 在这个团队和需要完成的所有其它项目之间如何设置相对优先级？
   
    所以现在我们将一个团队定义为三个子团队：程序员、客户和管理。

    尽管管理团队对某些重大业务作决策，但管理开发工作并不是由一个团队负责的。每个人都属于一个团队，不同的人担任不同的角色。当然，说要比做容易。需要有许多人愿意完成不同的工作。有失败（并可能终止）的风险，但回报也可能是可观的。

    非常好。我们有了一个团队。每个人做什么呢？就象一年前那样，所有 XP 实践将四个价值转换成了作为一个软件开发团队成员每天应该做的工作，不管是不是技术方面的工作。对成员而言，不管是否从事技术工作都没有什么十分新的东西。XP 编程实践被业界公认为非常好的实践已经有好几年了，而且更关注于业务的实践被认为很有效（请参阅参考资料的 Standish Group CHAOS Report 以获取证据）。极端编程中的“极端”一词来自两方面，这一点仍然正确：

    . XP 采取经过证明的业界非常好的实践并将其发挥到极致。
    . XP 将这些实践以某种方式进行组合，使它们产生的结果大于各部分的总和。

    如果每个人都在同一个团队中，那么第二点会令人惊奇。但只要您砍掉凳子的一条腿，那就准备掉在地上吧。XP 从未保证 — 以后也不会保证 — 人们始终会做得正确，但它给予他们尝试的机会。这适用于团队中所有成员，不管是不是技术人员。团队中使用所有实践的成员一起工作会在速度和效率上得到明显的提高。这些实践可以营造使组织产生出优秀软件的环境。是否还有任何其它种类的实践呢？

    修订的实践

    XP 的 19 个实践（请参阅表 1）定义了团队各种成员应有的习惯。这个月，我们将较深入地研究联合（joint）实践，因为它将一个团队中的所有成员都聚集在一起。下个月，我们将讨论开发（development）实践，它形成了最初的 12 个 XP 实践的主体。再下个月，我们将讨论客户（customer）和管理（management）实践。这将使您更好地理解用 XP 开发软件意味着什么。

    表 1. XP 的 19 个实践 联合实践 迭代

    在我们讨论联合实践之前，让我先澄清什么是实践，以及什么不是实践。实践不是 XP。XP 不只是实践。事实上，XP 的价值也不是 XP。Ken Auer、Erik Meade 和 Gareth Reeves 共同写了一篇称为“The Rules of XP”的文章（请参阅参考资料），其中对此描述得非常好。他们简明扼要地说：

    XP 的价值使 XP 灵活。XP 的实践没有定义 XP . . . XP 是由它的规则定义的。

    他们使用 Alistair Cockburn 的游戏作类比，接着描述了“交战规则”，该规则说明了进行有效的软件开发所需的环境。然后他们讨论了“游戏规则”，它定义“交战规则”框架内每一分钟的活动和规则。他们建议：

    . “游戏规则”确保 XP 的唯一性。
    . 遵守“游戏规则”就是极端编程。
    . 遵守“游戏规则”和“交战规则”就是极端软件开发。

    XP 实践很重要，因为它们强制了一些行为，这些行为增加了团队生产出与团队成员期望值相符的优秀软件的可能性。但 XP 不只是如此。它不仅是编程，还扩展至包括整个软件开发过程。修订的 XP 实践考虑到了这一点，它们要求所涉及的每个人都有不同的行为。

    XP 实践的四个类别正逐渐变得清晰。一个团队中的每个子团队有一个集合，而且还有将三个子团队聚集起来的集合。最初 12 个实践中的大多数都在开发团队集合中，但有些可能会去掉。有些名称已改变，主要因为最初的名称要么不太合适，要么没有反映它们应有的意义。有些实践没有列在最初 12 个实践的列表中。在下一节（以及以后的文章）中，在每个名称后，我将附加说明该实践是新的、未更改的还是到最初名称的映射。请注意这些名称还会有更改，但原则或许不变。

    在描述实践之前，阐述我如何看待“‘部分’观点”，这一点很重要：团队必须使用所有实践，还是只需挑选它所喜欢的呢？作为规则，XP 假设团队一直使用所有实践，但团队可以挑选几个实践，并成功使用它们（诸如重构或结对编程）。您可以在您的团队中随意这样做。对于我的团队，我不选择这样做，因为我认为实践会相互补充，一起使用效果好，所以如果我不选一个或多个实践，那么就会放弃一些令人惊奇的东西。但应由您自己来作出决定。如果您想尝试 XP，我建议您暂且一直使用所有实践，来确定您要放弃哪些实践。我敢打赌您要放弃的那些实践所组成的列表会很小。

    好了，让我们来描述实践吧。本月我将讨论联合实践来为所有其它实践打基础。首先我们需要确保我们有一个使用所有实践的团队。这是先决条件。

    联合实践：建立一个团队

    这组实践适用于每个人。团队中的每个人（程序员、客户和管理）需要一直进行这些实践。这些实践使子团队聚集在一起以建立我们需要的一个团队。

    公共词汇表（映射到比喻）

    最初的比喻（metaphor）实践失败了。但其思想并非很糟糕：这是一幅控制图，其中的系统是用每个人都能理解的术语描述的，而且赋予该系统一个统一的主题，该主题使团队知道新事物适合哪方面。问题是，该实践确实偏离了主要目的：对系统的共同理解。团队中的每个人都需要理解它。有时不能获得一个非常好的比喻，或要想出这样的比喻非常费时。请不要仅仅因为不能对您正设法构建的系统找到一个恰当的比喻描述而耽搁时间了。应将重点集中于每个人都能使用的共享词汇表（Ward Cunningham 称之为“名称系统”）。如果比喻有帮助的话，那么就使用一个。如果您不能找到一个很好的比喻，那就用共享词汇表（它列出了类、方法等的名称）吧。

    在 Extreme Programming Explored（请参阅参考资料）中，Bill Wake 也谈到了比喻。他说：

    当项目已经开始并有所成果时，在研究阶段确定比喻。随着进展来修改它。让比喻来指导您的解决方案。将其名称用于较高级的类。理解那些类是如何交互的。

    他建议当您不能想出一个更好的名称时，就使用“自然的比喻”（即，让对象成为其自身）。真是好建议。

    开放式工作区（新）

    大部分时候非正式的交流比正式交流更有效。办公室小房间使非正式交流比较困难。非常好的解决方案是采用开放式工作区，其中人们可以在旁边听到讨论，当交流的内容有意义时，可以一起讨论，提出自己的想法，而且还可以对任何重要的事情进行即时讨论。这种群体交互可以产生令人惊奇的意外结果。我已经在工作中看到了成效。“推倒墙壁”。您的团队将因此而合作得更好。如果您的组织不同意搬动家具，那么您就有更大的问题了。
   
    对开放式工作区实践的典型反应是怀疑一群人在同一个区域讨论会相互分散注意力。从经验来说，这确实会发生。当团队中的成员相互足够尊重，以致可以在开放式工作区一起工作，而不是滥竽充数时，开放式工作区就会发挥作用。如果有人想偷懒，就让他到可以偷懒的区域，那当然是另外一个地方。这并不意味着工作区不能有乐趣。它应该有乐趣，但它也应该是可以完成工作的地方。如果团队成员相互关心并关注他们正从事的工作，那么他们就能使开放式工作区起作用。您应该设想它不会有问题，并且只在真有问题时才处理它。

    我听说有人提出开放式工作区实践意味着 XP 不适用于大型的团队。他们认为一大群人在一个大空间（或一些其它开放式工作区）的地方会很混乱。可能他们是对的。坦率地说，我认为这个侧重点是错误的。他们似乎假设了两点：您需要大型的团队，以及没有支持团队的协作式环境。

    可能您需要大型团队。但是您真的这么认为，还是刚有这个想法？可能在一个有助于顺利完成工作的环境中共事的一小组优秀的开发人员 — 拥有他们需要的支持 — 可以比一个大型团队做得更多、更好和更快。也可能不是这样，但它值得考虑。

    假设您真的需要一个大型团队。为此您如何为它建立一个合作的环境，而完全没有产生混乱呢？如果您有多个相邻的开放式工作区，彼此处于半隔离状态（敞开的大门、半堵墙、在大空间之间有通道等），那么怎么样呢？有些人指出不能创造支持大型团队的合作环境，我认为他们中的大多数通常不太喜欢这个想法 — 不管是对于小型团队还是大型的。假设开放式工作区不适合大型团队是个错误。

    迭代（新）

    使用 XP 的人经常谈论项目的“节奏”。这个节奏有不同的级别，但迭代的节奏级别简直就象心脏跳动那样快。每隔一到三个星期，团队就交付具有客户要求的新功能的工作系统。那是基本思想。但人们不习惯以这种方式创建软件。大多数方法注重在编写代码之前先进行大量的工作。XP 要求您编写代码、让人们使用它，并让他们的反馈把握项目的方向（我们将在以后的文章中更详细地讨论这个概念）。

    每次迭代从制定一些规划开始。我（以及许多其他人）称之为迭代规划，我们在迭代规划会议上完成它。在这个会议上制定的规划看上去非常象发行规划（我们也将在以后的文章中更详细讨论这个概念），只不过是更详细的级别。我们只关心下一次迭代。我们询问客户，“如果项目在下一次迭代之后将结束，您想要项目具有什么功能？”然后我们估计构建那些功能所需的工作。我们在这次迭代中加入可以加入的东西，而推迟完成其它东西。客户确定优先级；程序员确定成本。那意味着有些事情必须推迟进行，让位给当前的迭代。您不能对此采取折衷办法。您不可能获得更多的时间。

    时间定量（timeboxing）一词在这里非常重要。时间定量是对某些工作设置完成期限的做法，在未到期限之前，一直从事这些工作，期限到时，就停止，然后评估您完成了多少。它是一种技术，防止团队在某些任务上花的时间太长，而影响其它需要完成的工作。迭代实践不仅仅是关于时间定量的。实际上迭代实践是关于要求人们作出艰难决定的，而这些人最有资格作出相应的决定。客户决定下一步要构建哪些最重要的功能。程序员对关于如何构建功能以及需要多少工作作出技术决定。管理层就有关项目的战略方向以及该项目如何才能适合于组织的其它部分而作出决定。这涉及项目团队中的每个人，但他们坚持遵循他们知道的。他们当然经过深思熟虑，但还要相信别人也同样如此。

    对于将这个实践称作什么有些争论。我们应该称它短迭代以强调迭代的节奏快，还是该称作迭代规划以强调集合每个人进行规划的合作方面？我喜欢短迭代，因为它强调使用户获取真正的、有效的软件以返回具体反馈的需要。

    回顾（新）

    这是我职业生涯中很罕见的项目，团队中每人都花少量时间进行回顾，并公开指出什么地方确实没有做好。我必须自己来完成。当我这样做（如果我有时间的话）时，我通常发现如果团队花一点时间来解决项目中的问题，那么通常这些问题在它们成为“问题”之前就被解决了。那就是回顾（Norm Kerth 创造的术语）所要做的。

    不反思您正做的工作就继续做下去会使您陷入重复失败的境地。团队中每人都最好反思他自己的工作以及他吸取的经验和教训，然后与团队中其他成员分享反思的结果。正如我和 Chris Collins 在我们的 XP2001 论文 Adaptation: XP Style（请参阅参考资料）中所概述的那样，我正讨论的个人行为是自省。回顾时，您公开您的自省。

    思考您在项目中吸取的经验和教训。思考哪些做得好，哪些搞砸了。思考团队是如何运行的。思考团队整体产生了什么。可否将工作完成得更好？为什么？更重要的是，怎么做？什么是您做得好的，是您确信要继续保持的？该怎么做？这种共同评审应该以有组织的方式至少在每次发布后进行一次，最好在每次迭代之后进行。不会花很长时间。在迭代规划会议时留出头一到两小时用于回顾上一次迭代。可能的话留出一天（或几天）用于发布后的回顾。不要有任何松懈。在这里您正设法使团队更优秀，设法提高您可以对组织增加的价值，设法通过在工作中添加一点乐趣使自己的生活更美好。这是至关重要的。

    我和大部分同事都觉得团队中的每两个成员结成对在每天结束时进行“迷你回顾”很有帮助。反思只需几分钟。如果我们学到了值得共享的东西，那么我们可以在第二天的团队会议中提出。通过这种方法我们学到了很多。

    回顾当然要使一些薄弱环节得到有效解决。弥补了团队的不足后，团队就变成了一个更完整的团队。每个人都要参与回顾，包括技术和非技术成员。如果这需要太多的人，以致在一个场所容纳不下（而且是可能的）时，则子团队（例如管理）可以进行他们自己的回顾，然后派一名代表参加一个较小型的会议。关键是吸取经验和教训，这样我们就减少了重复犯相同错误的机会。这就需要一个团队和每个人都全身心地投入其中。

    组织性变革

    最后，XP 是关于组织性变革的 — 它只是从软件开始。使每个人参与同一个团队，但分配不同的工作，这是我所能想像到的发生有效变革的非常好的途径。这个月我们讨论了 XP 的联合实践，它有助于创建为产生那种真正的、持久的组织性变革所需的一个团队。