敏捷软件开发（Agile software development）
它是一种用来应对软件需求的不断变更的新的软件开发技术。
强调整个开发过程中业务人员和开发人员紧密协作在一起，面对面交流，频繁性的交付软件，随时应对需求的变更。追求在尽可能短的时间内交付较小的可用的功能，并在整个项目周期中持续改善和增强。
极限编程（Extreme programming，简XP）
极限编程是敏捷开发中最富有成效的几种方法学之一。
XP是一种近螺旋式开发方法，它将复杂的开发过程分解成一个个小的开发周期，对需求分析、设计、编码、测试进行反复迭代。在小的开发周期中通过客户、业务人员和开发人员的积极交流可以非常清楚软件开发过程中现存的问题并进行及时调整。
需求
把需求分为很多小的模块（功能），客户根据模块的商业价值进行优先级排序，开发人员确定每个模块的风险，保证高风险的模块先被开发，综合评估后将每个模块安排到开发过程中不同的时期。
设计
XP内层的过程是一个个基于测试驱动的开发周期，即先进行测试再编码。每个开发周期开始都有很多相应的单元测试，最开始因为还未开发所有测试都是失败的，通过需求模块的不断完成，通过的单元测试也越来越多。XP设计的最终目标就是每个简单需求模块写出来的程序都能通过所有相关的单元测试。
编程
提倡结对编程（PairProgramming），即两个人一起合作完成。
测试
在开发之前就写好单元测试，开发人员将每次开发好的模块整合到一起进行单元测试，发现bug就要增加相应的测试。除了单元测试之外，还有集成测试、功能测试、压力测试和系统测试等。
12个最佳实践
1.计划的制定( Planning Game )
制定计划的目的是确定本次迭代的范围。要求结合项目进展和技术情况，确定下一阶段要开发与发布的系统范围。
本步骤的重心应该放在决定什么是对客户来说最重要的任务和如何首先完成这些任务。 计划的制定包括客户选择的项目大小、程序功能的优先级、各个版本的合成和发布日期。
2.小版本( Small Release )
小版本这一实践背后的观点是：用最少的代码工作量带来最大的业务价值。 程序的特性必须有原子性（不可分解）。 一个特性必须实现足够的功能来实现它的业务价值。 这个步骤可能是违反直觉的，但这样做是为了使项目尽快转化为产品。
发布小版本可以从客户那儿得到反馈和通过让客户确认，这就是他们需要的软件来降低项目的风险。
基本上，这个步骤使用Paredo规则：20%的努力能带来80%的业务价值。 小版本在计划的制定下，一版接一版地发布来决定何种特性将带来巨大的影响， 同时这也配合保持简单设计这一实践的实施。
3.简单设计( Simple Design )
简单的设计能保证代码的简单。
最简单的设计并不通过预测未来的需求来尝试未来的问题。 最简单的设计将软件的一个可测试版本交付给用户。 最简单的设计通过所有测试，没有重复和费解的逻辑代码，但能够表达每一个程序员的意图。 这个步骤伴随着小版本的发布。 如果你的系统架构不能够很好的表达和满足预期的需要，你将不能够尽快的交付。
我们是程序员，不是占卜者。 我们没有水晶球，所以预测客户未来的需求最好的方法是给他们一个可以工作的系统， 并且从他们那儿得到反馈。 大多数客户不知道如何准确表达他们的需要，你交付一些他们能够切实可用的东西有助于缓解这种问题。 记住，一幅图片胜过千言万语，一个工作模型抵得上一千幅图片。
4.测试驱动( Test-driven )
测试是极限编程的核心。
测试应该是自动的，这样你会有信心和勇气来改变和重构代码，同时不破坏系统。 这与瀑布开发模型正好相反。
5.持续集成 ( Continuous Integration )
持续集成是一个至关重要的概念。
为什么我们要等到项目的最后才检查系统的每一部分是否都能正常工作？ 每几个小时（至少一天一次）系统必须构建和测试一遍。 通过经常这样做，你将能够知道何处的改变破坏了系统并作出调整， 从而避免浪费时间一直等到修改已堆积成山并且你自己都忘记了修改的细节。
6.代码重构( Refactoring )
重构的使用确保程序员加入新的功能后代码仍保持简单， 从而保证简单的代码仍然能够运行所有的测试。
这个实践的思想是不复制代码，也不写“丑陋”、“发臭”的代码。 重构的重心在于测试能够验证代码仍然具备需要的功能。 测试和重构交替进行。 自动单元级（unit-level）测试给你勇气来重构和保持代码的简单和表现力。
7.结对编程( Pair Programming )
结对编程大概是极限编程中最具革命性的实践—这通常是管理者最花时间来习惯的地方。
在表面上，他们的反应很容易理解：如果我们的项目进度落后了， 那么怎样在同一个任务中使用两个程序员来提高开发速度呢？ 为什么需要两个程序员使用一个键盘和一个显示器呢？
首先，它增加了团队成员之间的交流。 我们工作的很大一部分需要依靠其他程序员的工作。 这个程序员今天和你在一个团队，不一定明天还有必要和你在一个团队。 同样，如果一个人知道许多特定的技术（如：EJB或是Oralce）或者掌握专业领域的技能， 试问有其他更好的方法比和那个人结对能更好地向对方学习吗？ 什么是质量？ 结对编程能提供持续的信息反馈和确保正在编程的人进行重构、测试和遵守编码标准。
8.代码共享( XP )
代码共享这一极限编程中的实践表明任何一个人都能够对系统作出修改。认为开发小组的每个成员都有更改代码的权利，所有的人对于全部代码负责。
每个程序员都拥有系统的所有权和需要对系统负责。 如果没有人了解某一特定细节，那么单元测试负责检验API和检查你的改变有没有破坏系统。 因此，你没有必要等到团队中的另一个成员来修正这个错误。 如果不采用代码共享，并且在系统中有一些错误，那么每一个人必须停下来等待直到你将这个错误修复。
9.每周只工作40小时( 40-hour Week )
充分利用时间。
这一规则的隐含意思是统计的时间是处于高效率工作的有效时间和必须从你的工作时间中得到最大的收益。 长时间的仁义应该避免。 任何妨碍在下一个发布版本中提供最大商业价值的行为都应该被避免。 劳累过度的程序员将犯下许多错误。
10.现场客户( On-site Customer )
如果有可能，客户应该与程序员直接接触。
客户必须阐明需求的功能。 客户也参与到计划的制定中，记录客户需求时，用程序员和客户都能理解的语言编写。
11.隐喻( System Metaphor )
记录客户需求时，用程序员和客户都能理解的语言编写。 通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。
12.代码规范( Code Standards )
极限编程的实行者应该遵守代码规范这一实践。 你必须能够明白其他程序员写的代码。
