抉擇在需求與平衡
軟體開發的成本如何計算？怎樣的人力與時程安排才合理？這是大部份組織都關心的問題。功能點分析方法自1970年代開始發展，目前已經成為ISO標準，軟體業界的基準(Benchmarking)資料，例如生產力、錯誤密度等度量，普遍地以功能點為基礎計算。要與國際接軌，使用功能點似乎是一個必要的選擇。然而對於敏捷式開發方法，故事點是普遍採用的規模計算單位，主要的原因是”簡單”。
依據研究資料，訓練過的功能點分析估算人員，他們間的估算誤差可以落在10%左右。能夠得到這樣的精確度，可想而知功能點的估算方法必定要很嚴謹，才能避免主觀認知的誤差。嚴謹代表著計算難度高，有一定的門檻；反觀故事點的計算方法或許不在意精準度有多高，只要能累積每個反覆(Iteration)或衝刺(Sprint)的經驗，加上固定的團隊成員，估算的準度是可以有效提升的。
以下為兩種典型方法的比較。你要選擇哪一種方法？就要衡量得失，看看自己的需求是什麼。當然，兩種方法都使用，相互比較結果，也是符合估算的原理的。
思辨顧問的軟體專案估算實作研習課程會介紹這兩種估算方法，請參考課程說明。
Function Points 與 Story Points 比較
| 特性 | Function Points (功能點) | Story Points (故事點) |
|---|---|---|
| 在專案層級的估算與規劃是否有用(Useful) | 具備歷史FP資料時 | 具備歷史SP資料時 |
| ISO/標準 | ISO 20926 | 否 |
| 擷取客戶觀點 | 預期的(Expected) | 絕對的(Definitely) |
| 與公司外的基準比較(Benchmarking) | 可能 | 較不可能 |
| 容易計算 | 較不容易 | 容易 |
| 容易驗證重現性與一致性 | 較可能 | 較不可能 |
| 客觀性 | 較客觀 | 較不客觀(團隊/團隊成員存在易變性) |
| 獨立於所使用的開發技術 | 是 | 可能 |
| 對客戶的功能性度量(Functional Measurement) | 是 | 不全然[可能包含重構(refactoring)、設計、與其它工作] |
Joe Schofield, Size – The Forgotten Measure; SEPG North America; Albuquerque, N. M.; March 15, 2012
Recent Comments