极限编程XP是由Kent Beck在1999年提出的一种轻量型的软件开发方法，它是多种敏捷方式的一种。

它摒弃了大多数传统的“重量型”软件开发过程的中间产物（诸如甘特图、状态报告、长篇需求文档等）来提高软件开发速度、适用新的需求、提高编程效率、增加程序的稳定性。它强调四条基本价值观，即沟通、简单、反馈和勇气，它没有对软件开发的整个过程进行强制而繁琐的规定，

而是提供了一套在实际软件开发过程中需要遵守的实践原则。这些原则各个项目团队可以光明正大地实施“拿来主义”，也可以增加一些实践，或者修订一些实践再使用。

与Scrum不同的是，Scrum是一种工作方式的框架，从组织到团队的设计，Scrum偏重于过程，而XP关注的是具体的工程技术实践。XP旨在通过工程实践的合理搭配使用，使开发者们能够自信地响应客户需求。

XP则偏重于实践.在XP中，常见的工程实践有：

1、完整团队：XP项目的所有参与者（开发人员、客户或客户代表、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。

这个场所的墙壁上或者白板上悬挂着大幅的、显著的图表以及其他一些展示进度的东西，透明的可视化。

2、项目计划：计划是持续的，也是循序渐进的。开发迭代进行中的两周，开发人员就为下两周迭代估算候选特性的成本，而客户则根据成本和业务价值（优先级）选择要实现的具体特性。每一个迭代后都会经过测试和集成，发布一个可工作的软件。最重要的是，每一阶段完成时都有些东西能够拿给客户看。

3、客户测试：作为选择每个所期望的特性验收工作的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作且有质量，客户可以反复进行验收测试，

4、简单设计：团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。你无需设计未来，而是设计今天。整个理念就是写简单代码，在需求改变的时候相应的改变你的设计。

5、结对编程：所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。当然，对结对编程是否真的提高效率不少人不敢苟同，但对于团队新人和复杂逻辑采用结对的方式大家还是认同的。

6、测试驱动开发：先写测试代码再编写程序:没有单元测试，不实现任何功能代码；只编写仅能代表一种失败情况的测试代码；只编写恰好能通过单元测试的产品代码。

7、改进设计：随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。在不断迭代中重构，掌握重构的精髓，在重构时进行更好的设计，增强代码的可测试性和可维护性等。

8、持续集成：持续集成在XP的实践中占据着非常重要的位置，集成是收集、打包和验证的过程。为了让产品可以持续地交付到客户那里，从客户处获得客户的反馈，就有必要让产品可以持续地集成，加快集成的频率，缩短集成的周期一个人提交（Check in）后，跑持续集成，所有人都有责任进行代码集成。一旦提交失败，不能很快修复则进行回滚操作，保证持续集成的状态能够快速恢复成绿色的状态。

9、集体代码所有权：任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

lO、编码规范：团队遵循一个公共的编码标准。因此系统中所有的代码看上去都像出自单独一个非常有能力的人之手。因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码。这是实现集体代码所有权的重要前提之一。

11. 重构( Refactoring )：重新审视需求和设计，重新明确地描述它们，以符合新的和现有的需求；在不改变系统行为的前提下，重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。

与其他方法论相比，xp最大价值不同在于：

在更短的周期内，更早地提供具体、持续的反馈信息。

在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。

依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。

依赖于口头交流、测试和源程序进行沟通。

倡导持续的演化式设计。

依赖于开发团队内部的紧密协作。

尽可能达到程序员短期利益和项目长期利益的平衡。