為什麼軟體開發的時間難以估計?為什麼專案往往無法在預定時間內完成?
1.軟體開發的時間本來就難以估計
軟體開發本來就是個複雜的流程,除了許多複雜的邏輯與問題處理以外,
這個產業發展的速度太快,新的技術不斷的推出
使得每個專案都會遇到沒使用過的技術,沒有解決過的問題,即使是經驗豐富的開發者,
也不一定能準確的估算解決一個新的問題或技術要花多少時間.
2.軟體開發的需求,以及範圍經常變更
有許多的需求是隨著系統開發,使用者對於系統有更明確想法而產生的.
而在需求修改後,新的完成時間往往難以估算.
另外,專案開發一定必須debug,而debug的時間幾乎是完全無法預估,
許多的專案估算時間時沒有把debug與整合的時間算到專案開發時間內,
造成debug吃掉了本來應該用來開發的時間.
3.軟體開發有"技術債務",如果不維持品質,為了滿足短期交付而交出缺乏品質的程式碼,會導致後面的開發困難.
缺乏品質的程式碼的例子有:充滿大量剪貼的程式碼,許多用不到或浮誇的邏輯,
程式碼風格缺乏一致性,程式架構緊密偶合,肥大的class或頁面,沒有測試等等.
短期內這些問題並不會造成什麼嚴重的後果,但是就如"技術債務"這個詞所說的,
當這些問題沒有在發生的時候馬上處理,之後就要花上好幾倍的時間去處理這些債務.
估算專案時間的三種方法:
1:Time Base:
或稱為"Deadline Base",以專案的交付時間往回倒推.
例如說有三個月的開發時間,那麼就有2個禮拜作需求分析,2個禮拜做系統設計,5個禮拜開發,3個禮拜測試.
仔細一想就能明白,這個估算與實際上的開發內容完全無關,只是大致上的估算而已.
這種方式由來已久,並廣泛的用在各種行業與我們的生活,例如說考試前兩個禮拜要開始唸書
出國前3天要準備好護照與機票等等.
不過由於軟體開發的複雜性,這種方式並不能夠準確的估計專案的完成時間
2.Experience Base:
"經驗導向"為Time Base的延伸,基本上是去詢問工程師這個功能要做多久,
加上自己的經驗而判斷出來大概的時間,這種方式的準確度比較高,但是;
由於軟體開發的多變性與需求的變化,這並不一定能準確的估算,
而且人都有過短估計的傾向,與之相反的,
有時候這會變成"Promise Base",意思是要工程師在自己估算的時間準時交貨
但第一,估算一定與實際上要完成的時間與工作量有差距,這種估算方式就會導致
1.工程師儘量延長估算時間,避免無法完成
2.加班來達成自己的預估
3.延長完成時間以達成預估
比較好的作法是提供有彈性的預估範圍 －－ 一個樂觀預估,一個一般預估.
3.Fact Base:
就是Agile裡的Burndown Chart,將系統切分為可重覆,類似的流程,
然後以過去開發的平均時間,來估算未來的完成時間,這種方法比較接近統計學
而且:
1.可以反映出開發者的速率,經驗較淺的人會花比較多時間完成同樣的項目,而這會反映在對整個專案速率的推估上
2.可以限制專案開發的範圍,因為完成時間是以功能/功能完成時間而推估,所以減少功能=提早完成時間,這個等式變得很明顯,也可以強迫負責人找出真正重要的功能去完成.
No comments:
Post a Comment