1.2 交付价值
价值很难界定。在很多方面，这就像美和质量一样：“当我看到它的时候就会知道它。”对一个人很有价值、很重要，但对其他人也许一点儿也不重要。和其他很多事情一样，交付价值也是和具体情境非常相关的。对我而言，评估价值就像试图理解它是否是值得的，而这里的“它”可能指的是承担或继续一项自发行动或交付一个具体的特性。
当你所交付的（产出）满足了利益相关者的需求（提供了预期的结果）时，你的团队就是在交付价值（deliver value）。交付价值也为项目（project）决策和衡量成功提供了不同的依据。你仍然需要关注成本、时间和范围的三重限制（triple constrains），但范围（scope）的定义是以是否取得了预期的成果为基础的，而不是以团队交付的产出量为基础的。你会发现，你的团队需要采取行动，寻求以最小的产出取得最大的结果，同时确保满足成本和时间限制。
范围的定义由产出变为结果，这使对是否交付了事先约定的范围进行量化更加困难。这正是目的（goal）、目标（objective）和决策过滤器（decision filter，这一技术将在第13章详细介绍）派上用场的地方。目的、目标和决策过滤器既提供了一种清晰的方法来描述你所寻求的结果，也提供了一种方法来判断你何时取得了那个结果。把打算满足的范围定义为这些方面，也为团队在满足这个范围时提供了更多灵活性，并且能够避免团队制造不需要的产出，这也为能够满足项目的成本和时间限制增加了机会。
项目会积累很多潜在的特性，它们在当时看起来是不错的想法，但最后对于项目的终极目标可能无足轻重。交付价值最简单的方法之一就是，把不能对预期结果产生直接贡献的产出砍掉。这些产出包括很酷且也是某个利益相关者声称想要的，但对项目要解决的问题无所助益的功能（functionality）。我们把特性限定为具有真正可识别价值的功能，并且我们只想关注用户真正使用的极少数功能，这就回到了我们的前提 ——用户基于他们的行为感知有价值的特性。
正如Gojko Adzic在审阅本书初稿时所提醒的，把重点放在能驱动达成预期结果的事情上。当用户可能使用的功能或者利益相关者提出的需求和预期结果毫无关系时，不为其分心是个不错的主意。
会议投稿系统（将在第7章介绍）就是一个专注结果而非产出的案例。这个项目的主要目标是支持Agile2013大会的会议投稿流程。我们确实建立了一个该系统要包含的特性的待办列表（项目的产出），但这一待办列表更多的是进行估算和计划的起点，而不是必须遵守的范围定义。在项目进行的过程中，我们根据我们的发现在待办列表中增加了几个特性，也推迟了几个特性，因为在时间固定的指导原则下，这几个特性对于达成业务目标并非绝对必要。
一个重要的附加说明需要记住，有些用来满足法规监管或安全要求的产出，诸如系统文档和文书工作，对预期结果仍然是有贡献的，否则如果没有其他原因而未能完成这些产出，组织（organization）要么无法得到批准交付解决方案，要么可能招致惩罚。
我将在第5章讨论更多关于交付价值的想法。