敏捷開發一千零一問系列之三十：敏捷怎樣估算（中）？

方案

方案一：用早期功能點估算法進行報價或早期制定項目計劃

這個在以前談到過不少次了，具體能夠參考敏捷開發績效管理系列的之6、之七。另外在敏捷開發用戶故事分類與組織結構（一期） （整個活動1期）中有詳細描述。

這個是國際上迄今爲止惟一被大規模推廣使用的方法，中國即將發佈的國標就是基於這個的。如今世界上有6000多認證的功能點估算專家，中國只有2個（本人不是），因此顯得不太出名。這多是軟件界中外差距最大的一個知識領域了。

方案二：用敏捷撲克防止大規模的代碼和工做量浪費

幾種錯誤作法

可不是用了撲克牌就是敏捷估算的，好比下面的玩法：
1. 隨機抽一張牌，是多少就是多少
這個是最快的撲克牌估算，很快，尚未爭議。但相信沒有人喜歡，因此「快」不是咱們敏捷估算的目的。
2. 各自出一張牌，加在一塊兒除以人數
這個聽起來理智多了，還很民主，頗有點放權的意思。是否是正解？嗯……若是有人出1，也有人執意出100人天，怎麼辦？（1+100）/2 = 50.5？看來，民主和放權也未必是正解。
3. 不用撲克，主動領取，誰幹誰說了算，本身估算的本身幹着才帶勁
這個聽着也很敏捷，放權，激勵，承諾……都有了。不過，不論是不是敏捷，若是前面那幾位4000行和19萬代碼的來了，那就完了。無論高手有多厲害外加多熱情，代碼冗餘不可避免；而新手在寫下一份簡歷的時候，大概在想：我這兩年作的事情，實際上被一個傢伙兩個月重寫了。
這裏有個標準問題了：究竟是選擇符合敏捷標準的，仍是符合最小代碼和工做量的？
是我會選擇後者。畢竟敏捷是來服務咱們的，不是讓咱們來「遵照」或「追隨」的，若是都傷害了團隊和項目的利益，就算它是敏捷又如何。

那到底應該怎麼估算？

正確作法

在說正確作法前，先要找到正確目的。

放權，激勵，承諾，民主……這些不是目的嗎？不是，這些是手段。目的，是一種達成後，能直接看到進度、質量、成本、需求得以改善的東西，而不是還要七拐八繞才靠邊的東西。

其實咱們前面講到了，一個值得花費一天進行估算的目的，是估算能夠有效減小代碼行和工做量。

爲了達到這個目的，估算的過程應該是：

0. 產品經理講解需求，你們提問（若是願意，能夠稍加討論，建議不要太長）

1. 各自估算（扣牌出，不要亮牌）

2. 全部人出牌後，開牌

3. 最大值和最小值PK，其餘人起鬨也能夠參與

4. PK後，不要直接達成一致（好比「那就三天吧」），而是從新出牌

5. 返回2，直到達成「近似一致」

6. 肯定最終結果

肯定選擇最終結果的規則很複雜——實際上沒有很精確的規則，因此要「隨機應變」，往後會同一些反饋，在本話題的下篇中討論。

按照這個作法，大概會發生這些事情：

0. 產品經理：……好了，大概就是這樣，你們若是沒有什麼問題就出牌吧……

1. 小張：唔……我估計至少這些（X天）；老王：就這還講了半天，最多這些（Y天）

2. Scrum Master：都出好了？開牌！你們：天哪，X=20 & Y=0.5

3. 老王：最多一個小函數55行就能夠了啊，爲何要那麼多天？

小張：一個函數是55行，但是要處理13中不一樣類型，還要有5種不一樣的常數值。

老王：對啊，一個泛型+一個For循環傳入參數，最多56行。

分支A

4. 小張：等一下……循環，這個我怎麼沒想到呢……還有……泛型……有道理……我想一想……來，再出一次牌

5&6. Scrum Master：X = 1 & Y = 0.5……差很少就這樣了，算1天吧。下一個。

分支B

4. 小張：等一下……循環，這個我怎麼沒想到呢……這個好理解……泛型？什麼是泛型？

若遇到了分支B，請參考敏捷開發鬆結對編程系列，能夠直接閱讀之三及之四（泛型將在「之四」提到的「前關鍵點」中由師傅傳授給徒弟），或從頭開始。