2.2　规范敏捷思想的核心价值观

在原版《敏捷宣言》中提到的4个核心价值观都是以“此优彼劣”的形式来体现的。不过，对这种陈述正确的理解方法应该是，在你对“此”视若珍宝的时候，更应该深刻地理解到“彼”也具有极大的现实意义。所以，对原版《敏捷宣言》的正确理解应该是，它所陈述的“此”与“彼”之间，只有优劣之分，而无对错之别，它只是在引导我们关注特定的领域，而不是要刻意忽略其他领域。
改进过的《敏捷宣言》中的4个核心价值观如下（改动以楷体标出）。

1）个体和互动优于流程和工具。软件开发的主体是由人组成的团队，为了达成工作目标，他们必须能够协同高效地工作。你认为在下面两种情形中，哪一个团队能够开发出更优秀的产品：5个经验丰富、使用自己专属工具的软件开发人员集中在一起，相互配合地进行工作；还是10个技能水平较低的程序员，遵循精心设计的流程，使用复杂高效工具的软件，分别在各自舒适至极的办公室中工作。显然，我们会更愿意投资于人员精简、合作精神突出的团队。工具和流程固然重要，只是不如高效的团队合作更重要。
DAD的改动：无。规范敏捷交付思想完全相信个体和互动的价值高于流程和工具。
2）实际可见的解决方案优于复杂全面的文档。如果你问一个人他是喜欢通过阅读一本50页的功能描述来了解你对即将开发的解决方案的设想；还是喜欢看到你的解决方案的实际雏形，那么你觉得他会选择哪个？我猜100次中有99次他都会选择看到实际的解决方案。难道你不觉得如果能经常和快速地拿出一些实际有价值的解决方案，会比空洞的纸上谈兵更有意义吗？另外，项目利益相关者如果能看到实际的解决方案，能够更快更容易地了解项目，这比单纯地阅读复杂的技术文档和功能描述要高效和便捷得多。文档工作有其实际意义：一些最终交付给用户的文档，例如，用户手册和操作说明实际上正是最终解决方案中不可或缺的部分，不过也只是一小部分而已。永远不要忘记作为IT开发团队的首要任务是开发出符合用户需求的解决方案，而不是文档。不然的话，软件开发就该改名为“文档开发”了，不是吗？请注意，原版《敏捷宣言》用了“软件”而不是“解决方案”这个词汇。
DAD的改动：只有实用的软件是不够的，还应该有完整的、切实可行的解决方案，其中除了应包括软件外，还应包括运行软件可能需要做的硬件改动，对应的业务流程的改变，与软件一同发布的文档，甚至由该软件应用带来的新的组织结构变化。
3）利益相关者协作优于合同谈判。只有项目的利益相关者本人能够告诉你他的需求是什么。没错，他们可能无法很具体地描述解决方案。没错，他们第一次可能无法抓住重点。没错，在他们看到你的团队的实际工作成果后，可能会改变自己的想法。没错，现实工作环境中存在各种不同的项目利益相关者，包括最终用户、他们的上司、高级IT主管、公司战略负责人、运营人员、支持人员、合规审查人员以及其他各色人等（第4章将详细论述）。与项目利益相关者合作是一件困难的事情，但是这才是人们在实际工作中会遇到的情况。与利益相关者订立合约非常重要，但是这种刻板的合约关系有可能会让人们无法有效地沟通。成功的开发团队能够与各利益相关者紧密合作。他们会花费精力去发现利益相关者的真实需求，他们也会对利益相关者进行教育，在项目执行过程中，保持一致的思想。主流的开发思路认为团队应该在与外界绝缘的条件下，独立开发解决方案。他们只需要团队内部彼此间地合作，加上从“唯一的客户声音”（也就是通常所说的产品负责人）那里得到的指引就足够了。但这绝不适合大型软件项目的开发。团队必须与各式各样的利益相关者，比如上面列出的那些人进行合作，而不仅仅是客户。注意，原版《敏捷宣言》用了“客户”这一词汇，而不是“利益相关者”。
DAD的改动：显而易见的事实是，在每个解决方案的开发过程中，都有各种各样的利益相关者，绝不仅仅限于项目的商业客户。你需要与多个利益相关者进行互动，方能了解他们的真实需求。
4）响应变化优于遵循计划。人们会因为各种原因而改变自己做事的优先顺序。随着工作的不断进行，项目利益相关者对已完成的工作及所面临问题的理解会不断变化，并且真实的商业环境，甚至是能够采用的技术都会随之变化。变化是软件开发过程中所真实面临的问题，而你在整个工作流程中都必须时刻关注这一问题。预先制定项目计划是必需的。实际上，我们会觉得一个没有事先计划的项目是极不正常的。但是，项目计划必须是有灵活性的，并且只能结合近期的情况制定具体的短期行动计划（几周之内甚至更短）。
DAD的改动：无

关于这些核心价值观阐述的有趣之处在于，几乎每个人都会立即认同这些道理，但在实际行动中极少得以贯彻。管理层总是会把“员工是我们最重要的财富”这样的话挂在嘴边，但在实际工作中，他们又把员工看做可替代的、无关紧要的财产。一种更糟糕的情况是，管理层会要求项目团队按照特定的流程进行，却不提供足够的资源配置。每个人都认为创造出一个实用的解决方案是每个开发项目最主要的目标，但他们仍会花几个月的时间进行文档工作，以此来定义解决方案的性质以及如何进行开发，而不是直接卷起袖子开始做实质性的工作。你应该知道我的意思了，人们总会言行不一。必须改掉这样的习惯。规范敏捷开发人员必须言出必行，有一说一。