計劃發布和迭代

一個發布是由一個或者多次迭代組成的。發布計劃是指在預定的時間表和所需的功能集之間確定一個平衡。迭代計劃是指在這次迭代中選擇要包含的故事。客戶團隊和開發人員都參與發布計劃和迭代計劃過程。

為了計劃發布，客戶團隊開始對故事進行優先級排序。進行優先級排序要考慮如下因素。

這一特性對大多數用戶或者客戶是否具有吸引力。

對于少數重要用戶或者客戶來說，這一特性是否具有吸引力。

故事與其他故事之間的內聚關系。例如，一個“縮小顯示”的故事可能它自身不具有高優先級，但是如果作為故事“放大顯示”的補充，它就具有了高優先級。

對于許多故事，開發人員可能有不同的優先級定義。他們可能建議，故事的優先級應該根據技術風險或者因為它與另一個故事的互補關系而改變。客戶團隊應該聽取他們的意見，應該堅持交付組織最大化價值的原則，然后調整故事的優先級。

故事在優先級排序時必須考慮成本。去年夏天我的度假勝地本來是塔希提島(3)，直到我考慮了它的開銷，正是由于這一點，其他地點的優先級上升。所以要優先考慮每個故事的成本，故事的成本是由開發人員估算給出的。每個故事都有一個故事點數的估算，它顯式表明這個故事相對于其他故事的規模大小和復雜性。因此，估算有4點的故事是2點的故事的兩倍。

通過給發布中的迭代分配故事來逐步構建發布計劃。開發人員說明他們預期的速率，也就是他們認為每次迭代完成的故事點的數量。然后客戶將故事分配到迭代，確保分配給每次迭代的故事點的數量不會超過預期的團隊速率。

例如，假設表1.1列出了項目中所有的故事，它們按照降序排列。團隊估算每次迭代的速率為13點。故事將被分配到迭代，如表1.2所示。

因為團隊期望的速率是13，所以沒有迭代的計劃超過13點。這意味著第2和第3次迭代計劃只有12點。不要擔心評估的精確性不夠精確，如果開發人員的速率比計劃的要快，他們會要求再加一兩個小故事。注意，在第3次迭代中，客戶團隊實際上選擇了將故事J包含在更高優先級的故事中，這是因為故事I是5點，太大了，無法包含在第3次迭代中。

可以暫時跳過大故事，在迭代中放入更小故事的替代方法，是把大的故事拆分成兩個故事。假設5點的故事I我可以拆分成故事Y（3點）和故事Z（2點）。故事Y包含了舊故事中最重要的部分，可以適合第3次迭代，如表1.3所示。關于如何和何時拆分故事的建議請參見第2章和第7章。