如何使用DORA工程指標來改進軟體開發團隊

用於衡量軟體開發工作的客觀資料和指標一直存在。但很長一段時間以來，人們認為使用這些資料或指標來衡量軟體開發的想法是不可能的。而Martin Fowler和Joel Spolsky等軟體開發專家也認為這是不現實的。顯然，衡量軟體開發工作是一項具有挑戰性的任務，這讓一些軟體開發人員感到沮喪。

而如今隨著Git、Jira和其他項目管理工具等工具的興起，其指標開始變得清晰起來，使人們能夠更密切地、以資料驅動的方式檢視軟體開發項目內部發生的事情。

當然，很多組織已經開始採取行動。其中最重要和最著名的結果之一是由DevOps研究和評估組織(DORA)完成的。該組織在六年的時間裡對數千名DevOps工程師和領導者進行了調查，最終推出了被認為對軟體開發項目成功至關重要的四個指標。

四個DORA工程指標是：

• 部署頻率

• 變更的平均交付週期

• 平均恢復時間(MTTR)

• 更改故障率

部署頻率和變更的平均交付週期這兩個指標用來衡量開發團隊的開發速度。平均恢復時間(MTTR)和更改故障率用來衡量項目質量和穩定性。所有四個指標都可以通過挖掘開發團隊當前使用的工具得出。

這四個DORA工程指標旨在允許開發團隊根據業務目標調整他們的工作，它們已成為組織中的首席技術官(CTO)和工程副總裁獲得有關其組織績效的標準方式。通過密切關注並改進DORA指標推進開發團隊的工作，開發團隊可以確保他們做正確的事情來推動他們的項目，更重要的是他們的業務如何向前發展。

當然，瞭解指標實際衡量的內容及其含義對於使它們有用是必要的。此外，瞭解這些指標的當前狀態是在開發團隊改進它們的必要條件。

以下了解這四個關鍵指標。

1. 部署頻率

(1) 它是什麼?

部署頻率衡量程式碼部署到生產中的次數。通常在「每日部署」中報告。

生產如今對不同的客戶意味著不同的東西。對於SaaS公司來說，通常意味著將程式碼實際交付給客戶實際使用的生產平臺。對於其他公司，這可能意味著提供可供客戶使用的版本。

(2) 為什麼重要

增加部署頻率表明開發團隊的效率和對其流程的信心。能夠更頻繁地部署的團隊能夠更快地將工作轉移到他們的管道中，並且更高效地開發和處理他們的產品。

(3) 它是如何計算的?

它記錄了組織在一天內進行的部署總數。如上所述，「部署」的定義可能因組織而異。如果軟體開發團隊擁有持續整合(CI)/持續交付(CD)工具為其活動提供API，則該指標可以實現自動化。

(4) 如何改進它?

如果組織希望提高部署頻率，應該：

• 提高自動化測試覆蓋率。

• 與持續整合(CI)/持續交付(CD)工具整合。

• 自動化釋出驗證階段和釋出流程。

• 減少生產中的錯誤恢復時間。

2. 變更的平均交付週期

(1) 它是什麼?

變更的平均交付週期是從提交程式碼到將程式碼釋出到生產中所需的平均時間。

一些組織從項目程式碼的第一次提交開始來計算時間，而另外一些組織從將程式碼合併到主分支開始計算時間。

許多組織將變更的平均交付週期轉化為一個稱為週期時間(Cycle Time)的指標，以下將對此進行討論。

(2) 為什麼重要

較低的平均交付週期意味著組織的開發團隊可以高效地編碼和部署項目，並及時為其產品增加價值。試圖降低平均水平會激勵團隊適當地劃分工作、徹底審查程式碼並進行快速部署。

(3) 它是如何計算的?

每個項目都從頭到尾進行衡量，並計算這些時間的平均值。

(4) 如何改進它?

該指標可以通過以下方式改進：

• 將自動化新增到部署過程中。

• 確保持續整合(CI)/持續交付(CD)流程儘可能高效。

• 將項目分成更小、更易於管理的塊。

• 創建高效的程式碼審查流程。

3. 平均恢復時間(MTTR)

(1) 它是什麼?

該指標衡量團隊從系統故障中恢復所需的平均時間。而「故障」可能意味著任何事情，從生產中的錯誤到生產系統宕機。

(2) 為什麼重要

顯然，停機時間越短越好，團隊需要更快恢復。關注平均恢復時間將鼓勵構建更強大的系統，並加強對這些系統的監控。

快速恢復時間反映了開發團隊診斷問題和糾正問題的能力。測量平均恢復時間可以使團隊在整個開發過程中更加謹慎，並關注質量。

(3) 它是如何計算的?

通常情況下，通過測量系統中創建生產錯誤報告與解決該錯誤報告之間的平均時間來跟蹤此指標。或者，它可以通過測量創建報告和將修復部署到生產之間的時間來計算。

(4) 如何改進它?

平均恢復時間(MTTR)可以通過以下方式變得更好：

• 構建快速報告故障的持續整合(CI)/持續交付(CD)系統。

• 確保有一個對故障立即採取行動的流程。

• 將故障恢復優先於所有其他任務。

• 縮短部署時間。

4. 更改故障率

(1) 它是什麼?

更改故障率衡量程式碼更改導致生產故障的頻率。導致回滾、生產失敗或生產中出現錯誤的更改都會影響該指標。

(2) 為什麼重要

這個指標很重要，因為花在處理故障上的所有時間都不是花在向客戶交付新功能和價值上的時間。顯然，減少軟體中的問題是可取的。

(3) 它是如何計算的?

通常情況下，該指標的計算方法是計算部署導致故障的次數，然後除以總部署數以獲得平均值。平均值越低越好。

(4) 如何改進它?

當組織執行以下操作時，更改故障率會得到改進：

• 確保自動化單元測試涵蓋所有新程式碼。

• 作為持續整合過程的一部分改進自動化測試。

• 進行徹底和完整的程式碼審查，以幫助防止將問題引入生產中。

跟蹤DORA指標的好處

(1) 決策

始終如一地跟蹤DORA指標，將使開發團隊能夠在何處以及如何改進開發過程做出更好的決策。這樣做將揭示面臨的瓶頸，並使開發團隊能夠將注意力集中在可能導致流程停滯的地方，還可以確定發展趨勢，並且驗證關於關注點的決策質量。

跟蹤DORA指標可以幫助開發團隊和企業管理人員將注意力集中在能夠真正推動價值的事情上。它們使開發團隊能夠根據指標做出決策，而不僅僅是憑直覺做出決定。

(2) 交付價值

DORA指標可以衡量開發團隊交付的價值。如果DORA指標是有利的，則組織的開發團隊將為其客戶提供價值並保持必要的質量，以免偏離重點。這是組織的主要目標——為客戶提供價值。

(3) 良性迴圈

當任何東西被衡量時，它很可能會被人為操縱或更改———也就是說，人們會改變行為來優化被衡量的東西。很多時候這會對開發團隊的工作產生負面的的影響。

組織希望開發團隊努力優化這些DORA指標，可以提高效率並減少浪費，這會帶來良好的結果。通常情況下，刻意追求指標會對開發團隊產生負面影響，因為這些指標是經過精心設計的，其目的卻恰恰相反。

LinearB幫助組織衡量和改進DORA工程指標

DORA指標很重要，而LinearB可以輕鬆跟蹤它們，為組織提供開箱即用的DORA指標，可以輕鬆顯示和跟蹤。

通過向開發組織的高管提供其DORA指標的更高級別檢視，這樣的儀表板可能會很有用。通過簡單的檢視，高管可以一目瞭然地瞭解開發團隊的工作情況以及可能需要進行哪些中途更正的事項。

除了DORA指標之外，LinearB還可以跟蹤有助於提高組織績效的其他指標。例如拉取請求大小、拉取請求審查深度和拉取請求審查時間等指標都可以監控，改進後將會減少更改的平均交付週期和部署頻率。

LinearB超越DORA指標

LinearB超越了DORA的變更的平均交付週期指標，以提供週期時間(Cycle Time)指標。

週期時間是一個強大的指標，用於衡量給定程式碼單元從分支創建到生產部署所需的時間。它實際上是對給定任務或子任務交付給終端使用者速度的衡量。當然，交付功能是每個開發組織的目標之一。

週期時間分為四個部分：

(1)編碼時間——通常是指第一次提交到給定分支和為該分支創建拉取請求之間的時間。

(2)拉取請求時間——這是創建拉取請求和開始審查該拉取請求之間的時間。

(3)拉取請求審查時間——從拉取請求審查開始到合併程式碼之間的時間。

(4)部署時間——部署時間是程式碼合併和程式碼實際部署到生產之間的時間跨度。

改善週期時間有很多好處：

• 密切跟蹤編碼時間可以鼓勵開發團隊將開發工作分成更小、更易於管理的塊。如果給定的分支或項目很大並且需要很長時間，那麼週期時間就會增加。相反，它鼓勵更小的工作量。

• 推動團隊及時處理拉取請求。它有助於防止緩慢的拉取請求和過大而無法有效審查的拉取請求。

• 跟蹤部署時間的團隊被激勵專注於改進和簡化構建和部署流程。

• 週期時間的增加可以成為項目遇到困難的早期預警系統。如果必須為團隊選擇一個指標來衡量，那就是週期時間。

WorkerB改進了DORA指標

空閒時間是在軟體開發過程中等待事情發生的時間——拉取請求閒置且未經審查就是一個很好的例子。它是影響DORA中的部署頻率和平均變更提前期這兩個重要指標的主要因素。

WorkerB是由LinearB提供的一項功能，它可以減少對空閒時間產生的積極影響，從而提高組織的DORA指標。通過通知團隊成員有關儲存庫事件，可以確保團隊立即瞭解週期時間的組成部分(例如拉取請求提取時間和拉取請求審查時間)，並允許他們以更及時的方式做出反應。

根據LinearB一些使用者的反饋，在使用WorkerB的前四個月內，週期時間減少了50%以上。

衡量成功

DORA指標基於對軟體開發團隊的多年研究。通過DORA指標來衡量成功將通過組織的開發管道交付更多價值。

LinearB可以幫助組織的開發團隊始終如一地跟蹤它們，從而對其軟體開發過程和業務產生深遠而持久的影響。