[獨自murmur]品質與開發時間的平衡

  • 7050
  • 0

[獨自murmur]品質與開發時間的平衡

 

最近公司開始在推廣CI( Continuous Integration,持續整合),
(CCNet、NAnt、SourceMonitor、Simian、NUnit、NCover、FxCop、Fortify等等...)

強調即時發現錯誤或可疑的癥狀,越早發現錯誤,修正錯誤的成本最低。

最終目的,當然就是產出較高品質的系統,
同時在提升品質時,透過auto build,縮短defact發現時間,來降低相對付出的成本。

不過,在追求高品質系統的過程中,所有成員還是應該對Report上的指標、issue有著一定的認識和瞭解。

時程、進度與品質(或產品)一向是專案管裡的三個平衡角,
不會因為有了CI,這三個角的平衡就獲得了救贖。

軟體快速開發』(Rapid Development)裡,第四章有講到一個『品質保證原則』,
裡面引用了Capers Jones的Applied software measurement: global analysis of productivity and quality一張圖

QualityAndDevelopTime

 

這張圖的解釋是,
其實軟體品質在95%以前,為了提升品質,品質越好,其實對總體開發時間(當然包括維護),花費的時間是更少的。


這代表,在品質達到95%以前,為了提升品質所投資的開發時間成本是值得的,
這代表以往為了治標,使得大樓越蓋越歪,一層疊過一層的掩飾系統內部腐敗的作法,之後維護一定要付出更大的代價。

然而,
這張圖的另一個重點,在於品質95%~100%的這個區間,
為了達到最後5%的完美品質,所要花的額外開發時間成本,可能是原本的一倍。

有了CI產出的Report,大家都想做到完美,
但是這樣的追求完美,也應該要有個漲停損點來克制自己對品質的慾望,
追求品質的過程中,仍然要有取捨。

擔心在未來的專案(尤其是專案...)開發過程中,
大家追CI Report追得很開心,原本20/80法則,可以用20%的時間,完成80%的進度,
最後卻花了20%+80%+100%的時間,只完成了不到100%的進度,
最後進度趕不及,出不了貨。

已經完成了專案60%,品質100%的進度,
跟已經完成專案100%,品質90%的進度,
兩種結果的選擇....請負責人一定要掌握住自己希望的結果。

巧婦難為無米之炊,每個人一天也只有24小時,
大家都有心把系統做好...
希望不會發生,最後在成本的轉嫁過程,是導致專案失敗,開發團隊士氣低落,
最後反而CI擔上了這個罪名上...


blog 與課程更新內容,請前往新站位置:http://tdd.best/