第1章　概述

软件需求是一个沟通问题，需要新软件的人（使用或者要销售的人）必须与那些构建新软件的人进行沟通。为了取得成功，项目依赖于来自不同人群的信息：一方面是客户和用户，有时候是分析师、领域专家和其他从商业或者组织角度看待软件的人；另一方面是技术团队。

如果任何一方支配或主导了这些沟通，项目就会遭受损失。当业务方处于支配地位时，他们就会只关注实现的功能和日期，很少关注开发人员是否可以同时满足这两个目标，或者开发人员是否确切地知道什么是真实的需求；当开发人员支配了沟通时，技术术语就会取代业务语言，导致开发人员失去了通过倾听来了解什么是真实需求的机会。

我们需要的是一种协同工作的方式，这样双方都不占优势，因此将共同面对资源分配中的意气用事和政治问题。当资源分配问题完全落在一方时，项目就会失败。如果开发人员承担这个问题（通常是以“我不关心你怎么做，但必须在六月之前完成”的形式），他们可能会对其他特性进行质量交易，可能只部分实现一个特性，或者可能自行去做一些本该有客户和用户参与决策的决定。当客户和用户承担资源分配的负担时，我们通常会在项目开始时看到一系列冗长的讨论，其中的特性会逐渐从项目中移除。然后，当软件最终交付时，它的特性甚至还不及之前已识别的简化集。

到现在我们已经认识到，我们不能完美地预测一个软件开发项目。当用户看到软件的早期版本时，他们会提出新的想法，意见也会改变。由于软件的不确定性，大多数开发人员在估算事情需要花费的时间方面是众所周知的难事，由于这些和其他因素，我们不能制定一个完美的PERT（计划审查技术）(1)图表来显示项目上必须做的一切。

那么，我们该怎么办呢？

我们基于手头现有的信息来做决定，我们经常这样做。我们不是在项目的一开始就制定一个包罗万象的决定，而是在项目的整个过程中分散式决策。为了做到这一点，我们要确保我们有一个能够尽可能早、更频繁地获取信息的方法。用户故事由此产生。