使用 Java 语言所进行的面向对象编程变得空前普及。它使软件开发发生了某种程度的变革。但最近的研究表明，有半数软件开发项目滞后，而三分之一的项目超出了预算。问题不在于技术；而是开发软件所使用的方法。所谓的“灵活”方法，与诸如 Java 之类的面向对象语言的能力和灵活性结合在一起，或许刚好就是答案。最流行的灵活方法称作极端编程（Extreme Programming），或简称 XP，但许多人并不真正了解它。对软件开发项目使用 XP 可以大大提高成功的机会。由 Roy Miller 撰写的这个新专栏从重访他受欢迎的文章“XP 精华”开始，将消除谣言和误解，帮助您理解 XP，并解释为什么它这么重要。Roy 很快还会在相关论坛中讨论 XP。 自从我和 Chris Collins 共同编写“XP distilled”以来已有一年了，那以后发生了很大的变化。极端编程（XP）有些成熟了，而且与以前相比，更多人在他们的组织中实现它。尽管 XP 得到了发展并由此产生了各种议论，但对于 XP 是什么和不是什么还是有许多混淆和争论。不必惊讶，甚至微软也把其最新的操作系统贴上“Windows XP”的标签，这更增加了人们的疑惑。 在此后的几个月中，我将在本专栏中澄清围绕 XP 的误解、误传和真正的疑惑。我希望向您提供解答有关 XP 问题的实用资源以及如何在组织中实现它的思想。本专栏前几篇文章将是“XP 精华”的扩展版本，它们将涉及与 XP 相关的当前实践和思想。我的目标是向您提供支持进一步探索 XP 的扎实基础以及解释它如何给您的公司和职业生涯带来变化。 我从事软件行业中的某些工作已有大约十年了。在此期间，我从未看到或使用过象 XP 那样令我兴奋的软件开发方法。我相信这是一种自然的编程方法 — 当人们开始使用时，可能并不是每个人都能感觉到自然。但如果有机会使用它，您就会惊讶于您以前怎么会使用任何其它方法进行工作的。 当然，XP 并不是开发优秀软件的唯一方法，但我深信两点：
所以，如果您还不了解它，那么我将怀着极大的热情介绍 XP。最后，我希望您也会被它所吸引 — 但并不是因为高明的市场营销。我认为让其他人信服 XP 的最佳方法是据实演示 XP，然后让他们自己决定 XP 方法是否比他们正使用的方法更好。 业务问题 50 多年来程序员一直在艰苦地编写代码。这期间，写出的代码“堆积如山” — 有些很好，但大多数很糟糕。平均起来很糟糕的原因很简单：传统的软件开发方法会导致项目的失败。最糟糕的是拥有满腔热情、努力工作的优秀人员看到他们大量的项目都失败了。在“XP 精华”中，我们给出了有关项目成功的一些数字。图 1 显示了 2000 Group CHAOS Report 中更新的一些数字。（顺便提一下，我的编辑问我是否介意定义一下“CHAOS”。我回答说，我不会介意，但 Standish Group 拒绝透露缩写词的含义。正如我告诉编辑的那样 — 不，我没骗您。您可以在参考资料的 Keeping CHAOS quiet 中读到有关的介绍。） 我在一本软件杂志的文章中第一次看到与此类似的图。作者将该图称作“项目显示稳步的提高（Projects Show Steady Improvement）”，而且他们说明，1994 年只有 16% 的项目成功了，而在 2000 年有 28% 的项目成功了。尽管 28% 当然要比 16% 好，但是结果还是非常糟糕的。正如我以前说过的，如果您使用标准软件开发方法，那么即使开发 Java 应用程序，也要做好失望的准备。尽管自 1994 第一次发布 CHAOS Report 以来，已有了一些提高，但几乎四分之三的项目还是失败了。难怪公司领导人不愿在软件项目上进行投资。 为什么这些数字这么糟糕？有多少人问此问题，可能就有多少种观点，但我认为有几个主要原因：
让我们简要讨论这三个原因。 不相信他们有问题 在您的组织中，IT 团队和“业务人员”之间的关系是否很僵？组织中的企业领导人是否说过这样的话：“如果技术真的是这样好的话，为什么我从 IT 团队听到的只是‘不’呢？”如果是这样，那么您就有问题要解决了。如果您不解决，那么“惯性”或许会使您可以暂时继续工作，但失败已隐约可见了。 知道存在问题，但担心解决它会带来风险 由于成功的机会渺茫，大多数人就采用阻力最小的捷径。这种方法在短期内可能会保护所从事的工作，但它仅仅推迟了问题的出现，并使之更复杂。如果等待时间太长，小的问题也会变得难以克服。最终将没有方法激励人们变得勇敢，去冒更多风险，但本专栏及相关论坛中的思想可能帮助您使组织中的人（包括您自己）战胜对失败的恐惧。 知道存在问题，也愿意设法解决它，但误解了要解决的问题 如果您设法使软件开发过程过度“机械化”或过多控制此过程，那么您将对此失去控制。我希望本专栏即将发表的文章会有助于清晰地阐明您正试图解决的软件开发问题。 知道存在问题，也愿意设法解决它，但受现状约束 一个解决方案：灵活方法 可能是为了防止对该名称不合适和目光短浅的批评，那些认为象 XP 之类的方法很好的人，已开始将这样的方法称作灵活（agile）方法。您会听到将 Crystal Method、适应性软件开发（Adaptive Software Development）和（目前最流行的）XP 称为灵活方法。所有这些过程都有这样一个事实，即需要人们共同合作来开发软件。成功的软件过程必须充分发挥人们的长处，而尽量避免他们的缺点。依我看来，XP 做得最好的地方在于它解决了如何互补影响涉及到的人员的所有力量，而且当团队中的程序员编写代码时，帮助他们完成正确的事情。它还让他们在大部分时间内编写代码，而这正是他们喜欢做的。 不管您把您的方法称作灵活的还是其它，这都不重要 — 结果最重要。目的是均衡所有的力量以有效地开发软件。依我看来，这个方法始终需要真诚。它要求人们遵守基本的承诺，这样您就不会在持续的压力下屈服、退出，去采用旧方法完成任务。这还要用到技巧。 与大多数人所说的相反，我认为不是每个程序员都会在 XP 团队中受益。XP 方法需要太多始终如一的真诚和谦虚。程序员在学校中往往不可能学到这些，而且大多数的企业环境也不鼓励这样做。软件是由人类开发的。我们都有弱点，并且我们都有许多相同的弱点。我们需要使人类还原本色的方法，一种使人们难以出差错的方法。我认为 XP 是我见到过的任何方法中这一点做得最好的方法。 XP 的价值
在我与其他人为在意大利撒丁岛召开的 XP2001 会议而合著的论文中，我建议在上面的列表中加上“自省”。但当在那儿演讲此论文时，我意识到自省实际上不仅仅是实践。坚持学习作为另一个价值被包含进来，这个强大的候选选项是以 Joshua Kerievsky 的一篇论文（请参阅参考资料）为基础的。在该论文中，他谈到对于一个健康的 XP 团队来说，持续学习（Continuous Learning）是如何成为必要条件的。我同意。我不知道添加另一种价值需要 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 从未保证 — 以后也不会保证 — 人们始终会做得正确，但它给予他们尝试的机会。这适用于团队中所有成员，不管是不是技术人员。团队中使用所有实践的成员一起工作会在速度和效率上得到明显的提高。这些实践可以营造使组织产生出优秀软件的环境。是否还有任何其它种类的实践呢？ 修订的实践 表 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 实践的四个类别正逐渐变得清晰。一个团队中的每个子团队有一个集合，而且还有将三个子团队聚集起来的集合。最初 12 个实践中的大多数都在开发团队集合中，但有些可能会去掉。有些名称已改变，主要因为最初的名称要么不太合适，要么没有反映它们应有的意义。有些实践没有列在最初 12 个实践的列表中。在下一节（以及以后的文章）中，在每个名称后，我将附加说明该实践是新的、未更改的还是到最初名称的映射。请注意这些名称还会有更改，但原则或许不变。 在描述实践之前，阐述我如何看待“‘部分’观点”，这一点很重要：团队必须使用所有实践，还是只需挑选它所喜欢的呢？作为规则，XP 假设团队一直使用所有实践，但团队可以挑选几个实践，并成功使用它们（诸如重构或结对编程）。您可以在您的团队中随意这样做。对于我的团队，我不选择这样做，因为我认为实践会相互补充，一起使用效果好，所以如果我不选一个或多个实践，那么就会放弃一些令人惊奇的东西。但应由您自己来作出决定。如果您想尝试 XP，我建议您暂且一直使用所有实践，来确定您要放弃哪些实践。我敢打赌您要放弃的那些实践所组成的列表会很小。 好了，让我们来描述实践吧。本月我将讨论联合实践来为所有其它实践打基础。首先我们需要确保我们有一个使用所有实践的团队。这是先决条件。 联合实践：建立一个团队 公共词汇表（映射到比喻） 在 Extreme Programming Explored（请参阅参考资料）中，Bill Wake 也谈到了比喻。他说： 当项目已经开始并有所成果时，在研究阶段确定比喻。随着进展来修改它。让比喻来指导您的解决方案。将其名称用于最高级的类。理解那些类是如何交互的。 他建议当您不能想出一个更好的名称时，就使用“自然的比喻”（即，让对象成为其自身）。真是好建议。 开放式工作区（新） 对开放式工作区实践的典型反应是怀疑一群人在同一个区域讨论会相互分散注意力。从经验来说，这确实会发生。当团队中的成员相互足够尊重，以致可以在开放式工作区一起工作，而不是滥竽充数时，开放式工作区就会发挥作用。如果有人想偷懒，就让他到可以偷懒的区域，那当然是另外一个地方。这并不意味着工作区不能有乐趣。它应该有乐趣，但它也应该是可以完成工作的地方。如果团队成员相互关心并关注他们正从事的工作，那么他们就能使开放式工作区起作用。您应该设想它不会有问题，并且只在真有问题时才处理它。 我听说有人提出开放式工作区实践意味着 XP 不适用于大型的团队。他们认为一大群人在一个大空间（或一些其它开放式工作区）的地方会很混乱。可能他们是对的。坦率地说，我认为这个侧重点是错误的。他们似乎假设了两点：您需要大型的团队，以及没有支持团队的协作式环境。 可能您需要大型团队。但是您真的这么认为，还是刚有这个想法？可能在一个有助于顺利完成工作的环境中共事的一小组优秀的开发人员 — 拥有他们需要的支持 — 可以比一个大型团队做得更多、更好和更快。也可能不是这样，但它值得考虑。 假设您真的需要一个大型团队。为此您如何为它建立一个合作的环境，而完全没有产生混乱呢？如果您有多个相邻的开放式工作区，彼此处于半隔离状态（敞开的大门、半堵墙、在大空间之间有通道等），那么怎么样呢？有些人指出不能创造支持大型团队的合作环境，我认为他们中的大多数通常不太喜欢这个想法 — 不管是对于小型团队还是大型的。假设开放式工作区不适合大型团队是个错误。 迭代（新） 每次迭代从制定一些规划开始。我（以及许多其他人）称之为迭代规划，我们在迭代规划会议上完成它。在这个会议上制定的规划看上去非常象发行规划（我们也将在以后的文章中更详细讨论这个概念），只不过是更详细的级别。我们只关心下一次迭代。我们询问客户，“如果项目在下一次迭代之后将结束，您想要项目具有什么功能？”然后我们估计构建那些功能所需的工作。我们在这次迭代中加入可以加入的东西，而推迟完成其它东西。客户确定优先级；程序员确定成本。那意味着有些事情必须推迟进行，让位给当前的迭代。您不能对此采取折衷办法。您不可能获得更多的时间。 时间定量（timeboxing）一词在这里非常重要。时间定量是对某些工作设置完成期限的做法，在未到期限之前，一直从事这些工作，期限到时，就停止，然后评估您完成了多少。它是一种技术，防止团队在某些任务上花的时间太长，而影响其它需要完成的工作。迭代实践不仅仅是关于时间定量的。实际上迭代实践是关于要求人们作出艰难决定的，而这些人最有资格作出相应的决定。客户决定下一步要构建哪些最重要的功能。程序员对关于如何构建功能以及需要多少工作作出技术决定。管理层就有关项目的战略方向以及该项目如何才能适合于组织的其它部分而作出决定。这涉及项目团队中的每个人，但他们坚持遵循他们知道的。他们当然经过深思熟虑，但还要相信别人也同样如此。 对于将这个实践称作什么有些争论。我们应该称它短迭代以强调迭代的节奏快，还是该称作迭代规划以强调集合每个人进行规划的合作方面？我喜欢短迭代，因为它强调使用户获取真正的、有效的软件以返回具体反馈的需要。 回顾（新） 不反思您正做的工作就继续做下去会使您陷入重复失败的境地。团队中每人都最好反思他自己的工作以及他吸取的经验和教训，然后与团队中其他成员分享反思的结果。正如我和 Chris Collins 在我们的 XP2001 论文 Adaptation: XP Style（请参阅参考资料）中所概述的那样，我正讨论的个人行为是自省。回顾时，您公开您的自省。 思考您在项目中吸取的经验和教训。思考哪些做得好，哪些搞砸了。思考团队是如何运行的。思考团队整体产生了什么。可否将工作完成得更好？为什么？更重要的是，怎么做？什么是您做得好的，是您确信要继续保持的？该怎么做？这种共同评审应该以有组织的方式至少在每次发布后进行一次，最好在每次迭代之后进行。不会花很长时间。在迭代规划会议时留出头一到两小时用于回顾上一次迭代。可能的话留出一天（或几天）用于发布后的回顾。不要有任何松懈。在这里您正设法使团队更优秀，设法提高您可以对组织增加的价值，设法通过在工作中添加一点乐趣使自己的生活更美好。这是至关重要的。 我和大部分同事都觉得团队中的每两个成员结成对在每天结束时进行“迷你回顾”很有帮助。反思只需几分钟。如果我们学到了值得共享的东西，那么我们可以在第二天的团队会议中提出。通过这种方法我们学到了很多。 回顾当然要使一些薄弱环节得到有效解决。弥补了团队的不足后，团队就变成了一个更完整的团队。每个人都要参与回顾，包括技术和非技术成员。如果这需要太多的人，以致在一个场所容纳不下（而且是可能的）时，则子团队（例如管理）可以进行他们自己的回顾，然后派一名代表参加一个较小型的会议。关键是吸取经验和教训，这样我们就减少了重复犯相同错误的机会。这就需要一个团队和每个人都全身心地投入其中。 组织性变革 正如我在下几个月中每次结束时都要谈到的，我重申：这里描述的已修改的实践未必就是“新”XP 将来的模样，这一点很重要。我想我们所有人都必须等待 Kent Beck 的 Extreme Programming Explained: Embrace Change 第二版的发布以看看下一发行版是什么样。 下个月 |
