使用故事的過程是什么樣的？

和以前習慣的相比，一個使用故事的項目將會帶給你一種不同的感覺和節奏。使用傳統的面向瀑布的過程會導致一個循環，即編寫所有需求、分析需求、設計解決方案、編碼實現解決方案，然后最終測試它。在這種類型的過程中，客戶和用戶通常在開始編寫需求和最終接受軟件的時候參與，但是在編寫需求和最終接受之間的過程，用戶和客戶可能幾乎完全沒有參與。到如今，我們已經知道這是行不通的。

在一個故事驅動的項目中，首先關注的第一要事就是客戶和用戶在整個項目期間都保持參與其中。在項目的中途，他們不會被期望（或者允許！）消失。不管團隊是否在使用極限編程（XP，參見附錄A獲得更多信息），敏捷版本的統一過程，像Scrum一樣的敏捷過程（見第15章），或者是一個原生的、故事驅動的敏捷過程。

新軟件的客戶和預期用戶應該準備在編寫用戶故事時扮演非常積極的角色，特別是在使用極限編程時。編寫故事的過程最好從考慮預期系統的用戶類型開始。例如，如果你正在構建一個旅游預訂網站，你可能會有一些用戶類型，例如飛行常客、度假計劃者等等。客戶團隊應該包含盡可能多的用戶類型的代表，但是如果做不到這點，用戶角色建模就有幫助。（關于這一主題的更多內容，請參閱第3章）。

一個項目的初始故事通常都是在一個故事編寫工作坊里寫出來的，但故事可以在整個項目的任何時候來編寫。在故事編寫工作坊中，每個人都盡可能多地進行頭腦風暴。有了一個初始的故事集，開發人員就可以估算每個故事的大小。

客戶團隊和開發人員協同選擇一個大約持續時間從1周到4周長的迭代長度，項目期間會使用同樣長度的迭代。在每次迭代結束時，開發人員將負責交付應用程序的某個完全可用的代碼子集。在迭代過程中，客戶團隊仍然高度參與，與開發人員一起討論在迭代過程中開發的故事。在迭代過程中，客戶團隊還詳細地定義測試，并與開發人員一起工作，運行自動化測試。同時，客戶團隊確保項目不斷向前推進，及時交付產品。

一旦選擇了迭代的長度，開發人員就會估算他們在每次迭代中能夠完成多少工作，我們稱之為“速率”。因為沒有辦法預先知道速率，所以團隊對速率的初始估算是不準確的。然而，我們仍然可以使用最初的估算來粗略估計發布計劃中每一次迭代將要包含的工作量以及需要多少次迭代。

為了計劃發布，我們將故事分成不同的批次，每一批次代表一次迭代。每一批次都將包含一些故事，這些故事的估算總和不超過估算的速率。最高優先級的故事會進入第一批次，當這批次報滿時，次高優先級的故事就會進入第二批次（代表第二次迭代）。如此往復，直到你的批次累積時長超過了項目時限要求或者直到這些批次體現了一個令人滿意的新產品的發布。（關于這些主題的更多內容，請參閱第9章和第10章。）

在每次迭代開始之前，客戶團隊可以對計劃進行中途修正。當迭代完成時，我們可以獲悉開發團隊的實際速率，并且可以使用它來取代估算的速率。這意味著每一批次的故事都需要通過添加或者刪除故事來進行調整。另外，有些故事會比預期的要容易得多，這意味著團隊有時想在這次迭代中考慮額外增加一個故事來做。但是有些故事比預期的要難，這意味著有些工作需要轉移到后期的迭代中，或者完全移出發布。