极限编程:
ExtremeProgramming（极限编程，简称XP）是由KentBeck 1996在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念。
极限编程 是一种高度动态的过程，它通过非常短的迭代周期来应对需求的变化。XP是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。一个严格实施XP的项目，其开发过程应该是平稳的、高效的和快速的，能够做到一周40小时工作制而不拖延项目进度。
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，已经被证明了是许多项目经理和项目程序员开发项目的成功的开发方法，具有很好的开发风格。但是它并不适用与所有的情况或所有的项目团体。如果你不考虑你的开发小组、开发部门或开发公司的情况，而去试图选择极限编程作为你的核心开发方法，这才是本末倒置。你应该确保你的开发单位是适用于这个极限编程开发方法的特殊需要的。
在简单的团队中，极限编程把开发者而不是项目经理作为项目开发的核心人员，它选择使用开发人员来进行项目的决策。这个技术可以提高开发效率，也可以使管理接口的麻烦最小化，但是极限编程会给你带来你不曾有的问题，它爱管闲事，并缺乏有效的管理。另外，管理应该在合适的时候添加进来，如果不进行开发管理将对你的项目开发有害无益。
极限编程内容:
计划 Planning
User stories are written.
由（用户）编写用户故事
Release planning creates the schedule.
根据发布版计划制定进度表
Make frequent small releases.
频繁发布可运行的包含用户故事的版本（小型发布）
The Project Velocity is measured.
度量项目速度
The project is divided into iterations.
将项目划分为多个迭代
Iteration planning starts each iteration.
每次迭代开始前制定迭代计划
Move people around.
角色互换
A stand-up meeting starts each day.
每日立式晨会
Fix XP when it breaks.
根据项目情况对XP作出调整
设计 Designing
Simplicity.
简单
Choose a system metaphor.
选取一个系统描述
Use CRC cards for design sessions.
在设计会上使用CRC卡片
CRC: Class – Responsibility – Collaboration
• Responsibility：Class的行为。
• Collaboration： Class之间的相互联系和作用；Collaborator指和某行为(Responsibility)相关的Class。
• 可以在卡正面加上父类名，子类名；可以在卡背后加上属性。
1#图：CRC卡
Create spike solutions to reduce risk.
通过技术原型降低风险(需求原型和技术原型，分别用于解决业务风险和技术风险，这里的spike solutions就是技术原型)
No functionality is added early.
不要过早加入功能
Refactor whenever and wherever possible.
尽可能地进行重构
编码 Coding
The customer is always available.
客户一直伴随始终
Code must be written to agreed standards.
代码必须符合相应的编码标准
Code the unit test first.
首先编写单元测试
All code is pair programmed.
编码过程实施结对编程
Only one pair integrates code at a time.
严格的串行代码集成
Integrate often.
频繁地进行代码集成
Use collective code ownership
代码集体所有制
Leave optimization till last.
将优化工作留到最后
No overtime
不要加班
测试 Testing
All code must have unit tests.
所有代码必须有单元测试
All code must pass all unit tests before it can be released.
所有代码发布前必须全部通过对应的单元测试
When a bug is found tests are created.
发现了错误必须要增加相应的测试
Acceptance tests are run often and the score is published.
经常运行接受测试并且公布其结果
极限编程的生命周期：
TDD：
测试驱动开发
（Test-Driven Development，TDD）是通过测试定义所要开发的功能的接口，然后实现功能的开发过程。 TDD 极限编程的一个重要组成部分。是XP的12个团队实践的一个环节。
一、TDD的基本过程
1） 明确当前要完成的功能。可以记录成一个 TODO 列表。
2 ） 快速完成针对此功能的测试用例编写。
3 ） 测试代码编译不通过。
4 ） 编写对应的功能代码。
5 ） 测试通过。
6 ） 对代码进行重构，并保证测试通过。
7 ） 循环完成所有功能的开发。
2 ） 快速完成针对此功能的测试用例编写。
3 ） 测试代码编译不通过。
4 ） 编写对应的功能代码。
5 ） 测试通过。
6 ） 对代码进行重构，并保证测试通过。
7 ） 循环完成所有功能的开发。
二、TDD的基本思想：
测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。
三. TDD-sub-cycle
本文转自 fsjoy1983 51CTO博客，原文链接：http://blog.51cto.com/fsjoy/78528，如需转载请自行联系原作者
