寻求客户合作的价值重于对合同的谈判。软件开发的终目标是提供给客户满意的软件，而只有客户才更清楚怎么样才能满意，敏捷开发提倡客户和开发团队密切的在一起工作，并尽量经常行得提供反馈。各种不同的敏捷方法都会利用短期迭代，通过尽早提供软件来达到与客户频繁沟通和反馈的，这也可以把问题及早暴露出来，以免隐藏的问题在后期造成更大的影响。

　　虽然我们致力于客户协作，但为了双方利益和需要仍旧需要进行合同谈判。

　　响应变化   胜过    遵循计划

　　计划赶不上变化，敏捷项目承认开发过程中的不确定性，所以不会在开发中制定长时间的复杂计划，它们的成功都是建立在现实反馈的基础上的。 Scrum依照一组简单实践及规则，实施经验性过程控制方法的检查、适应和保证可视性等步骤，处理软件开发项目中的复杂问题。通过迭代开发，每次迭代都是基于上一迭代的完善基础之上进行的，通过不断的响应变化来消除开发中的不确定性。

　　虽然我们致力于响应变化，但并不是像上面漫画所说的不需要计划了，反而我们需要更多的规划。

　　《Agile Estimating and Planning》（中文书名：敏捷估计与规划）一书对如何做规划进行详细的讲解。它认为规划是困难的，而且作出的计划常常会出错，面对这样的问题，开发小组往往会走上两个极端：要么根本不做任何规划，要么在计划中投入大量的精力直到自己确信计划是正确的。不做规划的小组对一些基本的问题，例如“你们什么时候能完成？”以及“我们可以在6月份安排产品发布吗？”都无法回答。而做了大量计划的小组会自欺欺人地认为某个计划是“正确的”。他们的计划也许更全面，但这并不一定意味着它更准确或更有用。这两种极端都是敏捷需要避免的，开始漫画所说的“我们实施敏捷，不再需要计划和文档了”的论调是及其错误的。

　　敏捷不是不需要计划，相反它需要更多的规划。不确定性是影响计划正确的主要因素，对大部分不确定而言，在获取知识、减少不确定性的办法是通过执行－作一些事情、构建一些东西或模拟一些东西－然后获得反馈。许多项目管理方法是“规划、规划。规划－执行”，而敏捷开发方法是“规划－执行－调整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功越是至关重要，不断学习和调整是敏捷开发的核心。

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

　　方法和工具是死的，人是活的，如何没有个人和团队协作，再强大的方法和工具都是摆设。一个使用普通工具的人员会比使用工具的普通人员做得更好，一个具有合作精神、自组织的团队比通过过程规范的团队工作得更好。敏捷项目首先拥有一个小规模但拥有各种不同职能的成员，每个成员都需要定时和团队的其他成员一起查看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。自组织团队通过个人能力和协作能力，可以自发的通过各种途径解决开发过程中遇到的问题。

　　虽然我们致力于个体和交互，但并不是不需要过程与工具了。Scrum、XP等方法本身也有一些方法和过程，每日构造等敏捷实践也需要工具的支持，需要哪些过程和工具由自组织团队制定，而不是由领导制定。

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

　　在合同中有时会看到分别在需求、设计、开发、测试阶段提供什么文档，支付多少金额等内容，而这些文档对用户来说是不是真的有价值呢？面面俱到的文档对客户来说确并不重要，用户需要的是一个能够运行起来，能够实质解决工作中问题的可以工作的软件。面面俱到的文档对开发团队也不重要，上百页的报告没有人愿意写，更没有人愿意去读，对开发团队来说好的两份文档是代码和团队。通过频繁的提供可以工作的软件，我们也可以更为频繁的搜集对产品和开发过程的反馈，保证开发小组始终是在处理具有价值的功能，而且这些功能可以满足用户的需要。

　　虽然我们致力于提供可供做的软件，但并不是不要文档。我们在开发过程中仍然需要进行内部交流，  也需要和客户交流，我们仍旧可能需要制作原型，书写一些主要需求和算法，只要自组织团队认为足够行了。

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

　　这四句价值观用语句表达是：

　　自组织团队与客户紧密协作，通过高度迭代式、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件

　　胜过

　　与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，后交付需求。