四個經常被忽視的KPI指標 - Crowdbotics

banq發表於2021-03-01
KPI指標

在本文中，我將重點介紹如何有效地評估軟體開發效能，並舉例說明如何在FXStreet上實現它們。
多年來，已經進行了許多嘗試來衡量軟體團隊績效的困難。問題在於大多數模型都存在兩個主要缺陷：
  1. 他們專注於產出而不是結果。
  2. 他們專注於個人績效而不是團隊或公司績效。

在輝煌的過去中，一些公司使用許多程式碼行來衡量效能和生產率。這種方法的缺陷是顯而易見的，通常可以維護的行數更少，但是另一方面，幾行程式碼可能很難理解。因此，在大多數情況下，此KPI都不理想。
隨著敏捷方法的引入，流行的度量指標是速度。儘管比程式碼行更好，但它仍然很棘手，僅適用於團隊成員變化不大的孤立團隊或公司。在大型組織中，此度量可用於比較團隊之間的生產率，從而提高其估計值。
Nicole Forsgren的Accelerate提供了一種科學的方法來提高現代軟體開發中的生產率。在回顧了2000家組織之後，Forsgren概述了有關如何改善公司文化和績效的關鍵要點。在Accelerate中，Forsgren，Humble和Kim確定了4個度量標準，這些度量標準解決了前面解釋的2個常見陷阱。
  • 交付時間
  • 部署頻率
  • 更改失敗百分比
  • 平均恢復時間（MTTR）

 交付時間
交付時間可以告訴您從提出請求的客戶到得到滿足所需的時間。為了簡單起見，我們對定義進行了一些更改，對於我們來說，定義是從開始一項任務到為客戶提供價值（生產中）以來，需要花費多少時間。
我們使用Jira作為我們的任務管理工具，幸運的是，Jira擁有“控制圖”報告。它向您顯示任務（故事，錯誤等）處於特定狀態的時間。因此，在每次衝刺之後，我們都使用此圖表得出交付時間。
 

部署數量
部署數量告訴您一段時間內軟體開發已部署到生產中的次數，通常是sprint。
由於我們使用Azure DevOps來管理CI和CD的管道，因此我們在釋出過程中建立了一個步驟（PowerShell），該步驟儲存了部署內容和部署時間。
 

更改失敗百分比
變更失敗百分比告訴您生產失敗的變更百分比，包括修補程式，回滾，修復前瞻等。
這是最棘手的指標，可以採用多種策略來記錄此KPI：

  • 每次部署到生產中並且某些單元/整合/ ui /系統測試失敗時，都在表中記錄。
  • 如果您有部署前的批准，則當有人拒絕部署時，會自動記錄下來。
  • 如果有人在部署後發現錯誤，則可以建立與部署關聯的錯誤，並在每次衝刺之後對它進行計數。

在這種情況下，我們的方法是手動的，我們只檢視sprint中的所有部署，以查詢在短時間內兩次部署相同服務的情況，並記下某個功能釋出後是否有人發現了錯誤。
 

平均恢復時間
平均恢復時間告訴您解決緊急情況（如服務中斷）所需的時間。
 

結論
在閱讀了Accelerate之後，我決定將這四個指標付諸實踐，看看是否可以作為一個團隊來改善我們的軟體交付流程。在過去的3個月中，我們一直在使用這種方法，我看到了2個優點：

  • 最後，我可以向管理委員會中的非技術主管以及股東大會上的所有員工介紹有意義且易於理解的內容，僅因為這四個指標對每個人都很容易理解。
  • 更好的是，由於我們的團隊非常有競爭力，我們希望儘可能減少生產的交貨時間。這使我們找到了一種新的更好的方式來拆分SCRUM故事。來自積壓工作的每個子任務必須能夠獨立地部署到生產中。



 

相關文章