對于所有需要進行技術債務管理的開發組織來說，這都是一個巨大的挑戰，技術債務指的是過去在軟件開發工作中做出的決策所產生的大量工作。
解決技術債務的工作常常受到冷遇，因為這些工作無法解決急迫的業務需求，加上投資回報率的不明確，因此通常會被認為是可延期的。對于任何涉及維護的問題，無論是代碼還是房屋，這都是一個經典問題。但是也有一些方法可以用來衡量和管理技術債務，這將有助于你保持對技術債務的控制。
您今天開發的應用程序是如何演變為明天的遺留應用程序的?您和開發團隊正在按照常規的發布計劃快速發布應用程序的改進，因此可能很難想象這些應用程序將來會變成遺留狀態。您可能還想知道，在開發應用程序以降低成為遺留應用程序的風險時，您可以在今天做些什么。
應用程序不會在一夜之間成為遺留項目，之所以會變成這樣，有兩個主要原因:
•隨著應用程序的發展，組織可能會分配更少的人員來維護它，而將人員轉移到更具戰略性的項目。
•隨著時間的推移，團隊致力于對應用程序進行技術改進的時間可能會越來越少，因為他們會關注新的活動。
技術債務的定義
通常，那些因技術改進而帶來的積壓工作被稱為技術債務。技術債務是開發團隊為維護應用程序的體系結構、底層平臺和代碼而必須要做的事情。技術債務的例子包括:
•在需要更多時間來實施更強大的解決方案時，那些應該重構小段代碼的工作。
•在實現了一個復雜的特性之后，留下來的維護工作。團隊可能已經用大量的設想預估了這個特性，但是產品負責人仍然優先考慮它的開發。它是在最好的意圖下開發出來的，但事后看來，可能還有更高效、更強大的實現。這造成了另一個技術債務來源。
•一個為簡單用例開發的代碼模塊，但隨著時間的推移，它需要重構來適應用于更廣泛的用例。
•有時，代碼在沒有適當的輔助工具的情況下被發布。這些輔助工具應該包括應用程序日志記錄、錯誤檢查、異常處理、文檔和其他工件。
•有時，代碼模塊可以作為獨立的微服務以實現進行更好的管理。這種類型的轉變可能被一些人認為是架構升級，但我仍然將其稱為技術債務，因為這是技術驅動的改進。
•有時，團隊開始使用庫或服務的新版本來部署新代碼，并將舊代碼的升級保留到以后來完成。這種拖延造成了技術性債務。
•升級和補丁平臺、第三方服務、開發工具和新API版本的連接也是技術債務的一種形式。
衡量這種債務表明了開發團隊認為的還需要做多少工作才能最好地支持應用程序。具有大量且不斷增長的技術債務的應用程序是它們正走向遺留狀態的有力指標。
維護應用程序以及避免或至少延遲遺留狀態的秘訣在于組織和團隊如何管理技術債務。
弄清楚了這些技術債務的來源之后，不同規模的技術組織應該如何處理這些問題呢?首席信息官面臨的最棘手的問題之一就是如何管理遺留系統和實現技術的現代化，因此我們在管理技術債務方面需要面對既得利益者。
每周四的下午2點，我都會在#CIOChat標簽下參與Twitter聊天。我詢問了他們的技術債務戰略，并在接下來的5個最佳實踐中包括了他們關于如何最好地度量和管理技術債務的一些想法。
1.管理技術債務從衡量技術債務開始
如果沒有某種方法可以捕捉細節并加以管理，你就無法管理日益嚴重的問題。正如云技術合作伙伴公司副總裁兼首席架構師Ed Featherston所說的:
一切都是一種權衡。技術債務也是這種權衡下的結果。為了權宜之計做出的決定，留下了必須償還的債務。我所見過的處理這一問題的最好方法之一是將特定的技術債務積壓與產品積壓分離開來。這為累積的債務帶來了可見性和透明度，并且每個迭代周期都應該包括產品和技術債務的故事。
對敏捷團隊來說，在待辦事項列表中標記技術債務是一個重要規則。這可以在一個迭代周期中完成，因為技術債務得到了確認，所以可以在迭代周期回顧會議中進行捕獲。Featherston和我在這里有所不同：我更喜歡在相同的待辦列表中捕獲產品的增強和技術債務，但是技術債務用戶故事和任務被標記為一個或多個不同的標簽。但是，只要團隊和產品負責人能夠看到在每個迭代周期中添加和處理的技術債務是什么，任何一種方法都是有效的。
2.使用發布計劃策略來管理技術債務
大多數開發組織都有一種管理應用程序發行版的方法，來對這些發行版的目標范圍和時間做出決策。但即使是執行持續發布周期的團隊也會召開會議來審核短期和長期的優先事項。在這些會議中，架構師和開發人員可以表達哪些功能的優先級是復雜的，并可能導致新的技術債務形式。
用Affinitas Life的首席技術官Wayne Sadin的話來說:
通過確保項目預算和計劃能夠明確處理正在進行的維護成本，包括被替換系統的退役(日期/成本/過程)，來停止增加技術債務。填補深坑的第一步：停止挖掘!
Sadin在規劃會議上提到了幾個強有力的管理原則:
•在規劃時討論復雜的功能，尋找更易于實施的更簡化的解決方案，以減少技術債務。
•確保將團隊的百分之一的優先事項用于解決技術債務。我的經驗是，發布速度的30%應該應用于處理債務，而發布計劃會議是討論和辯論優先級的好地方。
•當我們都喜歡構建新的應用程序并致力于創新時，開發組織也需要關注舊的平臺、應用程序、庫和代碼模塊。這也可以納入發布計劃。
•最后，可能也是最重要的，是技術組織如何管理新技術的選擇和采用，包括開發平臺和庫。如果您選擇一項技術是因為它是“下一個最好的東西”，而“下一個最好的東西”與已經使用的技術重疊，那么你就是在制造新的技術債務!
3.Devops CI/CD使解決技術債務變得更加容易
Devops的關鍵實踐之一是實現持續集成、持續測試和持續交付管道或CI/CD管道。這種自動化可以將代碼嵌入版本控制系統，打包應用程序，將代碼交付給開發或測試環境，并通過一系列的回歸測試。
通過這種自動化，讓團隊對代碼庫進行小的、增量的更改有了更多的信心，因為部署是腳本化的，而回歸測試可以最快地識別應用程序的問題。
與此形成鮮明對比的是沒有這種自動化或測試系統的遺留應用程序。開發團隊在對這些應用程序進行更改時將變得越來越擔心，因為他們不知道什么時候會中斷，也不知道部署是否能夠可靠地執行。這種擔心減緩了團隊解決技術債務的速度，并加快了應用程序到到達遺留狀態的速度。
4.規劃發布周期以解決補丁和升級問題
較小的技術債務項目，如修復和重構代碼，可以在發布范圍內完成。但是當涉及到更大的升級時，則通常需要一個專門的“系統升級”版本來執行和測試升級。系統升級最好是在不引入新功能的情況下執行，這樣團隊就可以根據已建立的測試和已知行為來驗證升級。
有紀律的組織通常會執行周期性的計劃，以在對業務和用戶需求影響最小的時候安排這些升級周期。正如奧克蘭大學的CIO Theresa Rowe所說:
我們通過對現有技術投資進行謹慎地周期性規劃來管理技術債務;任何投資都需要進行規劃來與戰略舉措相匹配。
例如，如果您的應用程序在Java和MySQL后端上運行，開發團隊可能會考慮每年進行一次重大升級，來跟上這些平臺的主要發布周期。然后，它應該尋找使用率相對較低的時段來安排這些升級。
5.傳達遺留應用程序和技術債務的狀態
重要的是要認識到應用程序的維護狀態對大多數業務領導者來說是不可見的。只有當遺留應用程序的可靠性較差或需要的功能升級時間太長或實現成本太高時，它們才會感覺到遺留應用程序的存在。換句話說，他們可以感知應用程序何時達到遺留狀態，但是他們對導致遺留狀態的技術債務的測量和管理缺乏很好的理解和可見性。
解決這一差距是技術組織的共同責任。首先，你需要測量它。然后，通過提前確定優先級并解決它。最后，通過創建報告或合適的溝通工具來提供這些遺留問題的可見性。
京公網安備 11010502049343號