如何领导团队做好技术债管理?
來源: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