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