2001年2月11日至13日，在美国犹他州瓦萨奇山，17个来自于各类敏捷方法的实践者共同达成了一个共识，也就是后来广泛流传的《敏捷宣言》，这个宣言也作为敏捷的核心思想，一直指导着后续敏捷实践的进程。
《敏捷软件开发宣言》
我们一直在实践中探讨更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体与交互 高于流程和工具
可用的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值
尽管敏捷宣言结构简单语言简洁，但是这四大价值观中蕴含了很多内容，理解这些思想是为了在实际的项目中应用敏捷方法，甚至应用到非软件开发项目中。
首先，我们说"A高于B"，例如"个体与交互高于流程和工具"，体现了我们关注的重点和工作的方向。这并不能简单理解为"做A而不做B"。实际上，在项目开展过程中，A和B两种情况都可能出现，但是我们应该强调关注，影响A而不是B。
接下来，谈一谈对这4句话的理解：
1 ）个体与交互高于流程和工具
盲目的遵循流程容易让人走入误区，软件世界中存在很多优秀的实践经验，但并不是所有的这些实践都适合项目的当前情况。这个原则团队中的所有成员应该都要心里有数。他们需要理解团队在一起的工作方式，明白每个人的工作会对其他人造成怎样的影响。当我们打算在团队中实施一项流程或工具时，即使在逻辑上和理性上看上去很合理，你还需要做的是让大家明白这么做的理由，知道团队到底在为此做什么。如果不能让团队很好的理解你的目的或初衷，那么在他们看来你只是在发号施令。
尽管在项目中，流程和工具似乎非常必要，但是我们应该将关注的重点放在个体与交互上。这是因为项目是由人来执行的，而不是工具。人是获得成功的关键因素，如果团队中没有优秀的成员，那么使用再好的流程也无法拯救失败的项目，但是糟糕的流程却可以是优秀的成员失去效用。优秀的成员如果没有良好的沟通，从而为团队工作，那么即使拥有一批十分优秀的成员，也会失败。
虽然我们致力于个体和交互，但并不是不需要流程和工具了。Scrum、XP等方法本身也具备流程，每日构造等敏捷实践也需要工具的支持，需要哪些流程和工具由团队制定，而不是由领导制定。合适的工具对于成功来说非常重要，如编译器、IDE、SVN等，但是与成员相比，我们认为人更重要。
2 ）可用的软件高于详尽的文档
很多团队都会要求详尽的文档，事无巨细地记录下来，也不考虑以后会不会有人阅读。在一个软件项目中，有太多的事情需要文档化，这无形当中加大了研发人员在整个软件生命周期中的开发量。软件项目是典型创造新价值的活动。高质量的软件，通常是在临时交付物中产生的，就像是对最终成果物目标描述的一个扩展补充。敏捷更注重可用的软件，即可以给公司带来价值的软件（可出售或可运营的软件等等）。
所谓的价值：项目能交付的价值或能节省的成本 > 开发软件本身的成本
虽说如此，但没有文档的软件是一种灾难，代码并不是传达系统原理和结构的理想媒介。团队需编写易于理解的文档，需适当控制文档的数量，毕竟可用的软件才是我们最终想要的。
关注可用的软件可以确保团队没有偏离正轨，如果文档能清晰地表明可用软件的方向，那么这种文档对项目就是有贡献的。团队通常可以采用一些将文档嵌入软件内部的实践，比如TDD（测试驱动开发）。
那么，敏捷开发至少需要维护哪些文档？建议如下，欢迎参考：
1、《产品需求规格说明书》
也即PRD：定义产品应该具有的功能、边界描述等，它作为产品团队之间共同的讨论基础，并在设计和开发过程中不断的更新维护，并记录所有的需求变更;
2、《系统设计说明书》
开发人员编写的技术设计，包含数据库E-R图，架构设计等：说明产品如何实现，内部之间是什么关系等;
3、《测试用例》
由测试人员编写：记录所有功能点的测试计划、过程和测试结果;
4、《软件迭代计划》
由Scrum Master组织编写：包含需求规划与评审、UI设计、软件开发与测试和软件发布的各个节点。
3 ）客户合作高于合同谈判
软件外包公司经常会遇到这样的客户：客户扔下一笔钱，写下自己期望的软件的样子，然后离开，直到软件验收阶段，才询问软件是否完成。但他们看到软件的样子的时候，他们经常会惊讶：这不是我们想要的呀！
合同谈判无法帮助开发人员理解客户的需求，只有通过和客户更多的交流才能帮助开发人员或者产品经理理解客户的需要，从而开发出不偏离客户需求的软件，经常保持沟通是一种重要的措施。Scrum要求每个迭代开发出可用的软件，同时用这个开发出的软件与客户演示或交流。
4 ）响应变化高于遵循计划
作为项目经理，最熟悉的经历莫过于计划变更。我们意识到计划是会变的，能交付的软件比严格遵守计划更重要。不确定性是影响计划正确的主要因素，对大部分不确定性而言，获取知识、减少不确定性的唯一办法是通过执行------做一些事情、构建一些东西或者模拟一些东西------然后获得反馈。当计划出现偏差或者项目中出现不确定性过多时，团队需要不断的发现变化，适应变化并且最后能快速的响应变化。
工具之上需要总结，道理之上需要感悟！