第1章　概述

軟件需求是一個溝通問題，需要新軟件的人（使用或者要銷售的人）必須與那些構建新軟件的人進行溝通。為了取得成功，項目依賴于來自不同人群的信息：一方面是客戶和用戶，有時候是分析師、領域專家和其他從商業或者組織角度看待軟件的人；另一方面是技術團隊。

如果任何一方支配或主導了這些溝通，項目就會遭受損失。當業務方處于支配地位時，他們就會只關注實現的功能和日期，很少關注開發人員是否可以同時滿足這兩個目標，或者開發人員是否確切地知道什么是真實的需求；當開發人員支配了溝通時，技術術語就會取代業務語言，導致開發人員失去了通過傾聽來了解什么是真實需求的機會。

我們需要的是一種協同工作的方式，這樣雙方都不占優勢，因此將共同面對資源分配中的意氣用事和政治問題。當資源分配問題完全落在一方時，項目就會失敗。如果開發人員承擔這個問題（通常是以“我不關心你怎么做，但必須在六月之前完成”的形式），他們可能會對其他特性進行質量交易，可能只部分實現一個特性，或者可能自行去做一些本該有客戶和用戶參與決策的決定。當客戶和用戶承擔資源分配的負擔時，我們通常會在項目開始時看到一系列冗長的討論，其中的特性會逐漸從項目中移除。然后，當軟件最終交付時，它的特性甚至還不及之前已識別的簡化集。

到現在我們已經認識到，我們不能完美地預測一個軟件開發項目。當用戶看到軟件的早期版本時，他們會提出新的想法，意見也會改變。由于軟件的不確定性，大多數開發人員在估算事情需要花費的時間方面是眾所周知的難事，由于這些和其他因素，我們不能制定一個完美的PERT（計劃審查技術）(1)圖表來顯示項目上必須做的一切。

那么，我們該怎么辦呢？

我們基于手頭現有的信息來做決定，我們經常這樣做。我們不是在項目的一開始就制定一個包羅萬象的決定，而是在項目的整個過程中分散式決策。為了做到這一點，我們要確保我們有一個能夠盡可能早、更頻繁地獲取信息的方法。用戶故事由此產生。