專案中的隱形殺手：技術債( Technical Debt ) – 艾菲肯專案管理小學堂

• 不良設計：曾經合理但如今卻不再是如此的設計。
• 不足夠的測試覆蓋率：我們知道該多做一點測試，卻一直沒有這麼做的地方。
• 缺失：軟體裡已知的問題，而我們還沒有時間排除它們。
• 過多的人工測試：當我們應該要有自動化測試時，卻還是用人工進行測試
• 不良的整合與版本管理：用極度耗時並且容易產生錯誤的方式來進行這些活動。
• 缺少平台經驗：例如，我們有一些用COBOL語言開發的大型電腦主機軟體，但我們再也沒有足夠的資深COBOL開發人員。

---

• 我們寫出一些雜亂的程式碼時，會使開發團隊的產能持續下降，逐漸趨近於零。
• 當產能降低，管理團隊只能做一件事，就是想辦法僱用更多的新員工，期待能夠增加產能，新員工對系統的設計概念並不熟稔，所以他們不知道什麼樣的修改才符合設計的原意，什麼樣的修改會破壞設計的原意。
• 新進的員工及團隊裡的其他人，都為了增加產能而面臨巨大的壓力，於是他們製造更多雜亂的程式碼，導致產能更進一步趨近於零。
• 最後開發團隊開始反抗，告訴老闆，無法在這樣的程式基礎上進行開發，他們只得要求重新設計。老闆雖然並不想花資源重新打造一個行之有年的系統，卻也無法否認目前糟糕的處境。
• 最後老闆只好屈服於開發者的要求。
• 這樣的開發可能歷經數年，原本待在團隊上的成員早已離開，新成員又嫌系統太糟，而要求再次重新設計系統，不斷經歷這樣的循環。

---

• 降低可預測性：積欠大量的技術債的產品幾乎無法做任何形式的預測。
• 信用破產：公司不再信任開發團隊所說的任何事；客戶也不再信任公司所說的一切
• 產品衰退：我們停止開發或修護雖然可以繼續使用舊產品，但留下的缺失以及無法因應市場變化的趨勢，潛在客戶會愈來愈失去對產品的吸引力。
• 增加交付的時間
• 大量的缺失與錯誤
• 增加開發和技術支援的成本：高技術債的利息隨著時間迅速成長。導致變更需求或更新版本的成本越來越高。
• 績效表現不佳：預期人員的開發績效愈來愈低，因此不再期待，導致士氣低落。
• 降低客戶滿意度

---

• 為了在技術與商業之間取得平衡，我們需要結合開發人員與業務人員，討論兼顧商業和技術觀點的處理方式。
• 我們可能策略性的累積技術債達到商業上的需求，也可能因為一些無法避免的情況導致技術債的累積。但我們必須停止莽撞行事和製造雜亂所產生的技術債。
• 運用良好的技術實務、簡單設計、測試驅動開發、持續整合、自動化測試、重構。
• 在執行為客戶帶來價值的工作時，同時要償還技術債，其優點為：
  • 減少技術債，不只是開發團隊成員的責任，而是專案相關人士的責任，不該延後再交由其他人處理。
  • 幫助我們確認高利息的技術債會先被償還，最起碼我們還知道這些我們會接觸到的程式碼仍然是重要的，因此我們還在用它來建立新的功能。
• 重構
  • 重構是用來償還債務的重要工具。
  • 可降低複雜性。
  • 可提高維護性與擴展性。
  • 用戶願意花錢買新功能，因此我們可藉由重構解決新功能與舊系統的相容性問題。

---

• 開發者都感受過截止期限的壓力，所以只好產生一些爛程式來達到目標。但多數情況，他們並沒有讓開發速度變得更快，只是延遲處理問題的時間，讓利息越滾越大。
• 想讓開發速度變快，最有效的方法就是隨時隨地確保程式碼的整潔。

---

• Robert C.Martin，《Clean Code》(無瑕的程式碼)
• Kenneth S.Rubin，《Essential Scrum-A Practical Guide to the Most Popular Agile Process》
• Robert C.Martin，《Agile Software Development：Principles, Patterns, and Practices》(敏捷軟體開發-原則、樣式及實務)

( End )