如何领导团队做好技术债管理？
來源：InfoQ
作者：Csaba Okrona（在 Contentful 擔(dān)任高級工程經(jīng)理）
譯者：張健欣
策劃：褚杏娟?
技術(shù)債（Technical debt，或 tech debt）在過去幾年中成為一個流行的術(shù)語。隨著時間的推移，我們的代碼庫和系統(tǒng)往往會變得“有缺陷”，這使得以后更難對其進(jìn)行更改或構(gòu)建。
技術(shù)債是 Ward Cunningham 的一個比喻。Ward Cunningham 是敏捷宣言的合著者，也是第一個 wiki 軟件的創(chuàng)建者。比喻，和模型一樣，幫助塑造我們對特定主題的思考。因此，為什么我們稱之為“技術(shù)債”而不是簡單的“有缺陷”？原因是，在某些方面，它類似于金融債務(wù)——如果我們不償還，它會對新功能及其維護(hù)造成損害，就像金融債務(wù)的利息積累一樣。
技術(shù)債的一個來源是我們在設(shè)計和構(gòu)建系統(tǒng)時有意識和無意識的權(quán)衡，缺乏干凈的代碼、文檔和最佳實踐。另一個來源是系統(tǒng)及其生態(tài)系統(tǒng)在演化，兩年前的完美解決方案現(xiàn)在不再那么完美了。
我將聚焦于技術(shù)來說服利益相關(guān)者“采納這個意見”，在產(chǎn)品開發(fā)中優(yōu)先安排償還技術(shù)債。
兩種積壓工作
讓我們先看看不要做什么。許多團(tuán)隊最終有兩種積壓工作——一種是以產(chǎn)品為中心的，另一種是以技術(shù)為中心的。這無法再生效是由于多種原因：
幾乎不可能在積壓的項目間穿插其它優(yōu)先的項目。
它助長了“我們 vs. 他們”的心態(tài)，這扼殺了團(tuán)隊凝聚力和共同目標(biāo)。
確定優(yōu)先級是整個團(tuán)隊的工作；把產(chǎn)品代表排除在外是行不通的。除非你對如何分 配團(tuán)隊力量有嚴(yán)格規(guī)定（例如，20% 持續(xù)用于技術(shù)債務(wù)），否則這會使工期規(guī)劃變得更加困難。
保留一個積壓工作并在那里添加任何類型的工作。如果你想要統(tǒng)計數(shù)據(jù)或過濾視圖，請隨意標(biāo)記技術(shù)債，但請確保將整個積壓工作一起安排優(yōu)先級。
不要讓技術(shù)債成為一場指責(zé)的游戲
另一個常見的錯誤是對技術(shù)債的爭論充滿了指責(zé)。我見過一些（工程和產(chǎn)品之類的）管理人員說這樣的話，“好吧，如果你一開始就創(chuàng)造了一個更好的解決方案，我們就不會處于現(xiàn)在這種情況”——這是愚蠢的、不人道的，最終也是毫無意義的。
沒有什么是完美的。我們都是人，時移世易，萬物變遷。接受這一點吧。我們能做的最好的事情就是從我們的錯誤中吸取教訓(xùn)，應(yīng)用良好的實踐，并盡可能清楚我們做的決策的利弊權(quán)衡。
玩指責(zé)游戲會使我們的注意力從解決手頭的問題上轉(zhuǎn)移開。這使大多數(shù)人都有防御性，會將討論變成不必要的來回扯皮，而不會更接近解決方案。
不帶指責(zé)的回顧和剖析才是正確的方式。解決方案總是系統(tǒng)性的，而不是針對個人的。
如何討論技術(shù)債
現(xiàn)在我們知道了該避免什么，讓我們來看看一些討論償還技術(shù)債的重要性的方法。這通常圍繞現(xiàn)有技術(shù)債務(wù)的風(fēng)險，由其引起的（維護(hù)）辛苦，以及它如何 阻礙新功能 的開發(fā)。
根據(jù)我的經(jīng)驗，大多數(shù)工程師不需要被說服去處理技術(shù)債務(wù)。事實上，正是他們提出了這一要求。另一方面，工程和產(chǎn)品經(jīng)理通常需要更多的上下文信息來理解償還技術(shù)債的重要性。
這里，你最好的策略是理解如何用你的利益相關(guān)者能夠理解的語言提供上下文信息。“好吧，為什么這很重要是無關(guān)緊要的”，這樣的說法是行不通的。你的待辦事項中還有 50 項對他們來說“非常重要”。
還有，不要把它說成是關(guān)于你自己的事情。你熱衷于解決這個問題是很好的，但是如果它聽起來像是你的寵物項目而沒有任何進(jìn)一步的爭論，那么它可能不會得到優(yōu)先考慮。我將向你展示幾種構(gòu)建觀點的方法。
題外話：這些都是關(guān)于將你的技術(shù)債務(wù)與你的內(nèi)部或外部客戶以及產(chǎn)品的性能關(guān)聯(lián)起來。
風(fēng)險
一定比例的技術(shù)債務(wù)附帶有相應(yīng)的風(fēng)險。一個簡單的例子是，當(dāng)你的解決方案使用的第三方（庫 / 服務(wù)）即將終止。這里的風(fēng)險是，如果你不升級或遷移到另一個受支持的解決方案，依賴第三方的系統(tǒng)可能會出現(xiàn)功能失調(diào)，或者（例如）將來會收不到安全補(bǔ)丁，從而有可能出現(xiàn)漏洞，這顯然對你的用戶或客戶不利。
當(dāng)然，并不是每種情況的風(fēng)險都是同等的——我們是會在下周下線，還是有比較低可能會在兩年內(nèi)發(fā)生低影響安全問題，這很重要。查看下面的“延誤成本”部分。
另一種風(fēng)險也與用戶保留有關(guān)，但是不那么直接。因為不太好的解決方案（想想頻繁的宕機(jī)和緩慢的服務(wù)）造成的低劣體驗造成了客戶流失的風(fēng)險。
技術(shù)債圍繞風(fēng)險的一些措辭示例：
我們可能在 2 個地方修復(fù)了一個 bug，但由于代碼重復(fù)而錯過了第 3 個。
當(dāng)前系統(tǒng)的設(shè)計可能會導(dǎo)致在高并發(fā)場景下的用戶體驗比較慢。
缺乏安全措施可能導(dǎo)致違約和法律責(zé)任。
由于我們?nèi)狈卧獪y試，可能會在功能中引入新的 bug。
代碼庫的復(fù)雜性和不靈活性導(dǎo)致我們由于開發(fā)時間太長而對新功能說不。
為了使你的論點更加有力誠懇，你要盡可能收集數(shù)據(jù)并使其成為論點的一部分。當(dāng)然，這并不總是可能的。請記住，數(shù)據(jù)也可以是行業(yè)最佳實踐，例如，長測試運(yùn)行時間 vs. 可接受的測試運(yùn)行時間。
???維護(hù)的辛苦
???在復(fù)雜或不靈活的代碼庫中，大多數(shù)任務(wù)將花費更長的時間，造成維護(hù)的辛苦；通過使用無效或缺失的工具，造成維護(hù)的辛苦。這一點，再加上大量的客戶和技術(shù)問題，可能會使整個團(tuán)隊陷入停頓，因為即使是微小的修復(fù)也需要一整天的時間來完成和發(fā)布。
現(xiàn)在，你需要 4 個小時來了解系統(tǒng)中發(fā)生了什么，另外 2 個小時來使測試通過，因為其中一些測試是不穩(wěn)定的，還有 1 個小時來部署你的修復(fù)程序，因為部署系統(tǒng) 5 次卡住了 3 次。
像上面的情況（應(yīng)該！）作為一種風(fēng)險盡量避免，但很多時候，只有當(dāng)風(fēng)險嚴(yán)重發(fā)生時（人們經(jīng)常大聲抱怨），你才會意識到這一點。
這里的數(shù)據(jù)主要是傳聞的，但你可以很好地了解你會節(jié)省多少時間，如果事情都完好運(yùn)行的話。與你的團(tuán)隊談?wù)勊麄儗υ黾庸ぷ髁康目捶?#xff0c;并提出一個粗略的估計來支持你的論點。
為了幫助你的利益相關(guān)者理解其重要性，請描繪一個持續(xù)向用戶提供價值的更好的世界。
開發(fā)新功能的效率
這里降低的效率，加上上面提到的辛苦，本身就值得說一說。雖然維護(hù)的辛苦會占用團(tuán)隊的時間，導(dǎo)致交付新功能的能力下降，但還有一些其它因素。
在難以理解的代碼庫中工作會降低開發(fā)速度（并可能增加引入的新缺陷的數(shù)量和嚴(yán)重性）。
使用這樣的代碼庫會使得團(tuán)隊投入更多時間和精力來引入新團(tuán)隊成員。
在一個設(shè)計拙劣或架構(gòu)過時的系統(tǒng)中實現(xiàn)一個解決方案是困難的。可怕的長達(dá)一個 月的重構(gòu)項目就是這樣誕生的。
在一個不適合你正在實施的新解決方案的系統(tǒng)中修修補(bǔ)補(bǔ)（基本上圍繞現(xiàn)有系統(tǒng)工作）通常會增加由此產(chǎn)生的系統(tǒng)的復(fù)雜性，并增加更多的技術(shù)債務(wù)——這是一個惡性循環(huán)!
優(yōu)先級排序技術(shù)
7.1 延誤成本
“延誤成本”并不是一個完整的優(yōu)先級排序技術(shù)，但在考慮風(fēng)險時，它是一個方便的屬性。
延誤成本是精益管理中的一個指標(biāo)。它結(jié)合了緊迫性和價值——人類并不擅長區(qū)分這兩件事。
由于大部分時間我們傾向于只關(guān)注生產(chǎn)成本和其它固定成本，我們很難確定優(yōu)先級，因為一些成本是不可預(yù)測的，潛在價值也可能是不可預(yù)測的，因為隨著時間的推移，這些都不是固定的。更好的方法是計算延誤成本。該值表示公司晚于市場或客戶期望的時間交付特定功能 / 項目 / 產(chǎn)品所產(chǎn)生的隨時間稀釋的成本。
計算延誤成本隨著時間的變化，需要相當(dāng)成熟的跟蹤和監(jiān)控。計算延誤成本隨時間變化的另一種方法是選擇以下模型之一：
你對某個問題的延誤成本模型的判斷將告知你的影響評級。
7.2 ICE 和 RICE 得分
你最終會得到許多不同大小和影響的項目，然后變得非常混亂。ICE 有助于為這種混亂帶來秩序，它可以通過一種系統(tǒng)性的方法來評估這些項目，并創(chuàng)建一個單一數(shù)字表示它們的優(yōu)先級，你可以簡單地借此對它們進(jìn)行排序。
ICE 代表影響（Impact）、信心（Confidence）和努力程度（Ease/Effort）。RICE 中的 R 代表影響范圍（Reach）。
對于其中每一個因素，團(tuán)隊在一組數(shù)值點上達(dá)成一致，例如：Massive = 3 High = 2, Medium = 1, Low = 0.5, Minimal = 0.25
影響 —— 解決此問題會對客戶產(chǎn)生什么影響（記住，客戶也可能是內(nèi)部的！）——或者，在考慮風(fēng)險時，解決此問題不會產(chǎn)生什么影響？
信心 —— 你對影響（以及可選的努力程度）的估計有多大信心？
努力程度 —— 努力程度通常更容易談?wù)摗鉀Q問題需要付出多少努力？請記住，這是一個相對指標(biāo)，只能與當(dāng)前批次中的其它問題進(jìn)行比較。
響應(yīng)范圍 —— 這將影響多少人？100% 的客戶群？還是只有某一特定角色的客戶？重要的是，要了解這些分?jǐn)?shù)僅在本地相對環(huán)境中有意義，不應(yīng)跨域進(jìn)行比較。
一旦你有了這些數(shù)字，計算就很容易了：
RICE 得分 = (Impact x Confidence) / Effort or Impact x Confidence x Ease
在這篇很棒的文章中 可以了解更多關(guān)于 RICE 和 ICE 的內(nèi)容。
關(guān)于如何實際削減技術(shù)債務(wù)的一些建議
我可以快速重復(fù)這些策略來實際削減技術(shù)債務(wù)。這里沒有完美的策略，每一種策略都有利弊權(quán)衡。
為技術(shù)債分配專用力量
有些團(tuán)隊將一定比例的工期時間用于各種類型的工作。一個常見的設(shè)置是 70% 用于功能開發(fā)，20% 用于技術(shù)債，10% 用于學(xué)習(xí) / 實驗。
這種設(shè)置的挑戰(zhàn)是，通常比較大的技術(shù)債問題無法在 20% 的時間內(nèi)解決——從一段工期轉(zhuǎn)移到下一個工期，通常會失去上下文，因此重啟它們更困難。另一個挑戰(zhàn)是，考慮到估計的難度，保持準(zhǔn)確地用時幾乎是不可能的。你可以嘗試限制固定時間，但這需要自律。
每段工期都要解決 N 個技術(shù)債問題
另一個極端是停止討論投入的時間，而只是從每個工期的積壓工作中拿出固定數(shù)量的技術(shù)債問題。
這里有一個明顯的問題，有些技術(shù)債問題可能很大，會占用工期的大部分時間。你如何確保時間被均衡分配？
將比較重要的技術(shù)債務(wù)當(dāng)作項目
有時，技術(shù)債務(wù)的形式是比較長的項目，實際上需要相應(yīng)的規(guī)劃和執(zhí)行。一個好的技術(shù)債項目的關(guān)鍵是真正把它們當(dāng)作常規(guī)項目：明確目標(biāo)、范圍、設(shè)定目標(biāo)（并對目標(biāo)進(jìn)行實際評估！）
將中等大小的技術(shù)債當(dāng)作涉及該系統(tǒng)或代碼庫的下一個項目的一部分
所謂的“童子軍規(guī)則”的一個版本：你應(yīng)該讓代碼庫和系統(tǒng)變得更好。
一種方法是經(jīng)常在項目中規(guī)劃一些額外的技術(shù)債償還。
這里的問題是，技術(shù)債喪失了優(yōu)先權(quán)——你償還什么技術(shù)債是由你下一個項目所接觸到的東西驅(qū)動的。
要做到這一點，你還需要與你的產(chǎn)品同事建立牢固的信任關(guān)系，因為這對他們來說似乎是一種職責(zé)越權(quán)。
結(jié)束語
這似乎違反直覺，但速度可以降低成本；信心可以加快速度；信心需要品質(zhì)保證。循環(huán)往復(fù)。
原文鏈接：https://hackernoon.com/how-to-lead-your-teams-technical-debt-management
這個沒去大廠的程序猿，用 4 年時間證明自己做對了！
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
“因為內(nèi)存泄漏，我的 M1 MacBook Pro 癱瘓了”
2021-11-24
我碰到過很多聰明人，但他們永遠(yuǎn)做不成大事
2021-11-23
總結(jié)
以上是生活随笔為你收集整理的如何领导团队做好技术债管理？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Yarn 内存分配管理机制及相关参数配置
- 下一篇： 很多未解之谜终于有答案了——2018年J