XP中的使用者需求分析：Planning Game 和 User Story概述

Extreme Programming 中的需求分析，是通過Planning Game 完成的。雖然我們從Planning 
Game開始，討論Extreme Project的具體過程，但實際上，Planning Game中的一些階段幾乎貫穿了專案
開發的始終。（用Game這個詞，可以讓大家的心理放鬆些。）

        做計劃，是一件說起來容易做起來難的事情。做計劃時，程式設計師考慮的是怎麼樣程式設計更快；項
目經理考慮的是到底程式設計師多久才能做完這些事情；客戶考慮的是多久時間後拿到多少東西……一開始
就全面考慮這些問題當然沒有什麼不對，但計劃和任何事情一樣，都是一步步完成的。

Planning Game 分為三個階段，探測、計劃和調整。

探測階段：客戶和開發人員一起把需求分解成很多小的，可估算的部分。
計劃階段：客戶和開發人員一起制訂釋出計劃。
調整階段：客戶和開發人員一起，在開發過程中，根據實際情況，及時調整原有的計劃或者制訂新計
劃。

象所有的棋牌遊戲一樣，XP的Planning Game有它的牌（棋）、目標、玩家和遊戲規則。

牌（棋）：Planning Game中的牌（棋）是User Story。每個User Story都是一個很小的使用者需求；經
常是幾個詞或者一、兩句話。每個User Story都寫在一個卡片上，卡片上列出了它的商業價值和開發成
本。因為一個User Story的商業價值與開發成本可能和另一個User Story的取捨密切相關，所以這些卡
片有時候看起來比較複雜。

目標：如果我們把產品比作一個盒子，那麼遊戲的目標就是，在遊戲結束時，使盒子中的Story卡上的
商業價值總和儘可能地最大。

玩家：客戶和開發人員。

遊戲規則：

寫Story：遊戲中的任何時候都可以將一個新的使用者需求寫成一個Story。每個Story除了包含它的商業
價值（客戶眼中的優先順序）外，還有足夠的內容以便開發人員估計開發成本。

估計Story：開發人員估計每個Story的理想開發周。如果大於2周，則應該把該Story分解（這個分解過
程，可能會導致多個Iteration。）。如果估計開發時間很短（比如半個小時），則可以考慮在適當時
候把它和另一個Story合併。

制訂釋出（Release）計劃：客戶和開發人員一起，決定哪些Story是這一次釋出要完成的，哪些是下一
次釋出時要完成的，什麼時候交付產品，產品應該包括哪些Story。制訂釋出計劃時有兩種出發點，基
於Story和基於時間。

基於Story：客戶把一些Story卡歸為下一個釋出計劃要完成的內容。每放一張卡，客戶描述這個Story
的內容，開發人員估算這個Story的開發時間和釋出日期。

基於時間：客戶指定了一個交付日期或者釋出日期。開發人員估算從現在到那個日期之間，可以完成多
少工作（多少個理想工作周），然後由客戶來選擇要完成哪些Story，所有選中的Story的總開發時間應
該小於開發人員估算的理想工作周總數。
商業價值和開發風險優先：儘量將商業價值高的Story安排在早期計劃中（商業價值優先）；儘量將高
開發風險的Story安排在早期計劃中（開發風險優先）。開發人員將Story排列後，應該可以承諾在幾個
星期內，給客戶一個可工作的，但是比較粗略的系統。

糾正估算：比如，開發人員以前估計可以在交付日期之前完成20個Story，但是開發過程中，通過不斷
地計算開發速度和重新評估，發現只能完成15個Story。客戶就從原來的20個Story中挑選5個放到下一
期開發中。（有時候，客戶也有可能為得到所有的Story而延遲交付日期。）

更正商業價值：客戶可以隨時更改每個Story的商業價值（優先順序）。相應地，開發人員根據這些更改
調整Story的開發次序。

引入一個新Story：客戶可以隨時加入一個新Story。開發人員要估算開發成本和風險。如果客戶要求在
這次開發中完成這個Story，開發人員要和客戶一起，按照商業價值和開發風險優先的原則，重新估算
相關的Story。

分解一個Story：客戶把一個大的或複雜的Story分解成兩個或更多的小Story。客戶要估計每個分解後
得到的Story的商業價值；開發人員要估算開發成本。分解Story，通常是因為這個Story不可能在短期
內由少數人完成。

Spike：客戶可以讓開發人員集中資源，用很短的時間（可能是兩、三天）來證明一個想法的可行性或
應付一個緊急情況（比如恢復資料）。如果這個需求比較複雜（不是打個小補丁），使用者應該把它寫成
一個Story。這個Story也應該按照商業價值和開發風險優先的原則被評估。Spike通常都是會影響開發
速度的。

重新估算：開發完一個Story後，開發人員重新估計剩下的Story，可能會發現以前過高估算了自己的開
發能力，也有可能發現開發時間可以縮短。

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-580386/，如需轉載，請註明出處，否則將追究法律責任。