指標，這是軟件研發管理繞不過去的話題，這也是大家一直以來的管理慣例。
不過，在如今內卷至混亂的年代，沒有太多數理邏輯的量化指標頻頻受到質疑，為什么是5%，不是6%；實際項目如此復雜，固定的指標合理嗎？
質疑并非沒有道理，但指標存在的意義不在于能夠應對這些質疑。我們可以從另外兩個角度理解：
- 此為無奈之舉，簡化至可以理解和管控的可量化指標，是認識的需要，也是管理的抓手。
- 指標既會作為具備相當一致性的成熟產品或團隊的績效表征，也是將不成熟推向成熟的手段，而且推動意義大于表征意義。
既然仍然需要指標，本文會匯總對汽車軟件相對有價值的度量指標，以供大家選用。
1 需求規模
需求規模=需求大小或顆粒度
該指標反映了單個需求交付及開發的復雜度，如果能對需求規模進行比較好的拆分與估算，十分有利于項目計劃與工作量的合理規劃。
按照不同的項目或產品類型，可以使用故事點、feature、功能點、對應代碼當量等維度來評價。
2 需求交付周期
需求交付周期=需求釋放時間-需求創建時間
該指標反映了團隊對新需求的評估及交付速率，這也體現了敏捷宣言中擁抱變化的力度。
算法里的需求釋放時間可以按照系統里需求通過評審釋放或變更經過CCB批準釋放的時間來定義，而需求創建時間可以按照系統里需求打基線或者提交的時間來定義。
3 需求變更率
需求變更率=發生過變更的需求數/已釋放的需求總數
該指標反映了對變更控制的能力，在傳統汽車瀑布式開發下，對變更控制的能力也會指向管理的水平，但敏捷時代下，低需求變更率甚至是負面的表征。
算法里的需求數可以按照需求管理系統里的條目數或者需求文本的數量來統計。
4 開發交付周期
開發交付周期=軟件發布時間-需求釋放時間
該指標反映了開發團隊的開發效率，算法里的軟件發布時間可以按照軟件打包發布的時間來定義，而需求釋放時間可以按照系統里需求通過評審釋放或變更經過CCB批準釋放的時間來定義。
軟件發布通常會區分內部發布和外部發布，可以根據實際業務需求來選擇度量方式。
需求吞吐量=統計周期內交付的需求規模
該指標與需求交付周期度量的目標接近，但交付周期側重于單位需求的交付效率，吞吐量關注的則是整體產能。
算法里的統計周期可以按照月度或季度來統計。
需求按時交付率=按時交付的需求數/計劃交付需求數
該指標反映了需求按時交付的能力。
算法里的數量可以按照需求管理系統里的條目數或者變更管理系統里工作項數量來統計。
需求評審通過率=通過評審釋放的需求數/提交評審的需求數
該指標反映了需求提出者撰寫需求的能力，也會反映出對需求上線進行整體規劃的能力。
算法中的需求數可以按照需求管理系統里的條目或者變更管理系統里工作項的數量來統計。
8 需求評審缺陷密度
需求評審缺陷密度=需求評審檢出缺陷數/需求規模
該指標反映了需求評審的效果。
算法中的缺陷數可以按照評審finding或者開出的問題項的數量來統計，而需求規模可以使用故事點、feature、功能點、對應代碼當量等維度來統計。
9 設計評審通過率
設計評審通過率=通過評審的組件數/提交評審的組件數
該指標反映了組件及接口定義和設計的質量。
算法里的組件數可以按照軟件架構的組件拆分來統計。
10 設計評審缺陷密度
設計評審缺陷密度=設計評審檢出缺陷數/設計規模
該指標反映了設計評審的效果。
算法中的缺陷數可以按照評審finding或者開出的問題項的數量來統計，而設計規?？梢酝ㄟ^需求規?；蛘呓M件數來統計。
11 組件按時交付率
組件按時交付率=按時交付的組件數/計劃交付組件數
該指標反映了軟件開發人員進行模塊或組件開發的能力，軟件需要多組件集成后才能進行下一步的測試和發布，各組件開發都要按節奏協調起來。
算法里的組件數可以按照軟件架構的組件拆分來統計。
12 組件復用率
組件復用率=復用的組件數/總組件數
該指標反映了架構設計、組件設計甚至需求溝通方面的能力，不重復造輪子、進行復用開發是我們所鼓勵的。
算法里的組件數可以按照軟件架構的組件拆分來統計。
13 接口變更率
接口變更率=變更的接口數/總接口數
該指標與組件復用率關注的能力接近，但組件復用率提升的是單個組件開發的效率，接口變更率更會致力于跨組件、跨系統的協同開發效率。
算法里的接口數可以按照系統及軟件架構中定義的軟件接口與軟硬件接口來統計。
代碼開發當量=代碼抽象語法樹加權最小編輯距離
該指標反映了代碼的邏輯量和修改代碼的工作量，排除了編程風格、換行習慣、注釋等干擾因素，準確性比傳統的代碼行數更好。
15 代碼提交頻率
代碼提交頻率=單位時間代碼提交次數
該指標反映了代碼開發的活躍度，也是敏捷中鼓勵的小步快跑提交，但有可能也會讓開發進行表面化的頻繁小提交，反而帶來質量的下降。
算法中的代碼提交次數可以按照代碼配置管理系統中記錄的代碼變更次數來統計。
16 代碼重復率
代碼重復率=重復代碼的代碼規模/總代碼規模
該指標反映了代碼的可維護性，即代碼重復率越高，代碼可維護性越差，因為多處修改所需的工作量越大。這個指標會驅動代碼抽象，如用函數、類、庫、服務來封裝等。
算法中的代碼規?？梢杂?/span>代碼當量或代碼行數來統計。
17 代碼評審缺陷密度
代碼評審缺陷密度=代碼評審檢出的缺陷數/代碼規模
該指標反映了代碼評審的效果。
算法中的缺陷數可以按照評審finding或者開出的問題項的數量來統計，而代碼規?？梢杂?/span>代碼當量或代碼行數來統計。
18 靜態掃描缺陷密度
靜態掃描缺陷密度=靜態掃描檢出缺陷數/代碼規模
該指標反映了編碼規范程度，如MISRA C。
算法中的缺陷數按照工具掃出來的finding統計，而代碼規?？梢杂?/span>代碼當量或代碼行數來統計。
19 提測成功率
提測成功率=提測成功次數/提測總次數
該指標反映了開發滿足測試準入條件的水平，除了軟件質量本身，通常也會涉及一些過程規范性要求。
算法里的提測次數可以按照真實版本或者對應的releasenotes的數量來統計。
20 測試一次通過率
測試一次通過率=一次性通過測試的版本數/總測試的版本數
該指標反映了開發的質量，會一定程度推進團隊對代碼評審或單元測試等開發測試的重視，但是，能否通過測試終歸是來源于對測試準出條件的定義，如果發布壓力大于質量壓力，準出條件形同虛設，這個指標也就失去了意義。
算法里的版本數可以按照真實版本或者對應的releasenotes的數量來統計。
測試覆蓋率=測試覆蓋的條目數量/需要測試條目的總數量
該指標反映了測試對需求或代碼的覆蓋程度，也細分為測試需求覆蓋率或測試代碼覆蓋率。
算法中的條目數量，對于需求的覆蓋，可以按照需求管理系統里的條目數來統計，而對于代碼的覆蓋，可參考《汽車軟件單元測試的要點與意義》里的描述。
22 測試缺陷密度
測試缺陷密度=測試檢出缺陷數量/代碼規模
該指標反映了測試的效果。
算法中的缺陷數可以按照開出的缺陷項的數量來統計，而代碼規?？梢杂?/span>代碼當量或代碼行數來統計。
缺陷重開率=重新打開缺陷數量/總缺陷數量
該指標反映了缺陷修復的效果，重開率高組件或團隊應進行針對性的分析與改進。
算法中的重新打開缺陷可能需要缺陷管理工具配置對應的字段來統計。
缺陷階段移除率=某一階段引入中移除的缺陷數量/該階段引入的總缺陷數
該指標反映了特定階段的活動或團隊對于缺陷的整體貢獻，自己帶來的缺陷最好自己帶走。
算法中的階段移除（這里的移除指在該階段發現）和引入缺陷數都需要依賴缺陷管理工具配置的特定字段來統計。
缺陷逃逸率=后期發現的缺陷數量/總缺陷數量
該指標反映了前期缺陷檢出的效果，也直接反映了汽車軟件質量的真實水平。
算法中后期發現的缺陷數量可以理解為售后、工廠、整車集成這些環節發現的缺陷數量。
26 缺陷檢出率
缺陷檢出率=各階段發現的缺陷數量/總缺陷數量
該指標反映了軟件開發不同階段的缺陷檢出的效果，同缺陷逃逸率指向接近，但它對不同階段的不同活動或團隊的缺陷檢出進行了細化，通常作為優化缺陷逃逸率的進一步指標。
算法中各階段可以理解為需求評審、設計評審、代碼評審、開發測試、集成測試、軟件測試、系統測試、整車測試、工廠生產、售后這些不同環節。
27 缺陷率
缺陷率=致命級別的問題個數*10+嚴重級別的問題個數*3+一般級別的問題個數*1+提示級別的問題個數*0.1
該指標反映了缺陷視角下的軟件整體質量狀態，其中的缺陷等級定義以及對應權重的劃分是指標有效與否的關鍵。
缺陷分布=缺陷不同屬性的交叉分析
該指標反映了缺陷屬性交叉分析的結果，同其他分布一樣，它更多作為整體對比、分析、決策的工具。
缺陷屬性可以根據類型、嚴重度、根本原因、模塊、優先級、測試環境和負責的測試人員等進行分類，這些屬性之間可以進行二維或多維的交叉分析，比如，利用透視表、直方圖、餅圖或帕累托圖等方式。
測試自動化率=自動化測試用例數/總測試用例數
該指標反映了自動化測試的能力，要想實現敏捷的頻繁迭代發布，很重要一個前提就是快速的自動化測試，尤其要關注回歸測試的測試自動化率。
流負載=已開始但未交付的需求數分布
該指標反映了需求、設計、 開發、測試、發布各階段的需求數分布狀態，類似工作量分布，但關注的是在制品瓶頸和積壓，控制在制品數量有助于提高交付效率。
算法里的需求數可以按照需求管理系統里的條目數或者需求文本的數量來統計。
流效率=活躍工作時間（即無阻塞地工作）/總交付時間（包括活躍工作時間和等待時間）
該指標反映了軟件開發過程的順暢程度和資源利用效率，也能比較好地將軟件開發工作透明化。
算法里的活躍工作時間指的是需求溝通、需求評審、架構設計、開發、測試、發布等實際工作的時間，而總交付時間則包括了活躍工作時間以及各種等待時間，如配置在ALM工具中的待評審、待開發、待測試、待發布之類的等待階段的停留時間。
32 工作量分布
工作量分布=不同維度下的工作量差異展示
該指標反映了軟件開發過程中，不同階段、不同團隊下的工作量分布比例，通常用來支持項目管理的工作分配，也會與其他指標進行關聯分析。
工作量可以通過工作項數量（缺陷、變更、任務等）或者工作時間或者代碼規模或者需求規模等不同維度體現。
33 售后問題響應時長
售后問題響應時長=售后問題響應時間-售后問題提出時間
該指標反映了響應售后客戶問題的及時性，算是“態度”問題。
算法里的響應時間可以按照系統里分配或者給客戶首次正式答復（有切實計劃）的時間來定義，而提出時間可以按照接到客戶投訴的時間來定義。
售后問題解決時長=售后問題解決時間-售后問題響應時間
該指標反映了解決售后客戶問題的及時性，是“能力”問題。
算法里的解決時間可以按照系統里解決或者按照OTA或刷件解決實車問題的時間來定義，而響應時間可以按照系統里分配或者給客戶首次正式答復（有切實計劃）的時間來定義。
35 凈推薦值NPS
凈推薦值NPS=客戶愿意向其他人推薦某功能或場景的意愿
該指標反映了客戶的主觀感受，而不聚焦在工程或軟件質量本身。這在場景體驗評價里，是一個有價值的指標，它也可以用于客戶滿意度的整體評價。
凈推薦值以0-10的數字范圍表示，得分為0到6的客戶是負面評價者；7和8的分數是中立者；9和10是推薦者。
軟件的高質量必然指向可指標化，而指標也是高質量的重要推手。
轉自水輕言
