長期以來，衡量軟件工程團隊的績效一直被視為一項複雜而艱巨的任務。随着軟件變得更加複雜和分散，尤其如此。

為了交付更好的軟件，工程團隊需要持續改進的可見性、數據和決策。軟件工程團隊用來管理流程和發布軟件的應用程序可以訪問比以往更多的數據。團隊可以使用這些數據來衡量他們的績效——如果他們知道哪些數據最準确地反映了團隊績效。

Google的DevOps 研究和評估(DORA) 團隊設計了一個為期六年的計劃，以了解高績效軟件工程團隊與低績效軟件工程團隊的區别。他們調查了多個行業的數千個團隊，以衡量和了解 DevOps 實踐和能力。這是同類中運行時間最長的學術嚴謹調查，提供了對推動技術交付以及最終組織成果的高性能的可見性。

DORA 團隊有兩個他們想要驗證的假設：

1. 軟件工程團隊的績效可以用一種有意義的方式來衡量。
2. 高績效的軟件工程團隊（基于他們發現的衡量标準）可以預測更廣泛的組織績效。簡單來說，高績效團隊為組織帶來高價值。

DORA 發現，高績效組織更關注工程成果而不是産出，而團隊則更關注個人。從研究中，他們确定了表明軟件工程團隊績效的四個關鍵指标：

1. 部署頻率
2. 平均變更提前期
3. 平均恢複時間
4. 更改失敗率

這些指标提供了一種數據驅動的方法來分析和改進基于實際研究的性能。DORA 使用這些指标來識别精英、高、中、低績效團隊。他們的研究發現，精英團隊實現或超過其組織績效目标的可能性是低績效團隊的兩倍。

讓我們更深入地研究這四個指标，以了解關注它們如何幫助團隊更快、更有效地交付軟件。

在高層次上，DORA 工程指标衡量軟件工程團隊的速度以及他們構建和發布的軟件的穩定性。如果團隊可以不斷改進這些指标，他們就可以更快地向客戶發布更高質量的軟件。

對于以下四個 DORA 工程指标中的每一個，我們将介紹指标是什麼、如何計算、為什麼重要、如何改進以及精英團隊的目标價值。

部署頻率是軟件工程團隊将代碼部署到生産環境的頻率。這個重要的指标可以代表團隊為客戶提供新價值的頻率。

持續交付和交付代碼，因為快速、小型、頻繁的部署是 DevOps 的關鍵組成部分。部署頻率揭示了團隊的工作和發布流程的效率。例如，如果部署頻率變慢，則可能表明新工作流程存在問題。測量部署頻率可以揭示變更對團隊結構、人員或流程的更廣泛影響。與其他指标一起測量部署頻率可确保部署的更改為客戶增加真正的價值。

部署頻率通常以每天的部署報告。您可以通過從團隊的持續集成/持續交付工具中提取數據來自動執行此測量。

軟件工程團隊可以采用一些實踐來提高他們的部署頻率：

• 減少每批工作的大小，以便團隊可以更頻繁地交付較小的工作。另一個優勢：風險較小的部署可以在出現問題時輕松跟蹤或回滾。
• 與持續集成/持續交付工具集成，以提高發布過程的效率。
• 在将新更改部署到生産環境之前，使用自動化測試來提高對代碼質量的信心，并減少對緩慢手動測試的需求。

精英團隊每天多次部署生産變更，以持續為客戶增加價值。

變更提前期（也稱為周期時間）是從代碼提交到代碼成功運行所花費的時間。它允許您跟蹤軟件工程團隊的步伐。更快的團隊優化了流程，可以更快地将新功能推向市場。這種提高的效率為增加組織收入、提高客戶續訂率和創建快樂高效的團隊提供了機會。另一方面，交付速度較慢意味着流程中存在浪費或效率低下，從而導緻客戶延誤。

衡量變更提前期還有助于團隊識别其工作流程中的瓶頸，以便他們可以優化和改進。

平均變更提前期是通過跟蹤每個代碼提交到生産中交付的代碼之間的時間并計算平均值來計算的。

軟件工程團隊可以采取哪些措施來改善他們的平均變更提前期？

• 将測試集成到開發過程中。
• 自動化測試而不是手動測試。
• 與持續集成/持續交付工具集成
• 簡化代碼審查流程以減少延遲。

精英團隊的平均變更提前期低至一小時。

平均恢複時間衡量軟件工程團隊從故障中恢複的速度。故障是指任何中斷預期生産服務質量的事情，從部署中引入的新錯誤到托管基礎設施出現故障。平均恢複時間表明軟件工程團隊能夠以多快的速度理解和解決生産中出現的問題。停機時間對客戶來說從來都不是好事。較短的平均恢複時間讓團隊有信心，如果生産受到影響，它可以迅速恢複到功能狀态。

平均恢複時間是通過跟蹤報告生産錯誤或故障與修複該問題之間的平均時間來計算的。

以下是軟件工程團隊可以提高平均恢複時間的一些方法：

• 引入可快速報告生産故障的監控工具。
• 實施強大的待命和支持文檔系統。
• 縮短部署時間，以便可以将已修複的問題快速發布到生産環境中。
• 使用功能标志，您可以通過單擊按鈕來打開/關閉生産中的功能。這可以将平均恢複時間減少到幾秒鐘。

精英團隊的目标是平均恢複時間少于一小時。

變更失敗率衡量軟件工程團隊發布導緻失敗的生産變更的頻率。這些更改會導緻錯誤或必須回滾，因為它們不符合客戶的期望。該指标表明團隊構建的軟件的質量。修複錯誤和回滾代碼是一項代價高昂的工作，因為它占用了可用于構建為客戶增加價值的新功能的時間，因此高更改失敗率表明低質量的軟件會讓客戶感到沮喪。

更改失敗率以百分比計算。它是每個部署次數的失敗次數與生産的比率。

軟件工程團隊可以實施這些實踐來提高他們的變更失敗率：

• 引入自動代碼審查工具來捕捉手動代碼審查遺漏的問題。
• 為所有新代碼添加自動化測試。
• 使用持續集成/持續交付工具運行所有自動化測試作為發布過程的一部分。
• 引入事件回顧，以便團隊了解導緻事件的原因并努力确保它不會再次發生。

精英團隊的目标是讓變更失敗率在 0% 到 15% 之間。

當然，在評估軟件工程團隊的績效時，這些并不是您可以考慮的唯一指标。您可以跟蹤的許多其他指标可以提供對團隊績效的洞察。然而，DORA 發現這四個指标與更廣泛的組織成功最相關。

四個 DORA 指标看起來很簡單，但如果使用不當，就會産生問題。

每個使用 DORA 工程指标的團隊都存在于自己的環境中，其産品/服務将與其他團隊不同。這些指标應該用于幫助各個團隊不斷改進他們的交付。一種反模式是使用指标來對您的團隊進行相互評分。這是不公平的，因為每個團隊的背景和出發點都不同。

一起考慮所有四個指标，而不是隻關注一個子集。這些指标旨在平衡速度和質量，因此對子集進行歸零可能會導緻性能下降。例如，如果您發布的許多更改都有錯誤，那麼高部署頻率可能會對質量産生負面影響。

這些指标不應該消耗你的團隊，成為他們唯一關注的事情。改進指标永遠不應該是你的主要目标。古德哈特定律說：“任何成為目标的措施都不再是好的措施。” 目标應該是不斷、有效地為客戶提供價值，使用指标來反映您的團隊朝着該目标取得的進展

最後，确保 DORA 工程指标不會成為顯示數字的虛榮指标，但沒有提供關于采取什麼行動的明顯線索。如果一個團隊部署 100 次，這意味着什麼？一天、一周、一年有 100 次嗎？自上次測量以來，這個數字是否有所改善？如何改進？其他指标是否受到影響？DORA 指标幫助團隊評估和提高他們的績效，但為了讓團隊采取有意義的行動，他們需要了解指标在上下文中做了（和不）表明什麼。

軟件工程團隊一直在尋找改進流程和交付的方法。多年來，團隊一直缺乏一種客觀、有意義的方式來衡量他們的表現。DORA 團隊希望通過關注指标來改變這種狀況，這些指标不僅可以表明團隊的表現，還可以揭示有關組織整體健康狀況的重要線索。

您的團隊在 DORA 的四個指标方面的表現如何？這對您的組織有什麼影響？

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!