Extreme Programming（极限编程，简称XP）是由Kent Beck在1996年提出的。Kent Beck在九十年代初
期与Ward Cunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有
效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月，
Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。
XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观
是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简
单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个
相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚
开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
什么是软件开发
软件开发的内容是：需求、设计、编程和测试！
需求：不仅仅是用户需求，应该是开发中遇到的所有的需求。比如，你首先要知道做这个项目是为了解
决什么问题；测试案例中应该输入什么数据……为了清楚地知道这些需求，你经常要和客户、项目经理
等交流。
设计：编码前，肯定有个计划告诉你要做什么，结构是怎样等等。你一定要按照这个来做，否则可能会
一团糟。
编程：如果在项目截止日，你的程序不能跑起来或达不到客户的要求，你就拿不到钱。
测试：目的是让你知道，什么时候算是完成了。如果你聪明，你就应该先写测试，这样可以及时知道你
是否真地完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。
软件开发中，客户和开发人员都有自己的基本权利和义务。
客户：
• 定义每个用户需求的商业优先级；
• 制订总体计划，包括用多少投资、经过多长时间、达到什么目的；
• 在项目开发过程中的每个工作周，都能让投资获得最大的收益；
• 通过重复运行你所指定的功能测试，准确地掌握项目进展情况；
• 能随时改变需求、功能或优先级，同时避免昂贵的再投资；能够根据各种变化及时调整项目计划；
• 能够随时取消项目；项目取消时，以前的开发工作不是一堆垃圾，已开发完的功能是合乎要求的，
正在进行或未完成的的工作则应该是不难接手的。
开发人员：
• 知道要做什么，以及要优先做什么；
• 工作有效率；
• 有问题或困难时，能得到客户、同事、上级的回答或帮助；
• 对工作做评估，并根据周围情况的变化及时重新评估；
• 积极承担工作，而不是消极接受分配；
• 一周40小时工作制，不加班。
这就是软件开发，除此之外再还有其它要关心的问题！
灵巧的轻量级软件开发方法
一套软件开发方法是由一系列与开发相关的规则、规范和惯例。重量级的开发方法严格定义了许多的规
则、流程和相关的文档工作。灵巧的轻量级开发方法，其规则和文档相对较少，流程更加灵活，实施起
来相对较容易。
在软件工程概念出现以前，程序员们按照自己喜欢的方式开发软件。程序的质量很难控制，调试程序很
繁琐，程序员之间也很难读懂对方写的代码。1968年，Edsger Dijkstra给CACM写了一封题为GOTO
Statement Considered Harmful 的信，软件工程的概念由此诞生。程序员们开始摒弃以前的做法，转
而使用更系统、更严格的开发方法。为了使控制软件开发和控制其它产品生产一样严格，人们陆续制定
了很多规则和做法，发明了很多软件工程方法，软件质量开始得到大幅度提高。随着遇到的问题更多，
规则和流程也越来越精细和复杂。
到了今天，在实际开发过程中，很多规则已经难于遵循，很多流程复杂而难于理解，很多项目中文档的
制作过程正在失去控制。人们试图提出更全面更好的一揽子方案，或者寄希望于更复杂的、功能更强大
的辅助开发工具（Case Tools），但总是不能成功，而且开发规范和流程变得越来越复杂和难以实施。
为了赶进度，程序员们经常跳过一些指定的流程，很少人能全面遵循那些重量级开发方法。
失败的原因很简单，这个世界没有万能药。因此，一些人提出，将重量级开发方法中的规则和流程进行
删减、重整和优化，这样就产生了很多适应不同需要的轻量级流程。在这些流程中，合乎实际需要的规
则被保留下来，不必要的复杂化开发的规被抛弃。而且，和传统的开发方法相比，轻量级流程不再象流
水生产线，而是更加灵活。
Extreme Programming（XP）就是这样一种灵巧的轻量级软件开发方法。
为什么称为“Extreme”（极限）
“Extreme”（极限） 是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、
做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其
开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。
XP的软件开发是什么样
1 极限的工作环境
为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也
做得最好。每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利
和义务。所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房子中工作，还有茶点
供应；每周40小时，不提倡加班；每天早晨，所有人一起站着开个短会；墙上有一些大白板，所有的
Story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；下班后大家可以一起玩电脑游
戏……。
2 极限的需求
客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一
直起着很重要的作用。开发人员和客户一起，把各种需求变成一个个小的需求模块（User Story），例
如“计算年级的总人数，就是把该年级所有班的人数累加。”；这些模块又会根据实际情况被组合在一
起或者被分解成更小的模块；它们都被记录在一些小卡片（Story Card）上，之后分别被程序员们在各
个小的周期开发中（Iteration，通常不超过3个星期）实现；客户根据每个模块的商业价值来指定它们
的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）
需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被
安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；客户为每个需求模块指定验收测试
（功能测试）。
每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面
实现了相应的计划中的所有需求。而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发
完成后才能开始使用。
3 极限的设计
从具体开发的角度来看，XP内层的过程是一个个基于测试驱动的开发（Test Driven Development）周
期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试
（Unit Test）。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的；随着一个个小的需
求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行
了对客户的承诺。XP提倡对于简单的设计（Simple Design），就是用最简单的方式，使得为每个简单
的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式（Big
Design Up Front），因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计
复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过
程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需
求。
4 极限的编程
既然编程很重要，XP就提倡两个人一起写同一段程序（Pair Programming），而且代码所有权是归于整
个开发队伍（Collective Code Ownership）。程序员在写程序和重整优化程序的时候，都要严格遵守
编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。
5 极限的测试
既然测试很重要，XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到
一起（Continuous Integration），每次整合后都要运行单元测试；做任何的代码复核和修改，都要运
行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。除了单元测试之外，
还有整合测试，功能测试、负荷测试和系统测试等。所有这些测试，是XP开发过程中最重要的文档之
一，也是最终交付给用户的内容之一。
