在一起（最好是單數），圍繞在一個需求人員的周圍；需求人員邀請開發(fā)人員在桌上的卡片中挑選出一個可以被認為是基準工作量的卡片，不要過大，也不要過小，我們的經驗是一對Pair在10個小時能夠完成的用戶故事（包含測試）。
當找到這個基準點之后，我們要做的是由需求人員對每張卡片進行講解，具體描述這張卡實現之后，作為用戶我可以做的1，2，3點，目的是讓開發(fā)人員了解范圍?；谶@個范圍，需求人員可以鼓勵開發(fā)人員提問，當遇到當時無法澄清的問題時，由需求人員把這個問題轉化假設寫在卡片上，讓開發(fā)人員基于假設進行估算。
估算值的大小采用費貝納切數列1，2，3，5，8，13+，注意有三點：
- 這里只有層級的概念，而沒有倍數的關系，2點的故事不代表工作量兩倍于1點的故事；而是只要認為這個故事大于基準故事卡而小于一個3點的故事卡時，那么這個故事的點數就是2。所以在一開始如果發(fā)現有一張卡片遠遠高于當前被估算最小點數的卡片，可是暫時不估，等待一個最相似工作量的卡片被估計出來繼續(xù)；
- 原則上不應該出現8個點以上的故事，如果出現，那么證明這個故事應該被拆分。這樣的故事可以被估計為13+，之后由需求人員繼續(xù)拆分；
- 對于不能估計的故事，打上問號，由需求人員之后澄清后再進行補充；
Mike Cohn發(fā)明了用卡片游戲進行估計的方法，考慮到成本較高，我們采用“猜拳法”。當大家已經明確卡片里的內容后，由需求人員喊：1，2，3！開發(fā)人員按照自己的想法用手指把點數表達出來，出拳之前大家不要商量，不要影響別人的判斷，像殺人游戲里投票的規(guī)則一樣“不能跟票”。規(guī)則是：
－ 重大差異雙方PK后重新出拳：如果結果相差兩個數量級，比如1和5，雙方進行PK，讓大家充分考慮不同意見，然后重新出拳；
－ 少數服從多數：如果出現相差不大的情況，少數服從多數，有特別需要提出的，可以給予機會提出，酌情考慮重新出拳；
－ 平票估多不估少：如果出現平票，比如3個3，3個5（因此盡量避免偶數人參加）時，按照估算量大的來算；
需求人員要作為主持人控制整個工作量預估的節(jié)奏，防止過度陷入細節(jié)，酌情給予重新出拳的機會。
注意，工作量點數應該寫在卡片背面。
迭代計劃
迭代計劃首先需要明白的是到底整個團隊能夠在一個迭代里交付多少。我們的實踐是，把之前準備的卡打散，由需求人員對核心開發(fā)人員（參加估計工作量的）說：“既然大家都已經完成了工作量預估，也對需求有了大致的了解，那么大家看一看估計兩周的時間里，我們團隊能差不多做些什么東西？請在這些卡里挑”。
這里需要注意的是，如果團隊是新建團隊，大家對團隊能力沒有一個經驗的參考，可以讓大家選擇自己估計能在兩周內完成卡片，之后的規(guī)則也基本類似。
這樣的挑卡活動大概進行6到8輪，每輪都把卡片重新洗過，由需求人員記錄每輪收集卡片的總工作量（這也是為什么把工作量放在卡后，這樣可避免開發(fā)人員有意識地挑選工作量大或小的卡片），然后除以輪數，得到一個大概的團隊單迭代（兩周）最大交付能力的數字。
因為永遠只能看到昨天的天氣，這個數字一定是不準確的，它將會在兩周后根據第一迭代的交付情況進行適當的調整。
至此，我們已經得到了一個團隊極限交付能力值，假設這個值是30。那么接下來要做的事情便是設計迭代計劃。
迭代計劃需要考慮的兩個進入標準是：
－ 優(yōu)先安排技術風險較大的技術任務在剛開始的迭代；
－ 每個迭代的一系列故事聚合在一起應該有一個明確的業(yè)務目標，體現一種明確的業(yè)務場景，而不是零零散散的功能點；
我們做的實踐是給需求人員和核心團隊與團隊極限交付能力相等數量的“籌碼”（我喜歡使用曲別
針），我們的例子里是30個。把30個籌碼按照上述的進入標準，分別放與工作量相等數量的曲別針在卡上。當30個全部用完，那么第一迭代的故事卡片就被確定。接下來是第2個迭代的需求，以同樣的方法，直到所有卡片被排完。注意越到后面迭代的卡片越不準確，因此可酌情考慮只做迭代1，2的計劃。
到此為止，我們至少直到了迭代1和迭代2計劃安排的工作內容，接下來的工作便是按照迭代泳道把這些卡片貼在墻上，當第一個迭代需求分析完畢后，全體開發(fā)人員進行Kickoff會議，快速開始迭代。
版權聲明：轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://yizhituzei.blogbus.com/logs/70698391.html