Posted on 2010-12-23 23:55
mingj 閱讀(6412)
評論(2) 編輯 收藏 所屬分類:
agile 敏捷 、
PM 項目管理
作為技術人員，我們經常需要跟客戶、業(yè)務分析人員等非技術人員溝通軟件設計方面的問題。如何比較直觀地向這些非技術人員解釋設計、軟件質量對項目的
影響，解釋糟糕設計、不干凈代碼給項目帶來的風險，解釋我們必須開始關注軟家設計問題？這里有兩個概念（metaphor）可以幫助我們達到這一點：
技術債（Technical Debt）
“技術債”指的是，團隊為了更早交付軟件、更快交付客戶價值或者其他一些考慮，被迫放棄良好的設計和干凈的代碼，從而對軟件未來的擴展和維護欠下了“債
務”。技術債就像財務上的欠債一樣，在前期債務較少的時候，投入時間和精力來解決技術債或許不如盡快交付的價值高。但隨著債務的增多，必然會影響新需求的
交付和既有代碼的維護，反而會延遲軟件的交付。而且，技術債也具有財務債的特點，就是隨著時間會像“滾雪球”一樣指數(shù)上升。
設計償還底線（Design Payoff Line）
與技術債對應的的概念是設計償還底線（Design Payoff Line），指的是可以通過犧牲設計質量來獲得上市速度（Time to
Market）的功能數(shù)量。當系統(tǒng)功能少于這個數(shù)量時，我們還能繼續(xù)選擇承擔債務，但一旦超出這個數(shù)目時，債務就將影響軟件的上線速度。可惜的是，這個值
更多的是一個經驗值，團隊很難預判項目的設計償還底線在哪里，但是有一個后置評判標準是：當團隊成員覺得無法忍受代碼的設計質量時，或者當客戶頻繁聽到代
碼質量影響交付速度時，團隊肯定已經突破了這條底線。