生產力指標。關於軟件中的性能測量，您需要了解什麼？

儘管特定編程語言、工具和技術的實用技能和知識是作為軟件開發人員找到一份全職工作的關鍵，但還有另一個有價值的指標，在許多方面可以被視為在這個職業中取得成功的先決條件：生產率。生產力衡量是所有專業軟件開發人員都需要了解和考慮的事情，因為性能指標對於當今商業環境中的任何軟件開發團隊來說都非常重要。

為什麼您作為開發人員的生產力很重要？

在敏捷開發、DevOps 和縮短軟件發布週期的時代，當開發人員需要盡快發布產品的新版本時，公司會使用多種不同的生產力指標來評估單個程序員和整個團隊的表現。從開發人員的角度來看，性能測量可以服務於許多有價值的目的，幫助您跟踪編程技能的進步，這將使您實現持續的專業成長。高效的編碼人員最終會收到令人瞠目結舌的薪水，並開始從事最令人興奮的項目。但即使你不是一個高成就者，只是想從事軟件開發方面的任何工作並在其中取得相當大的成功，您仍然需要至少對績效指標以及如何使用它們來衡量工作投入的生產率有基本的了解。這就是我們今天要討論的內容。

軟件開發生產力測量指標

什麼是軟件開發生產力指標？

軟件開髮指標是編程工作的領域，可以應用定量測量來跟踪開發人員的性能、工作質量和生產力。每個生產力指標都基於從開發過程中獲取數據並使用它來衡量生產力。由於與軟件開發相關的幾乎沒有任何事情是簡單直接的，您可以說衡量編程生產力在整個行業中也非常不一致和分散。或者，簡單地說，不同的團隊和公司可以使用完全不同的績效指標，從多個角度來解決這個問題。因此，您無需費心學習軟件開發團隊可能使用的每一個指標。

有哪些類型的軟件開發生產力指標？

自然地，有多種不同的生產力指標可以從不同的層面和角度衡量績效。以下是此類生產力指標的最常見類型：

• 正式的以規模為中心的指標。

這些指標側重於衡量程序員工作成果的大小，例如代碼行數 (LOC)、代碼指令長度、代碼複雜度等。在當今的軟件開發行業中，這些指標越來越被認為已經過時。

• 以時間和功能為中心的生產力指標。

瀑布式軟件開發中使用了一系列傳統的生產力指標，例如活躍天數、特定時間段內發布的功能範圍、代碼改動率、分配的任務數量等。

• 敏捷開發過程指標。

敏捷開發過程指標，如衝刺燃盡報告、速度、提前期、週期時間等，可能是當今軟件開發團隊最常用的指標。我們將在本文後面更詳細地討論敏捷指標。

• 運營分析指標。

這組指標側重於衡量軟件在其當前生產環境中的性能。平均故障間隔時間 (MTBF)、平均恢復時間 (MTTR) 和應用程序崩潰率是此處最常用的指標。

• 測試指標。

軟件測試有自己的一套指標來衡量系統測試的質量，例如自動化測試的百分比、代碼覆蓋率等。

• 客戶滿意度指標。

最後，任何軟件的最終指標都是最終客戶體驗，並且還有一整套指標，例如客戶努力得分 (CES)、客戶滿意度得分 (CSAT)、淨推薦得分 (NPS)和別的。

敏捷軟件開髮指標

如您所見，很容易迷失在軟件生產力指標的所有復雜性中。然而，普通軟件開發人員唯一應該熟悉的是敏捷指標，當今軟件開發團隊通常將其用作衡量軟件開發生命週期不同部分的團隊生產力的標準。讓我們列出主要和最常用的敏捷指標。

1. 衝刺燃盡。

Sprint Burndown 報告是敏捷 Scrum 開發團隊的關鍵指標之一。在敏捷中，開發過程是通過有時間限制的衝刺來組織的，Sprint Burndown 被用作在衝刺期間跟踪任務完成情況的一​​種方式。小時或故事點用作度量單位。目標是實現一致的進展，並根據最初的預測交付工作。Sprint Burndown 幫助團隊衡量工作節奏並在需要時進行調整。

2. 團隊速度。

速度是另一個關鍵指標，它也是以小時或故事點數作為衡量單位。它衡量團隊在衝刺期間完成的平均工作量，並用於整個項目的估算和規劃。跟踪速度對於確保團隊提供一致的性能非常重要。

3.故事點。

在單個開發團隊成員的級別上，故事點是一個有價值的指標，因為程序員在每次發布期間交付的故事的大小是該編碼員生產力的指標。

4.週期控製圖。

測量從任務或另一個積壓項目的工作開始到完成的總時間。允許跟踪和控制週期時間，提供更可預測的結果。

5. 吞吐量和交付價值。

項目經理分析分配給開發人員的任務並為他們分配價值。然後使用該指標衡量團隊的吞吐量，換句話說，衡量完成的增值工作量。

6. 代碼流失。

代碼流失是另一個值得一提的指標，因為它既可用於衡量整個團隊的生產力，也可用於跟踪單個程序員的表現。代碼流失衡量開發人員刪除或更改之前添加的代碼行的頻率，以及之前編寫的代碼最終被更改或丟棄的百分比。

專家意見

最後，補充一些觀點，引用經驗豐富的軟件開發行業專業人士對此事的一些看法。“我確實希望您不要將您的指標與某種標准或什至與另一家公司的另一個團隊的績效進行“比較”。在我工作過的每個地方，他們對故事點、速度、每小時估算、任務等的定義都有獨特的差異，這真的使得幾乎不可能將一家公司的一個團隊的績效直接與另一家公司的另一個團隊的績效進行比較公司，”前技術產品經理兼敏捷教練 Cliff Gilley指出. “在指導團隊績效方面，我對指標有點懷疑。一旦你只關註一個或兩個變量，就很容易陷入（有意或無意）衡量指標的遊戲並自欺欺人地認為你正在改進 - 當你所做的只是改進指標時。例如，基於速度的指標可以通過團隊轉移到更小的故事來“改進”（每個故事的工作更少——所以完成的故事更多——所以速度上升）。如果這些故事是有用的用戶故事，可以提供較小的商業價值增量，那可能是一件好事。如果故事變得更小，更“技術性”的任務本身並不能帶來真正的價值，那可能是一件壞事，”另一位行業專家 Adrian Howard說. “在基於拉動的系統中工作時，我重視吞吐量和周期時間。第一個給了我關於我們團隊能力的一般信息，隨著時間的推移可以成為一個非常強大的預測指標。第二個有助於作為我們管道效率的一般衡量標準。如果週期時間很長，是時候開始查看管道了，因為有一個限制條件，我們可能會努力緩解/利用。但指標只是工具。不要迷失在其中，當然也不要開始針對特定指標進行計劃。想想你作為一個團隊在做什麼，以及你自然如何工作，然後圍繞人構建系統。這些指標應該可以幫助您了解您的系統如何支持每個人的工作。或者不是，”視頻遊戲開發製作人戴夫·塞拉 (Dave Cerra)總結道。