3.1 什么是敏捷
IvarJacobson的观点是，敏捷是来应对不断的变更的，软件工程师必须能适应这些快速的变化。
然而，敏捷不仅仅是用来应对变更的。敏捷还鼓励建立有结构性的团队、建立团队内技术人员与商业人员的沟通更加快捷迅速的体制。它还强调及时提交对软件的更改，将客户作为开发团队的一部分，消除你我的观点。
3.2 敏捷与变更的代价
在软件开发过程中，普遍认为变更的代价是非线性增长的。敏捷开发的拥护者认为、可以有一种设计良好的敏捷开发过程可以降低变更代价的增长，使之基本“平坦”，从而使开发团队可以很好的应对变更，而不必付出巨大的时间、开销代价。
3.3 什么是一个敏捷开发过程
敏捷的开发过程，一定是可适应的。可以适应我们并没有预想到的情况。
然而，不停的进行适应性工作，而过程没有进展，是无意义的。因此，敏捷的开发过程必须是可增长的。为了完成这些，敏捷开发要求客户应当给予反馈。为了获得客户有效的反馈，提供一个可执行的原型或者系统的某一操作是十分重要的。因此，我们应当建立一个良好的制度来对每个周期的开发增长进行总结。
3.3.1 敏捷开发原则
这里介绍了12条原则，在多种敏捷开发的框架中，这些原则并不是同样的重要，而且有些模型可能忽略一条或几条原则。然而，这些原则定义了一种敏捷精神。
3.3.2 敏捷开发的派别
如何实现敏捷开发最好？或者说，如何开发软件可以应对当今客户的需求并且展现软件的可扩展的特性、可满足客户长期的需求变更的良好的软件质量？
现今并没有一个很好的答案来回答这些问题，即使是教授敏捷开发的学校本身。
3.3.3 人为因素
敏捷开发的拥护者付出了重大的痛苦来强调人为因素的重要性。
3.4 极限编程
极限编程是一种使用最为广泛的敏捷开发方法。
3.4.1 极限编程的价值观
交流、简洁、反馈、鼓励和尊重，是极限编程的5个价值观。每一种价值都被应用在极限编程的活动、行为与任务之中。
为了更好的实现软件工程师与其他人员的交流，XP强调紧密，也就是顾客与开发者合作密切，发布有效的约定（metaphors），持续的反馈。
为了实现简洁，XP使开发者只为当前的需求进行设计，而不是为了未来进行设计。
反馈有三个来源，软件实现本身，客户以及其他的软件团队成员。
3.4.2 极限编程过程
极限编程使用面向对象的开发模式，因为该模式是一种发展的模式、遵循一套规范并且实践着计划、设计、编码、测试这样一个框架活动。
3.4.3 工业界的极限编程（IXP）
IXP与传统意义的XP不同，IXP在管理方面有了极大的加强，并且他将客户扩展为一个角色，并且升级了技术的实践方式。
IXP引入了6个新的实践方式，用来使一个XP项目工作的更加顺利。
3.4.4 极限编程的争论
3.5 其他敏捷开发模型
在敏捷开发的历史上，存在许多的模型。
3.5.1自适应软件开发（ASD）
ASD（AdaptiveSoftware Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
3.5.2 Scrum
SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。SCRUM中发布产品的重要性高于一切。
该方法由Ken Schwaber和 JeffSutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。
3.5.3动态系统开发方法（DSDM）
DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。
3.5.4 Crystal
Crystal Methods（水晶方法族）由AlistairCockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。
3.5.5特性驱动开发（FDD）
特性驱动开发由PeterCoad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。
3.5.6精益软件开发（LSD）
精益软件开发一词起源于MaryPoppendieck 和Tom Poppendieck写的一本同名书籍。这本书将传统的精益原则以一种新的方式呈现---作为22种敏捷开发实践工具之一，并且和其他工具进行了比较。
和精益制造原则的概念相近，精益开发也可以总结为如下七条原则：消除浪费、增强学习、尽量延迟决定、尽快提交每阶段原型、鼓励团队、将才智融入其中、关注全局。
3.5.7 敏捷建模（AM）
在过去30年中，有许多软件工程建模方法被用来进行分析和设计。这些方法都是存在其价值的，但是同时也被证明难以去应用而且难以长期延续。部分原因是这些方法都太庞大了。
敏捷建模遵循一切敏捷原则。它的哲学就是一个敏捷团队必须与勇气来决定拒绝一个设计或者重构。这个团队必须谦虚的认识到不是所有的技术都能实现，不是所有的商业专家和其他人员都需要被尊重和相信。
3.5.8 统一敏捷建模（AUP）
类似于UML的一种统一的建模方法。
最近看书的读书笔记，有些翻译的特别特别傻....