个体和交互                      胜过         过程和工具
可以工作的软件               胜过         面面俱到的文档
客户合作                         胜过         合同谈判
响应变化                         胜过         遵循计划

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

人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。
记住，团队的构建要比环境的构建重要的多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。

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

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。
然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。
如果全部拥有的仅仅是一份简短的系统原理和过够方面的文档，那么如何来培训新的团队成员，使他们能够从事与系统相关的工作呢？我们会非常密切地和他们在一起工作。我们紧挨着他们坐下来帮助他们，把我们的知识传授给他们。我们通过近距离的培训和交互使他们成为团队的一部分。
在给新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是唯一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
许多团队因为注重文档而非软件，导致进度拖延。这常常是一个致命的缺陷。有一个叫做“Martin文档第一定律（Martin's first law of document）”的简单规则可以预防该缺陷的发生：直到迫切需要并且意义重大时，才来编制文档。

3.客户合作胜过合同谈判

不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格趋开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时，失败是惨重的。
告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。
成功的项目需要有序、频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。
一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。在大多数的情况下，合同中指明的条款远在项目完成之前就变得没有意义。那些为开发团队和客户的协同工作方式提供知道的合同才是最好的合同。

4.响应变化胜过遵循计划

响应变化的能力常常决定一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应上午和技术方面的变化。
较好的做计划的策略是：为下两周做详细的计划，为下三周做粗略的计划，再以后就做极为粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略地了解一下后三个月要实现的需求。至于系统一年后将要做什么，有一个模糊的想法就行了。
计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦指定了这个详细的计划，就很难进行改变，因为团队会根据这个计划启动工作并有了相应的投入。然而，由于计划仅仅支配了几周的时间，计划的其余部分仍然保持着灵活性。