敏捷开发
敏捷开发是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种能应对快速变化需求的软件开发能力。敏捷开发以人为核心、以迭代方式循序渐进开发，在这一过程中，软件项目的构建被分成多个子项目，各个子项目之间的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可用状态
敏捷开发的价值观
2001年年初，在美国犹他州雪鸟滑雪胜地，敏捷方法发起者和实践者发起组成了敏捷联盟的聚会，并共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述：
（1）人机交互重于过程和工具
（2）可以工作的软件重于求全责备的文档
（3）客户协作重于合同谈判
（4）随时应对变化重于循规蹈矩
敏捷开发价值观认为，后者的内容虽然也有其价值，但前者的内容最为重要
敏捷开发的十二条原则
（1）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
（2）欣然面对需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。
（3）经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
（4）业务人员和开发人员必须相互合作，项目中的每一天都不例外。
（5）激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。
（6）不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
（7）可工作的软件是进度的首要度量标准。
（8）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
（9）对技术精益求精，对设计不断完善，将提高敏捷能力。
（10）以简洁为本，极力减少不必要工作量。
（11）最好的架构、需求和设计出自于自组织的团队。
（12）团队定期地反思如何能提高成效，并依此调整团队的行为
极限编程
极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的，是一种软件工程方法学，是敏捷软件开发中可能是最富有成效的几种方法学之一。
极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。
XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
极限编程的目标
极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中，系统需求是在项目开发的开始阶段就确定下来，并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更（而这样的需求变更在一些发展极快的领域中是不可避免的）将导致开发成本急速增加。
极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。
极限编程的四个核心价值观
（1）沟通
构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。
（2）简单
极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。
（3）反馈
在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
① 来自系统的反馈：通过编写单元测试，程序员能直观的得到修改后系统的状态。
② 来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。
③ 来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户 [1] 。
反馈是与“交流”、“简单”这两条价值紧密联系的。为了弥补沟通的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性测试。
（4）勇气
极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。
开发过程
工作环境
（1）每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务
（2）所有的人都在同一个开放的开发环境中工作，还有茶点供应
（3）每周40小时，不提倡加班
（4）每天早晨，所有人一起站着开个短会
（5）提供用于讨论问题的时候可以在上面写写画画的大白板
需求
（1）客户应该是项目开发队伍中的一员，而不是和开发人员分开的；因为从项目的计划到最后验收，客户一直起着很重要的作用。开发人员和客户一起，把各种需求变成一个个小的用户故事
（2）客户根据每个模块的商业价值来指定它们的优先级；开发人员要做的是确定每个需求模块的开发风险，风险高的（通常是因为缺乏类似的经验）需求模块将被优先研究、探索和开发；经过开发人员和客户分别从不同的角度评估每个模块后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；
（3）客户为每个需求模块指定验收测试（功能测试）
设计
（1）从具体开发的角度来看，XP内层的过程是一个个基于测试驱动开发周期，诸如计划和设计等外层的过程都是围绕这些展开的。每个开发周期都有很多相应的单元测试。刚开始，因为什么都没有实现，所以所有的单元测试都是失败的
（2）随着一个个小的需求模块的完成，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。
（3）XP提倡简单设计，使得为每个简单的需求写出来的程序可以通过所有相关的单元测试。XP强调抛弃那种一揽子详细设计方式，因为这种设计中有很多内容是你现在或最近都根本不需要的
（4）XP还大力提倡设计走查、代码走查以及重构，所有的这些过程其实也是优化设计的过程。在这些过程中不断运行单元测试和功能测试，可以保证经过重整和优化后的系统仍然符合所有需求
编程
（1）XP就提倡结对编程
（2）代码所有权是归于整个开发队伍的，任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试
（3）程序员在写程序和重构程序的时候，都要严格遵守编程规范
测试
（1）XP提倡在开始写程序之前先写单元测试
（2）开发人员应该经常把开发好的模块整合到一起，每次整合后都要运行单元测试
（3）做任何的代码走查和修改，都要运行单元测试
（4）发现了BUG，就要增加相应的测试
（5）除了单元测试之外，还有集成测试，功能测试、压力测试和系统测试等
（6）所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一
十二个核心实践
（1）完整团队
XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。
（2）计划对策
XP方法中需要制定两个计划：发布计划和迭代计划。计划是根据业务的优先级和技术评估结果来制定的，早期需要制定的计划往往是不准确的，需要在迭代过程中不断修正
（3）测试
XP方法提倡测试优先，先写测试后写代码，测试优先是为了在编码前使开发人员对代码进行周密思考，使开发人员尽快地检验他们想法的可行性
（4）简单设计
简单设计是指设计刚好满足当前定义的功能即可。它通过所有的测试，没有重复逻辑，表达出了开发者想表达的所有东西，并且包含尽可能少的代码。
（5）结对编程
两个程序员并排坐在一起在同一台机器上编程。一个程序员在开发的同时，另一个程序员负责检查程序的正确性和可读性
（6）小软件版本
经常、不断地发布可运行的，具有商业价值的小软件版本，供现场用户评估和最终使用
（7）改进设计
随时对程序结构进行持续不断的梳理，在不影响程序外部可见行为的情况下，对程序内部结构进行改进，保持代码简洁、无冗余。
（8）持续集成
每完成一个模块的开发后，立即将其组装到系统中，并进行集成测试。持续集成能保证项目组中所有开发好的模块始终是组装完毕、完成集成测试且是可执行的
（9）集体代码所有权
任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。
（10）编码标准
XP方法强调制定一个统一的编码标准，使系统中所有的代码看起来就好像是被单独一人编写的。
（11）隐喻
将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
（12）可持续的速度
团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。
