英文原文：Technical Debt a Perspective for Managers
作者：Mark Levison 譯者：賴勤毅 發布于 2010年11月5日
現在已經到第十次迭代開發周期了，你的項目開發速度開始變慢。在之前的幾個迭代周期中，團隊沒有像以前那樣完成很多的“故事場景”（stories）。此外，最近在新的故事場景和回溯中卻發現更多缺陷(bug)。項目經理知道，團隊成員沒有變，他們也花同樣的時間工作。但是，客戶會發問：“發生什么事情了？這個團隊還在努力工作嗎？”
很多敏捷團隊的產品改進率為150-500%，可是你們的項目看起來卻貌似只有20-40%左右的改進率。這到底是怎么回事呢？在此我們找不到什么大問題；相反，只是有無數的小問題。有時，這些只是一些為了方便而使用的捷徑（開發人員沒有時間去清理這些修改），有時開發人員僅僅是不熟悉這中語言。還有一些問題就是，代碼跟灌木叢一樣凌亂，需要大幅度的修整。所有這些都屬于“技術債務”。
什么是“技術債務”？
它就是“那些內在的事物，現在你不去解決，遺留下來（不干完），它就會阻礙未來開發”[Ward Cunningham]。 表面上，應用程序看起來質量很高且狀況良好，但是這些問題卻隱藏在下面。 QA（質量保證部門）甚至可能告訴你說，這個應用程序真是不錯，幾乎找不到缺陷，但是其中仍然存在“技術債務”，如果我們沒有很好地管理并設法降低這些“技術債務”，那么，程序編寫和維護的代價最終將會超過它對客戶的價值。
技術債務就像信用卡一樣，會有很高的利息率，就如同給團隊留下了大量的帳務開銷。這種情況下，開銷將會體現在時間花費和解決問題所需的努力上面。開發團隊拖延債務的時間越長，所積累的利息就越多（會額外增加很多工作），付出的成本也就越高。
另外，這還增加了實際的財務支出：開發團隊處理技術債務所花費的時間，可以用在對團隊有價值的其它工作上。同時，這些難讀的代碼引起的技術債務也讓我們難以找到軟件的缺陷。再且，理解代碼所損失的時間還可以用來做其它更有價值的事情呢。
我們為何要累積技術債務呢？
項目編碼初期，不整理代碼，不寫單元測試，也不做測試驅動開發，整個團隊粗制濫造出更多的“故事場景”。 這些問題通常都不會馬上暴露出來，而循規蹈矩地編寫代碼往往需要更多的時間，特別是在早期階段。
技術債務來自哪里？
- 沒有經驗的開發人員 —— 有些項目里面，編寫Java/C#/Ruby的開發人員沒有接受過培訓，或者沒有面向對象的觀念。結果呢，他們會一直編寫適用于他們曾經習慣的編程語言——像Visual Basic等——的代碼。
- 項目工期的壓力 —— 那些來自于經理或客戶的顯性壓力和其它一些潛在的壓力。“我們承諾在以后迭代（發布）的故事場景中做到這些”。開發團隊會發現他們不會交付這些承諾的發行版本（迭代版本），而是采取便捷的手段。“我們不得不把事情做完；我們無法承擔修整代碼所耗費的時間。如果這不是新特性/缺陷，那么就不用去做”。 不幸的是，這些觀點還會得到管理人員的支持，特別是在管理層沒有意識到這些成本的時候。
- 凌亂而難讀的代碼。當一個方法或類中存在一些難讀的代碼，下一個開發人員繼續這些工作的時候，就覺得他也沒有必要迫使自己編寫清晰的代碼。所以，每次有人接手這些代碼的時候，一小段臟亂的代碼將會變成一大堆亂七八糟的代碼。
- 專業領域的代碼 —— 往往有這樣的觀念：這些代碼看起來就是很差勁，但是這不屬于我的領域，所以我不能或不會改變它們。另外，對于修改專業領域的代碼，開發人員也會覺得力不從心。
- 過度復雜 —— 開發人員經常趨向于在需求之前設計解決方案。而且，很多情況下他們的代碼沒有找到正確的方向，還會寫一些沒有用處的代碼。或者，這些代碼沒有真正地符合需求，因為代碼在問題還沒有完全明白的時候就已經寫完了。還有另外一種情況，過度設計花費了額外的時間，產生的代碼不是不能使用就是不符合項目的需求。
- 糟糕的設計 —— 有些解決方案只是設計不佳。但在設計不好的代碼上面繼續擴展，而不去解決這個問題，會使問題更加惡化。
解決問題
這個問題的并不是一下子可以解決的，解決方案需要通過幾個迭代周期。并且，你需要耐心，并要從多個角度尋找解決途徑。
解決方案中的要點
- 讓開發人員接受語言方面的基本培訓并教授他們面向對象的原理，從而把他們的理解力提升至入門階段。要想既成功又有效的話，這需要花幾個禮拜的時間培訓，還需要有精通這方面的人員來跟進和支持這一系列培訓。
- 告訴開發人員和管理人員，當前的這些問題都是需要花費企業資金的。這點尤其重要，因為它會使解決這些問題的意義更加明確。你要清楚地告訴他們，管理人員會重視這些問題，并且已經開始著手償還這些技術債務了。不斷支持這些工作使之成為常規的原則之一，這樣整個團隊就會信任這個準則。
- 提供一些培訓，包括代碼的壞味道，重構，單元測試和測試驅動開發等。還可以結合課堂會議，基于網絡的材料和書籍來進行培訓。
- 在工作的時候，給他們一些空余時間去研究和練習他們的技能（一個禮拜兩個小時應該是達成這個目標的最小的時間量）。練習的代碼應該被丟棄，這樣，他們就能無拘無束地嘗試和試驗一些事情，不管怎么樣，他們不用在基礎代碼庫上面進行練習。花點時間練習和研究應該是最有用的建議了。假如沒有為他們提供空閑的時間，就壓根不會發現真正合理的敏捷開發方式。這種組織方式也被稱為“道場”-Dojo（更加詳細的資料可以參考 TDD Randori Session 和 TDD Randori Workshop）。
- 使用工具（靜態分析，單元測試，持續集成，自動化可接受性測試）來幫助團隊發現、減少和衡量他們的技術債務量。應該在團隊層面利用這些度量數據，而不能分享給管理人員。團隊成員需要知道，他們并不會因為對這些技術債務的度量而接受獎勵或者遭受懲罰。如果我們把這些度量數據報告給管理層，并由管理層來追蹤的話，開發人員很快會找到一些竅門來規避它們，這樣就失去了本來應有的價值了。
- 當人們完成了他們的培訓或者在技術上取得了少許提升時，應該得到獎勵。獎勵可以是給予一次認可的表彰或者是一些小小的禮物，但不要直接給予現金獎勵。
- 每兩個禮拜進行一次午餐聚會和一些關于技術方面的學習型會議。利用這些會議來促進開發成員之間的討論。提供午餐可以提高參會人數。另外比較重要的是需要管理人員每次都來出席，這樣就很清楚的表明他們也一直支持大家提高技術。
- 維護關于技術債務的備忘錄 – 任何時候，如果開發人員發現一些無法立即應付的技術債務時，就需要填寫一份技術債務登記卡。開發人員應該優先考慮這些技術債務，并花費10-15%的精力來償還這些技術債務。大多數項目中，任何的一些小事都會使問題變得更加嚴重。
基于這樣的立場，你會發現問題，也會擁有機會。你的問題是：項目的基礎代碼一直在積累技術債務，但是這些債務已經開始下降了。然而，現在跟客戶申請用于處理這些問題的資金會跟處理這些問題一樣困難。你的機遇是：提高了開發人員的技能；清楚地表達了管理層對這項工作的支持，還有，軟件的代碼質量會不斷改善，軟件缺陷的數目也會不斷減少。同時這也會很好的提高團隊的整體開發能力。