极限编程是关于放弃羁绊尽力而为绽放自我

以下揉摘自Kent Beck《解析极限编程：拥抱变化》。

放弃羁绊

极限编程（Extreme Programming，XP）和社会性的变革（social change）相关。XP要求我们放弃那些妨碍生产率但保护我们自己的防御行为。虽然这可能会使我们感觉到自己失去了掩蔽。

XP要求我们坦承自己有能力做什么，然后去做这些能力所及的事情。同时允许并希望其他人也这样做。放弃我们不成熟的自负——“我比其他人都懂得多，我需要的就是让我独立行事，成为最棒的。”XP要求我们在更大的范围内，在包括商业/工作领域的团体中找到我们正确的位置；XP是关于每个人是如何成为最好的自己，如何成为自己所能成为的最好的开发者的过程。XP探讨了如何才能写出伟大的、对业务真正有益的代码。

好的合作关系是做好事情的保证。除了编码和其他活动，我们在工作场所的人际关系也会影响到生产率和自信心。成功既需要技术又需要好的合作关系，极限编程致力于同时解决这两个问题。

尽力而为

为成功做好准备。不要因为踌躇退缩而与成功失之交臂。尽力而为，然后处理其结果，这就是极限（Extreme）的含义。暴露自己，对有些人来说，这不可思议，而对其他人却习以为常。

XP是一种软件开发的风格，专注于编程技术、清晰沟通还有团队协作的精彩实践，这些将帮助我们完成以前几乎不可想象的事情。XP包括：

一种软件开发的哲学，基于沟通、反馈、简约、勇气和尊重的价值观。

一整套被证明在软件开发中有用的实践。这些实践相辅相成，相互增强。我们将它们作为以上价值观的表达形式。

一系列用来将以上价值观投入实践的、辅助的原则和智能技术。当缺乏对应你的独特难题的现成实践时，它会起作用。

一个共享这些价值观和实践的社区。

XP是一条可以使得一起开发软件的人们共同进步直至卓越的途径。它和其他方法的区别有：

开发周期短，提供及早的、具体的、持续的反馈。

增量计划方法。迅速地提出一个总体计划，并在项目生命周期中不断演化。

能够灵活安排功能的实现，以对变化的业务需求做出反应。

使用由程序员、客户和测试人员编写的自动测试来监控开发进度，支持系统的演化，并尽早发现缺陷。

通过口头沟通、测试和源代码沟通系统结构和意图。

演化的设计过程贯穿整个系统生命周期。

依赖于能力普通但能积极参与的程序员之间的紧密协作。

各种实践兼顾项目成员的短期直觉以及项目的长期利益。

绽放自我

XP是Kent Beck在自己的软件开发实践中协调人性和生产率并共享这个协调的一个尝试。越是有人情味地对待自己和别人，我们大家的生产率就越高。成功的关键不在于自我禁欲，而在于承认我们是人，我们生活在人与人之间交往的环境中。

技术同样重要。我们是工作于技术领域的技术人员。工作方式有好坏之分，对卓越技术的追求在开发型组织中是非常重要的。技术支持信任关系的建立。如果你能准确地评估你的工作，第一时间提交有质量的工作，建立快速的反馈循环，你就能成为一个可以信赖的搭档。XP需要参与者学会高层次的技术，为团队的目标服务。

良好的、安全的社会交往和优秀的技术技能对成功的XP开发都是必不可少的。

一个例子是“不设防才是真正的安全”的观念。隐瞒一些事情来保持安全的旧习惯并不能真正起作用。隐瞒20%工作量并不能保护我，当项目失败的时候，没有尽全力的事实并不会真的让我感觉好一点，也无法消除不能让项目运作所带来的失败感。如果我尽了全力写程序而人们不喜欢，我仍然可以自我感觉很好，因为我尽力了。这种态度才让我感到安全，不管在什么环境下。如果我感觉如何的基础在于我是否尽力，我就能够通过尽全力而使自己感觉良好。

XP团队竭尽全力去取胜而且勇于承担后果。如果自尊没有跟项目联系起来，在任何情况下我们都会尽全力做到最好。在XP中我们不为失败作准备。在人际关系上保持一点距离、通过偷懒或加班来隐瞒工作量、拖延反馈导致又一次责任扩散，所有这些行为在XP团队中都没有存在的空间。

如果你有6周时间去完成一个项目，你唯一能够控制的是你自己的行为。你会完成6周的活还是少干一点呢？你不能控制别人的期望，但你可以告诉他们你所知道的关于项目的所有事情，这样他们的期望才有跟现实匹配的可能性。当我知道了这一点，我对最后期限的恐惧就消失了。“管理”其他人的期望不是我的工作，而是他们自己需要操心的，我要做的就是尽可能沟通清楚。

XP是一个致力于解决软件开发过程中所有层次上的风险的软件开发学科。同时XP也高效产出高质量的软件，并且在XP的执行中也有许多乐趣。那么，XP如何解决开发过程中的风险呢？

进度延迟——XP提倡短发布周期。一个发布周期最多几个月，这样，任何延迟的范围都是有限的。在一个发布周期内，XP使用客户要求的功能的每周迭代来形成关于进度的详细反馈。在一个迭代内，XP计划许多小的任务以保证团队可以在该周期内解决问题。最后，XP还提倡优先实现高优先级的功能，这样可以保证在发布版本中错过的功能的价值比较低。

项目取消——XP中的最小发布必须是满足最大商业意义的部分，这些功能的选择工作由团队中面向商业的成员来承担。这样，在部署之前出错的可能就会较少，同时也保证了软件的价值最大。

系统恶化——XP中创建并维护一整套自动测试，每次系统发生改变后都要运行（一天好几次）这些测试，以确保质量基线。XP总是保证系统处于可部署的状态，而不允许出现问题的积累。

缺陷率——XP中既包括了程序员书写的每个函数（function）的测试，也包括了客户书写的对每个程序特性（program feature）的测试。

业务误解——XP提倡业务人员成为团队成员。项目规约（specification）在开发过程中不断改进，因此客户和团队的知识都能反映在软件中。

业务变更——XP缩短了发布周期，因此在一个单独的发布周期中几乎没什么变化。在一个发布周期中，客户可以随意用新的功能替代没有完成的功能。开发团队甚至不会注意到他们是在开发一个新发现的功能还是几年前就定义的特性。

错误特性太多——XP坚持只解决最高优先级的任务。

人员流动——XP要求程序员估算自己工作所需时间并完成工作。同时XP也将这些工作的实际完成时间返馈给程序员，帮助他们改善估算的精确性，从而使估算的结果得到尊重。在XP中，谁能做出估算，谁能改变估算都很清楚，因此程序员几乎不会因为被要求去完成明显不可能完成的任务而感到沮丧。XP同样鼓励团队中的相互沟通，来减少孤独感，因为这常常是工作不满的主要原因。最后，XP中有一个关于人员流动的清晰模型。鼓励新成员逐渐承担越来越多的责任，新成员之间互相帮助，同时老成员也为新成员提供帮助。

XP假设你把自己看成团队的一部分，一个具有清晰目标和执行计划的理想个体。XP假设你想与别人一起工作。XP假设可以经济地应付变化。XP假设你希望成长、改善自己的技能，改善人际关系。XP假设你愿意做出改变来达成这些目标。

总结：什么是XP?

XP是放弃旧的、低效的技术和习惯而采用新的有效的技术和习惯。

XP是因为你今天的竭尽全力而充分欣赏自己。

XP是努力在明天做得更好。

XP是要你按照对团队共同目标做出的贡献来评价自己。

XP是让你的一些人性需求在软件开发中得到满足。

价值观为什么

价值观是知识和理解的另一个层次。价值观是在某种处境中我们喜欢或不喜欢某事的根源。当一个程序员说“我不想估算我的任务”，通常这和技术无关。事实上他已经做出了估算，只是不想暴露他的真实想法，他担心提供了一个判断的基准点，以后会对自己不利，因此，最好给出一个3倍的估算！这件事情揭露了一些深层次的问题，关于这个程序员是如何看待开发中的社会性力量（social forces）的问题。原因也许是过去他曾受到不公正的指责。在这种情形下，对这个程序员而言，保护的价值要胜过沟通。价值观是用于评价我们所见、所想和所做的一大标准。

将价值观显式化很重要，因为没有价值观，实践很快会变成生搬硬套，为行动而行动，缺乏目的或方向。当我听说一个程序员摆脱了某个缺陷，我听到的是价值观的失败，而不是技术的失败。缺陷本身可能只是技术失败，但是不愿从缺陷中吸取教训则表示这个程序员实际上没有重视学习和自我改进。对程序、组织和程序员本人来说，这样都无法从缺陷中得到最大的收益。从根源上分析，价值观与实践的结合意味着程序员有充分的理由会选择高效率地执行一个实践。价值观让实践有的放矢。

实践是价值观的表现。价值观是在一个高层次上的表达，因此我能够以价值观的名义做任何事。“因为我重视沟通，所以写了这份1000页的文档”，也许是这么回事，也许不是。如果每天一次15分钟的交谈比写这份文档更有效的话，那么文档就不能说明我重视沟通，以最有效的方式交流才能说明我重视沟通。

实践是清楚明确的。每个人都能知道我是否参加了早上的站立式会议。我是否真正重视沟通并不是那么明确和具体的，但我是否在进行加强沟通的实践却是具体的；正如价值观让实践有的放矢，实践使价值观变得具体可见。

价值观和实践是大洋的两岸。价值观是普适的。理想的情况下，我工作中的价值观同我生活中其他时候的价值观一样。然而，实践却有非常强的情景性。如果我想得到自己编程好坏的反馈，可以进行持续的构建和测试；如果我在换尿布时想得到反馈，“持续的构建和测试”则是荒谬的。这两件事所涉及的外力是截然不同的。为了获得换尿布的反馈，我不得不在换完后将婴儿抱起来，看看尿布是否会掉下来，我不可能半道儿测试。在编程和换尿布这两种活动中，“反馈”的价值观是以完全不同的形式表现出来的。

在价值观与实践之间架起桥梁的是原则。原则是生活中具体领域的指导方针。作为一名园艺师，Paul在原则层次上的知识也是超过我的。我也许仅仅知道在草莓边上种植万寿菊，Paul却知道伴栽法可以使彼此毗邻的植物相互弥补自己弱点的原则。万寿菊天生克制吃草莓的虫子。将它们种植在一起是一种实践，伴栽法就是原则。

如果每个人都关注什么对团队才是重要的，那么他们应该关注的是什么？XP中包含了5个指导开发的价值观：沟通、简单、反馈、勇气和尊重。

沟通

在团队软件开发中最要紧的是沟通。每当开发中出现问题的时候，通常已经有人知道了解决方法，但有权做出改变的人却不知道。当忽视自己直觉的时候，即使是我一个人也会出现这种问题。人们之间的沟通的情况则更加复杂。

一旦你发现了一个令人惊异的问题，沟通会帮助你解决它。你可以向过去碰到过类似问题的人打听。你们可以作为一个团队讨论如何避免问题的再次发生。

每当你遇到一个问题，首先问自己这个问题是不是由于缺乏沟通引起的，你需要什么样的沟通来解决该问题？需要什么样的沟通来使你以后避免这样的麻烦？

沟通对于创造团队意识和高效合作意识是很重要的。虽然沟通并不能给予你高效软件开发所需要的全部。

简单

简单是XP价值观中智力色彩最强烈的。构造一个优雅地解决今天问题同时又足够简单的系统是很难的。昨天的简单解决方案在今天看来可能仍然不错，但也可能过于简单了，或者太复杂了。当你需要做出改变，以重新获得简单性时，你必须找到一条从你当前位置到目的地的路径。

我请人们思考这样一个问题：什么是最简单而又可能有效的？批评家通常会忽略了这个问题的后半部分：“嗯，我们的系统不能简化，因为它有严重的安全和可靠性约束。”我并不是要你思考过于简单而无效的东西，只是要求调整你的思想以消除多余的复杂部分。如果安全上的考虑导致本来只需使用一个处理器就可以解决的问题必须分成两个处理器来解决的话，那么对我而言，结果仍然可以是简单的。更好的解决方案仅仅在于你能否找到一种在单个处理器上处理安全问题的方法。

简单的意义与具体的环境相关。如果我正在和一个懂得解析器生成器的团队一起编写解析器，那么使用解析器生成器就是简单的。如果团队中没有人知道如何解析，并且要解析的语言也很简单的话，使用自顶向下的递归解析器将会更简单。

价值观之间是相互平衡和相互支持的。加强沟通能够去除那些不需要的或者可暂缓的需求，从而达到简单化。同时，力求简单化会使你大大减少沟通的内容。

反馈

没有哪个固定方向是长久有效的，不论我们在谈论软件开发细节、系统需求还是系统架构。超越经验而确定出来的方向，它的半衰期尤其短。变化是不可能避免的，变化产生了对反馈的需要。

“从一开始就选择正确的做法，不是更容易嘛？”——当然可以，除了三件事情：

我们可能不知道“正确”的做法是什么。如果我们正在解决一个全新的问题，也许有几种有效的解决方案，也许根本没有明确的解决方案。

今天正确的东西明天可能就是错误的。在我们控制之外的或没有能力预测的变化很容易就会使昨天的决定失效。

今天按照“正确”的做法去做每一件事，可能需要太长时间，以至于还没有完成之前，明天环境的变化就使之失效了。

我们不断改进，并不期望可以马上做到完美，我们使用反馈来一步步地接近我们的目标。反馈有很多种形式：

你和你队友关于某个想法的观点；

当你实现一个想法时，代码会是什么样的；

测试是否容易编写；

测试能否运行；

一旦该想法被部署，它运转得如何。

XP团队致力于在尽可能快的情况下产生尽可能多的反馈。尽量将反馈的周期缩短为分钟或小时，而不是星期或月。知道得越早，你就可以调整得越早。

可能会出现太多反馈。如果团队正在忽略重要的反馈，则需要暂缓下来（这可能会让人失去信心），直到响应了重要的反馈，团队才可以处理那些导致过多反馈的潜在问题。例如，试想你在将要发布季度版本时突然发现很多缺陷报告，多得以至于在发布前你都处理不完；此时应该暂缓版本发布直到你处理完所有的缺陷报告并开发新功能。用这段时间来搞清楚为什么会出现如此多的缺陷或为什么处理每个缺陷都要花费这么长时间。一旦这个基本的问题得到了解决，就可以开始重新按季度发布并加快反馈机制了。

反馈是沟通的关键部分。“性能会成为一个问题吗？”“我不知道，让我们写一个小的性能原型看看。”反馈同样有益于简单。三种解决方案中谁将是最简单的？都尝试一遍就会明白了。虽然将同一件事情重复三遍看起来有些浪费，但这也许是获得足够简单的解决方案最有效的途径。同时，系统越简单，获取它的反馈就越容易。

勇气

勇气是面对恐惧的有效行动。有些人反对使用“勇气”这个词，认为它是保留给正在穿越黑暗之门的那些巡逻士兵的。我不是要抹杀士兵身上展现出来的这种自然的勇气，但软件开发中的人们同样也会感到畏惧。他们面对恐惧时的处理方法显示了他们是否是一个团队的有效组成部分。

有时勇气表现为对某种行动的偏爱。如果你知道问题是什么，那你就去做吧。

有时勇气表现为耐心。如果你知道有问题存在但不知道问题是什么，则需要勇气来等待真正问题的明显出现。

如果没有其他价值观的平衡，勇气会是危险的。不顾后果地盲目行事不是高效的团队合作方式。恐惧的时候，我们需要鼓励团队，并根据其他价值观来指导下一步的行动。

仅仅只有勇气是危险的，与其他价值观相呼应的勇气才是有力的。表达愉快或不愉快真相的勇气会有助于沟通和信任的建立；放弃失败的解决方案和寻求新方案的勇气会有助于鼓励对“简单”这一价值观的追求；寻求真实具体答案的勇气会有助于增加反馈。

尊重

前面提到的4个价值观指向处于它们背后更深刻的另一个价值观：尊重。如果团队成员不关心彼此，也不理会别人所做的事情，XP是无用的。如果团队的成员不关心项目，那么这个项目就没救了。

受软件开发影响的每个人，都有其作为人的价值观。不会有某个人本质上比其他人更有价值。所以要同时提高软件开发的人性和生产率，每个人对团队的贡献都应该得到尊重。我是重要的，你也是。

其他

沟通、简单、反馈、勇气和尊重，这些不是高效软件开发所必需的价值观。但它们驱动着XP。你的组织、团队和你自己可能会选择其他的价值观，但最重要的是要根据团队的价值观矫正团队的行为。如果你这么做，你将会把因为同时维持众多价值观而产生的浪费降至最低。

其他重要的价值观包括：安全、保密、可预测性和生活品质。坚持这些价值观会采用与XP价值观不同的方式修正你的实践。

求道致用，做最好的敏捷知识库。