在20世纪90年代末期，传统软件开发的方式因为其繁杂的过程，以及对文档的过于严格的要求，很大程度上造成了效率的下降，也就是人们所说的“重型化危机”。因为这一原因，人们开始反思传统方法的利弊，并对其弊端进行了改进，提出了敏捷方法。敏捷思想代表着一个对传统过程的“反叛”流派，它强调对变化的适应和对人的关注，在对待用户需求问题方面，强调适应变化，而不去过多地预测明天可能会产生的需求或需求变化，在对待工作流方面，强调以人为中心，而非流程为中心。

对比RUP，RUP是一种重量级方法（厚方法学），一般适应于中大型项目的开发，而敏捷过程是一种轻量级方法，适用于小型项目。敏捷过程可以理解成是对RUP进行适当裁剪以适应小项目的结果，因为RUP中严格的计划、复杂的文档对于小的开发团队简直就是噩梦，因为没有人愿意花大把时间在生成和维护文档上。

1.敏捷核心价值观

2001年2月，17位著名软件专家联合起草了敏捷软件开发宣言，标志着“敏捷流派”的诞生。这份宣言由4个核心价值观组成。

（1）“个体交互”胜过“过程和工具”

人是软件项目获得成功最为重要的因素，当然，不好的过程和工具也可以使最优秀的团队成员失去效用。团队成员的合作、沟通以及交互能力要比单纯的软件编程能力更为重要；合适的工具对于成功来说也非常重要，但工具的作用不可被过分地夸大。敏捷过程强调：团队的构建（包括个体、交互等）要比项目环境（包括过程、工具）的构建重要得多，应该首先致力于构建团队，然后再让团队基于需要来配置环境。

（2）“可以使用的软件”胜过“面面俱到的文档”

软件开发最终交付给用户可以工作的软件而不是文档，否则应该称之为文档开发而不是软件开发。没有文档的软件是一种灾难，但过多的面面俱到的文档比过少的文档更糟。敏捷过程强调：软件开发的主要和中心活动是创建可以工作的软件，仅当有迫切需要并且具有重大意义时，才进行文档编制，且编制的内部文档应尽量短小并且主题突出。

（3）“客户合作”胜过“合同谈判”

客户不可能做到一次性地将他们的需求完整清晰地表述在合同当中，在开发过程中甚至交付后，客户需求还可能随时发生变化。敏捷过程强调，开发团队与客户紧密协作，全方位地满足客户需求，为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。

（4）“响应变化”胜过“遵循计划”

软件开发过程总会有变化，这是客观存在的现实。一个软件过程必须反映现实，因此，软件过程应该有足够的能力及时响应变化。敏捷过程强调，项目计划必须有足够的灵活性和可塑性，在形势发生变化时能迅速调整，以适应业务、技术等方面的变化。

为了贯彻上述4个价值观，敏捷宣言还提出有别于传统过程的12个原则。

●优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

●即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。

●经常性交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

●在整个项目开发期间，业务人员和开发人员应该每天都工作在一起。

●使用积极的开发人员进行项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。

●在团队内部，最具有效果并且富有效率的传递信息的方法，是面对面的交谈。

●能工作的软件是首要的进度度量标准。

●敏捷过程提倡可持续的开发速度，投资人、开发人员和用户应该能够保持一个长期稳定的步调。

●不断地关注优秀设计的技能和好的设计会增强敏捷能力。

●简单（尽可能减少工作量）是最重要的。

●最好的架构、需求和设计都来自于自组织的团队。

●团队要定期总结如何提高效率，然后相应地调整自己的行为。

2.极限编程

在敏捷的所有方法中，极限编程（eXtreme Programming，XP）是最负盛名的一个，其名称中“极限”二字的含义是指把好的开发实践运用到极致，它消除了大多数重量型过程中过于繁琐和僵化的内容，建立了一个渐进的开发过程，使软件能以尽可能快的速度开发出来，向客户提供最高的效益。目前，极限编程已经成为一个典型的开发方法，广泛应用于需求模糊且经常改变的场合。

图2-12描述了极限编程的整体开发过程。首先，项目组针对客户代表提出的“用户故事”（用户故事类似于功能用例，但比用例更简单，仅描述功能需求）进行讨论，提出隐喻，在此项活动中可能需要对体系结构进行“试探”，即提出相关技术难点的试探性解决方案；然后，项目组在隐喻和用户故事的基础上，根据客户的要求，设定优先级，制定交付计划，这一过程中为保证交付计划的可行性，需要对某些技术难点进行试探；接下来开始多个迭代开发过程，根据交付计划制定每次的迭代计划，以结对编程的方式完成每次迭代开发任务，通过“站立会议”解决遇到的问题、调整迭代计划等；最后将开发出的软件经过验收测试后交付用户使用。

极限编程在很多方面都和传统意义上的软件过程不同，具体执行时，它有12个有效的开发实践，只有完全引用了以下12个实践，才是真正使用了极限编程，只引用部分并不代表使用了极限编程。下面简述极限编程的12个开发实践。

（1）完整的团队

所有的小组成员应在同一个工作地点工作，成员中必须有一个现场用户，由他提出需求，确定开发优先级，通常还设一个“教练”角色，教练指导极限编程方法的实施，以及与外部的沟通和协调。

（2）滚动计划

计划是持续的、循序渐进的。一般每隔两周，开发人员就为下一个两周修订滚动计划。开发人员针对一些候选特性估算成本，客户则根据成本和应用价值来选择要求实现的特性，最终形成下一个两周计划。

（3）客户测试

针对每个所期望的特性，按客户的要求使用脚本语言，定义出验收测试方案，以通过验收测试来表明该特性可以工作。

（4）简单设计

保持设计内容恰好和当前的系统功能相匹配，并能通过所有的测试，不包含任何重复，能表达出编写者想表达的所有东西，并且包含尽可能少的代码，避免过度设计。

（5）结对编程

所有的产品软件都是由两个程序员，并排坐在一起在同一台机器上构建。

（6）测试驱动

在实施设计和编程之前，先拟定一个测试目标，然后以通过测试作为设计和编码的目标，通过之后再考虑重构和优化。

（7）改进设计

随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

（8）持续集成

总是使系统完整地被集成。

（9）代码集体所有

任何结对的程序员都可以在任何时候改进任何代码，没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其他方面的开发。

（10）编码标准

系统开发人员遵守共同的编码标准，代码看起来就好像是被单独一人编写的。

（11）隐喻

隐喻是整个系统的全局视图，它是系统的未来影像，它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么就知道该模块是错误的。

（12）可持续的开发速度

只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，把项目看作是马拉松长跑，而不是全速短跑。