fbpx

The Clean Coder 書摘 - 如何有效地預估軟體專案時間?

預估51BSQqef+6L

軟體專案管理中,時間預估是一項必要執行的工作,重要關係人都想知道完成這個專案「要多久?」。那為什麼需要「預估」呢?因為一般的情況下,我們通常會去做一件以前沒有做過的事,這裡指的就是去「建構一個以前沒有實做過的系統」,既然以前沒有做過,理所當然我們需要用「估算」的方法來規劃時程,這過程需要很多經驗與方法。在實際的情況下,「預估」本身就擁有曖昧的特性,因為是估算,所以估不準是正常的。

預估的誤會

在討論「預估」之前,我們先看看「預估」這個詞的定義:

對業務端而言,預估就是承諾!

對開發者來說,預估其實是猜測!

看來兩種角色對於「預估」有不同的定義,這下我看誤會大了!對於業務端而言,開發者告訴業務端這項工作的預估工期,一但無法如期完成,似乎變成某種程度的欺騙。但對於開發者而言,預估並沒有任何承諾的色彩,這兩者是有很大程度的差異。

然而實際上,大多數的工程師對於時間預估都是樂觀的,僅靠著詢問開發者的預估時間做為專案期程,是高風險的作法。為了盡力降低時間預估與實際的落差,因此我們需要一些方法來幫助我們。書中介紹了幾種預估方法,我選了 PERT (計畫評審技術) 與 Delphi (德爾菲法) 來與各位分享。

PERT (Program Evaluation and Review Technique) 估算法

這一種統計的概念,可以用科學的方法計算出一個比較適合的預估時間,主要透過以下三種指標來估算:

    • O: 樂觀預估 (Optimistic Estimate)
    • N: 常規預估 (Nominal Estimate)
    • P: 悲觀預估 (Pessimistic Estimate)

上述三種類型的估算方法很好理解,第一種「樂觀預估」指的就是天干地支加運氣就可以完成的時間;第二種「常規預估」指的是一般正常的情況下需要的時間;最後一種「悲觀預估」就是很不幸發生種種不可預期的因素造成的開發時間。

前面也有提到「大部分的工程師都是樂觀的」,所以我們也不是直接用「常規預估」來計算時間,這樣太危險了。看來我們需要一個比較有效的統計方法來計算成果,假設 David 這位開法者對於以下三項工作的預估時間如下(開始無聊的數學時間 -_-):

圖片3

上述的「期望值」與「標準差」我們可以透過以下公式來計算:

    • 期望值:μ = ( O + 4N + P) / 6
    • 機率分佈標準差:σ = ( P - O ) / 6

但是三項工作若是要合併計算,可不是直接「相加」就可以,必須要稍微科學一點的方法來計算整體 (Sequence) 的期望值標準差,公式如下:

     a_es    u_es

看到數學式,先不要怕!說穿了整體期望值就是累加;整體標準差就是平方根,由此可以預估出 David 若是完成這三項工作可能需要 14 天、17 天(一個標準差)或 20 天(兩個標準差),通常超過兩個標準差算是偏離值,整體計畫通常都是 GG 收場。

Delphi 德爾菲預估法

這個方法有點像是遊戲,進行方法為找一群人一同估計每個工作的時間,集大眾之智來完成。為了避免別人的預估結果影像到自己,採用「比手指(數隻)」的方式進行。比如詢問這項工作需要多少天?倒數三秒後所有人一起比出手指!若是大家的預估都接近可以取平均值做為估算值,反之如果有某人提出比較不同的預估數,那就請他提出自己的想法,以取得共識。

比手指開始之前還有一個動作,就是事先立定計算方式,比如以各位「預估數取平均乘二」做為結果等等規則。

討論

若是採用 PERT 預估法,由於是採用統計的方式來計算預估值,找到合適的輔助工具來進行是必要的。Delphi 預估法就比較輕鬆,但是在實務上,其實不容易集聚一群開發者來進行這個預估遊戲。

無論是用什麼方法,都有風險存在,書中沒有談到專案執行人數的問題,其實專案成員的特性與數量都會影響到預估。為了盡可能降低風險,一開始將工作進行切割是個好方法,以「大數定理」的觀點來看,由很多小工作集合的預估,每個小工作的誤差對於整體的影像可以大幅降低,但是要花很多時間倒是真的。

回頭看看敏捷開發的理念,以小功能實作範圍做為規劃,以迭代的方式進行系統建構,是個聰明的方法。

參考投影片

  3 comments for “The Clean Coder 書摘 - 如何有效地預估軟體專案時間?

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料