現在已經到第十次迭代開發周期了，你的專案開發速度開始變慢。在之前的幾個迭代週期中，團隊沒有像以前那樣完成很多的「故事場景」（stories）。此外，最近在新的故事場景和回溯中卻發現更多缺陷(bug)。專案經理知道，團隊成員沒有變，他們也花同樣的時間工作。但是，客戶會發問：「發生什麼事情了？這個團隊還在努力工作嗎？」
\ 很多敏捷團隊的產品改進率為150-500%[1]，可是你們的專案看起來卻貌似只有20-40%左右的改進率。這到底是怎麼回事呢？在此我們找不到什麼大問題；相反，只是有無數的小問題。有時，這些只是一些為了方便而使用的捷徑（開發人員沒有時間去清理這些修改），有時開發人員僅僅是不熟悉這中語言。還有一些問題就是，**跟灌木叢一樣凌亂，需要大幅度的修整。所有這些都屬於「技術債務」。
\\ 它就是「那些內在的事物，現在你不去解決，遺留下來（不幹完），它就會阻礙未來開發」[ward cunningham]。 表面上，應用程式看起來質量很高且狀況良好，但是這些問題卻隱藏在下面。 qa（質量保證部門）甚至可能告訴你說，這個應用程式真是不錯，幾乎找不到缺陷，但是其中仍然存在「技術債務」，如果我們沒有很好地管理並設法降低這些「技術債務」，那麼，程式編寫和維護的代價最終將會超過它對客戶的價值。
\ 技術債務就像信用卡一樣，會有很高的利息率，就如同給團隊留下了大量的帳務開銷。這種情況下，開銷將會體現在時間花費和解決問題所需的努力上面。開發團隊拖延債務的時間越長，所積累的利息就越多（會額外增加很多任務作），付出的成本也就越高。
\ 另外，這還增加了實際的財務支出：開發團隊處理技術債務所花費的時間，可以用在對團隊有價值的其它工作上。同時，這些難讀的**引起的技術債務也讓我們難以找到軟體的缺陷。再且，理解**所損失的時間還可以用來做其它更有價值的事情呢。
\\ 專案編碼初期，不整理**，不寫單元測試，也不做測試驅動開發，整個團隊粗製濫造出更多的「故事場景」。 這些問題通常都不會馬上暴露出來，而循規蹈矩地編寫**往往需要更多的時間，特別是在早期階段。
\\\ 這個問題的並不是一下子可以解決的，解決方案需要通過幾個迭代週期。並且，你需要耐心，並要從多個角度尋找解決途徑。
\ 解決方案中的要點
\ 讓開發人員接受語言方面的基本培訓並教授他們物件導向的原理，從而把他們的理解力提公升至入門階段。要想既成功又有效的話，這需要花幾個禮拜的時間培訓，還需要有精通這方面的人員來跟進和支援這一系列培訓。\
告訴開發人員和管理人員，當前的這些問題都是需要花費企業資金的。這點尤其重要，因為它會使解決這些問題的意義更加明確。你要清楚地告訴他們，管理人員會重視這些問題，並且已經開始著手償還這些技術債務了。不斷支援這些工作使之成為常規的原則之一，這樣整個團隊就會信任這個準則。\
提供一些培訓，包括**的壞味道，重構，單元測試和測試驅動開發等。還可以結合課堂會議，基於網路的材料和書籍來進行培訓。\
在工作的時候，給他們一些空餘時間去研究和練習他們的技能（乙個禮拜兩個小時應該是達成這個目標的最小的時間量）。練習的**應該被丟棄，這樣，他們就能無拘無束地嘗試和試驗一些事情，不管怎麼樣，他們不用在基礎**庫上面進行練習。花點時間練習和研究應該是最有用的建議了。假如沒有為他們提供空閒的時間，就壓根不會發現真正合理的敏捷開發方式。這種組織方式也被稱為「道場」-dojo（更加詳細的資料可以參考tdd randori session 和tdd randori workshop）。\
使用工具（靜態分析，單元測試，持續整合，自動化可接受性測試）來幫助團隊發現、減少和衡量他們的技術債務量。應該在團隊層面利用這些度量資料，而不能分享給管理人員。團隊成員需要知道，他們並不會因為對這些技術債務的度量而接受獎勵或者遭受懲罰。如果我們把這些度量資料報告給管理層，並由管理層來追蹤的話，開發人員很快會找到一些竅門來規避它們，這樣就失去了本來應有的價值了。\
當人們完成了他們的培訓或者在技術上取得了少許提公升時，應該得到獎勵。獎勵可以是給予一次認可的表彰或者是一些小小的禮物，但不要直接給予現金獎勵。\
每兩個禮拜進行一次午餐聚會和一些關於技術方面的學習型會議。利用這些會議來促進開發成員之間的討論。提供午餐可以提高參會人數。另外比較重要的是需要管理人員每次都來出席，這樣就很清楚的表明他們也一直支援大家提高技術。\
維護關於技術債務的備忘錄 – 任何時候，如果開發人員發現一些無法立即應付的技術債務時，就需要填寫乙份技術債務登記卡。開發人員應該優先考慮這些技術債務，並花費10-15%的精力來償還這些技術債務。大多數專案中，任何的一些小事都會使問題變得更加嚴重。\
基於這樣的立場，你會發現問題，也會擁有機會。你的問題是：專案的基礎**一直在積累技術債務，但是這些債務已經開始下降了。然而，現在跟客戶申請用於處理這些問題的資金會跟處理這些問題一樣困難。你的機遇是：提高了開發人員的技能；清楚地表達了管理層對這項工作的支援，還有，軟體的**質量會不斷改善，軟體缺陷的數目也會不斷減少。同時這也會很好的提高團隊的整體開發能力。
\ [1]
rpm software – by robin dymond；embedded agile project by the numbers with newbies （2006） - by nancy van schooenderwoert；how agile projects measure up， and what it means to you （2008） by michael mah
\檢視英文原文：technical debt a perspective for managers
\ 感謝侯伯薇對本文的審校。
\
從彙編角度看引用
引用型別到底是什麼？它和指標有什麼關係？它本身占用記憶體空間嗎？帶著這些疑問，我們來進行分析。先看 include include using namespace std void main 通過彙編檢視 如下 9 int x 1 00401048 mov dword ptr ebp 4 1 10 ...
產品經理如何幫助減少技術債務 ？
產品經理擁有廣泛的知識，能夠接觸到公司的不同部門和利益相關者。這使得他們處於乙個理想的位置，可以圍繞預防和應對技術債務創造一種工作文化。我們提供了一些有用的策略。根據gartner的2019年產品經理調查，只有55 的產品發布如期進行。這對於按時發布產品的產品經理來說意義重大，因為他們更有可能在發布...
產品經理如何幫助減少技術債務 ？
產品經理在促進產品成功方面扮演著關鍵角色 願景 特性 戰略 產品發布 市場定位 競爭對手以及路線圖。產品經理位於工程 銷售 支援和營銷互相交叉的十字路口，這意味著他們處於解決技術債務問題的獨特位置。這裡有一些會起到幫助的可行策略。產品經理的職責應該包括與技術主管 首席技術官和其他部門主管建立牢固的關...