一、个体和交互胜过过程和工具
团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。
二、可以工作的软件胜过面面俱到的文档
对于团队来说，编写并维护--份系统原理和结构方面的文档是一个好主意，但是那份文档应该是短小的(short）并且主题突出的(salient)。“短小的”意思是说，最多有一二十页；"主题突出”的意思是说，应该仅论述系统的高层结构和概括的设计原理。
三、客户合作胜过合同谈判
不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。
成功的项目需要有序、颊繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地在一起工作，并尽量经常地提供反馈。
四、响应变化胜过遵循计划
较好的做计划的策略是:为下两周做详细的让划，为下三个月做粗略的让划，再以后就做极为粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略地了解下以后三个月要实现的需求。
至于系统年后将要做什么,有-一个模糊的想法就行了。
计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。--旦制定了这个详细的计划，就很难进行改变，因为团队会根据这个计划启动工作并有了相应的投入。然而，由于计划仅仅支配了几周的时间，计划的其余部分仍然保持着灵活性。
