我目前正在使用一個相當古老的產品，這個產品在過去一直受到來自差的程序員和不良開發實踐的大量技術債務的困擾。我們正在開始變得更好，技術債務的創造已經大大減緩。您如何估算清除技術債務的投資回報率？
我已經確定了形狀不好的應用領域，我可以估計修復這些區域的成本，但是我很難估計投資回報率（ROI）。
該代碼將更容易維護，將來更容易擴展，但我怎麼能把這些美元數字？
一個好的開始看起來像回到我們的錯誤跟蹤系統，並根據與這些「壞」區域相關的錯誤和功能來估計成本。但這看起來很耗時，可能並不是最有價值的預測指標。
有沒有人在過去進行過這樣的分析，並對我有任何建議？
經理們關心通過增長（首先是吸引新客戶的新功能）和通過優化流程生命週期來實現（第二）。你的問題
看，你的提案在第二類：這無疑將落後目標＃1（從而得到優先下來甚至，如果這可以節省錢......因爲省錢意味着花錢（大部分時間至少;-)）。
現在，把「壞技術債務」的美元數字轉化爲一個更積極的轉折點（假設以下情況適用於您的情況）：「如果我們投資修復組件X，我們可以快速引入特徵Y，從而讓Z更多的客戶「。
換句話說，評估技術債務的成本與商業機會損失成本。
我認爲你是在正確的軌道上。
我還沒有計算這個數據，但是我和一位管理着大量軟件開發組織的朋友進行了一些討論，這些組織有很多遺留代碼。
我們討論過的一件事是通過分析VCS提交併使用它們來劃分程序員小時的粗略估計來生成一些粗略的工作量度。這受到Joel Spolsky的Evidence-based Scheduling的啓發。
做這樣的數據挖掘可以讓你識別代碼被維護時的集羣，並將它跟蹤系統中的bug完成進行比較（除非你已經有幸在兩個精確記錄之間緊密集成）。
合理的投資回報率需要計算的全額返還，所以有些事情要考慮的是： - 維護（顯然）的成本下降 - 機會成本的停機時間的企業或錯過了不能及時補充新功能該剝離 - 能力產生由於重構
記住，一旦你有導出數據的規則，你可以有究竟如何計算的事情爭論，但至少你有一些新產品線數字種子討論！
你可以詳細說明如何根據提交生成工作量估計嗎？是否像開發人員提交A和提交B之間的時間差異是對提交B的粗略努力？ – StevenWilkins 2009-11-24 14:51:06
是的，（我確實說過「粗糙」） - 簡單地回顧已知工作日的提交時間。 – 2009-11-24 22:26:32
在一個歷史悠久的大型代碼庫上，像這樣的統計方法應該合理估計。當然，你的確需要知道人們可以在什麼程度上投入時間進行項目，但這是一個簡單的時間序列分析，可以在人們查看數據時進行細化。 （「嘿，我當時正在度假，五月份每週工作30小時在FizzBuzz 2.0上」）。 – 2009-11-24 22:30:04
作爲一個大部分單獨或小團隊的開發人員，這不在我的領域，但對我來說，一個很好的解決方案來找出時間浪費在哪裏是非常非常詳細的計時，例如使用一個方便的任務欄工具this one甚至可以在去廁所時過濾出來，並且可以將所有內容導出到XML。
起初這可能很麻煩，而且向團隊介紹也是一個挑戰，但是如果您的團隊每隔15分鐘就能記錄一次由於軟件中的錯誤，錯誤或誤解而花費的時間，那麼您將積累一個令人印象深刻的基礎，關於哪些技術債務實際上每個月在工資上花費的實際數據。
我鏈接到的工具是我的最愛，因爲它非常簡單（甚至不需要數據庫），並通過任務欄圖標提供對每個項目/項目的訪問權限。還可以在那裏輸入關於所進行的工作的額外信息，計時在幾秒鐘內即可激活。 （我不隸屬於供應商。）
Sonar有一個很棒的插件（technical debt plugin）來分析你的源代碼來尋找這樣一個指標。儘管你可能沒有特別的能力將它用於你的構建，因爲它是一個maven工具，它應該提供一些很好的指標。
這裏是他們的算法的一個片段：
Debt(in man days) =
cost_to_fix_duplications +
cost_to_fix_violations +
cost_to_comment_public_API +
cost_to_fix_uncovered_complexity +
cost_to_bring_complexity_below_threshold
Where :
Duplications = cost_to_fix_one_block * duplicated_blocks
Violations = cost_to fix_one_violation * mandatory_violations
Comments = cost_to_comment_one_API * public_undocumented_api
Coverage = cost_to_cover_one_of_complexity *
uncovered_complexity_by_tests (80% of
coverage is the objective)
Complexity = cost_to_split_a_method *
(function_complexity_distribution >=
8) + cost_to_split_a_class *
(class_complexity_distribution >= 60)
可能更容易估計它已經花費你過去量。一旦你這樣做了，即使你的老闆能理解，你也應該能夠用範圍和邏輯來得出對未來的估計。
這就是說，我對這種事情沒有太多經驗，只是因爲我從來沒有見過一位經理願意爲此修改代碼。當我們必須修改錯誤的代碼時，它總是我們修復的東西，所以重構實際上是所有修改和錯誤修復的隱藏代價。
+1對於jldupont專注於失去的商業機會。
我建議考慮管理層認爲的那些機會。他們認爲什麼影響收入增長 - 新功能，上市時間，產品質量？將債務支付與這些驅動因素相關聯可以幫助管理層瞭解收益。
專注於管理理念將幫助您避免錯誤的計數。投資回報率是一個估計值，並不比在其估計中做出的假設更好。管理層只會懷疑數量上的爭論，因爲他們知道某處存在某種定性。例如，在短期內，您的債務支付的實際成本是程序員沒有做的其他工作，而不是這些程序員的現金成本，因爲我懷疑您會爲此僅僱用和培訓新員工。未來開發時間或質量的改進是否比這些程序員要添加的功能更重要？
此外，請確保您瞭解產品的管理範圍。如果管理層從現在開始沒有考慮兩年，他們將不會關心18個月內不會出現的福利。
最後，反思一下這樣一個事實，即管理層的看法讓產品首先進入這個狀態。什麼改變了會使公司更注意技術債務？如果差異是你 - 你是一個比你的前任更好的經理 - 記住你的管理團隊不習慣考慮這件事。你必須找到他們的胃口，並專注於那些將提供他們關心的結果的項目。如果你這樣做，你會獲得可信度，你可以用它來讓他們考慮進一步的變化。但是，對增長的欣賞可能會持續一段時間。
我只能說如何在迭代和增量過程中憑經驗做到這一點。
您需要收集指標以評估您的最佳成本/故事點。據推測，這表示你的系統剛剛在最初的架構流失之後，當時大部分的設計試驗和錯誤已經完成，但是熵最少時間導致衰減。在速度/團隊規模最高時找到項目歷史記錄中的點。將此用作您的成本/點基線（零債務）。
隨着時間的推移，隨着技術債務的累積，速度/團隊規模開始減少。這個數字相對於您的基線的百分比減少可以被轉化爲在每個新故事點上支付的「利息」。 （這實際上是利息支付技術和知識債務）
紀律重構和退火導致技術債務的利息穩定在某些價值高於您的基準。將此視爲產品負責人在系統中的技術債務上支付的穩態利息。 （同樣的概念適用於知識債務）。
一些系統達到每個新故事點的成本+興趣超過正在開發的特徵點的值的程度。這是系統破產的時候，現在是從頭開始重寫系統的時候了。
我認爲有可能使用迴歸分析來消除技術債務和知識債務（但我沒有嘗試過）。例如，如果您認爲技術債務與一些代碼指標密切相關，例如代碼重複，您可以確定由於技術債務與知識債務而支付的利息增加的程度。
（+1）我做了一次這樣的事情。如果我們不處理當前的技術債務，我基本上會考慮客戶的需求，這是我們無法實現的。我還展示了一個新功能（我能夠快速介紹），並展示如果我可以重構和重新構建源代碼，我該如何做得更多。它運行得非常好，結果程序更好，客戶和內部用戶都對結果感到滿意。 – JasCav 2009-11-24 15:01:42
@jason：確切！通過對這種情況進行「積極的轉動」來吸收「壞消息」總是比較容易的......轉動桌子！ – jldupont 2009-11-24 15:07:00
我明白了，所以你應該看看我們產品的路線圖（每個功能應該有一個估計的投資回報率）。然後估計清除技術債務會對未來特徵的ROI產生多大影響並報告？ – StevenWilkins 2009-11-25 15:08:32