前言

在20世紀90年代中期的大部分時間里，我都感到愧疚。我當時正在為一家公司工作，這家公司每年都會收購一家新公司。每次收購一家新公司，我都會被分派去負責打理他們的軟件開發團隊。收購的每個開發團隊都帶來了輝煌、美觀、冗長的需求文檔。我不可避免地感到愧疚，因為我自己的團隊從來沒有寫出過如此優美的需求規格說明。但是，我的團隊在生產軟件方面一直比我們收購的團隊成功得多。

我清楚我們成功的方法。然而，我總有一種難以名狀的感覺，如果我們能寫出大而冗長的需求文檔，我們可能會更加成功。畢竟，那正是我當時正在閱讀的書籍和文章中所描述的做法。如果成功的軟件開發團隊都在編寫華麗的需求文檔，那么看起來我們也應該這樣做。但是，我們從來沒有時間做。我們的項目總是太重要，需要我們盡快啟動，以至于我們從一開始就沒有時間來寫文檔。

因為我們從來沒有時間寫美觀而冗長的需求文檔，所以我們決定采用一種工作方式來與用戶溝通。我們不是把需求寫下來，讓它們來回傳遞，并在時間不夠用的時候還在談判，而是和客戶交談。我們會在紙上繪制界面樣例，有時候會創建原型，通常我們會寫一些代碼，然后向預期用戶展示我們編寫的內容。至少每月一次，我們會邀請一組具有代表性的用戶，并向他們演示我們開發的功能。通過貼近用戶并向他們演示小的增量進展，我們找到了一種方法來幫助我們在沒有美觀需求文檔的情況下取得成功。

盡管如此，肯特·貝克（Kent Beck）仍然感到愧疚，認為我們沒有按照我們應該的方式去做事。

1999年，肯特·貝克的革命性小冊子《解析極限編程》出版發行。一夜之間，我所有的愧疚蕩然無存。終于有人提出了開發人員和客戶之間用討論取代“寫文檔-商談-再寫文檔”的模式。肯特闡明了很多事情，并帶給我很多新的工作方法。但是，最重要的是，他證明了我從自己的實踐中領悟到的是正確的。

大量的前期需求收集和文檔可能在多方面導致項目失敗。最常見的一種情況是需求文檔本身成為軟件開發的目標。需求文檔只有在能夠幫助實現交付某些軟件的真正目標時才應該編寫。

大量的前期需求收集和文檔可能在多方面導致項目失敗的第二種情況是書面語言的不準確性。我記得很多年前聽到過一個小孩洗澡的故事。小孩的父親已經在浴缸中放滿了水，正準備幫助他的小孩進入水中。這個小孩大概兩三歲，先把腳趾頭伸入水中蘸了一下，然后迅速將腳趾移開，并告訴她的父親“讓它暖和一些”（make it warmer.）。父親把手伸入水中，驚訝地發現水不是太冷，已經比他女兒習慣的溫度更熱了。

父親思索了一下孩子的請求，意識到他們的溝通出現了問題，用相同的詞語來表示不同的意思。孩子“讓它暖和一些”的請求被任何成年人都解釋為“調高水溫”（increase the temperature）。然而，對于孩子來說，“讓它變暖”意味著“讓它接近我認為暖和的程度”。

文字，尤其是白紙黑字那樣的，通過它來表達軟件這樣復雜東西的需求，是比較簡單有限的載體。由于它們可能被誤解，所以我們需要用開發人員、客戶和用戶之間頻繁的對話來取代書面文字。用戶故事為我們提供了這種方法，讓我們寫下來足夠多我們不會遺忘的內容，并且我們可以估算和計劃，同時還鼓勵及時溝通。

讀完本書的第I部分時，你將準備開始改變總是嚴格寫下每一個需求最后細節的工作方式。讀完本書的時候，你會知道在具體環境中實施故事驅動過程所有的必要信息。本書分為四個部分和兩個附錄。

第I部分“開始”，描述開始編寫故事需要了解的一切。用戶故事的目標之一是讓人們說話而不是寫作。第I部分的目標是盡快讓你交談。第1章概述了什么是用戶故事以及如何使用故事。接下來的章節提供了編寫用戶故事，通過用戶角色建模收集故事，在無法訪問實際最終用戶時編寫故事以及測試用戶故事的更多細節。第I部分的結尾部分提供了一些指導方針，可以用來改進用戶故事。

第II部分“估算和計劃”，有了一系列用戶故事后，我們經常需要回答的第一件事是“需要花費多長時間來開發？”。第II部分介紹了如何使用故事點來估算故事，如何在3～6個月的時間范圍內計劃發布，如何更詳細地計劃隨后的迭代，最后如何度量進度并評估項目是否按照既定的意愿進行。

第III部分“經常討論的話題”，首先描述故事與用例，軟件需求說明和交互設計場景等需求方案的不同之處。隨后探討用戶故事的獨特優點，如何判斷出現問題的時間，如何調整敏捷過程Scrum以使用故事。最后一章著眼于各種小問題，例如是否在紙質卡片或者軟件系統中編寫故事以及如何處理非功能性需求。

第IV部分“一個完整的項目案例”，一個擴展的例子，旨在幫助歸納用戶故事的所有內容。如果說開發人員可以通過故事更好地理解用戶的需求，那么本部分的完整示例是非常重要的，這個示例將展示用戶故事的各個方面及其結合方式。

第V部分“附錄”，用戶故事源于極限編程。閱讀本書之前不需要熟悉極限編程。附錄A提供了極限編程的簡要介紹。附錄B包含對各章結尾思考練習題的解答。