管理學大師德魯克說：你如果你無法度量它，就無法管理它。要想做有效的管理，就很難繞開度量的問題。
軟體開發的過程或者技術團隊的管理也存在著如何去合理的度量效率的問題。而度量是把雙刃劍，度量具有極強的引導性。度量指標會激勵團隊重視並改善能夠度量元素，也會導致你忽視無法度量的元素，並使得問題進一步惡化。所以，選擇合適的度量指標考核技術團隊成員，需要慎重考慮。例如，程式碼行數和千行程式碼Bug率指標就值得商榷。
什麼是千行程式碼Bug率
首先我們來看一下，千行程式碼Bug率是怎麼定義的：
千行程式碼Bug率 = Bug數量/ (程式碼行數/1000)
度量的標準：千行程式碼Bug率數值越小質量越好。
關於CMMI級別中和BUG率相關的資訊如下：
| CMMI級別 | BUG率 |
|---|---|
| CMM1級 | 11.95‰ |
| CMM2級 | 5.52‰ |
| CMM3級 | 2.39‰ |
| CMM4級 | 0.92‰ |
| CMM5級 | 0.32‰ |
考核千行程式碼Bug率的問題
從考核千行程式碼Bug率來看，主要存在兩個方面的問題：
首先，從考核標準上來說，Bug率數值越小就說明越好，基於這個結果，會引導團隊成員做出一些對長遠和整體效率無益的行為，例如：
1. 增大基數，增加無意義程式碼
2. 把定長迴圈分開寫，寫成順序方法
3. 把可配置資訊寫死到程式碼中
4. 大量的複製、貼上程式碼
5. 重新發明各種輪子
統計“千行程式碼Bug率”和“每日生產程式碼行數”一樣，都是沒經過大腦思考，而直接打算把優秀員工踢出團隊的懶人式管理方式。特別是對從事智力型工作工程師來說，是很不合適的考量指標。
因為優秀的程式設計師是通過減少程式碼行數來增加功能的。
千行程式碼Bug率，雖然沒有明確鼓勵增加程式碼行數，但是這個計算結果對於優秀的員工來說是相當的不公平。它隱含的推廣了“儘量增大程式碼行數”這個意思。
其次，從考核階段看，Bug率的資料主要產出在研發階段的後期，及提交測試後產出bug數。從專案的研發階段和效率價值金字塔來看，其對專案的整體質量方面更多的聚焦在微觀層面問題，整體的質量的影響範圍會較小。而前面幾個階段的缺陷，會影響整個專案的進度，甚至導致專案失敗，管理者和團隊更應該將風險控制和度量指標向前移。
研發階段和效率價值金字塔
如何更合理的度量質量
如果考核千行程式碼Bug率不能很好的解決質量核心問題，那我們還有那些方法和方案來提高專案的整體質量呢？
個人覺得，我們還是從專案的研發階段和效率價值金字塔出發，重整體上去把控質量，上下游一體，從源頭開始：
1. 需求的評審
2. 架構設計方案評審
3. 程式碼模組設計，包的依賴的規劃，介面的設計的review
4. 程式碼的review的機制
5. 測試用例評審
6. 使用程式碼檢測工具，自動發現問題
過程評審是最有效也是成本最低的質量和效率保證和提升的手段。另外，過程評審還是迅速提高新人能力及其成果物的規範性的一個有效手段。
但是過程評審，也存在一些問題：
1. 前期過度依賴於團隊的人員素質
2. 規則的定義也比較難，產出不好量化
3. 評審耗時多
4. 團隊的意識不一致
對於過程評審的實施，最核心的統一團隊意識，團隊意識不一致時，效果一定不好。 意識意識不一致，在資源的投入上就會縮手縮腳；只有把過程評審做到位，才能體會到評審活動的高效，避免那種走馬觀花式的“評審”，是浪費時間，不是真正的評審。到位地完成評審後，會有那種對系統質量“踏實了”的感覺，過程中輔以嚴密的變更管理和風險控制手段，系統質量出大問題可行性會很小或者近乎為零。
系統質量是要靠上游工程做出來的，而且上游的工作質量會更為重要，上游的問題的影響範圍將更廣，對效率和價值的影響更大，應該是我們重點關注的地方。僅僅依賴下游工程(種種測試)來把質量關，是十分低效，而且代價是非常昂貴的。
總結
想做有效的管理，就很難繞開度量的問題。在選擇度量指標上，大部分管理者總是傾向於關注容易度量的指標，而忽略難以度量的指標。但是容易度量的指標不一定是重要的，難以度量的反而可能是重要的。
軟體開發產出最直觀的結論就是一行行程式碼，實際上程式碼行數的多少並不代表價值的多少。當考核不合理導致出現大量的複製，不合理的設計，大量的冗餘，不但難以理解和維護，甚至沒有實際執行起來。這樣就造成大量的時間浪費，同時也造成質量的嚴重腐化。
而基於全過程的評審機制和持續改進方法，可以很好的改善質量。但持續改進需要一個過程，需全團隊從認知達成一致，並共享問題，統一步調和規範，持續的執行和改進。
另外，從工程師自身來說，千行程式碼Bug率用來自我評估和改進，還是很有價值的。