3.1.1　敏捷宣言

我们先来看一下敏捷宣言的内容，也就是敏捷方法所倡导的价值观。其中，尽管右项有其价值，但我们更重视左项的价值。

个体和互动高于流程和工具

敏捷开发强调人的贡献和团队沟通，鼓励当面沟通和建立信任，有些公司将办公室设计成开放式布局，以消除员工之间近距离沟通的障碍。合适和正确的工具能够帮助人们更好地完成工作，但如果认为过程和工具会对项目成败起关键的决定性的作用，那么就是本末倒置了。项目是由人来完成的，成败的关键在于每一个人的态度。不要认为更大的、更好的工具可以自动地帮你做得更好。通常，它们造成的障碍要大于带来的帮助[7]。

工作的软件高于详尽的文档

软件开发作为一项智力活动，很难用静态文档对其进行完备的定义和分析，与其让软件工作者和客户面对众多繁杂而又单调的文档，不如采取演示和讲解的方式更高效。这并不是说必须做到“无文档化”，没有文档的软件是另一种灾难，但过多的文档往往比过少的文档更不利，因为撰写这些文档需要时间，维护这些文档更需要时间，缺乏维护的文档给软件工作者带来的误导也会增加额外的成本。至于如何把握撰写文档的“度”，Martin文档第一定律（Martin’s first law of documentation）给出了简洁的结论：直到需求迫切且意义重大时，才撰写文档。

客户合作高于合同谈判

既然敏捷开发重视人的作用，那么与客户的合作也同样遵循这一理念。软件开发工作难以标准化，进度难以度量，这些是其固有的属性，我们不要纠结于合同措辞和商务谈判，而是要与客户加强沟通，尽可能频繁地给客户反馈，让客户与开发团队密切地凝聚在一起，这才是最好的“合同”。

响应变化高于遵循计划

正所谓人算不如天算，如果指望软件开发过程中没有变化，那么基本上都是会令人失望的，被动地遵循计划，不如主动地拥抱变化，这可能是敏捷开发最重要的理念之一。事实上，敏捷开发欢迎需求变化，认可需求变化背后的业务考量，面对变化的一种通行做法是，针对下一个迭代周期（如两周）的工作建立详细的计划，针对三个月内的工作建立粗糙的计划，针对更远的工作建立更原始的计划，平衡整体工作的稳定性和灵活性。