[[419257]]

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

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

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

四個DORA工程指標是：

(1)部署頻率

(2)變更的平均交付周期

(3)平均恢復時間(MTTR)

(4)更改故障率

部署頻率和變更的平均交付周期這兩個指標用來衡量開發團隊的開發速度。平均恢復時間(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可以幫助組織的開發團隊始終如一地跟蹤它們，從而對其軟件開發過程和業務產生深遠而持久的影響。

原文標題：How To Use DORA Engineering Metrics To Improve Your Dev Team，作者：Nick Hodges

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】