极限编程

（ExtremeProgramming，简称XP）

由KentBeck在1996年提出的，适用于小团队开发。

是一个轻量级的、灵巧的软件开发方法；

基础和价值观：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。此外还扩展了第五个价值观：谦逊（Modesty）。 

XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

 13个核心实践

规划策略(The Planning Game)；

结对编程(Pair programming)

由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常一个人负责写编码，而另一个负责保证代码的正确性与可读性。

测试驱动开发(Testing-Driven Development)

强调”测试先行”。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。

重构(Refactoring)

重构的使用确保程序员加入新的功能后代码仍保持简单， 从而保证简单的代码仍然能够运行所有的测试。

简单设计(Simple Design)

团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

代码集体所有权(Collective Code Ownership)

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

持续集成(Continuous Integration)

把代码持续集成到一个主干可以避免重复和不匹配的代码。

客户测试——（Customer Tests）

客户对每个需求都定义了一些验收测试。通过运行验收测试，开发人员和客户可以知道开发出来的软件是否符合要求。极限编程开发人员把这些验收测试看得和单元测试一样重要。为了提高效率，最好能将这些测试过程自动化。

小型发布（Small Release）

强调在非常短的周期内以递增的方式发布新版本，从而可以很容易地估计每个迭代周期的进度，便于控制工作量和风险；同时，也可以及时处理用户的反馈。

每周40小时工作制（40-hour Week）

XP过程通过使用一些形象的比喻让所有人对系统有个共同的、简洁的认识。XP认为加班是不正常的，因为这说明关于项目进度的估计和安排有问题。

编码规范（Code Standards）

系统隐喻（System Metaphor）

为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。比如，对于一个搜索引擎，它的Metaphor可能就是“一大群蜘蛛，在网上四处寻找要捕捉的东西，然后把东西带回巢穴。”

极限编程