什么是极限编程？什么是借口编程？什么是敏捷开发？
ExtremeProgramming（极限编程，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能行以及面临的困难。1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。
XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
为什么称为“Extreme”（极限）
“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。
XP的软件开发是什么样
1极限的工作环境
为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也做得最好。每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。所有的人都在同一个开放的开发环境中工作，最好是所有人在同一个大房子中工作，还有茶点供应；每周40小时，不提倡加班；每天早晨，所有人一起站着开个短会；墙上有一些大白板，所有的Story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；下班后大家可以一起玩电脑游戏……。
2极限的需求
客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一直起着很重要的作用。开发人员和客户一起，把各种需求变成一个个小的需求模块（UserStory），例如“计算年级的总人数，就是把该年级所有班的人数累加。”；这些模块又会根据实际情况被组合在一起或者被分解成更小的模块；它们都被记录在一些小卡片（StoryCard）上，之后分别被程序员们在各个小的周期开发中（Iteration，通常不超过3个星期）实现；客户根据每个模块的商业价值来指定它们的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；客户为每个需求模块指定验收测试（功能测试）。
每发布一次开发的软件（经过一个开发周期），用户都能得到一个可以开始使用的系统，这个系统全面实现了相应的计划中的所有需求。而在一些传统的开发模式中，无论什么功能，用户都要等到所有开发完成后才能开始使用。
3极限的设计
从具体开发的角度来看，XP内层的过程是一个个基于测试驱动的开发（TestDrivenDevelopment）周期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试（UnitTest）。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的；随着一个个小的需求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。XP提倡对于简单的设计（SimpleDesign），就是用最简单的方式，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式（BigDesignUpFront），因为这种设计中有很多内容是你现在或最近都根本不需要的。XP还大力提倡设计复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过程；在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需求。
4极限的编程
既然编程很重要，XP就提倡两个人一起写同一段程序（PairProgramming），而且代码所有权是归于整个开发队伍（CollectiveCodeOwnership）。程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。
5极限的测试
既然测试很重要，XP就提倡在开始写程序之前先写单元测试。开发人员应该经常把开发好的模块整合到一起（ContinuousIntegration），每次整合后都要运行单元测试；做任何的代码复核和修改，都要运行单元测试；发现了BUG，就要增加相应的测试（因此XP方法不需要BUG数据库）。除了单元测试之外，还有整合测试，功能测试、负荷测试和系统测试等。所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一。
XP中一些基本概念的简介
UserStory：开发人员要求客户把所有的需求写成一个个独立的小故事，每个只需要几天时间就可以完成。开发过程中，客户可以随时提出新的UserStory，或者更改以前的UserStory。
StoryEstimates和开发速度：开发小组对每个UserStory进行估算，并根据每个开发周期（Iteration）中的实际情况反复计算开发速度。这样，开发人员和客户能知道每个星期到底能开发多少UserStory。
ReleasePlan和ReleaseScope：整个开发过程中，开发人员将不断地发布新版本。开发人员和客户一起确定每个发布所包含的UserStory。
Iteration（开发周期）和IterationPlan：在一个Release过程中，开发人员要求客户选择最有价值的UserStory作为未来一两个星期的开发内容。
TheSeed：第一个开发周期（Iteration）完成后，提交给客户的系统。虽然这不是最终的产品，但它已经实现了几个客户认为是最重要的Story，开发人员将逐步在其基础上增加新的模块。
ContinuousIntegration（整合）：把开发完的UserStory的模块一个个拼装起来，一步步接近乃至最终完成最终产品。
验收测试（功能测试）：对于每个UserStory，客户将定义一些测试案例，开发人员将使运行这些测试案例的过程自动化。
UnitTest（单元测试）：在开始写程序前，程序员针对大部分类的方法，先写出相应的测试程序。
Refactoring(重整和优化)：去掉代码中的冗余部分，增加代码的可重用性和伸缩性。
小结
XP的一个成功因素是重视客户的反馈——开发的目的就是为了满足客户的需要。XP方法使开发人员始终都能自信地面对客户需求的变化。XP强调团队合作，经理、客户和开发人员都是开发团队中的一员。团队通过相互之间的充分交流和合作，使用XP这种简单但有效的方式，努力开发出高质量的软件。XP的设计简单而高效；程序员们通过测试获得客户反馈，并根据变化修改代码和设计，他们总是争取尽可能早地将软件交付给客户。XP程序员能够勇于面对需求和技术上的变化。
XP很象一个由很多小块拼起来的智力拼图，单独看每一小块都没有什么意义，但拼装好后，一幅美丽的图画就会呈现在你面前。
什么时候来避免极限编程
极限编程，有时也被叫做XP，已经被证明了是许多项目经理和项目程序员开发项目的成功的开发方法，具有很好的开发风格。但是它并不适用与所有的情况或所有的项目团体。如果你不考虑你的开发小组、开发部门或开发公司的情况，而去试图选择极限编程作为你的核心开发方法，这才是本末倒置。你应该确保你的开发单位是适用于这个极限编程开发方法的特殊需要的。
在简单的团队中，极限编程把开发者而不是项目经理作为项目开发的核心人员，它选择使用开发人员来进行项目的决策。这个技术可以提高开发效率，也可以使管理接口的麻烦最小化，但是极限编程会给你带来你不曾有的问题，它爱管闲事，并缺乏有效的管理。另外，管理应该在合适的时候添加进来，如果不进行开发管理将对你的项目开发有害无益。
－＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
借口编程(Excuse Programming)。是的，这就是很多项目团队，尤其是项目经理们一直在做的事情。他们总是一直在给出一个又一个的借口。为没有很好地进行需求开发和需求管理找借口，为没有跟踪项目风险和项目问题并且系统化地、及时地解决它们找借口。
最常见的借口就是时间，也就是没有时间。为什么会没有时间呢？因为时间都被浪费到做错误的事情上了，所以他们就需要加班。他们是在做片面的极限编程，或者，应该说是额外编程(Extra Programming)，这是一个恶性循环，他们需要走出这个怪圈，让事情走上正轨。但屡见不鲜的情况是，项目经理往往过于自负，很难走出这个怪圈。他们总在给出一个又一个的借口，没有例外管理，而是借口管理。
请注意：我们是支持极限编程XP的，但极限编程是适用于那些非常清楚自己在做什么的人。极限编程不适用于那些为了伪装他们所作所为的人，极限编程适合于专家，而不是冒牌货。极限编程不是借口编程，它不是一个用于你不做正确的事情的借口。
从借口编程到极限编程
我们认为每个开发人员、经理——每个软件开发社区的专业人士，都应该思考哪些是他们知道的，哪些是是他们不知道的，对自己和别人都应该绝对诚实。我们也应该十分认真和充满热情地提高我们的技能。除此之外，没有其他捷径，请不要再找借口了。
所以让我们非常坦诚地面对问题。但人们（例如项目经理等）的问题往往是他们并不知道他们自身的问题。他们还没有意识到这一点。如果你试图说服他们意识到他们有问题，你会寻找出更多的问题。别忘了他们都是借口编程高手。你并没有看清所有的问题。所以，有时，人们从自身的错误中学习，有些人从不学习也会侥幸成功，有些人从不学习并重复地犯相同的错误。
但是也有少数人会总是问自己：我如何才能做得比昨天更好？幸运地是，我们周边还有一些这样的人。当你给他们建议时，他们可能会反对，但当他们回到家里，冷静下来，开始思考，然后他们会回来找你。这些人还是有希望的。有希望的是，我们有越来越多这样的人。
一旦借口编程被驯服，我们可以原谅他们的过去。一切都可以被原谅。我们可以开始教育他们正确的方式，常常地我们甚至可以从他们身上学到不少东西。有很多种方式来武装他们，他们可以阅读书籍等，他们也可以从导师那里寻找帮助，甚至是虚拟的导师。
作为一个经理或客户，你总是需要以挑剔的眼光来选择谁来做你的项目，一个团队（尤其是她的领导）的选择是一个非常关键的要素。如果他们是专家那就最好了，否则，寻找那些有潜力的，并设计一种策略让他们以最快的速度前进——如何以最快的速度进行，这又是另一个话题。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷开发是全新理论吗？答案莫衷一是。细心的人们可以发现，敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有更多。
改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”
敏捷肯定是奔着软件本身去的。
抛开软件本身谈过程，没有技术的积累去谈敏捷风格的项目管理，那都是扯谈。
什么过程，设计，集成，测试都是以软件本身为主导的。
适度的 unit test 用例，自动化构建/自动化测试，那是敏捷的外在表现。
一个适度设计，持续改进的构思，是敏捷的精髓。最后把这些都反映到代码上，那就是一个敏捷的实施了。
如果能够围绕这些构造一个良好的技术讨论氛围，互助的精神，那就实现了敏捷的胜利以及价值了。
对不懂代码，没有做过编程的人，关于敏捷，我们没什么好谈的
| 敏捷开发有什么缺点? |
| 1、敏捷开发以人为本，对PM的要求比较高，管人是需要一些艺术的.PM如果控制不好,整个项目的风险会比较大! 2、敏捷开发在平衡过程中，必然会对某些方面带来忽略，容易在这些方面出现问题 3、敏捷开发对团队成员要求很高，水平不能相差太远，否则节奏不好控制 |
参考来源：
http://tech.acnow.net/Html/Program/soft_project/SoftMethod/2005-8/7/230147673.shtml
http://hi.baidu.com/mayig/blog/item/dbf2f81f0c093ef5e0fe0b58.html