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

這是敏捷開發一千零一問系列的第三十篇。（在這裡提問，之一，之二，之三，問題總目錄）

續前文，預計未來還要有一篇，暫時做為中篇。

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

這個在之前談到過很多次了，具體可以參考敏捷開發績效管理系列的之六、之七。另外在敏捷開發使用者故事分類與組織圖（一期） （整個活動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.53. 老王：最多一個小函數55行就可以了啊，為什麼要那麼多天？    小張：一個函數是55行，可是要處理13中不同類型，還要有5種不同的常數值。    老王：對啊，一個泛型+一個For迴圈傳入參數，最多56行。分支A4. 小張：等一下……迴圈，這個我怎麼沒想到呢……還有……泛型……有道理……我想想……來，再出一次牌5&6. Scrum Master：X = 1 & Y = 0.5……差不多就這樣了，算1天吧。下一個。分支B4. 小張：等一下……迴圈，這個我怎麼沒想到呢……這個好理解……泛型？什麼是泛型？若遇到了分支B，請參考敏捷開發松結對程式設計系列，可以直接閱讀之三及之四（泛型將在“之四”提到的“前關鍵點”中由師傅傳授給徒弟），或從頭開始。

本人正在參加CSDN部落格之星評選，如果您經常來本部落格閱讀或曾經下載《火星人敏捷開發手冊》，歡迎投票（需要登入）：

http://vote.blog.csdn.net/item/blogstar/cheny_com

每人可以為10個博主投票，所以如果看到其他常去拜訪的博主，也請投上一票！