一.概述 　　极限编程 XP 是敏捷方法中最耀眼的明星，也是相对来说最成熟的一种。
XP 是一种敏捷、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。
与其他方法论相比，其最大的不同在于：在更短的周期内，更早地提供具体、持续的反馈信息。
迭代地进行计划编制，在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断地完善它。
依赖于自动测试程序来监控开发进度，并及时地捕获缺陷。
依赖于口头交流、测试和源程序进行沟通。
倡导持续的、演化式的设计。
依赖于开发团队内部的紧密协作。
尽可能达到程序员短期利益和项目长期利益的平衡。
　　XP 由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联，并通过行为贯穿于整个生命周期。
极限编程-是真的极限 二.四大价值观 　　XP 的核心是其总结的沟通、简单、反馈、勇气四大价值观，它们是 XP 的基础，也是XP 的灵魂。
沟通沟通。
从最基层的开发人员来说，沟通是团队协作的前提，沟通不畅会导致功能错位，重复开发等许多问题。
诸如某个程序员做出了一个设计决定，但是却没有及时地通知团队中的其他成员，结果可能导致功能不兼容或整合有偏差。
而在传统的开发方法中，并不在意这种口头沟通不畅的问题，而是希望借助于完善的流程和面面俱到的文档、报表、计划来替代，但是，这又引入了效率不高的新问题。
因此，小组成员之间要做到持续的、无间断的交流。
XP组合了诸如结对编程这样的最佳实践，鼓励大家进行口头交流、通过交流解决问题，提高效率。
简单。
XP 方法在工作中秉承“够用即好”的思路，也就是尽量地简单化，只要今天够用就行，不考虑明天会出现的新问题【这也是XP不能大范围实行的原因所在，大家都想一劳永逸】。
这一点看上去十分容易，但要真正做到保持简单的工作其实是很难的，因为在传统的开发方法中，都要求开发人员对未来做一些预先规划，以便对今后可能发生的变化预留一些扩展空间。
反馈。
缺乏必要的反馈是客户、管理层不理解开发团队的原因所在【更内在的原因是程序开发的难度对非开发人员来说是无法判断的，但往往会往简单的方向想，这就是说起来容易，做起来难】。
在很多项目中，当开发团队经历过了需求分析阶段之后，在一个相当长的时间段中，是没有任何反馈信息的。
整个开发过程对于客户和管理层而言就像一个黑盒子，进度完全看不到。
因此，开发团队需要更加注重反馈。
反馈对于任何软件项目的成功都是至关重要的，而在 XP 方法论中则更进一步，通过持续、明确的反馈来暴露软件状态的问题。
勇气-最多就是凉凉勇气。
在应用 XP 方法时，每时每刻都在应对变化：由于沟通良好，会有更多需求变更的机会；由于时刻保持系统的简单，新的变化会带来一些重新开发的需要；由于反馈及时，会有更多中间打断思路的新需求【这是开发者难以接受的点】。
总之，这一切使得开发团队处于变化之中，因此，这时就需要有勇气来面对快速开发，面对可能的重新开发。
勇气可以来源于沟通，因为它使得高风险、高回报的试验成为可能；勇气可以来源于简单，因为面对简单的系统，更容易鼓起勇气【凉凉】；勇气可以来源于反馈，因为可以及时获得每一步前进的状态（自动测试），会让人更勇于重构代码。
三.十二个最佳实践　　在 XP 中，集成了 12 个最佳实践，有趣的是，它们没有一个是创新的概念，大多数概念和编程一样老。
其主要的创新点在于提供一种良好的思路将这些最佳实践结合在一起，并且确保尽可能彻底地执行，使得它们能够在最大程度上互相支持。
计划游戏。
计划游戏的主要思想就是先快速地制定一份概要的计划，然后，随着项目细节的不断清晰，再逐步完善这份计划。
计划游戏产生的结果是一套用户故事及后续的一两次迭代的概要计划。
小型发布。
XP 方法秉承的是“持续集成、小步快走”的哲学思维，也就是说每一次发布的版本应该尽可能地小，当然前提条件是每个版本有足够的商业价值，值得发布。
小型发布可以使客户能够实时地了解项目的进展情况，从而提出改进意见，以实现更高的客户满意度。
隐喻。
常用于四个方面：寻求共识、发明共享语汇、创新的武器、描述架构。
简单设计。
强调简单的价值观，引出了简单性假设原则，落到实处就是“简单设计”实践。
其实，XP 的简单设计实践并不是要忽略设计，而是认为设计不应该在编码之前一次性完成，因为那样只能建立在“情况不会发生变化”或者“我们可以预见所有的变化”之类的谎言的基础上。
测试先行。
测试是开发的校验。
没有经过测试的开发是无效的开发，随着开发的延伸，测试会越来越麻烦。
这样，就导致了一个恶性循环，越是没测试，代码的效率与质量越差，花在找缺陷、解决缺陷的时间也越多。
由于效率降低，因此时间更紧张，压力就更大。
重构。
重构是一种对代码进行改进而不影响功能实现的技术。
重构的目的是降低变化引发的风险、使得代码优化更加容易。
结对编程。
结对编程大大降低了沟通的成本，提高了工作的质量。
结对编程技术被誉于 XP 保证工作质量、强调人文主义的一个最典型的实践，应用得当还能够使开发团队协作更加顺畅、知识交流与共享更加频繁、团队稳定性也会更加牢固。
集体代码所有制。
团队中的每个成员都拥有对代码进行改进的权利，每个人都拥有全部代码，也都需要对全部代码负责。
同时，XP 强调代码是谁破坏的（修改后出现问题），就应该由谁来修复。
持续集成。
持续集成是最佳实践的基本支撑条件。
每周工作 40 小时。
“每周工作 40 小时”中的“40”不是一个绝对数，它所代表的意思是团队应该保证按照“正常的时间” 进行工作。
现场客户。
在 XP 项目中，应该时刻保证客户负责业务决策，开发团队负责技术决策。
因此，在项目中有客户在现场明确用户故事，并做出相应的业务决策，对于 XP 项目而言有着十分重要的意义。
编码标准。
XP 方法的编码标准的目的不是创建一个事无巨细的规则列表，而是要能够提供一个确保代码清晰，便于交流的指导方针。
　　有句经典名言“1+1>2”最适合表达 XP 的观点，XP 方法的最大价值在于，在项目中融会贯通地运用这 12 个最佳实践，而非单独使用。
当然，可以使用其中的一些实践，但这并不意味着就应用了 XP 方法。
XP 方法真正能够发挥其效能，就必须完整地运用 12 个实践。