在将什么是极限编程之前，咱们先来讨论一下，当今信息技术中最迫切的两个问题是:
How do we deliver functionality to business clients quickly?
如何能快速地向商业用户交付功能？
How do we keep up with near-continuous change?
如何才能跟上近乎连续的变化?
变化本身也在不断地变化中。不仅仅是变化的速度在不断地提高 ，已经成为电子商务支柱的Internet, 就已使大范围的行业产生剧变–更多的是打断的平衡而不仅仅是一次剧变。当整个商业模式正在发生变化，当”时间意味着市场”正成为公司的咒语，当适应性与互连性正在成为甚至是最呆板的组织的需要的时候，我们将有必要检查以下的每一个方面:
1.商业是如何管理的，
2.客户为什么而感到高兴，
3.以及产品是如何开发的。
终极编程(Extreme Programming )运动成为面向对象编程这个团体的一部分已经有数年了， 但是直到最近才引起了越来越多的注意，特别是最近Kent Beck的《终极编程 释义:拥抱变化》(Extreme Programming Explained: Embrace Change)一书的出版。
有一种趋势，特别在那些严格的方法论者中，希望剔除那些与”能力 成熟度模型”(Capability Maturity Model CMM)或者是国际标准化组织的标准相比不那么笨重的方法，比如象hacking.注释: hacking推崇行动而不是思考从而导致了较低的质量。 剔除与某人关于这个世界的假设相冲突的实践，这倒不失为一种简单的方法。
从另一个角度来看XP，它倒可能是一个难题的某个潜在的部分，这个一个我在过去18个月中一直都在写的内容。混乱 的时期产生新的问题，而后者又导致了新的实践–新的实践公然违抗 传统的知识，但却得以幸存下来是因为它们能更好地适应这个新的现实世界。至少有四种实践方式我觉得是属于这个范畴的:
XP
轻量级的开发(Lean development)
轻量级的Crystal方法(Crystal Light methods
自适应软件开发(Adaptive software development)
我必须承认一件事情，就是我喜欢XP的原因应该是它没有其他的那些花哨的东西。支持XP的人们总是会向你指出XP适合的地方以及他的某些局限性。而XP的实践者Beck以及Ron Jeffties却相信XP会有更广泛的应用前景。他们通常对于自己的要求都是很谨慎的。例如：小的（小于10人），公司局部（他们有直接的经验）两者对于XP的适应性都是很明显的；他们并没有试图让人们相信XP可以适用于一个200人的团队。
xp基础—工程
最为著名的XP项目是克莱斯勒综合补偿系统（Chrysler Comprehensive Compensation system称为C3工程）。
最初，C3是一个基于OO（面向对象技术）的开发项目，尤其是它采用Smaltalk语言进行开发。作为著名的Smalltalk专家，Beck被邀请来讨论有关SmalTalk性能优化的问题，并且在原项目被认为不可救要的时候将其变为一个采用面向对象OO（XP）方法的试验性项目。Beck并且带来了Jeffries用于帮助那些基本的东西，Jeffries在C3组一直干到1999年的春天。最开始的需求是要做一个对约10，000个雇员每月薪水发放进行管理的系统。这个系统由大约2，000个类以及30，000个方法构成，并且在计划方面提供有合理的容忍度 。当有人问Jeffries他怎样成功的将C3变为XP并应用到其他的克莱斯勒IT项目。他笑着告诉了我。多年来我为许多大型IT组织开发了不少RAD系统（快速原型开发），因此我知道为什么我们无法将成功的经验运用于其它项目中. 对于RAD, XP, 轻量级的开发以及其它一些未得到广泛应用的方法, 它们成功的原因至少有一百条.
xp基础—实践
应记住的一件事情就是我们应倾向于在小型的, 局部的团队中运用XP。除了代码与测试用例外, 尽量减少有些的影响。XP的实践既有正面的表现,也有负面的。在某些方面看来，他们听起来就像一堆规则，要做这个，不要做那个。对此Beck解释道, 与规则相比, XP更像是指导方针，一个灵活的依赖于具体环境的开发方针。但是诸如“每周工作40小时”等看起来可能会感觉絮絮叨叨。Jeffries使得实践也会互相作用的，平衡，互相加强。以至于挑选使用的同丢弃的都是棘手的事情。
计划的制定：XP中关于制定计划的实现方法中可以反映出大多数迭代式RAD项目的特点。短期的，每三周为一个循环，频繁地更新，按优先级划分任务与技术， 分配stories（一个story定义了一个特殊的功能需求并以一种简单的方式记录在卡片上），所有的这些就是构成了XP中的计划。
小版本：“每个版本应该尽可能的小，而且包含最有商业价值的需求”，Beck如是说。这也反映了Tom Gilb在他的<软件工程管理原则>书中提到的关于渐进式发布的两点：“所有的大的项目都可以被分为局部的, 有用的小的步骤”以及“进化的步骤会传递到下一级。”小型版本的发布意味着具有在大型项目中经常缺少的频繁的反馈的实现.。 然而，一个开发小组当然需要考虑到“发布”同“可发布”的不同。无论是否是最终的版本发布还是一个简单的可发行版本的发布, 都需要付出安装，培训，转化等代价。
隐喻：在XP中“隐喻”以及“story”的使用可能会让人有一点不舒服。但是，这些术语的使用可以帮助我们以一种更人性化的方式加以理解，尤其是对客户而言。从某种程度上来说，隐喻同体系结构是同意语――他们都着重于从全局描述一个项目。但是体系结构经常会陷于符号与连接的泥潭。而XP使用“隐喻”定义一个从开发者到商业客户都可联系的全面一致的主题。隐喻用于描述项目全面的面貌，而Story用于描述个别具体的特征。
简单的设计：简单的设计包含两个部分。一，为已定义的功能进行设计，而不是为潜在地未来可能的功能进行设计。二，创建最佳的可以实现功能的设计。换句话说，不用管未来会是怎样，只创建一个目前为止可以实现的最好的设计。“如果你相信未来是不确定的，并且你相信你可以很方便的改变你的主意的话，那么对未来功能的考虑是危险的。”Beck写到。“只有在你真正需要的时候才去做“。 数据的质量是使用功能，不是捕捉与存储。此外，我说数据如果不是很系统的使用便会变坏。数据质量是系统使用的功能，不是可预料的设计。无论预期的对还是错，试着设计一个我们从来都不会用到的数据，最终结果很可能我们一次也不会用到它们。XP的简单设计方法反映了相同的观点。如在本文后来所描述的那样，这并不意味着不需要预测，而是说为预测的内容所做的设计一旦发生变化，其导致的代价是十分巨大的。
重构：如果我不得不找出一个能够将XP和其他方法区别开来的东西那就是重构――不断的软件再设计以改进它对于变化的反应。RAD方法常常很少甚至根本不与设计相关；XP应当被看作持续设计。当变化既快而且频繁的时候，应投入更多的精力于重构之上。参见下面的“重构”和“数据重构”部分。
测试：XP充满发人深思的有趣的难题。例如：什么是“先测试后编码”？在一些软件公司是通过代码的行数来对程序员的绩效加以考核，而测试的绩效则是通过发现的缺陷的数量来考核的。这两种方法都不能鼓励减少测试前产生的缺陷的数量。XP使用两种测试：单元测试和功能测试。单元测试要求在写代码之前就开发出相应功能的测试方法，并且测试应当是自动化的。代码一完成，它就被立即用有关测试集加以测试，从而能立即得到反馈。
配对编程：代码检查（还是直接用Inspection为好？）（也称审查或走查）也是被广为接受（至少在理论上）和有效度量的少数软件工程实践之一。在最好情况下，Inspection这种协同交互的检查能够加速学习，同时发现缺陷。一个较少被知道的关于Inspection的统计数据是尽管它在发现缺陷方面非常有效，但通过团队对于好的开发实践持续的学习和协作，可以更好的在第一时间预防缺陷。 一家软件公司客户引用一个内部研究结果，表明在测试阶段发现一个缺陷需15小时，在Inspection阶段发现一个缺陷则需2－3小时，而在Inspection之前发现缺陷只需15分钟。后面的数据来自于产生于常规审查的持续的团队学习。配对编程将这个带入下一步――与其用Inspection来递增式学习，为什么不用配对编程来学习呢？ “配对编程是两个人试图同时编程和理解如何更好编程的一种对话”，Beck写道。让两个人同时坐在一台终端前面（一个人敲代码或测试用例，一个人审查和思考）产生一种持续的、动态的交流。Williams在犹他大学进行的博士论文研究证明了配对编程不仅仅是一种美好的想法而且确有实效。
代码共享：项目组中的每个人都可以在任何时候修改其他项目成员的代码，这就是XP中所定义的代码共享。。对许多程序员以及经理而言，，共有代码的想法会引起一些疑虑，诸如”我不想让那些笨蛋改我的代码”，”出现问题我应该怪谁？”等等。共享代码从另一个层面提供了对配对编程中协作的支持。
经常集成：每日构造（build）在许多公司已经成为规范，许多公司将每日编链作为最小要求，XP实践者将每日集成作为最大要求，选择每两个小时一次的频繁编链。XP的反馈周期迅速：开发测试集、编码、集成（编链）和测试。 对于集成缺陷危险的认识已有多年了，但我们并不是总能拥有相应工具和时间将这些知识好好用起来。XP不仅提醒我们有可能有严重的集成错误，而且从实践与工具的角度提供了一种新的认识。
每周只干40小时：XP有12条实践的基本原则，但是有时候，比如象每周只干40小时的原则，听起来更象规则。我同意XP中的观点。只是不认为有必要硬性规定工作小时数。相比起来，我更喜欢一句类似于“不要把部队烧光”的话。在一些情况下，工作40小时太劳累，而在另外一些组里，甚至需要一周60个工作时。 Jeffries提供了关于加班的更多思索：”我们说的是加班被定义为我们不想在办公室的时候呆在办公室。而且你不应当加班超过一周。如果你超过了，就有什么东西出了问题――你过于劳累，有可能比你按时下班干的还差。我同意你关于60工作时一周的感受。在我们年轻和满身干劲的时候，这也许没问题。值得注意的是拖沓的一周又一周。” 我不认为一周的工作时间会造成大的差别。决定区别的是自愿的贡献。人们愿意来工作吗？他们对每一天都充满干劲吗？人们必须来工作，但是他们通过投入项目来创造巨大成就，而投入仅仅产生于目标感。
现场客户：这就对应到了最初软件开发时所提出的问题――用户参与。XP，同其他的快速开发一样，要求客户在现场持续地参与到项目组中。
编码标准：XP实践相互支持。例如，如果你进行配对编程并让他人修改共有代码，那么编码标准看起来就是必须的。
价值和规则
在2000年一月一日周六时候，华尔街日报（周一到周五出版的）用一个58页的版面发布了一个千僖年纪念版。在篇首的有关工业及金融的介绍里标着Tom Petzinger.写的：“长久的需求与召唤：经济新的增长点――显得同以往不同”。底下的一行 Petzinger 写着：“创造性正代替’万金药’的资本在成为首要的因素”。 Petzinger并没有谈论少数天才的创造性，而是谈了以下群体的创造性――从组到部门。一旦我们撇下天才们的个体创造，创造性就是环境的功能，而人们运用并互相协助而达到我们的结果的能力。如果你的公司认为软件开发只是一个统计上的重复试验，刻板的，技术性的过程，那么XP对于您也许并不合适。虽然XP中也有技术实践里的严格，但是XP本身是追求”创造”与”沟通”。
环境是靠价值同规则共同驱动的系统。XP（或者其他类似的）可能、也可能不适合您的单位，可是，应该澄清的是成功并不是只靠每周40小时的疯狂工作或者配对编程，也不是依靠XP之中应用在您单位中的价值或者是规则。 Beck指出了四个价值，五个基本规则，以及十个辅助规则–不过我要提到是这五个规则。
沟通：是的，沟通，可是，这里似乎没有新的东西在里面？沟通主要是看人们自己的看法，XP构建的基本是人与人，通过最简洁的文档，最直接的面对面沟通获得对任务环境的理解。
简洁：XP问每个开发组成员：“可能实现的最简洁的方法是什么？”。今天所保持的简洁，可以降低明天由于变更所带来的费用
反馈：Beck说：”对于编程而言，乐观主义是一种冒险。”，”而反馈则是相应的解决良药。”无论是用反复的构建或者频繁的用户功能测试，XP都能不断地接收到反馈。虽然每次对软件开发策略进行研讨时，我们都会说及反馈–即使是非常有害的瀑布模型–不同的是XP的实践者认为反馈比起前馈(feedforward)来更为重要。无论是对测试失败的代码进行修改或者是对用户拒收的软件从新返工，开发环境的快速变化要求开发人员对反馈有更好的认识。
勇气：无论您是使用CMM方法或者是XP的方法，方法使用的本身是要求勇气的。许多地方将勇气定义为做某件事情的权利，即使被迫去做其他的事情。开发人员经常借口压力而发出带有许多缺陷的产品，并对此加以坚持。然而，更进一步的应该包括其他的正确的不同的东西进来。通常，人们并不是缺少勇气，而是缺少一种让正确实践获得承认的理由，而且，也不坚信这点，勇气不像看起来那么重要。而如果你对之没有信心，那么是很难尽力工作的。 “勇气并不只是方法”，Jeffries说道，它是一种最终的价值。如果你在一种基于”沟通”，”简洁”，”反馈”的模式下工作，你将获得勇气，越往前信赖就越不重要。
优质的工作：好，如果你们中有赞成劣质工作的话，那么请举手离开这儿吧。不论你是一个Rational Unified Process，CMM，或是XP的赞成者，其本质的观点”你怎样定义质量”与”什么样的活动会赢得高质量”，定义”无缺点”质量是这个问题的一个方向。Jerry Weinberg的定义是”质量是对多数人有益”
