細節在哪里？

說明“用戶可以搜索工作”是一件事，把它作為指導用來開始編碼和測試是另外一件事。細節在哪里？需要解答的問題可能如下。

用戶可以搜索哪些值？州？城市？工作職位？關鍵字？

用戶必須是網站的注冊會員嗎？

可以保存搜索參數嗎？

匹配的工作要顯示哪些信息？

這些細節可以用額外的故事來表達。事實上，更多的小故事要優于龐大的故事。例如，整個BigMoneyJobs網站可以描述成這兩個故事。

用戶可以搜索工作。

公司可以發布空缺職位。

很明顯，這兩個故事太大了，用處不大。第2章能夠完全解決故事大小的問題。一個出發點是，好的故事可以在一天半到兩周的時間里由一個或者兩個程序員進行編碼和測試實現。而前面的兩個故事可以很容易地覆蓋BigMoneyJobs網站的大部分功能，所以大多數程序員可能會花上一周多的時間。

當一個故事太大時，可以稱為“史詩”。史詩可以拆分為兩個或者更多個較小的故事。例如，史詩“用戶可以搜索工作”可以拆分成以下幾個故事。

用戶可以通過諸如工作地點、薪資范圍、職位名稱、公司名稱和工作發布日期等字段來搜索工作。

用戶可以查看搜索到的相匹配的每個工作的信息。

用戶可以查看已經發布的工作所屬公司的詳細信息。

然而，直到有了一個包括所有最終細節的故事，才不會繼續拆分故事。例如，“用戶可以查看搜索到的相匹配的每個工作的信息。”就是一個非常合理和真實的故事。

不需要進一步將其拆分為下面幾項。

用戶可以查看工作描述。

用戶可以查看工作的薪資范圍。

用戶可以查看工作的地點。

與此類似，在典型的需求文檔中不需要增加這種樣式的用戶故事。

4.6　用戶可以查看搜索到的相匹配的每個工作的信息。

4.6.1　用戶可以查看工作描述。

4.6.2　用戶可以查看工作的薪資范圍。

4.6.3　用戶可以查看工作的地點。

與其將所有這些細節描述為故事，不如讓開發團隊和客戶討論這些細節。也就是說，在細節變得重要的時候，再對細節進行討論。在一個基于對話的故事卡上做一些注釋是沒有錯的，如故事卡1.2中所示。然而，相對故事卡上的注釋，對話才是關鍵。三個月之后，開發人員和客戶都不能指著卡片說：“但是，看，我說的就在這里。”故事不是合同義務。正如所看到的，記錄的達成一致的內容通過了測試，這表明一個故事已經正確開發好。

故事卡1.2　帶有注釋的故事卡