敏捷软件开发宣言

由于看到众多团队陷入了不断增长的过程的泥潭，一批业界专家概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，这些专家称自己为敏捷（Agile）联盟，并创造出了一份价值观声明，也就是敏捷联盟宣言。

个体和交互胜过过程和工具

人是获得成功的最主要因素。如果团队中没有优秀的成员，那么就是再好的过程也不能挽救失败的项目。但是不好的过程可以使优秀的团队成员失去作用。如果团队成员不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会失败。

一个优秀的团队成员不一定要是一个一流的程序员，可以是一个平均水平的程序员，但是却能够很好的和他人合作。合作、 沟通以及交互能力要比单纯的编程能力更重要。

合适的工具非常重要，比如编译器、 IDE、 源码管理系统等。然而使用过多的庞大、笨重的工具和缺少工具一样，都是不好的。大而笨重的工具带来的障碍往往大于带来的帮助。从使用小工具开始，感觉工具不够用了再去寻找先进的、价格昂贵的工具。

团队的构建比环境构建要重要的多。许多管理者往往希望先构建环境，然后期望团队可以自动凝聚在一起， 然而往往事与愿违。应该首先致力于团队建设，然后再让团队基于需要来配置环境。

可以工作的软件胜过面面俱到的文档

没有文档的软件是一种灾难，代码不是传达系统原理和结构的理想媒介，团队更需要编写易于阅读的文档，来描述系统以及其他设计决策的依据。

然而，过多的文档比过少的文档更糟糕。编制众多的文档需要花费大量时间，并且要使文档和代码保持同步就需要花费更多时间，如果代码和文档之间失去了同步，那么文档就失去了作用，甚至会造成误导。

对于团队来说，有必要编写并维护一份系统原理和结构方面的文档，文档应该是篇幅短小的并且主题突出的，应该仅论述系统的高层结构和概括的设计原理。

在给新的团队成员传授知识方面，最好的两份文档就是代码和团队。代码真实的表达了它所做的事情，是唯一没有二义性的信息源。在团队成员的大脑中，保存着市场变化的系统脉络图，人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。

所以直到迫切需要并且意义重大时，才来编制文档。

客户合作胜过合同谈判

告诉研发团队想要的东西，然后期望研发团队消失一段时间后就能够交付一个需要的系统，这对于公司的管理者来说是具有诱惑力的，然后这种模式终将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。

一个指明了需求、进度以及项目成本的合同存在根本上的缺陷，那些为研发团队和客户的协同工作方式提供指导的合同才是最好的合同。

响应变化胜过遵循计划

响应变化的能力常常决定着一个软件的成败，当我们构建计划时，应当确保计划是灵活的，并且易于适应商务和技术方面的变化。

计划不能考虑的过远。首先，商务环境可能会变化，会引起需求的变动；其次，客户看到系统后，他们很可能会修改需求；最后，即使我们熟悉需求，并且确信他们不会改变，我们仍然不能很好的估算出开发他们需要的时间。

为未来两周做详细的计划，为未来三个月做粗略的计划，更远的时间就做更为粗糙的计划。我们应该清楚的知道未来两周要完成的任务，粗略的了解一下未来三个月的计划，至于半年后甚至更久远的时间，有一个模糊的想法就行了。由近及远逐渐降低细致程度，仅仅对于迫切的任务才耗费时间进行详细的计划，一旦制定了这个详细的计划，就尽量不要改变。计划仅仅支配了几周的时间，计划的其余部分仍然保持着灵活性。