功能無法停止傳遞，遺留的技術債務問題怎麼解決

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

如果你曾在一家高速增長的軟體工程公司待過，你可能會聽過類似這樣的一段對話，是關于技術債務的：

張三：“如果我們隻做 X 的話，那麼我們可以更快地傳遞……”

李四：“說得挺有道理的嘛，那你為什麼還不去做呢？”

張三：“哎！我們要做這麼多功能，哪有時間啊，根本做不過來。”

或者是類似這樣的評論：

“我們真的需要這麼做。我們應該停止所有的功能開發工作，直到解決這個問題為止。”

對于這種情況，我一直持觀望态度。當我站在李四的立場來看，解決問題幾乎總是合乎邏輯的，但并不總是能得到所需的支援！

那麼，問題究竟在哪兒呢？為什麼償還技術債務明明是一個很明顯且合理的舉措，但是卻很難說服大家來做呢？

我們對技術債務的定義正确嗎？

“技術債務” （Technical Debt 或 Tech Debt），這一古老的流行語通常被當成一個包羅萬象的術語，用來描述我們希望我們所建構或正在開發軟體更好的東西。由于在開發早期階段所做的一些捷徑或權衡，軟體通常并不會達到預期的狀态。

凡是被貼上技術債務标簽的東西，幾乎都是軟體的非功能性更改。比如，重構代碼來消除全局代碼，進而支援依賴項輸入、修複（或添加）測試、改進文檔、甚至讓測試套件在 CI 中運作，或者最終實作部署的自動化之類的事情。

因為這些東西都不是功能性的改變，也不會改變軟體的行為，是以對客戶來說，這些改進他們很可能看不到。是以，如果客戶并不會看到你在這個技術債務上所耗費的時間以及軟體的任何變化，那你送出的價值又在哪兒呢？又為什麼要在技術債務上投入時間呢？

如何向别人闡述解決技術債務的價值

向客戶闡述解決技術債務的商業價值，是獲得解決債務所需時間的關鍵。

通常來說，人都會抱有一種固定思維模式（ “我們也想解決這個問題啊，但我們沒有得到允許去解決這個問題呀” ）。記住，在任何組織中，人們都會作出決策，決策是關于權衡的，是可以受到影響、被推翻或改變。更重要的是，組織也在不斷變化，昨天做出的決策方式，到明天可能就行不通了！

如果說溝通價值是關鍵，那麼技術債務的償還價值應該如何溝通呢？對于這一問題，沒有一個放之四海而皆準的答案：但我寫下本文的初衷是勾勒出這麼一個架構，幫助産品團隊或工程團隊對問題進行分類、時間配置設定，并明确為什麼每段時間都應根據它将提供的價值進行适當的調整。

我希望本文勾勒出的架構能夠幫助你與利益相關者保持一緻，讓你能夠更有效地溝通價值，并讓你最終解決你一直想解決的技術債務問題。

解決技術債務的最簡單方法

“解決問題的最簡單方法就是否認它的存在。”——Isaac Asimov

當我們遇到技術債務問題時，要先問問自己：這裡真的有問題嗎？很可能不值得付出，除非：

• 它提高了産出的速度或品質。例如，重做這個建構配置将使我們的傳遞時間縮短一半，使部署頻率增加一倍。

• 延誤導緻高昂的代價，造成工期緊迫。例如，如果我們現在不解決這個問題的話，将直接影響客戶、利潤或者是收入。

  如果它不是我上面說的這兩種情況中的一種，最好是直接忽略它。

将所有工作進行分類

在組織的每個計劃階段，無論你的計劃節奏或持續時間是怎樣的，都應該能夠将所有工作進行分類或配置設定到以下四個方面之一：

• 功能改進：提供客戶看得到或用得到的功能改變。通常情況下，産品經理 / 所有者會根據研究和客戶的意見，對如何優先考慮這方面的優先級進行深入研究。示例：新穎的新功能。
• 計劃工作：更大範圍工作的一部分，是在團隊之外 / 組織内部進行的，通常由項目經理協調，将你的團隊列為該工作計劃的依賴者。示例：全平台本地化 / 國際化工作。
• 傳遞能力：以可量化的方式提高傳遞速度或産出品質。示例：将部署過程自動化，以便更快 / 更頻繁地将代碼從主幹 / 主分支投入到生産環境中。

• 計劃外工作：當延誤會導緻高昂的代價，且造成工期緊迫時，你應優先考慮這項工作，并立即解決問題，或者是與其他所有正在進行的事情一起解決，而不是将它們推遲到你的積壓工作中或未來的周期，包括 bug、客戶支援請求、生産事故等。示例：影響 20% 的客戶的生産停工。

  通過将工作歸類到這四個方面中，溝通工作的價值應該會變得更容易，并且騰出時間來處理技術債務問題也會變得更容易。

請注意，上述分類應該适用于整個積壓工作，而不僅僅是技術債務問題，因為将時間配置設定給技術債務問題就意味着不能将時間配置設定給其他工作了。還要注意的是，技術債務可能會被歸類為傳遞能力或計劃外工作。

規劃的層次結構

前面我提到的 “在每個階段” 是有原因的：能夠在組織層次之間用一緻的詞彙進行溝通，有助于影響解決技術債務問題的投資決策。

許多科技公司采用的模式是，每個小組、團隊或 “雙披薩” 團隊往往負責管理受組織層次影響的積壓工作。如果你的組織是這樣運作的，那麼讓決策層了解這一架構将有助于你在術語、邏輯和論證上保持一緻。

譯注：“雙披薩”團隊是指遵循兩個披薩原則的團隊。兩個披薩原則最早是由亞馬遜 CEO 貝索斯提出的，他認為如果兩個披薩不足以喂飽一個項目團隊，那麼這個團隊可能就顯得太大了。因為人數過多的項目會議将不利于決策的形成，而讓一個小團隊在一起做項目、開會讨論，則更有利于達成共識，并能夠有效促進企業内部的創新。亞馬遜内部有所謂的 “雙披薩” 團隊，指的是團隊的人數相當于可以吃掉 2 個披薩，這種組織理論非常知名。“雙披薩” 團隊得名的由來，是因為團隊的成員很少，隻有 6-10 人，用兩張披薩就能喂飽他們。“雙披薩” 團隊最重要的不是規模，而是它的 “适度職責”。它相當于為一個部門的損益負責，可以讓團隊保持專注、負上責任。在一些案例中，“适度職責” 本身就是為損益負責，例如，如果我是 SEM（ 搜尋引擎優化）團隊的一員，我的職責就是通過贊助連結提高營收，獲得更多利潤，降低點選的成本。一旦獲得準許，團隊就可以相對自治的執行，将 “适度職責” 最大化，它們可以尋找創新戰略，然後将戰略作為内部優先之事對待。一些工程師，搭配一個或者兩個技術産品經理，配一個設計師，他們直接向 “雙披薩” 團隊的主管報告；在團隊之間沒有必要協作，他們可以獨立在各部門間行動，将工作完成。這種模式讓亞馬遜在增長的同時保持靈活和創新。

無法分類的技術債務問題

與任何模型或架構一樣，也存在不适合其結構的極端情況。乍一看，你可能無法忽略某個問題，但又不能将其分類為傳遞能力或計劃外工作。請不要在第一眼看到問題時就放棄：督促自己找到一種方法，通過稍微深入地研究問題的細節（或與同行、中小企業進行合作），将這些問題合理地歸結為其中之一。如果在第二次嘗試後仍然不适合，那也沒有關系。

“這個代碼很難測試。” —— 這是那些令人感到棘手的場景中的一個例子，在這種場景下，可能很難直接忽略它，或者說你不清楚如何對它進行分類。遇到這種情況，我建議采用以下方法：

對你的代碼做一些小規模的、漸進式的改進，不要試圖花時間來解決 “大爆炸式” 項目。

每個拉取請求（Pull Request）都應該改進你的代碼、改進你的測試，并提高測試覆寫率（或者至少不能退步！）。CI 系統中的品質檢驗甚至可以強制執行一些規則，例如不允許測試覆寫率下降超過 X%，并且要求最低覆寫率為 Y%。

如果這看起來不是一個易于處理的方法，那麼你可能需要找到一種方法來重新定義問題，以便将問題分解成更小的 “塊” ，也許其中一些部分可以被忽略，一些部分可以被分類，還有一些部分可以用上面提到的即用即付（PAYG）方法來處理。

合理配置設定時間

一旦你将工作分類到四個方面之一之後，下一步就是 “切餡餅” 或者為每個方面配置設定估計的時間。

這四個方面的時間配置設定如下：

40% 時間用于功能改進；

10% 時間用于計劃工作；

20% 時間用于傳遞能力；

30% 時間用于計劃外工作。

确定正确的時間配置設定比例

下面是我成功使用過的一個方法：從确定數字開始，與利益相關者一起審查，然後在适當的地方進行調整。

如果沒有利益相關的參與，就無法成功确定時間配置設定比例，這主要是因為這些比例通常是可以協商的，但也涉及許多決策，是以需要進行權衡。

你應該按什麼順序來确定數字？

第一個要确定數字的是 計劃外工作；這不應該是你自己決定的事情，而應該以你所掌握的資料為基礎，這些資料可以讓你能夠推斷出對未來一段時間的預期。例如，如果你在做季度計劃，你可能會看前一個季度所花費的時間，以及（特别是受季節性影響的企業）上一年同一季度所花費的時間。如果利益相關者試圖就這一數字進行協商，請向他們介紹你是如何确定這一數字的，并幫助他們了解你的實際情況。

要确定的第二個數字是 傳遞能力。為什麼呢？基于上述架構，我們希望從一個有目标、但有基礎的數字開始。每個人都應該有減少計劃外工作的動力，而傳遞能力就是實作這一目标的重點。如果你的計劃外工作 “太大” （每個企業的容忍度不同），請考慮增加你的傳遞能力時間配置設定，直到該數字變得可接受為止。如果你下調了這一數字，請確定已與利益相關者就此溝通并進行權衡。

建議：Google SRE 一書中關于 “擁抱風險” 主題在識别企業内部的風險承受能力方面有一些很好的想法，這可能有助于确定配置設定多少時間給傳遞能力這方面。雖然對某些團隊或組織來說，使用錯誤預算可能是一個非常有效的選擇，但同意一個管理錯誤預算和實施或測量 SLO 的系統本身往往是一個挑戰。我在本文中介紹的架構時間配置設定或許有些重疊，但在某些方面可能提供了一種配置設定時間的替代路徑，以解決一些品質或可靠性問題，否則這些問題将使用錯誤預算來解決。

要确定的第三個數字是 計劃工作。這些要求通常來自其他團隊或業務部門，有的要求比較好商量。試着根據你認為接下來的時間必須要做的事情來确定這方面的時間配置設定。

要确定的最後一個數字是 功能改進。此時，你已經确定了配置設定時間，因為你這時候處理的是剩餘的百分比。你可能聽說過 “價值流” 這個術語，團隊的活動應該以滿足客戶的要求為目标。這方面通常是最主要的，它直接解決的是你的客戶想 “看到” 的東西。如果這方面的時間配置設定對于你認為需要傳遞的價值而言過小，以至于不能滿足你的客戶在新功能傳遞方面的期望，我們将很快為這一方面提供更多的時間配置設定。

一旦完成每個方面的初始時間配置設定，你将需要考慮如何根據與利益相關者的讨論對此進行調整，在這個架構内有兩個 “杠杆” 可供考慮：

傳遞能力工作應該減少計劃外工作。

計劃工作影響功能改進工作。

減少計劃外工作

理想情況下，任何分類為傳遞能力的工作都會減少下一個計劃周期或工作節奏的計劃外工作量。

建議：請閱讀 Nicole Forsgren 博士、Jez Humble 和 Gene Kim 所著的《加速》（Accelerate）一書——這是一本關于衡量和思考如何提高軟體傳遞能力的優秀指南，裡面有關于軟體傳遞能力的優秀定義，以及 4 個關鍵名額，即傳遞周期、部署頻率、平均恢複時間（Mean Time To Restore，MTTR）和變更失敗率。

傳遞能力可能會在兩方面影響計劃外工作：

傳遞能力工作應降低平均恢複時間。即使計劃外工作方面中的 bug 或問題的數量沒有減少，解決它們所需的時間也應該減少，進而減少配置設定給計劃外工作方面所需的總時間。

傳遞能力工作應提高産出品質，進而降低變更失敗率。理想情況下，我們希望看到導緻計劃外工作方面的問題能随着時間的推移而減少，而提高産出品質（在正确性、可靠性、性能、安全性等方面）恰恰可以做到這一點。根據具體情況，有時優先考慮平均恢複時間，而不是降低變更失敗率的做法是有意義的，例如，如果恢複能力需要幾天的時間，而故障的數量很少，但卻保持不變，那麼在選擇減少平均恢複時間并更快地解決這些未來問題之前，你可能會為客戶提供更多的價值，因為停機或 bug 的持續時間可能比數量的影響更大。我們的目的是利用這兩個變量，但要根據客戶的價值來建構決策過程。

計劃工作的影響

我認為，計劃工作和功能改進之間的平衡是一種配置設定杠杆。通過與計劃的利益相關者合作，有時你可以推遲或重新配置設定你的團隊被要求做的工作 —— 隻要這個決定的理由清楚地表達出來，并且這些利益相關者也同意進行出這樣的權衡。

計劃通常是由多個項目、團隊和依賴項組成的龐大而複雜的工作。重要是要保持平衡，是以你要預料到 “阻擊者”，避免成為其他團隊的 “阻擊者”。項目經理或高層很容易要求你的團隊提前完成相關工作，但從你的角度來看，将工作推遲一周 / 月 / 季度可能意味着你配置設定時間改變的方式，以及最終你的團隊能夠為客戶帶來的價值存在着巨大的差異。

考慮到計劃外工作在某種程度上是固定的，而降低計劃外工作的杠杆很大程度上就是傳遞性能 —— 當你試圖找到更多時間配置設定給功能改進時，我建議與計劃利益相關者合作，允許你減少對計劃工作的配置設定時間。你應該能夠做到這一點，通過解釋你時間配置設定的原因，以及為什麼你認為對你的客戶來說，推遲他們的請求是最好的事情。

由于這個杠杆的結構方式，他們所做的權衡實際上是将價值傳遞給特定于你産品的客戶，而不是緻力于進行更大的創新。

最大化配置設定時間

一旦你的團隊完成了将待辦事項分類到這四個方面中的一個，并為每個方面配置設定了一定比例的工作時間，你如何才能真正執行呢？

每個團隊都是不同的：團隊規模、經驗水準、任期 / 專業知識等因素都會影響到誰負責什麼工作的決定。

然而，在配置設定給團隊的時間時，有一些事情是你應該考慮的，那就是個人之間的時間配置設定：

團隊中每個人都應該有為客戶提供價值的能力。

團隊中的每個人都應該擁有産出的品質。這包括正确性、可靠性、性能、安全性等。

讓中小企業繼續專注于一個領域隻會掩蓋或延緩風險和成本：例如，如果團隊中有人不在 / 生病 / 不能上崗，則會造成業務連續性的缺乏現象；當他們辭職時，可能會造成的知識轉移成本等等。

有時候，你可能會為了讓事情快速完成，而權衡将風險推遲，這不是不可以，但你應該確定團隊或利益相關者能夠意識到這一點，并就這個決定保持一緻。

衡 量

如果你确實考慮采用本文提到的這個架構，我強烈建議你在開始之前考慮一下如何衡量自己的具體情況。比如，如果你使用的是像 Jira 這樣的問題跟蹤器，那麼可以考慮添加一個字段或标簽，以便使你能夠将問題配置設定到四個方面中的一個。

在你的下一個周期或沖刺階段之前，你應該能夠快速報告你的預期分解是什麼，在這個周期結束之後，你應該能夠分析你的表現如何。這裡經常被問到的一個問題是，是否要跟蹤問題的總數，或者估算時間、工作量等等的總和？這實際上要取決于你團隊的工作方式，以及你認為什麼樣的努力會帶來更好的回報。不要追求一個完美的系統，隻需選擇一個你認為能夠提供足夠實用的東西即可，讓你知道自己是如何跟蹤的。

标記并跟蹤你在每個方面的進展情況，這一做法對計劃外工作特别有用，你可以以每周期一次更有規律的節奏進行觀察，是否對周期産生了比預期更大或更小的影響。

持續改進

組織、團隊或積壓工作都會發生變化，是以你的計劃和時間配置設定的方法也應該有所變化。使用持續改進的思維方式，讓衡量或資料驅動的決策成為你工作方式的一部分，類似計劃或沖刺回顧之類的慣例，将會幫助你更好地改進時間配置設定。

作者介紹：

Ryan D，專注 DevOps、安全、Go 語言、Linux、Docker、Kubernetes 等。曾任 Cloudflare 的 DevOps 工程經理。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/zhibo

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-05-18

本文作者：萬佳

本文來自：“

InfoQ

”，了解相關資訊可以關注“

”