# 技術債務是什麼以及如何償還，範例 > 技術債務可能是軟體專案的無聲殺手。瞭解如何識別、排定優先順序並解決技術債務，以維持健全的程式碼庫。 Source: https://asana.com/resources/technical-debt ## 什麼是技術債務？如何償還 (附範例) #### 摘要 技術債務是選擇最快而非最有效的解決方案所造成的額外工作成本。 儘管有時技術債務是值得的，但重要的是您的團隊要了解快速決策的正面和負面影響，以及如何有效地管理返工。 產品經理、程式設計師和其他專案關係人應仔細考慮所涉及的權衡取捨。 在本文中，我們將說明什麼是技術債務，分享避免債務的技巧，並瞭解如何區分有價值和無價值的決策。在產品領域工作通常需要對軟體功能做出快速決策。 如果您曾在 DevOps 團隊中工作，您就會知道推動功能上線需要做出多少決策。 這些選擇可能會影響程式碼庫、使用者體驗、上市時間等。 技術債務是一個術語，用於描述在優先考慮速度的基礎上[做出決策的](https://asana.com/resources/decision-making-process)結果。 這些快速、即時的決策可以決定軟體更新的成敗。 但良好的決策和快速的決策之間應該取得平衡。 產生技術債務可能會導致負面結果，或是值得付出，這取決於您和團隊的決定。 這並不總是壞事，但過多的債務會降低可維護性和程式碼品質。 在本文中，我們將討論技術債務的定義、如何在開發過程中有效管理快速決策，並分享範例，讓您更好地瞭解如何避免未來的事故。 我們將涵蓋重構、自動化、指標、程式碼審查和與 Business 版需求保持一致等主題。 ## 什麼是技術債務？ 技術債務是選擇最快而非最有效的解決方案所產生的額外返工代價。 軟體開發人員 Ward Cunningham 於 1992 年首次使用這個詞，但此後它已經發生了變化。 如今，技術債務 (又稱為技術債和程式碼債) 通常發生在開發團隊選擇在構建軟體開發產品的新功能時編寫快速程式碼時。 快速交付程式碼有助於您的團隊在期限內完成工作，而您所累積的債務_可能_是值得的，但如果管理不當，也可能會導致負面結果。 一旦決定累積技術債務，這些負面結果往往無法避免。  無論您是經歷好的還是壞的結果，我們都會介紹有關技術債務的重要事實，以便您在當下做好準備做出正確的決定。 #### 擺脫資訊孤島：最佳化組織架構，強化跨團隊協作 在本電子書中，您將學習如何最佳化組織架構，以防止資訊孤島，加快行動速度，並在變革中維持團隊步調一致。 - [取得深入解析](/resources/organizational-structure-ebook) - [取得深入解析](/resources/organizational-structure-ebook) ### 技術債務是壞事嗎？ 與金融債務非常相似，技術債務的運用方式既有好有壞。 在某些情況下，技術債務是經過深思熟慮後的結果，既能滿足軟體期限，又能在衝刺期間交付高品質的程式碼。 在其他情況下，技術債務是發佈軟體更新時不可避免的錯誤所致。 - [閱讀：發佈管理：制定成功流程的 5 個步驟](/resources/release-management) ## 技術債務的成因是什麼？ 技術債務有四種不同的成因，稱為技術債務象限。 由 Martin Fowler 所創造的四個技術債務象限包括魯莽、審慎、蓄意和無意。 這些象限有助於團隊成員和專案關係人瞭解可能在程式碼庫中累積的不同類型的債務。 將技術債務分配到這四個象限有助於衡量程式碼問題的意圖和背景。 雖然某些程式碼債務可能是刻意的，並被歸類為_良性債務_，但其他債務（如快速修復和不良程式碼）可能是無意的，並被歸類為_不良債務_。 - **審慎和深思熟慮：**快速交付並處理後果的決定會導致審慎和深思熟慮的債務。 當軟體專案的風險相對較低，且快速交付的好處大於風險時，最常使用這種類型的債務。 這是一種有意識的權衡，以縮短上市時間。 - **魯莽且刻意：**瞭解如何產生最佳程式碼，但優先考慮快速交付，這就是魯莽且刻意債務的原因。 這通常會導致難以維護的舊版程式碼。  - **謹慎且無意：**當您渴望產出最佳代碼，但在實施後發現更好的解決方案時，就會發生謹慎且無意的債務。 自動化測試和其他方法有助於及早發現這一點。 - **魯莽和無心之失：**當團隊試圖在沒有必要知識的情況下產生最佳代碼時，就會發生魯莽和無心之失的債務。 團隊通常不知道自己犯了什麼錯誤。 這可能會導致漏洞和維護問題。 團隊為了快速交付而選擇有意識的技術債務，而無意識的債務則是意外發生的，發生在實施之後。 軟體工程師 Steve McConnell 在描述兩種整體類型的技術債務時，對這一差異進行了最好的說明。 瞭解這些象限是管理整個開發週期中的債務的關鍵。 讓我們深入瞭解每一個，以便更好地理解。   ## 技術債務的類型 Construx Software 的首席軟體工程師 Steve McConnell 表示，[技術債務有兩種類型](http://www.construx.com/uploadedfiles/resources/whitepapers/Managing%20Technical%20Debt.pdf)：有意和無意。 ### 1. 有意的技術債務 當組織有意識地決定為現在而非未來進行最佳化時，就會產生有意義的債務。 Business 版需求和產品經理和資訊長等專案關係人迫使快速交付功能的壓力，通常是背後的驅動力。 有意義的債務有短期和長期兩種變體。 例如，為了償還先前的設計債務而產生的有意債務是短期債務，而為了防止未來更大的文件債務而產生的有意債務則是長期債務。  - **短期債務**：短期債務是出於戰術原因（例如使用現有資源）而被動產生的。 此外，短期債務可以是聚焦或非聚焦的。 團隊成員可能會承擔短期債務，以便快速提供錯誤修復或其他使用者體驗改進。 - **聚焦式短期債務：**這包括個別可識別的捷徑。  - **非聚焦的短期債務：**這包括許多小捷徑。 隨著時間推移，這可能會大幅減緩開發週期。 - **長期債務**：長期債務是出於策略原因（例如遵守期限）而主動產生的。 自動化和重構投入量通常屬於此類別。 如您所見，產生的債務類型將決定償還債務所需的時間。 ### 2. 非預期的技術債務 另一方面，非預期的技術債務則是由於缺乏理解、意外錯誤或在某些情況下編寫的程式碼不佳而發生。 非預期技術債務的一個例子是，設計方法最終被證明容易出錯。 定期審查程式碼有助於及早發現這些問題。 我們可以假設非預期的技術債務是意外的，因為團隊並非故意產生這些債務。 最常見的情況是，您只有在實施軟體更新或已完成專案後，才會意識到自己的錯誤。  - [閱讀：您應追蹤的 27 項商業成功指標](/resources/success-metrics-examples) ## 如何衡量技術債務 軟體開發團隊必須衡量技術債務，才能瞭解其程式碼債務的程度，並就其管理做出明智的決策。 透過量化技術債務，團隊可以優先考慮重構投入量，並確保其程式碼庫從長遠來看仍然可維護且可擴展。 ### 指標與工具 可以使用各種指標來評估軟體專案中的技術債務量。 其中包括程式碼複雜度、重複性、測試覆蓋率和可維護性指數。 SonarQube、CAST 和 Kiuwan 等工具可以自動化測量流程，為您的程式碼庫健康狀況提供有價值的深入解析。 ### 評估最佳作法 在評估技術債務時，讓所有專案關係人參與至關重要，包括開發人員、產品經理和 Business 版領導者。 定期進行程式碼審查和債務隱喻討論有助於提高意識，並促進對技術債務影響的共同理解。 根據債務阻礙開發週期、功能和使用者體驗的能力來確定債務的優先順序，是有效評估的關鍵。 ## 如何償還技術債務 雖然您可能會有意累積一些技術債務，但許多產品團隊在追蹤和[溝通](https://asana.com/resources/effective-communication-workplace)技術債務方面卻苦惱不已。 這可能會導致在尋求解決軟體程式碼中的差距時，產生比預期更多的工作。  本逐步指南將協助您償還技術債務，並提高[工作空間中債務負擔的透明度](https://asana.com/resources/workplace-transparency)。  ### 步驟 1：識別並排定技術債務的優先順序 償還技術債務的第一步是確定並優先考慮您的程式碼庫中需要關注的領域。 這包括分析指標、進行程式碼審查，以及收集團隊成員的意見。 根據債務對功能、可維護性和 Business 版需求的影響，確定債務的優先順序。 - 在追蹤系統中維護債務清單。 每次產生債務時，請將償還該債務所需的任務輸入到追蹤系統中，並附上預估投入量和排程。 使用債務待辦項目追蹤您的技術債務進度。 任何超過 90 天未償還的債務都應被視為關鍵債務。 - 如果您使用的是 Scrum，請將債務清單作為 Scrum 待辦項目的一部分進行維護，將每筆債務視為 Scrum「故事」，並估算償還每筆債務的投入量和排程，就像您估算 Scrum 中其他故事一樣。 ### 步驟 2：重構並最佳化您的程式碼 確定高優先順序的技術債務後，就可以開始重構和優化您的程式碼了。 這可能涉及分解複雜的功能、消除重複、改進命名慣例以及更新過時的架構。 避免走捷徑和快速修復，因為從長遠來看，這些做法可能會導致更多債務。 ### 步驟 3：建立編碼標準和最佳作法 為了防止新的技術債務累積，請為您的開發團隊建立明確的編碼標準和最佳作法。 這包括程式碼結構、評論、測試和文件的指南。 鼓勵團隊成員一致遵循這些標準，並根據需要提供訓練和支援。 ### 步驟 4：持續監控並解決新的債務 技術債務是一個持續存在的問題，因此必須持續監控並解決新的債務。 使用指標和工具定期評估您的程式碼庫，並將債務管理納入您的開發流程。 考慮採用 Scrum 或 DevOps 等方法，以支援持續改進和減少債務。  - [閱讀：業務中的效率與有效性：團隊同時需要兩者的原因](/resources/efficiency-vs-effectiveness-whats-the-difference) ## 技術債務範例和解決方案 現在您已經瞭解了技術債務的管理以及非預期和預期債務背後的一些原因，讓我們來看看一些現實生活中的範例。  ### 範例 1：有意產生的技術債務 - **描述：**團隊選擇了一個快速構建的架構，該架構具有已知的性能問題，且功能最少。 - **解決方案：**團隊使用其他應用程式進行軟體後置實施，這些應用程式具有缺失的架構功能。 - **債務：**儘管他們在產品期限前完成了工作，但團隊需要在發佈後重新設計功能，並需要額外的資金。   ### 範例 2：非刻意的技術債務 - **描述：**團隊有許多初級開發人員協助在緊迫的期限內發佈新的軟體功能，但沒有足夠的資深開發人員來審查每一段程式碼。  - **解決方案：**團隊聘請資深開發人員提供額外的臨時支援，以查看程式碼並檢查功能是否正常。  - **債務：**雖然團隊發現了大多數問題，但全職員工和臨時支援人員之間的溝通不暢導致一些程式碼錯誤被忽視。 這意味著團隊需要在發佈後對這些問題進行偵錯。  如您所見，雖然有所不同，但無論是有意還是無意的債務都需要隨著時間的推移來償還。 透過針對技術債務的解決方案[進行腦力激盪](https://asana.com/resources/brainstorming-techniques)，您可以確保軟體更新按時發佈，且幾乎沒有產生債務。  ## 以透明的方式管理您的技術債務 在進行軟體產品發佈時，債務並非總是可以避免的。 從艱難的決策到程式碼中的錯誤，[敏捷](https://asana.com/resources/agile-methodology)團隊知道累積的技術債務會如何影響軟體更新。  償還債務的關鍵是維護和追蹤增量付款。 雖然每種情況下的債務償還類型各不相同，但團隊透明度和溝通可以幫助您更快地償還債務。 這是因為提升敏捷專案的明晰（度）可以強制針對手上的問題採取集體解決方案。 ## 常見問答：技術債務 **Scrum 中的技術債務是什麼？** 在 Scrum 中，技術債務是指為了維護和提高軟體產品品質而需要完成的工作積累。 當開發團隊有意識地決定優先考慮速度而不是品質，或由於缺乏經驗或知識而無意識地產生債務時，就會產生技術債務。 在 Scrum 中，技術債務通常表示為需要在未來衝刺中解決的待辦項目。 **技術債務是好是壞？** 技術債務本身並非好壞之分，而是取決於其管理方式。 在某些情況下，承擔技術債務可能是一項策略決策，使團隊能夠更快地交付價值。 然而，如果任其發展，技術債務可能導致維護成本增加、生產力降低，甚至專案失敗。 因此，在產生和償還技術債務之間取得平衡至關重要。 **技術債務的常見原因是什麼？** 技術債務的常見原因包括緊迫的期限迫使團隊採取捷徑、缺乏編碼標準和最佳作法、測試和文件不足，以及使用過時或不兼容的技術。 其他因素，例如團隊流動率和缺乏溝通，也可能導致技術債務累積。 **技術債務會如何影響專案？** 技術債務可能會對專案的成功產生重大影響。 隨著債務量的增加，程式碼庫變得更加複雜且難以維護，導致開發週期變長，且錯誤修復也增加。 這反過來可能會延遲新功能的交付，並對使用者體驗產生負面影響。 在極端情況下，技術債務會使專案無法進行，需要已完成的程式碼庫完全重寫。 **如何預防技術債務？** 預防技術債務需要採取積極主動的方法，並讓整個開發團隊參與其中。 這包括建立並遵守編碼標準和最佳作法、進行定期的程式碼審查，以及優先進行測試和文件記錄。 Scrum 等敏捷方法也可以透過鼓勵頻繁回饋和持續改進來幫助預防技術債務。 此外，在每次衝刺中分配時間來解決技術債務，有助於將其控制在一定範圍內。 - [專案管理](/resources/project-management) - [發佈管理：制定成功流程的 5 個步驟](/zh-tw/resources/release-management) 敏捷 #### 內容撰稿人 若您曾經歷過軟體發佈，您便會知道事情可以變得多麼複雜。從管理專案時間軸到追蹤截止日期和範疇，一個人需要處理很多事情。這就是發佈管理派上用場的地方。有了正確的流程，甚至連最複雜的任務都能有效管理。發佈管理是一種透過不同階段來管理、計劃和控制軟體更新以提高品質、速度和效率的技術。我們將更詳細地介紹發佈管理流程所包含的內容，並提供一份清單來幫助您開始制定自己的發 ... - [Kanban board template](https://asana.com/templates/kanban-board) 專案管理 敏捷 - [燃盡圖：燃盡圖是什麼？如何使用？(附範例)](/zh-tw/resources/burndown-chart) 敏捷 #### 作者 您的週一是以衝刺會議開始一天，您發現開發方面的工作有問題，可能會導致延誤幾天，心裡甚至納悶著：不知是否有足夠的時間在下週前完成所有工作？我們多數人都曾處於跟時間賽跑的類似情境，要在團隊的排程中找到足夠時間完成專案可能極具挑戰性。此時燃盡圖就能發揮作用。燃盡圖有助於分析您必須執行的工作，以及完成這些工作所需的時間。它是以視覺化方式呈現的絕佳工具，讓您更妥善地 ... - [Scrumban template](https://asana.com/templates/scrumban) 敏捷 - [What is technical debt and how to pay it off (with examples)](/zh-tw/resources/technical-debt) 敏捷 專案管理 - [內容撰稿人](/author/team-asana) 在產品領域工作通常需要對軟體功能做出快速決策。 如果您曾在 DevOps 團隊中工作，您就會知道推動功能上線需要做出多少決策。 這些選擇可能會影響程式碼庫、使用者體驗、上市時間等。技術債務是一個術語，用於描述在優先考慮速度的基礎上做出決策的結果。 這些快速、即時的決策可以決定軟體更新的成敗。 但良好的決策和快速的決策之間應該取得平衡。 產生技術債務可能會導 ...