敏捷宣言的四项核心价值观

敏捷宣言源自经验而非理论。当你在接下来的章节中重温这些价值观时，请考虑如果你将它们应用到实践中时，这些价值观意味着什么？这些价值观是如何对产品的及时上市、变更的处理以及对人们创新活动的评估进行支持的？

尽管敏捷价值观没有被创建者们编号，但为了便于参考，我们在整本书中都对它们进行了编号。编号与它们在敏捷宣言中的顺序相符。

价值观1：个体和互动高于流程和工具

当你能够让产品开发中的每一位成员都贡献他/她的独特价值时，结果将非常可观。当这些成员的互动聚焦于解决问题时，一致的目标就能形成。此外，用于达成协议的流程和工具要比传统方法中的流程和工具简单得多。

一次充分讨论产品问题的简单交谈就可以在相对较短的时间里解决许多问题。试图用电子邮件、电子表格和文档去替代直接交谈，会产生大笔的开销并使进度延期。这些被管理和控制的沟通类型不仅不能提高清晰度，反而会含糊不清且浪费时间，并且会导致开发团队在创造产品的工作中分散注意力。

考虑一下，如果你更重视个体与互动的价值，那么这将意味着什么？表2-1展示了重视个体和互动与重视流程和工具之间的一些差异。

记住比较好

如果流程和工具被视为管理产品开发以及与之关联的任何事情的必由之路，那么人们及其工作方法必须与这些流程和工具保持一致，这种一致性使得人们适应新的想法、需求和思考变得困难。然而，敏捷方法认为人比流程更有价值，对个人和团队的强调使得人们更专注于他们的创新和解决问题的能力。在敏捷产品管理中，你也会使用流程和工具，但是它们被刻意精简，并直接支持产品创造。流程和工具越强大，你越需要花费更多的精力去关注它，也越需要遵从它。然而，重视个体和团队的力量并坚持以人为本，则会使生产力实现质的飞跃。敏捷环境以人为本，并倡导共同参与，从而使人们更容易适应新的想法和创新。

表2-1 个体和互动与流程和工具的对比

价值观2：可工作的软件高于详尽的文档

开发团队应当专注于生产出可工作的功能。在敏捷产品开发中，衡量你是否真正实现产品需求的唯一标准是生产出与该需求相对应的可工作的功能。对于软件产品来说，可工作的软件意味着该软件符合所谓的完工定义（DoD）：至少是已开发、已测试、已集成和已归档。毕竟，可工作的软件才是投资的初衷。

你是否曾经在汇报会议中做出类似的报告：你已完成了项目工作的75%？如果你的客户说：“我们已经没钱了，现在能拿走这已完成的75%的项目吗？”你将怎么回答？在传统项目中，你并没有任何可工作的软件给到你的客户——传统上的75%意味着你的进展是75%，但是完成度是0。然而，在敏捷产品开发中，根据完工定义，你已经实现了75%的产品需求——并且是最高优先级的那75%的需求，是可工作的、潜在可交付的功能。

记住比较好

尽管敏捷方法源自软件开发，但你也能在其他类型的产品中加以使用。第2条敏捷价值观就可以简单地表述为“可工作的功能高于详尽的文档”。

必须对干扰开发有价值的功能的任务进行评估，以确定它们对可工作产品的创建是支持还是削弱。表2-2列举了一些传统项目文档及其有用性的分析。请思考你最近参与的项目中所使用的文档是否能为交付给客户的功能增加价值。

表2-2 识别文档是否有用

记住比较好

敏捷产品开发中的术语“刚好够”（Barely Sufficient）是个褒义词，意味着项目中的任务、文档、会议或者几乎所有需要创建的东西达到实现目标的程度即可。“刚好够”代表着实用和效率——是足够的、刚刚好。“刚好够”的反义词是“镀金”，意味着在特性、任务、文档、会议或其他任何事情上增加不必要的努力。

所有的开发工作都需要一些文档。然而在敏捷产品开发中，只有当它们能以最直接、不拘泥于形式的方式支持开发工作并“刚好够”满足可工作的产品的设计、交付和部署时，才是有用的。敏捷方法极大地简化了与时间、成本控制、范围控制或报告相关的行政文书工作。

小贴士大用途

我们经常在编写一份文档时停下来并看看有谁在抱怨。一旦我们知道该文档的请求者，我们将尽力去了解这份文档为什么是必须有的。这种情形下的“五问法”（5 Whys）很管用——在每个回答后连续问“为什么”，以获得需要该文档的根本原因。一旦你知道需要该文档的核心原因，那么接下来就看你怎么使用敏捷方法或精简的流程来满足该需求。

产品开发团队制作的文档不仅精简，且需要对其进行维护的时间少，同时又能及时地从中发现潜在的问题。在接下来的章节里，你将了解如何创建并使用简单的工具（诸如产品待办事项列表、冲刺待办事项列表、任务板）让团队理解需求并评估每日项目的实时状态。敏捷方法让团队将更多时间投入在开发上而不是文档上，从而能够更有效地交付可工作的产品。有关产品待办事项列表的信息，请参阅第9章；要了解更多关于冲刺待办事项列表的内容，请参阅第10章。

价值观3：客户合作高于合同谈判

客户不是敌人，真的。

在传统项目管理方法中，客户通常只能参与以下几个开发阶段。

>>项目开始：当客户和项目团队谈判合同细节时。

>>项目中任何范围变更：当客户和项目团队就合同变更进行磋商时。

>>项目结束：当项目团队交付完整的产品给客户时。如果产品没有达到客户的期望，项目团队和客户将针对合同的补充变更进行谈判。

这种聚焦于谈判、避免范围变更以及限制客户直接参与的传统，不但阻碍了有价值的客户输入，而且会在客户和项目团队之间造成对立关系。

不开玩笑！危险！

你对产品的了解一定会比刚开始开发时更多。在产品开发刚开始时就在合同中锁定产品细节，意味着你要在不完整的认知下做出决策。随着对产品的了解加深，如果你能够灵活地适应变更，那么，最终你将创造出更好的产品。

这些敏捷开创者们认识到，合作而非对抗能够产出更好、更精益、更有用的产品。在这样的思想指导下，敏捷方法论总是将客户看作产品开发的一部分。

在实践中使用敏捷方法，你将体验到客户与产品开发团队之间的伙伴关系。你在产品开发过程中的发现、质疑、学习与调整都将成为例行的、可接受的和系统化的步骤。因此，在这种伙伴关系中，开发团队可以交付出更符合客户需求的优质产品。

价值观4：响应变化高于遵循计划

变化是创建伟大产品的有价值的工具。通常如果能快速响应客户、产品用户和市场，团队就能开发出符合人们需要的、有用的产品。

不幸的是，传统的项目管理方法试图撂倒变更这个“怪物”，并把它牢牢钉在在地上，使其失去知觉。严格的变更管理程序和不能适应新产品需求的预算结构使得变更很困难。传统的项目团队经常发现他们盲目地遵从计划，而错失了创建更有价值的产品的机会，或者更糟糕的是，他们无法及时地响应不断变化的市场条件。

图2-1展示了在传统项目中变更的时间、机会与变更的成本之间的关系。当时间以及你对产品的认知增加时，变更的能力在降低，并且成本在增加。

图2-1传统项目和敏捷项目变更的机会

相比之下，敏捷开发能系统地适应变更。敏捷方法的灵活性实际上提高了产品开发的稳定性，因为产品变更是可预测并可管理的。换言之，变更对于产品开发团队而言是意料之中的，而非颠覆性的。在后面的章节中，你将发现如何使用敏捷方法制订计划、开展工作和进行优先级排序，从而使团队快速响应变更。

随着新活动的展开，团队将这些现实状况纳入正在进行的工作中。任何新的事项都可以成为提供额外价值的机会，而不是要避免的障碍，进而给开发团队提供更大的成功的机会。