來源：InfoQ

作者：Csaba Okrona（在 Contentful 擔(dān)任高級工程經(jīng)理）

譯者：張健欣

策劃：褚杏娟?

技術(shù)債（Technical debt，或 tech debt）在過去幾年中成為一個(gè)流行的術(shù)語。隨著時(shí)間的推移，我們的代碼庫和系統(tǒng)往往會(huì)變得“有缺陷”，這使得以后更難對其進(jìn)行更改或構(gòu)建。

技術(shù)債是 Ward Cunningham 的一個(gè)比喻。Ward Cunningham 是敏捷宣言的合著者，也是第一個(gè) wiki 軟件的創(chuàng)建者。比喻，和模型一樣，幫助塑造我們對特定主題的思考。因此，為什么我們稱之為“技術(shù)債”而不是簡單的“有缺陷”？原因是，在某些方面，它類似于金融債務(wù)——如果我們不償還，它會(huì)對新功能及其維護(hù)造成損害，就像金融債務(wù)的利息積累一樣。

技術(shù)債的一個(gè)來源是我們在設(shè)計(jì)和構(gòu)建系統(tǒng)時(shí)有意識和無意識的權(quán)衡，缺乏干凈的代碼、文檔和最佳實(shí)踐。另一個(gè)來源是系統(tǒng)及其生態(tài)系統(tǒng)在演化，兩年前的完美解決方案現(xiàn)在不再那么完美了。

我將聚焦于技術(shù)來說服利益相關(guān)者“采納這個(gè)意見”，在產(chǎn)品開發(fā)中優(yōu)先安排償還技術(shù)債。

兩種積壓工作

讓我們先看看不要做什么。許多團(tuán)隊(duì)最終有兩種積壓工作——一種是以產(chǎn)品為中心的，另一種是以技術(shù)為中心的。這無法再生效是由于多種原因：

• 幾乎不可能在積壓的項(xiàng)目間穿插其它優(yōu)先的項(xiàng)目。

• 它助長了“我們 vs. 他們”的心態(tài)，這扼殺了團(tuán)隊(duì)凝聚力和共同目標(biāo)。

• 確定優(yōu)先級是整個(gè)團(tuán)隊(duì)的工作；把產(chǎn)品代表排除在外是行不通的。除非你對如何分 配團(tuán)隊(duì)力量有嚴(yán)格規(guī)定（例如，20% 持續(xù)用于技術(shù)債務(wù)），否則這會(huì)使工期規(guī)劃變得更加困難。

保留一個(gè)積壓工作并在那里添加任何類型的工作。如果你想要統(tǒng)計(jì)數(shù)據(jù)或過濾視圖，請隨意標(biāo)記技術(shù)債，但請確保將整個(gè)積壓工作一起安排優(yōu)先級。

不要讓技術(shù)債成為一場指責(zé)的游戲

另一個(gè)常見的錯(cuò)誤是對技術(shù)債的爭論充滿了指責(zé)。我見過一些（工程和產(chǎn)品之類的）管理人員說這樣的話，“好吧，如果你一開始就創(chuàng)造了一個(gè)更好的解決方案，我們就不會(huì)處于現(xiàn)在這種情況”——這是愚蠢的、不人道的，最終也是毫無意義的。

沒有什么是完美的。我們都是人，時(shí)移世易，萬物變遷。接受這一點(diǎn)吧。我們能做的最好的事情就是從我們的錯(cuò)誤中吸取教訓(xùn)，應(yīng)用良好的實(shí)踐，并盡可能清楚我們做的決策的利弊權(quán)衡。

玩指責(zé)游戲會(huì)使我們的注意力從解決手頭的問題上轉(zhuǎn)移開。這使大多數(shù)人都有防御性，會(huì)將討論變成不必要的來回扯皮，而不會(huì)更接近解決方案。

不帶指責(zé)的回顧和剖析才是正確的方式。解決方案總是系統(tǒng)性的，而不是針對個(gè)人的。

如何討論技術(shù)債

現(xiàn)在我們知道了該避免什么，讓我們來看看一些討論償還技術(shù)債的重要性的方法。這通常圍繞現(xiàn)有技術(shù)債務(wù)的風(fēng)險(xiǎn)，由其引起的（維護(hù)）辛苦，以及它如何 阻礙新功能 的開發(fā)。

根據(jù)我的經(jīng)驗(yàn)，大多數(shù)工程師不需要被說服去處理技術(shù)債務(wù)。事實(shí)上，正是他們提出了這一要求。另一方面，工程和產(chǎn)品經(jīng)理通常需要更多的上下文信息來理解償還技術(shù)債的重要性。

這里，你最好的策略是理解如何用你的利益相關(guān)者能夠理解的語言提供上下文信息。“好吧，為什么這很重要是無關(guān)緊要的”，這樣的說法是行不通的。你的待辦事項(xiàng)中還有 50 項(xiàng)對他們來說“非常重要”。

還有，不要把它說成是關(guān)于你自己的事情。你熱衷于解決這個(gè)問題是很好的，但是如果它聽起來像是你的寵物項(xiàng)目而沒有任何進(jìn)一步的爭論，那么它可能不會(huì)得到優(yōu)先考慮。我將向你展示幾種構(gòu)建觀點(diǎn)的方法。

題外話：這些都是關(guān)于將你的技術(shù)債務(wù)與你的內(nèi)部或外部客戶以及產(chǎn)品的性能關(guān)聯(lián)起來。

風(fēng)險(xiǎn)

一定比例的技術(shù)債務(wù)附帶有相應(yīng)的風(fēng)險(xiǎn)。一個(gè)簡單的例子是，當(dāng)你的解決方案使用的第三方（庫 / 服務(wù)）即將終止。這里的風(fēng)險(xiǎn)是，如果你不升級或遷移到另一個(gè)受支持的解決方案，依賴第三方的系統(tǒng)可能會(huì)出現(xiàn)功能失調(diào)，或者（例如）將來會(huì)收不到安全補(bǔ)丁，從而有可能出現(xiàn)漏洞，這顯然對你的用戶或客戶不利。

當(dāng)然，并不是每種情況的風(fēng)險(xiǎn)都是同等的——我們是會(huì)在下周下線，還是有比較低可能會(huì)在兩年內(nèi)發(fā)生低影響安全問題，這很重要。查看下面的“延誤成本”部分。

另一種風(fēng)險(xiǎn)也與用戶保留有關(guān)，但是不那么直接。因?yàn)椴惶玫慕鉀Q方案（想想頻繁的宕機(jī)和緩慢的服務(wù)）造成的低劣體驗(yàn)造成了客戶流失的風(fēng)險(xiǎn)。

技術(shù)債圍繞風(fēng)險(xiǎn)的一些措辭示例：

• 我們可能在 2 個(gè)地方修復(fù)了一個(gè) bug，但由于代碼重復(fù)而錯(cuò)過了第 3 個(gè)。

• 當(dāng)前系統(tǒng)的設(shè)計(jì)可能會(huì)導(dǎo)致在高并發(fā)場景下的用戶體驗(yàn)比較慢。

• 缺乏安全措施可能導(dǎo)致違約和法律責(zé)任。

• 由于我們?nèi)狈卧獪y試，可能會(huì)在功能中引入新的 bug。

• 代碼庫的復(fù)雜性和不靈活性導(dǎo)致我們由于開發(fā)時(shí)間太長而對新功能說不。

為了使你的論點(diǎn)更加有力誠懇，你要盡可能收集數(shù)據(jù)并使其成為論點(diǎn)的一部分。當(dāng)然，這并不總是可能的。請記住，數(shù)據(jù)也可以是行業(yè)最佳實(shí)踐，例如，長測試運(yùn)行時(shí)間 vs. 可接受的測試運(yùn)行時(shí)間。

???維護(hù)的辛苦

???

在復(fù)雜或不靈活的代碼庫中，大多數(shù)任務(wù)將花費(fèi)更長的時(shí)間，造成維護(hù)的辛苦；通過使用無效或缺失的工具，造成維護(hù)的辛苦。這一點(diǎn)，再加上大量的客戶和技術(shù)問題，可能會(huì)使整個(gè)團(tuán)隊(duì)陷入停頓，因?yàn)榧词故俏⑿〉男迯?fù)也需要一整天的時(shí)間來完成和發(fā)布。

現(xiàn)在，你需要 4 個(gè)小時(shí)來了解系統(tǒng)中發(fā)生了什么，另外 2 個(gè)小時(shí)來使測試通過，因?yàn)槠渲幸恍y試是不穩(wěn)定的，還有 1 個(gè)小時(shí)來部署你的修復(fù)程序，因?yàn)椴渴鹣到y(tǒng) 5 次卡住了 3 次。

像上面的情況（應(yīng)該！）作為一種風(fēng)險(xiǎn)盡量避免，但很多時(shí)候，只有當(dāng)風(fēng)險(xiǎn)嚴(yán)重發(fā)生時(shí)（人們經(jīng)常大聲抱怨），你才會(huì)意識到這一點(diǎn)。

這里的數(shù)據(jù)主要是傳聞的，但你可以很好地了解你會(huì)節(jié)省多少時(shí)間，如果事情都完好運(yùn)行的話。與你的團(tuán)隊(duì)談?wù)勊麄儗υ黾庸ぷ髁康目捶?#xff0c;并提出一個(gè)粗略的估計(jì)來支持你的論點(diǎn)。

為了幫助你的利益相關(guān)者理解其重要性，請描繪一個(gè)持續(xù)向用戶提供價(jià)值的更好的世界。

開發(fā)新功能的效率

這里降低的效率，加上上面提到的辛苦，本身就值得說一說。雖然維護(hù)的辛苦會(huì)占用團(tuán)隊(duì)的時(shí)間，導(dǎo)致交付新功能的能力下降，但還有一些其它因素。

• 在難以理解的代碼庫中工作會(huì)降低開發(fā)速度（并可能增加引入的新缺陷的數(shù)量和嚴(yán)重性）。

• 使用這樣的代碼庫會(huì)使得團(tuán)隊(duì)投入更多時(shí)間和精力來引入新團(tuán)隊(duì)成員。

• 在一個(gè)設(shè)計(jì)拙劣或架構(gòu)過時(shí)的系統(tǒng)中實(shí)現(xiàn)一個(gè)解決方案是困難的?？膳碌拈L達(dá)一個(gè) 月的重構(gòu)項(xiàng)目就是這樣誕生的。

• 在一個(gè)不適合你正在實(shí)施的新解決方案的系統(tǒng)中修修補(bǔ)補(bǔ)（基本上圍繞現(xiàn)有系統(tǒng)工作）通常會(huì)增加由此產(chǎn)生的系統(tǒng)的復(fù)雜性，并增加更多的技術(shù)債務(wù)——這是一個(gè)惡性循環(huán)!

優(yōu)先級排序技術(shù)

7.1 延誤成本

“延誤成本”并不是一個(gè)完整的優(yōu)先級排序技術(shù)，但在考慮風(fēng)險(xiǎn)時(shí)，它是一個(gè)方便的屬性。

延誤成本是精益管理中的一個(gè)指標(biāo)。它結(jié)合了緊迫性和價(jià)值——人類并不擅長區(qū)分這兩件事。

由于大部分時(shí)間我們傾向于只關(guān)注生產(chǎn)成本和其它固定成本，我們很難確定優(yōu)先級，因?yàn)橐恍┏杀臼遣豢深A(yù)測的，潛在價(jià)值也可能是不可預(yù)測的，因?yàn)殡S著時(shí)間的推移，這些都不是固定的。更好的方法是計(jì)算延誤成本。該值表示公司晚于市場或客戶期望的時(shí)間交付特定功能 / 項(xiàng)目 / 產(chǎn)品所產(chǎn)生的隨時(shí)間稀釋的成本。

計(jì)算延誤成本隨著時(shí)間的變化，需要相當(dāng)成熟的跟蹤和監(jiān)控。計(jì)算延誤成本隨時(shí)間變化的另一種方法是選擇以下模型之一：

你對某個(gè)問題的延誤成本模型的判斷將告知你的影響評級。

7.2 ICE 和 RICE 得分

你最終會(huì)得到許多不同大小和影響的項(xiàng)目，然后變得非?；靵y。ICE 有助于為這種混亂帶來秩序，它可以通過一種系統(tǒng)性的方法來評估這些項(xiàng)目，并創(chuàng)建一個(gè)單一數(shù)字表示它們的優(yōu)先級，你可以簡單地借此對它們進(jìn)行排序。

ICE 代表影響（Impact）、信心（Confidence）和努力程度（Ease/Effort）。RICE 中的 R 代表影響范圍（Reach）。

對于其中每一個(gè)因素，團(tuán)隊(duì)在一組數(shù)值點(diǎn)上達(dá)成一致，例如：Massive = 3 High = 2, Medium = 1, Low = 0.5, Minimal = 0.25

• 影響 —— 解決此問題會(huì)對客戶產(chǎn)生什么影響（記住，客戶也可能是內(nèi)部的！）——或者，在考慮風(fēng)險(xiǎn)時(shí)，解決此問題不會(huì)產(chǎn)生什么影響？

• 信心 —— 你對影響（以及可選的努力程度）的估計(jì)有多大信心？

• 努力程度 —— 努力程度通常更容易談?wù)摗鉀Q問題需要付出多少努力？請記住，這是一個(gè)相對指標(biāo)，只能與當(dāng)前批次中的其它問題進(jìn)行比較。

• 響應(yīng)范圍 —— 這將影響多少人？100% 的客戶群？還是只有某一特定角色的客戶？重要的是，要了解這些分?jǐn)?shù)僅在本地相對環(huán)境中有意義，不應(yīng)跨域進(jìn)行比較。

一旦你有了這些數(shù)字，計(jì)算就很容易了：

RICE 得分 = (Impact x Confidence) / Effort or Impact x Confidence x Ease

在這篇很棒的文章中 可以了解更多關(guān)于 RICE 和 ICE 的內(nèi)容。

關(guān)于如何實(shí)際削減技術(shù)債務(wù)的一些建議

我可以快速重復(fù)這些策略來實(shí)際削減技術(shù)債務(wù)。這里沒有完美的策略，每一種策略都有利弊權(quán)衡。

• 為技術(shù)債分配專用力量

有些團(tuán)隊(duì)將一定比例的工期時(shí)間用于各種類型的工作。一個(gè)常見的設(shè)置是 70% 用于功能開發(fā)，20% 用于技術(shù)債，10% 用于學(xué)習(xí) / 實(shí)驗(yàn)。

這種設(shè)置的挑戰(zhàn)是，通常比較大的技術(shù)債問題無法在 20% 的時(shí)間內(nèi)解決——從一段工期轉(zhuǎn)移到下一個(gè)工期，通常會(huì)失去上下文，因此重啟它們更困難。另一個(gè)挑戰(zhàn)是，考慮到估計(jì)的難度，保持準(zhǔn)確地用時(shí)幾乎是不可能的。你可以嘗試限制固定時(shí)間，但這需要自律。

• 每段工期都要解決 N 個(gè)技術(shù)債問題

另一個(gè)極端是停止討論投入的時(shí)間，而只是從每個(gè)工期的積壓工作中拿出固定數(shù)量的技術(shù)債問題。

這里有一個(gè)明顯的問題，有些技術(shù)債問題可能很大，會(huì)占用工期的大部分時(shí)間。你如何確保時(shí)間被均衡分配？

• 將比較重要的技術(shù)債務(wù)當(dāng)作項(xiàng)目

有時(shí)，技術(shù)債務(wù)的形式是比較長的項(xiàng)目，實(shí)際上需要相應(yīng)的規(guī)劃和執(zhí)行。一個(gè)好的技術(shù)債項(xiàng)目的關(guān)鍵是真正把它們當(dāng)作常規(guī)項(xiàng)目：明確目標(biāo)、范圍、設(shè)定目標(biāo)（并對目標(biāo)進(jìn)行實(shí)際評估！）

• 將中等大小的技術(shù)債當(dāng)作涉及該系統(tǒng)或代碼庫的下一個(gè)項(xiàng)目的一部分

所謂的“童子軍規(guī)則”的一個(gè)版本：你應(yīng)該讓代碼庫和系統(tǒng)變得更好。

一種方法是經(jīng)常在項(xiàng)目中規(guī)劃一些額外的技術(shù)債償還。

這里的問題是，技術(shù)債喪失了優(yōu)先權(quán)——你償還什么技術(shù)債是由你下一個(gè)項(xiàng)目所接觸到的東西驅(qū)動(dòng)的。

要做到這一點(diǎn)，你還需要與你的產(chǎn)品同事建立牢固的信任關(guān)系，因?yàn)檫@對他們來說似乎是一種職責(zé)越權(quán)。

結(jié)束語

這似乎違反直覺，但速度可以降低成本；信心可以加快速度；信心需要品質(zhì)保證。循環(huán)往復(fù)。

原文鏈接：https://hackernoon.com/how-to-lead-your-teams-technical-debt-management

這個(gè)沒去大廠的程序猿，用 4 年時(shí)間證明自己做對了！

2021-11-28

曝騰訊天美程序員稅后250萬，月均20萬

2021-11-27

8年碼齡的技術(shù)總監(jiān)，去上市公司面試，結(jié)果涼了！

2021-11-26

系統(tǒng)架構(gòu)性能優(yōu)化思路

2021-11-25

“因?yàn)閮?nèi)存泄漏，我的 M1 MacBook Pro 癱瘓了”

2021-11-24

我碰到過很多聰明人，但他們永遠(yuǎn)做不成大事

2021-11-23

新人創(chuàng)作打卡挑戰(zhàn)賽發(fā)博客就能抽獎(jiǎng)！定制產(chǎn)品紅包拿不停！

總結(jié)

以上是生活随笔為你收集整理的如何领导团队做好技术债管理？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。