許多團隊都受技術債務困擾，不過，很少有團隊能真正地設計乙個計畫從中掙脫出來。為了更好的理解如何才能擺脫債務，我們首先要正確地理解什麼是技術債務。
技術債務是由團隊為了短期的專案利益故意做了欠佳的技術決策而招致的。例如，為了使乙個產品更快的投放市場，團隊可能不會像面對一段棘手的**那樣，編寫深入的自動化測試。或者，他們可能會決定基於乙個很快就會過時的框架構建專案，而不是花錢購買那個框架的乙個經過公升級、服務支援更好的版本。不管決策是什麼，關鍵是要認識到，真正的技術債務是團隊為了獲得短期利益故意做了會招致長遠債務的決策。
這意味著，許多我們通常歸咎於「技術債務」的事情實際上根本就不是債務。例如，隨著系統使用年限增加，團隊會無法一直保持最佳編碼實踐，在那種情況下出現「位衰減（bit dot）」是正常的，不是債務。或者，團隊自願做出的技術決策在隨後實現時竟然發現是不正確的，這也不是技術債務。在任何一種情況下，團隊都不是為了獲得短期利益而故意做了欠佳的長遠決策。這種差別很重要，因為我們只有在究竟是什麼組成了技術債務的問題上達成一致，我們才能針對如何減少技術債務做出最佳決策。
考慮我們在無意間引入**庫的債務所帶來的影響也很重要。不過，由於這類債務不是有意承擔的，所以我們無法計畫如何提前解決它。在這些情況下，我們一定要在發現的時候優先考慮並解決這種債務……就像團隊解決新發現的bug所做的那樣。
我們經常將技術債務與金融債務進行對比。但是，這是乙個對等的模擬嗎？比如，如果不首先確定何時以及如何償還，銀行真會願意借給我們錢嗎？很可能不願意。既然不首先描述如何償還債務，我們就確實無法借到金融資本，那麼我們也就不應該以這種方式對待技術資本。
這個金融比喻確實非常有效，因此，我們將對它進行更充分的討論。
償還計畫
正如金融債務一樣，在談論技術債務時，我們需要確定兩件事：如何償還債務和何時償還債務。
讓我們以前文提到的放棄自動化測試為例。如果為了一項功能能夠盡快投入生產環境，我們的團隊自願決定放棄為棘手的**段編寫自動化測試，那麼我們需要確定我們將如何糾正那塊債務。在這種情況下，我們只需要表明，我們會在將來的某個時點回到這段**，然後新增測試。不過，只表明「我們將在稍後新增測試」並沒有合理地解決這個問題。為了幫助干係人真正地了解我們的決策對招致技術債務會有多大的影響，我們需要盡我們最大的能力準確地說明等到後來新增自動化測試的影響。比如，我們應該指明需要新增測試的**段。我們也需要明確指出，在已有的**段上增加自動測試比在**段建立時直接新增測試總是難度更大成本更高。最後這點很重要，因為它明確指出，將這項工作推遲到後來完成，我們實際上要比現在直接完成花更多的錢來做這項工作。換句話說，……債務是會產生利息的。
在討論完償還方式之後，團隊及其干係人可能會意識到，這個問題要比他們是否應該在編寫**時編寫自動化測試更複雜。實際上，他們可能會發現，在兩個極端之間，他們確實有多種更適合整個專案的選擇。比如，他們可能會決定，使用類似「
圈複雜度（cyclomatic complexity）
」這樣的指標識別出新特性中最複雜的部分是非常有意義的，並立即新增測試覆蓋那些方面，而把簡單一些的方面推遲。或者，他們可能會決定，像單元測試這種更簡單但同時價值也更低的自動化測試型別可以立即新增，但像自動化使用者驗收測試這種難度更高的自動化測試可以推遲到將來的衝刺中。不管是哪種決定，團隊及其干係人都不大可能做出，因為他們沒有在第一時間對技術債務進行討論。
除了指明如何償還債務外，我們還希望指明何時償還債務。通常，債務越早償還越好。出於這個原因，最好是在債務產生的時候安排債務償還工作，以便更好地傳達承擔債務的影響。比如，如果你的團隊遵照乙個由衝刺構成的時間表，那麼你可能會選擇將工作安排到下乙個衝刺，或者，在最壞的情況下也不超過幾個未來的衝刺。
通常，團隊都會有最美好的願望，就是在債務出現的時候償還，但他們只是似乎從來都沒有時間那樣做。當你要消除債務的時候，在日曆上記下最後償還期限，並堅持按時完成。
對於我們的金融比喻，最後一部分是弄清楚，如果我們選擇拖欠債務，會出現什麼後果。在金融領域，如果我從來不償還汽車貸款，那銀行會開走我的汽車。拖欠技術債務的後果同樣應該明確指出。
讓我們繼續自動化測試的例子，如果團隊決定不償還技術債務，那麼以現有的未經測試的功能為基礎構建新功能只會使難度越來越大成本越來越高。在生產環境中，我們可能會看到更多的bug報告，這意味著，客戶可能會對我們的產品質量產生不好的印象。我們快速響應市場變化的能力也會被削弱，因為我們產品的很大一部分要麼很難快速修改，要麼快速修改風險太大。
上述各點都需要向干係人講清楚，幫助我們避開技術債務違約的**。
截至目前，我們討論的所有內容都集中在有計畫的技術債務上，就是那些作為正常專案的一部分團隊故意招致的債務，而如果我們不討論未計畫的技術債務，我們就失職了，因為它們也困擾著許多專案：位衰減。
如前所述，位衰減不是我們故意招致的，我們無法提前決定如何以及何時償還，在這個意義上，它不同於正常的技術債務。不過，雖然我們無法確切地知道位衰減在我們專案中的呈現形式，但這並不意味著我們無法計畫它。
就像我們計畫償還已知技術債務時所做的那樣，我們也可以在我們的專案計畫中加入乙個緩衝區，用於在每次衝刺中處理位衰減。雖然那時可能並不知道填充這個緩衝區的具體任務，但有乙個這樣的緩衝區在那裡，使我們有了乙個專門的空間，可以應對那些未計畫的問題，如bug，必須立即處理的小規模重構，或者我們稱之為**庫自然老化和衰減的小塊系統維護。
但是，對於那些用幾個小時的開發時間都無法解決的更大的問題，該怎麼辦？可能會有更多讓我們倍感困擾的系統性問題，如基礎設施故障或架構日益老化無法再滿足業務需求。由於這些問題太大，不容易解決，我們就可以使用這個緩衝區確認和研究這些問題，那樣，我們後續就可以在專案中給予它們應有的注意。比如，在基礎設施故障的情況下，或許我們能夠確定基礎設施中最經常出現故障的部分，那樣我們就可以在待辦事項列表中增加故事，用於替換這些部分。然後，我們會在正常的開發中排定優先順序並照此排程那些故事。或者，在架構日益老化的情況下，我們可以花些時間來確定，我們對於架構能夠動態做出的最有價值的修改是什麼，然後將那些修改分解成可以在將來的衝刺中分段處理的故事。不管問題是什麼，有時間確定問題並制定計畫就意味著可以像解決其它任何技術問題一樣解決它。
既然我們已經對招致技術債務的影響有了乙個更好的了解，那麼我們該如何真正確保償還技術債務？為了對此有乙個感官的認識，我們將上述金融比喻向另乙個方向擴充套件……預算。
我們中有許多人每隔幾周就會掙得乙份固定工資。這份工資是年度工資的一部分，全年平均分布。比如，如果我們每年能掙52000美元，那麼我們可能每隔2週就會收到2000美元……就是說，每年26次。
不過，雖然按規則我們每次都能領到2000美元工資，但我們實際上不大可能全部存放在活期賬戶上。相反，我們更可能只將一部分存放在活期賬戶上，而把其它部分用於長期投資或者償還債務。比如，我們起初有2000美元存款，預算分解實際上可能是下面的樣子：
現在，雖然沒人對這種安排感到特別興奮，但也基本沒人質疑。在某種程度上，它簡直是公認的規範。既然這種安排被如此廣泛地接受，那麼為什麼不將它擴充套件到我們的專案計畫中呢？
想象一下，我們正以故事點為單位計畫一次衝刺，並且，我們為那個衝刺分配了50個故事點。儘管我們希望將所有50個點都用在新的開發上，但實際上，最合理的方式是安排一些點用於償還技術債務。比如，對於原有的50個點，我們可能決定安排：
看看我們的點預算，我們可以看到它與我們前面描述的金融預算有一些明顯的相似之處。雖然每個衝刺我們有50個點用來做事，但並不是所有那些點都用在新的開發上。更確切地說，我們必須把那些點中的10個用於償還我們有意招致的技術債務，正如我們把工資的一部分用於償還我們的長期和短期債務。此外，我們將5個點完全用於保持不間斷的**庫維護，正如我們把每份工資的一部分用於稅收，幫助維持我們社群的正常運轉。剩下的點是我們自己的，可以根據我們的意願用於任何新的開發，正如剩下的錢存入活期賬戶，我們可以根據自己的意願自由支配。
通過工作預算的方式，我們可以確保我們的專案仍然在向前進行，而不允許它在技術債務的重壓之下崩潰。
當然，就像個人預算一樣，這種預算會有些偏差。比如，如果我們償還技術債務的速度比預期快，那麼我們就會有些剩餘的故事點可以用在新功能開發上。而同樣的，如果我們發現我們承擔著特別多的技術債務，那麼我們可能需要稍微降低新功能的開發速度，直到技術債務的數量回到乙個更可控的水平。
通過以金融債務做模擬考慮技術債務，我們可以對什麼時候會招致技術債務有乙個更明智的判斷，有利於專案改善。在專案進行過程中，我們還可以更好地計畫試圖償還債務所帶來的影響。
而且，通過在日常工作中計畫日常預算，我們可以更好地了解我們的債務什麼時候是可控的以及什麼時候會讓我們負擔過重。
DevOps 和技術債務償還自動化
當企業想要遷移到乙個 devops 模型時，經常需要償還高等級的技術債務 說得更明確一點，機構往往陷入 技術債務的惡性迴圈 中，以至於任何迅速 敏捷的遷移方式都無法使用。這是技術債務中的希臘債務危機水平。在多數情況下，機構會將層與層之間的流程和管理新增到軟體開發生命週期，從而緩解低質量版本 生產等級...
技術債務？管理債務？
昨天晚上重要客戶再次投訴。這已經是最近幾個月的第三次投訴了！當年為了爭客戶，給客戶迅速開發了跨越三個系統的定製需求。客戶爭到了，這個快速的定製需求就一直當正式工具被用起來。這是第三年了，這個定製功能一直在找麻煩，甚至有可能丟到客戶。昨天晚上是因為其中的乙個系統切換到備份，但是其他系統不認識備份系統的...
解析技術債務
原文 術語 技術債務 是由ward cunningham 首次提出，指的是開發團隊在設計或架構選型時從短期效應的角度選擇了乙個易於實現的方案，但從長遠來看，這種方案會帶來更消極的影響，亦即開發團隊所欠的債務。敏捷專家們就技術債務到底是什麼以及如何對其進行分類給出了自己的看法。martin fowle...