作為軟件交付的一個重要環節，程序開發需要所有團隊成員都不斷關注每一個細節。任何稍許的代碼級缺陷都會影響整個項目進程和產品質量。據相關研究統計，在常規項目開發完畢后，只有三分之一的軟件被認為成功實現了預期的功能與性能，而其他的軟件則不是被認為存在問題，就是被視為完全失敗了。

眾所周知，軟件項目失敗背后的主要原因包括：各種產品缺陷、需求上的歧義、產品測試不足、程序中的無效代碼、和其他性能上的問題。通常，衡量??軟件產品開發團隊??的生產力是防止項目失敗的關鍵方法之一。我們可以通過許多軟件開發的相關指標，來衡量團隊的生產力。下面，讓我們一起來詳細討論有哪些關鍵指標，可以協助我們盡早發現軟件項目中的風險，進而避免后期出現軟件故障。

1.客戶滿意度

客戶滿意度是衡量軟件開發團隊生產力的一項關鍵指標。業界常說的爽點和痛點是滿意度的直接體現，客戶只有使用滿意了才會將您的產品推薦給其他人，并成為軟件的忠實用戶。相反，客戶一旦覺得不滿意，就會立刻轉用競爭對手的產品。

衡量客戶滿意度的方法有很多，常見的標準方法有如下三種：

• 凈推薦值(Net Promoter Score，NPS)：它根據客戶向他人推薦您產品的可能性，以1-10的等級，對客戶進行評分。例如，覺得滿意的客戶會給出9或10分，而不滿意的客戶則會給出1或2分。NPS是滿意客戶與不滿意客戶數量的比率。由于它的整體范圍可以從-100到100，因此任何高于6的NPS分數都被認為是良好的，即表示客戶認為滿意。也就是說，軟件開發團隊的目標是要讓NPS的分值達到6分以上。
• 客戶反饋：衡量客戶滿意度的另一種方法是通過客戶提供的反饋和建議。您可以要求客戶根據他們對產品的體驗，提供從1到5的產品評級。就產品與服務而言，您最好在訂閱期結束之前，以電子郵件或消息推送的形式發送反饋請求。當然，您也可以通過Twitter和Facebook等第三方社交媒體網站去獲取反饋。
• 客戶調查：這是獲得產品客戶滿意度或客戶體驗指標的第三種有效方式。您應該在一定的時間間隔，比如在購買產品一個月后，根據客戶的購買與使用情況，發送一封調查電子郵件。調查的內容可以包括：有關客戶對于產品的體驗、他們向他人推薦本產品的可能性、以及對現有問題的任何建議等。

2.沖刺燃盡(Sprint Burndown)

沖刺燃盡是一次沖刺中已完成工作的圖形表示。它可以被用來跟蹤團隊的進度，并確定他們是否可以實現沖刺的目標。

創建沖刺燃盡圖背后的思想是，找出在沖刺中已完成的工作量，并將其與實際完成的工作進行比較。如下圖所示，x軸代表時間，而y軸代表剩余的工作量。斜線率代表了團隊如何完成工作。

沖刺燃盡圖通常由兩條線組成：一條表示預計進展，另一條表示實際進展。此外，它還包含如下六的方面：

• 起點：是沖刺時間的開始，剩余工作為100%。
• 終點：是沖刺結束的時間，剩余工作為0。
• 零線：在y軸上繪制零線，可以指示在起點和終點處剩余的工作。
• 實際進度線：是顯示沖刺中已完成工作量的線。
• 理想進度線：理想線顯示了如果一切按計劃進行的話，沖刺中應當完成的工作量。
• 燃盡率：燃盡率是實際進度線的斜率。

3.團隊速度

團隊速度可以衡量一個團隊在一定的時間內，可以完成的工作量。我們既然可以根據故事點(story points)來衡量，也可以根據理想天數來衡量。此處的理想天數是指所有團隊成員在某個項目上協同工作的總天數。它雖然根據所有團隊成員的100%出勤率來進行計算，但也包括了周末、節假日或任何其他類型的缺勤。顯然，更高的速度意味著團隊可以在更短的時間內，完成更多的工作。我們通常使用該指標，來跟蹤團隊在一段時間內的進度。

4.發布燃盡圖(Release Burndown)

發布燃盡圖是軟件開發團隊用來預測完成進度的工具。它使用速度作為預測項目完成所剩余天數的基礎。它有時也稱為發布計劃，調度的是需要的時間而不是任務。其基本原理是：速度乘以迭代次數，得到完成的故事點的總數。您可以通過將剩余的故事點乘以團隊的平均速度，來轉換為天數。

5.周期時間

周期時間是問題從開始到完成所需的平均時間。您可以在幾天、幾小時甚至是幾分鐘之內對其進行測算。周期時間的通用公式為：T=T+d(t)。其中，T是以小時或天為單位，表示花費在特定項目上的總時間;d(t)表示工作流中每個階段的問題所持續時間。

例如，QA團隊的Alice在1月1日創建了一個問題，并將其分配給了開發團隊的John。他在In Progress階段花費了兩天，在Completed階段花費了一天。那么該問題的總周期時間就是四天。

減少周期時間的目標就是要提高問題從開始到完成的速度。該指標可用于衡量團隊工作流程的效率，并有針對性地尋找改進方法。

6.交付周期(Lead Time)

交付周期是指某個問題被分配給特定團隊或成員之后，從開始到完成的平均時間。您還可以按天、小時或分鐘為單位進行測算。交付周期的一般公式為：L=L+d(t)。其中，L是完成一個問題所需的交付周期，以小時或天為單位;d(t)則表示進入每個工作流程階段的持續時間。

例如，QA團隊的Alice在1月1日創建了一個問題，并將其分配給開發團隊的John。他從In Progress到Completed需要五天的時間，那么此問題的總交付周期就是五天。

交付周期通常被作為一種指標，跟蹤問題的解決速度。該指標反應并衡量了團隊工作流程的效率，進而協助尋找改進方法。顯然，縮短交付周期可以改進問題的解決方式。

7.平均修復時間(Mean Time to Repair，MTTR)

平均修復時間是衡量在檢測到錯誤或問題后，開發團隊需要多長時間才能解決的指標。它也可以用天、小時或分鐘來衡量。MTTR的一般公式為：MTTR=T+d(t)。其中，T是以小時或天為單位計算的、花費在特定項目上的總時間，而d(t)則表示工作流中每個階段的問題所持續的時間。

例如，開發團隊的John在1月1日創建了一個問題，并將其分配給QA團隊的Joanne。她在Progress階段花費了兩天時間，并在Debugging階段花費了四天時間。那么該問題的總MTTR為六天。

該指標旨在減少發現錯誤或問題后，需要解決的時間。因此，它可被用于跟蹤問題解決的速度，進而協助尋找改進方法。

8.代碼審查

作為一種衡量軟件質量并防止代碼庫中出現缺陷的實踐，開發人員通過檢查彼此代碼的方式，提出改進或替代方案，并啟動實施此類更改的計劃。代碼審查的主要目標是提高代碼庫的整體質量，并防止向生產環境引入缺陷。

9.錯誤率

錯誤率是對軟件應用程序中發現到的缺陷或問題數量的衡量。您可以用它來衡量每個單元、每天、每周或每月的錯誤占比。錯誤率的一般公式為：R=N/t。其中，R是錯誤率，N是在特定時段內發現的錯誤數，t是該時段持續的時間。

例如，QA團隊的Joanne在2月1日發現了10個缺陷，并將它們分配給同為QA團隊的Bob。如果她花費了八天的時間，才重現所有發現的問題，那么這個期間的總錯誤率為每天0.8個錯誤。

該指標旨在衡量隨著時間的推移，QA團隊能夠在軟件程序中發現到的缺陷或問題數量。當然，該指標也常被用作比較工具，以確定測試過程是否有待改進，進而協助發現提高產品測試質量的方法。

10.任務量(Task Volume)+平均估計

任務量可以衡量有多少任務量需要被發送到產品環境中。它也可以按天、小時或分鐘來衡量。任務量的一般公式為：TV=TV+d(t)。其中，TV為總任務量，TV是任務總數，d(t)表示工作流中每個階段的工作時間的持續時間。

例如，來自QA團隊的Alex在1月1日創建了一個問題并將其分配給John。從InProgress到ReadyforDev需要五天時間。此問題的總任務量現在為15天。

任務量的目標是衡量交付產品所需完成的任務數量并確定減少它們的方法。該指標可識別工作流程中的潛在瓶頸，使團隊能夠在這些問題嚴重延遲項目之前解決這些問題。它還可以比較組、項目甚至軟件開發工作流程。

結論

本文中提到的指標對于衡量軟件開發生產力至關重要。雖然并非所有指標都適用于每個項目，但這些指標為評估團隊績效提供了一個很好的起點。衡量和跟蹤這些指標有助于確定提高生產力和質量的領域。

譯者介紹

陳 峻 (Julian Chen)，51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。

原文標題：10 Important Software Development Metrics That Every Project Manager Should Know，作者:Rita Roy