第一部分 敏捷开发
2001年初，由于看到许多公司的软件团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以软件开发团队具有快速工作、响应变化能力的价值观（value）原则。他们称自己为敏捷（Agile）联盟。在随后的几个月中，他们创建出了一份价值观声明。也就是敏捷联盟宣言（The Manifesto of the Agile Alliance）。
敏捷联盟宣言如下：
1.个体和交互胜过过程和工具。
人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。
一个由平均水平程序员组成的团队，如果就具有良好的沟通能力，将要比那些虽然拥有一批高水平的程序员，但是成员之间却不能交流的团队更有可能获得成功。
合适的工具对于成功来说是非常重要的。然而，工具的作用可能会被过分的夸大。使用过多的庞大、笨重的工具就像缺少工具一样，都是不好的。
团队的构建要比环境的构建重要得多。应该首先致力于构建团队，然后在让团队基于需要来配置环境。
2.可以工作的软件胜过面面俱到的文档。
没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。
对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好注意，但是那份文档应该是短小（short）并且主题突出的（salient）。“短小的”意思是说，最多有一二十页。“主题突出的”意思是说，应该仅论述系统的最高层结构和概括的设计原理。
在给新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实的表达了它所做的事情，是唯一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
Martin’s first law of document：直到迫切需要并且意义重大时，才来编制文档。
3.客户合作胜过合同谈判。
不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格来开发它。告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能交付一个满足需要的系统来，这对于公司的管理者来说是非常具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。
成功的项目需要有序、频繁的反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。
项目成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。
4.响应变化胜过遵循计划。
相应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。
较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。我们应该清楚的知道下两周要完成的任务，粗略地了解一下以后三个月要实现的需求。至于系统一年后要做什么，有一个模糊的想法就行了。
计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划，就很难进行改变，因为团队会根据这个计划启动工作并有了相应的投入。然而，由于计划仅仅支配了几周的时间，计划的其余部分仍然保持着灵活性。
综观上述四个过程，敏捷开发强调以人为中心，而不是以过程为中心，强调尽可能的沟通（与客户，与团队成员），尽可能地以最简单的设计解决问题（从而能够拥抱变化）。
到目前为止，已经有许多的敏捷过程可供选择了。包括SCRUM，Crystal，特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发（Adaptive Software Development，简称ADP），以及最重要的极限编程（eXtreme Programming，简称XP）。