大部分軟體專案以每2到6個月為一個新的釋出週期，這是最好的。以產品的開發路線圖開始規劃釋出通常很有幫助，路線圖展示未來幾個新發布中關注的重點。這個產品的開發路線圖毫無疑問會不斷改變------這是我們所期望的，因為這些改變標明我們更加了解自己的產品，它的市場以及我們開發產品的能力。

     產品的開發路線圖可以很簡單，它可以是未來幾個釋出要關注的重點列表，或者像Kent Beck所稱的“主題”。

     一旦得到了這些問題的答案，就可以通過估算團隊能在每輪迭代中完成多少工作來計劃釋出了。利用我們能在一輪迭代中完成多少工作量來估算，我們可以做一個合理的預測，即完成符合使用者期望的釋出需要多少輪迭代。

小結

• 在計劃釋出時，有必要知道客戶預期的大致釋出日期和故事的相對優先順序。

          理想情況下，開發人員和客戶可以談一個日期範圍，而不是一個具體日期。

• 故事應該以明確的順序排列（第一個，第二個，第三個等等），而不是利用諸如“非常高，高，中等”模糊順序的分組。

          為了一個計劃一個釋出，客戶必須排列故事的優先順序。把故事分成諸如高優先順序，中優先順序和低優先順序這三種類型是很有用的，但這會導致乏味冗長的爭論，會針對某個故事是高優先順序還中優先順序而爭論不休。幸運的是，我們可以借用來自DSDM的方法，它是另一種敏捷過程。

           DSDM包括一個排列優先順序的方法，稱之為莫斯科(MoSCoW)規則

           必須有（Must have）

           應該有（should have）

           可以有（Could have）   

           這次不會有（Won't have this time）

           “必須有的功能”是指系統的基本功能。“應該有的功能”是指很重要但短期內有替代解決方法的功能。如果專案沒有時間約束，通常認為應該有的功能是強制性的。“可以有的功能”是指如果沒有時間就可以在釋出中不予考慮的功能。列為“不會有的功能”是客戶期望擁有但同時承認需要在後續釋出中實現的功能。

•   故事的優先順序由客戶確定，但也要考慮開發人員的想法。

            開發人員實現故事時會有一個順序，就像客戶所期望的那樣。當客戶和開發人員對這個順序有不同意見時，最後每次都應該是客戶說了算。

            但是，客戶在沒有從開發團隊那裡獲得某些資訊之前，很難確定故事的優先順序。至少，客戶要知道每個故事需要大約多久才能完成。在確定故事的優先順序前，應該先估算它們，並且在故事卡上寫下估算。

            此時，客戶不會把對故事的估算加起來，然後決定一個釋出中包括什麼，不包括什麼。而是利用這些估算，結合自己對於每個故事價值的評估，把故事進行優先順序排序，使交付給自己公司的價值最大化。一個特別的故事對於客戶公司可能極有價值，但需要花一個月時間來開發。一個不同的故事可能只有它一半的價值，但可能要只要花一天時間就能開發完。

            使用混合優先順序。 如果客戶在確定一個故事的優先順序時遇到問題，可能需要分割這個故事。分割故事能使客戶對故事的優先順序排列出不同的優先順序。

            高風險故事。 敏捷方法旗幟鮮明地支援先做最有價值的部分。這讓敏捷專案能夠避免過早地解決風險，同時也推遲了可能並不需要的一些基礎性程式碼的開發。贊同先做最有價值的部分，還能使專案可能儘早釋出，那時只提供最有價值的功能。但是，即使以價值優先為嚮導，我們在排列優先順序時仍然需要考慮風險。許多開發人員傾向於先做風險最高的故事。有時這是恰當的，但這仍然必須由客戶決定。然而，在排列故事優先順序時，客戶應該考慮技術團隊的意見。

            根據架構需要安排優先順序。

• 使用速率將以理想日為單位的估算轉換成日曆日。

          假設客戶已經安排好所有故事的優先順序。團隊累加每個卡片的估算，總共有100個故事點。使用故事點使得估算故事變得更加容易，但現在我們需要一種方法，將故事點轉換成專案的預計工期。

          答案當然是使用速率 。速率代表一輪迭代中能完成的工作量。一旦知道團隊的速率，就可以用它將理想日轉變成日曆日。例如，假設故事專案需要100個理想日，如果速率是25，我們就可以估算出完成專案需要100/25=4輪迭代。

• 估算團隊的初始速率很有必要

          可以通過下面的方法獲得初始速率。

          -- 使用歷史值

          -- 執行一輪初始迭代，使用那輪迭代的速率

          -- 猜測

          如果我們需要猜測速率，這種方法至少應該是言之有理的，能清楚地跟別人解釋。幸運的是，確實有合理方法的，並且定義大約一個理想工作日為一個故事點。

           如果故事點是一個理想工作日，我們可以通過估算完成一個完整的理想工作日實際需要多少天籟估算初始速率。在迭代過程中，團隊顯然會受到許多幹擾，阻止團隊享受理想日。因為有干擾，把一輪迭代三分之一到一半的開發日作為預計速率是很常見的。

• 建立釋出計劃

         因此，如果專案有100個故事點，若估算的速率是每輪迭代20個故事點，則可以預計總共需要5輪迭代。釋出計劃的最後一步是把故事分配到每輪迭代中。客戶和開發人員一起協作，選擇優先順序最高的20個故事點，並且將它們放入到第一輪迭代中。下一組次高優先順序的20個股試點放入第二輪迭代中，如此進行直到分配完所有的故事。

         取決於團隊是否在同一地點工作，以及組織所需要的規範，有許多方法可以溝通釋出計劃。例如，我用過以下方法：

• 對於工作在一起的團隊，我把故事卡釘在牆上，用列來表示迭代。
• 對於記錄在電子表格中的故事，我根據它們的迭代進行排序，然後再每輪迭代的最後一個故事後畫一條厚重的粗線。
• 對於有興趣的遠端利益相關者，我影印記錄卡給他們。
• 對於有興趣的，比較講究形式的遠端利益相關者，我給他們建立簡單的甘特圖。

• 警告

          小心，不要太迷信釋出計劃！本章描述的方法將幫助你估算專案所需要的大致工期，讓你可以宣告“在5~7輪迭代後，可以準備釋出產品”。但是，這些方法不足以精確說明“我們會在6月3日完成”。

開發人員職責

• 負責提供資訊（有時包括基本假設和可能的替代方法）給客戶，以幫助她排列故事優先順序。
• 負責在基礎性或者架構性需求與其他客戶需求之間取得權衡，避免不切實際地提高基礎性需求或架構性需求的優先順序。
• 建立釋出計劃，負責在實際估算的基礎上，適當包括一定長短的時間用以專案緩衝。

客戶職責

• 負責以自己對故事價值的估計來確切排列使用者故事的優先順序。把故事排列為高，中，低這三個優先順序是不夠的。
• 負責誠實地表達釋出期限。如果在7月15號需要，請不要為了保險起見而告訴開發人員6月15號就需要。
• 負責理解理想日和日曆日的不同。
• 在想對故事的不同元件排列不同的優先順序時，負責分割故事。
• 負責瞭解為何不應該譴責活批評一位個人速率為0.6的程式設計師，只因為她的速率小於1.0。