Zi 字媒體

預估 軟體專案管理中，時間預估是一項必要執行的工作，重要關係人都想知道完成這個專案「要多久？」。那為什麼需要「預估」呢？因為一般的情況下，我們通常會去做一件以前沒有做過的事，這裡指的就是去「建構一個以前沒有實做過的系統」，既然以前沒有做過，理所當然我們需要用「估算」的方法來規劃時程，這過程需要很多經驗與方法。在實際的情況下，「預估」本身就擁有曖昧的特性，因為是估算，所以估不準是正常的。 預估的誤會 在討論「預估」之前，我們先看看「預估」這個詞的定義： 對業務端而言，預估就是承諾！ 對開發者來說，預估其實是猜測！ 看來兩種角色對於「預估」有不同的定義，這下我看誤會大了！對於業務端而言，開發者告訴業務端這項工作的預估工期，一但無法如期完成，似乎變成某種程度的欺騙。但對於開發者而言，預估並沒有任何承諾的色彩，這兩者是有很大程度的差異。 然而實際上，大多數的工程師對於時間預估都是樂觀的，僅靠著詢問開發者的預估時間做為專案期程，是高風險的作法。為了盡力降低時間預估與實際的落差，因此我們需要一些方法來幫助我們。書中介紹了幾種預估方法，我選了 PERT (計畫評審技術) 與 Delphi (德爾菲法) 來與各位分享。 PERT (Program Evaluation and Review Technique) 估算法 這一種統計的概念，可以用科學的方法計算出一個比較適合的預估時間，主要透過以下三種指標來估算： O: 樂觀預估 (Optimistic Estimate) N: 常規預估 (Nominal Estimate) P: 悲觀預估 (Pessimistic Estimate) 上述三種類型的估算方法很好理解，第一種「樂觀預估」指的就是天干地支加運氣就可以完成的時間；第二種「常規預估」指的是一般正常的情況下需要的時間；最後一種「悲觀預估」就是很不幸發生種種不可預期的因素造成的開發時間。 前面也有提到「大部分的工程師都是樂觀的」，所以我們也不是直接用「常規預估」來計算時間，這樣太危險了。看來我們需要一個比較有效的統計方法來計算成果，假設 David 這位開法者對於以下三項工作的預估時間如下（開始無聊的數學時間 -_-）： 上述的「期望值」與「標準差」我們可以透過以下公式來計算： 期望值：μ = ( O + 4N + P) / 6 機率分佈標準差：σ = ( P - O ) / 6 但是三項工作若是要合併計算，可不是直接「相加」就可以，必須要稍微科學一點的方法來計算整體 (Sequence) 的期望值與標準差，公式如下：           看到數學式，先不要怕！說穿了整體期望值就是累加；整體標準差就是平方根，由此可以預估出 David 若是完成這三項工作可能需要 14 天、17 天（一個標準差）或 20 天（兩個標準差），通常超過兩個標準差算是偏離值，整體計畫通常都是 GG 收場。 Delphi 德爾菲預估法 這個方法有點像是遊戲，進行方法為找一群人一同估計每個工作的時間，集大眾之智來完成。為了避免別人的預估結果影像到自己，採用「比手指（數隻）」的方式進行。比如詢問這項工作需要多少天？倒數三秒後所有人一起比出手指！若是大家的預估都接近可以取平均值做為估算值，反之如果有某人提出比較不同的預估數，那就請他提出自己的想法，以取得共識。 比手指開始之前還有一個動作，就是事先立定計算方式，比如以各位「預估數取平均乘二」做為結果等等規則。 討論 若是採用 PERT 預估法，由於是採用統計的方式來計算預估值，找到合適的輔助工具來進行是必要的。Delphi 預估法就比較輕鬆，但是在實務上，其實不容易集聚一群開發者來進行這個預估遊戲。 無論是用什麼方法，都有風險存在，書中沒有談到專案執行人數的問題，其實專案成員的特性與數量都會影響到預估。為了盡可能降低風險，一開始將工作進行切割是個好方法，以「大數定理」的觀點來看，由很多小工作集合的預估，每個小工作的誤差對於整體的影像可以大幅降低，但是要花很多時間倒是真的。 回頭看看敏捷開發的理念，以小功能實作範圍做為規劃，以迭代的方式進行系統建構，是個聰明的方法。 參考投影片 The Clean Coder - 預估與壓力 (書摘) from 家弘 周 分享到 Twitter(在新視窗中開啟) 按一下以分享至 Facebook(在新視窗中開啟) 分享到 LinkedIn(在新視窗中開啟) 點這裡寄給朋友(在新視窗中開啟) 按一下即可分享至 Skype(在新視窗中開啟) 分享到 Reddit(在新視窗中開啟) 分享到 Tumblr(在新視窗中開啟) 按一下以分享到 Telegram(在新視窗中開啟)