為了能夠更好地改進軟件項目，開發團隊往往會統計一些數據，用以分析總結，並作為下次開發改進的依據。那么在軟件開發中，你的團隊會統計哪些數據呢？這些數據又如何為下次項目改進提出幫助呢？
本文通過對軟件開發過程中統計的一些數據進行分析，讓讀者能夠從本質上重新理解統計數據的方法和意義。
1. 生產率
統計生產率是為了能夠了解開發團隊的生產效率在整個行業中處於何種水平。長期統計之后可以為下次工時估算提供依據。
單位：每人月可以生產的千行代碼數，KLOC/MM
統計了生產率對改進工作有什么樣的幫助呢？支持統計這個數據的人說，統計生產率是為了和社會平均生產效率進行對比，從而分析改進方案。當自己的團隊遠遠高於社會平均生產水平或者遠遠低於社會平均生產水平的時候，都預示着不好的信號。過高可能意味着代碼質量的下降，而過低又可能預示着效率不足。然而社會平均生產水平究竟是什么樣子的也沒有組織公布出來。沒有參考的數據，又如何判定高低呢？而社會平均生產水平真的具有參考價值嗎？某著名公司開發的一個網站，總共代碼不超過2000行，用了大概30個人月，難道他們的生產效率極低嗎？不是的，而是他們的產品質量極高，代碼具有高度的抽象性，十分容易擴展新功能。
另外，統計的方法也千差萬別，有人主張時間應該從需求分析開始直到發布這段時間，有人則認為只應該統計編碼階段的時間，因為前者經歷軟件開發的各個階段，而后者是外包型企業，只接觸從詳細設計到單元測試的這幾個階段。誰說的更有道理呢?於是中間派說，這個數據統計是用來和自己比的。那么統計數據之后，如果一直很穩定代表什么意思？一直在上升又是什么意思？一直在下降呢？或者沒有什么規律呢？
這個數據還有語言相關性。C++的代碼生產率和Java的生產率是不可比的，有人居然發明了一個折算指數，即生產x行Java代碼相當於y行C++代碼，這個折算指數是怎么來的？
更為可笑的是，根據代碼生產率來評價員工的情形，結果導致庸才得高評。
至於平均生產率用於工時估算也是不靠譜的。大多數組織每個項目都會由不同的人組成。即使有些團隊可以保持穩定的團隊，但是每次的項目內容也不同。就算項目內容也都差不多，那么我們來看看這個數字是怎么計算出來的。
估算工時 = 估算的代碼行數 / 平均生產率
平均生產率是統計出來的數字，相對比較穩定，但是估算的代碼行數是如何得到的？上一次我們差不多的功能用了x行，所以這次應該是x +/- 15%（誤差范圍可能有所不同）。
上次的時候你還在用Javascript實現的功能，這次改用jQuery實現了；
上次你需要開發一個基礎框架庫，這次可以復用那部分；
上次你才剛接觸到WPF，這次你已經很熟練了；
上次都是經驗者，這次卻都是新畢業生；
上次的東西對這次的參考價值有多大／長期統計的東西對於日新月異軟件開發來說更是難說其參考價值。
2. Bug密度
統計Bug密度是為了能夠掌握開發團隊的質量水准，也就是說這個數值越低代表質量越好。
其統計單位是：千行代碼Bug數（case/KLOC）
那么請看，這兩段代碼，
代碼1
public Color getZembraColor(int index) {
Color[] colors = new Color[]{Color.WHITE, Color.GRAY};
return colors[index & 1];
}
代碼2
public Color getZembraColor(int index) {
if (index % 2 == 0) {
return Color.WHITE;
} else {
return Color.GRAY;
}
}
這兩段代碼同樣是完成根據行號獲得斑馬線顏色的，第一段代碼用了4行，而第二段代碼用了7行，如果不幸發生了Bug，比如，應該用Color.DARK_GARY，而不是Color.GRAY。
那么，對於第一個人來說，Bug密度 = 1 / 4 ，而第二個人則為 1 / 7，結果是第二個人的代碼質量比第一個人好，事實真的如此嗎？這只是個例子同樣的情形比比皆是。
比如，查看一個字符串是否是許可字符串（俗稱：白名單）的處理
代碼1：
String [] enabledCodes = new String[]{"a", "b", "c", "d", "e", "f"};
public boolean isEnabledCode(String code) {
for (int i = 0; i < enabledCodes.length(); i++) {
if (code.equals(enabledCodes[i])) {
return true;
}
}
return false;
}
代碼2：
public boolean isEnabledCode(String code) {
return code.matches("a|b|c|d|e|f");
}
第一段代碼9行（空行不統計），第二段代碼3行。如果真的統計這個數據，又是一個庸才戰勝人才的案例。
有些組織甚至制定了Bug目標，比如 8個/千行。而且還振振有詞的說，超過這個數字代表質量不合格，低於這個數字代表測試不充分。於是很多人為了實現這個數字在一段高質量代碼中抓破了頭找Bug，最后把沒有使用TAB對齊作為Bug提出來。
3. Bug原因分類
統計產生Bug的原因分類，有助於針對某個開發階段進行改進，比如，如果是設計上的遺漏比較多，那就提升設計能力，如果是編碼上的問題比較多，那就提高編碼能力。
統計單位：百分比 （%）
計算方法：某類原因引起的Bug數量/Bug發生數量
如此統計似乎很可以有針對性的改進，然而如何從這組數據中得到改進的方案呢？一般做法是，針對特定類型Bug進行全面分析，總結出薄弱環節，改進其設計方法和/或加強其復查力度。
我們姑且排除技術人員為了推卸責任而將代碼實現的問題寫成設計問題或者需求問題。且當數據都是可靠的。那么對於設計不足你會采取什么樣的方法來改進呢？下面是一些可能被選為改進方案的選項。
-原來我們用的是流程圖，下次我們改進用UML圖；
-原來我們的復查工時為1倍，下次我們用1.5倍的時間；
-制定一個CheckList用以復查；
其結果真的會改進設計質量嗎？
-采用UML圖之后大家不明白數據流程了；
-多付出的復查時間只是被浪費了，因為做法沒有改變；
-制定的CheckList只是把已知的知識寫在了紙上；
因為產生設計遺漏的原因並不是設計能力不足，也不是復查不充分，而是因為設計本身就是一個猜想的工作*，所以遺漏是必然的。改進設計的方案應該是用測試代替設計**。
Bug產生的原因並不是這些：需求分析不充分，需求文檔書寫不全面，詳細設計有遺漏，編碼過程中有遺漏。
Bug產生的唯一原因是，寫了代碼沒有進行充分的測試。試想，為什么Bug沒有在開發組發現，而是被測試組發現，或者最終用戶發現。就是因為開發組所采用的測試用例集合不充分和/或執行不到位。把這個原因寫成其他原因所產生的結果就是摔倒了不說走路方法不對，卻說地不平，於是就會出現上面那些隔靴搔癢的改進措施。
4. 二次Bug率
二次Bug是指修改Bug的時候沒有修改完成，導致該Bug再次被測試出來，或者由於修改該Bug引起另外的Bug發生。統計二次Bug率把握Bug的修改質量。針對發生的問題集中區域進行改進，有助於提高質量，縮短測試周期，從而為保證交貨期而做出貢獻。
統計單位：百分比（%）
計算方法：二次Bug數量/本輪測試發生Bug數
如果二次Bug率居高不下，你會采取什么措施？
首先是原因分析，可能的結論是
-修改代碼的影響性分析不足
-修改代碼的方案審核不足
-修改代碼后的測試不足
於是，對應的改進方案可能是
-在Bug修改流程中增加影響性分析文檔制作過程
-代碼方案必須經過2個人審核
-代碼提交后必須經過2個人測試之后才能夠交給測試組
這樣做的通常結果是：
-二次代碼率很穩定，沒有得到任何改善
-Bug修改流程變長了，於是測試周期變得更長，於是交貨期更加不可靠
-開發人員的加班變多了，士氣下降了，質量更不可靠。
統計這個數據只能夠得到和與其相反的效果。
5.進度百分比
對任務進行分解，得到WBS之后，每個小任務都要進行工時估算，然后放入甘特圖，當任務在進行中的時候，每天統計該任務的完成情況，一般用百分比來表示。
統計單位：百分比（%）
計算方法：由任務執行者自行估算
眾所周知，軟件開發中有很多不可預見因素，導致技術人員容易偏向樂觀，往往估算工時會比實際工時短。盡管有時項目經理會適當增加Buffer，但是開發人員卻並沒有因此而減少樂觀的態度。於是一個開發人員在報告進度時，對於他認為快要完成了的任務報告為90%。而第二天，他發現了一個很大的遺漏，那個遺漏占到整個功能的60%，於是第二天他又不好意思說昨天發現了重大遺漏，所以，原來的90%其實是：40% * 90% = 36%。他只好說91%。這樣的進度報告又有什么意義呢？至於能夠估算為85%的進度又有多少可靠可言呢？然而管理人員就是這樣要求，所以開發人員也只好這樣報告。形成一個互相欺騙的環境。
6.測試用例執行速率
每單位時間能夠執行的測試用例數量是測試用例執行速率。了解測試用例執行速率可以估算出測試的執行時間。
單位：用例數/單位工時，例如每天可執行測試用例數。
每個人每天上班時間為8小時，但是工作時間並不是8小時，上個廁所，抽個煙，聊個天，開個會.....很多事情都會占用這8小時之內的時間，而且由於切換任務和打斷會導致效率進一步下降。更何況上次統計測試執行時間的時候所填寫的數據可靠度本身就很低。而且測試用例的執行難度並不相同，有的光准備數據就需要5分鍾，有的可以和別的共享數據，有的可以在前一個執行完之后馬上執行。這個數據中充滿着變化的因素。如何才能夠確保數據可靠？
如果你的團隊在統計這些數據，你如何控制其他那些“變化”的量？
如果你的團隊真的在統計這些數據，是否意味着你的團隊更喜歡庸才而不是人才呢？
如果你真的不明白這些數據的含義，你又為什么要統計這些數據呢？
你現在大概氣勢洶洶的准備問我，“那你說應該統計哪些數據！”。不要着急，下期就說。
--------------
*軟件開發本身充滿着太多的不確定因素，設計只是將能夠想到的內容寫下來的過程。
**用測試代替設計指的是測試驅動開發。