《程式員度量：改善軟體團隊的分析學》一有價值的資料

本書後續章節将讨論一些特定的程式員度量。某些度量相當簡單，基于産品bug這類原子資料；而有些度量相對更複雜一些，它們需要利用公式以及多個資料元素的組合。

無論如何，在深入探究特定的度量之前，我們都應考慮各種可用于程式員度量的資料類型，并思考這些資料是否有用處。我們需要廣泛而深入地思考那些令人關注的、新的資料元素，因為它們能夠帶來更有意義的度量。同樣，程式員和軟體團隊的工作需要關聯到團隊群組織的目标。我們也同樣需要認真地思考如何确定這些資料。

下面的清單是我發現的一些有用的資料示例，将在後續章節深入讨論。此處隻是說明性質的，是以僅僅描述了資訊的類别或分類，而具體的數值（例如計數或者平均值）會在後面的内容中讨論。

程式員加入團隊的時間。

團隊規模、團隊優化和團隊建設。

按複雜度分類并由程式員完成的任務。

程式員協同完成的任務或程式員幫助他人完成的任務。

特别緊急的任務，如修複嚴重的産品問題。

顯示程式員超常的創造力、創新和主動性的任務。

延期的、失敗的或者取消的任務。

程式員參與的項目、産品和産品領域。

花在任務上的時間。

花在會議上的時間，或者處理自己中斷的事宜花費的時間。

客戶發現的問題，以嚴重性和複雜度進行分類。

為了客戶支援工作而進行聯系的次數（電話、郵件或者聊天）。

購買或使用産品或特性的客戶數。

試用了産品或特性，但決定不再使用的客戶數。

取消或停止使用産品或特性的客戶數。

維持、獲得或直接競争對手失去的客戶數。

從産品或特性的改變中獲益的現有客戶數。

從産品、特性或者其他完成任務中獲益的内部員工數。

以上僅是可使用在度量中的一些資料類型的例子。除了本書中提及的一些資料之外，毋庸置疑，也确實存在其他有助于程式員度量的資料類别。按一般原則，極有可能我并未完全嘗試或考慮過許多潛在的資料。但對于有些資料類型，我本人曾經嘗試或者深入思考過，而由于各種原因，這些資料并不是很有用或者存在更好的選擇，是以本書中沒有使用這些資料類型。下面是關于這些排除的資料類型的幾個例子以及我排除它們的原因。

千行代碼量（kloc）

我們常常認為用代碼行數（kloc代表1000行代碼）來測量程式員的效率是非常有用的一種方法，并且也有不少執行個體認為kloc在估計技術和降低項目估計失誤的工具方面是有用的，特别是對一些大型項目而言。但一般而言，我認為kloc更像是活動而不是代碼的度量名額。我很難将這個度量名額關聯到明确的團隊目标上，例如客戶接受度、滿意度或者産品品質。kloc的另一個問題是，對不同的程式設計語言來說，它們沒有一個統一的标準。比如，寫1000行java代碼所花的時間和能力與寫1000行javascript、xml、php或者ruby代碼是完全不同的（ 雖然理論上可以有這樣的一個方法來進行跨語言的kloc标準化）。最後，我認為程式員很難認為這個度量名額與其工作業績或者成敗有什麼關系。進而，也就很難有效地使用kloc作為一種手段就技能與貢獻進行讨論。是以，出于本書中讨論的目的，我發現關注任務和基于複雜度的任務分類會比使用kloc更有意義。

開發階段的bug數量

bug數量肯定是評定代碼品質的一種度量。但是根據我的經驗，在開發階段的bug不同于釋出後産品的bug，由于存在太多的可變性，是以很難使得開發中的bug數量成為一個很有用的度量。開發過程中發現的bug的多寡會随着測試人員的數量、測試的深度和代碼在開發中的成熟度而波動。如果我們在開發周期早期就開始對一塊複雜的代碼進行徹底地測試，會發現許多bug，但是這并不能告訴我們什麼。也許會有人認為确實存在這樣一些bug，如果bug是在程式員認為功能已經實作且完成單元測試的情況下發現的，它們可以成為有用的度量。但是我發現，在實踐中，這項名額不太一緻，也很難下結論。最後，我認為我們僅需保持關于任務的複雜度和完成這些任務所花的時間的度量，它已經包含了充分修改開發bug的時間，否則代碼就無法釋出。如果程式員制造了許多bug，其結果就是完成任務的時間更長。對于同樣複雜的工作，花費時間更少的程式員一般更井然有序且産生的bug數目也較少。

産品收入

産品收入（毛收入或淨收入）是商業規劃和産品規劃中的一個關鍵部分。我們建造什麼産品，新增哪些特性，哪些問題值得花時間去修改，都依賴于财務分析的結果。在大多數情形下，軟體開發的預算與産品收入有直接的關系。事情本該如此。然而，如果把産品收入作為軟體開發流程中的度量，去衡量程式員和團隊的成功與相關貢獻，我認為這是有問題的。首先，很多軟體根本就沒有收入（開源項目和内部項目就是兩個很好的例子）。即使存在收入，這也不總是與軟體和軟體開發團隊的工作直接相關。它們廣泛地依賴于折扣、不同銷售人員的能力和更多的因素（包括國家或全球經濟）等。另一個重要的問題是，将金錢作為度量，很容易轉移注意力和帶來誤導。人們會變得更關注金錢，而不是度量的目标和意義。比如，每個客戶需要為新的iphone應用程式付費2美元，如果今天有1000個人購買，從許多方面來說，客戶數比2000美元的毛利能提供更清晰、正面的闡釋（2000美元無法讓人留下深刻印象）。相反，如果你的公司本周僅僅成交了一個10萬美元的訂單，這個數字或許聽起來令人印象深刻，但如果關注到存在那麼多的業務卻隻簽訂了一份訂單，這樣的事實就需要我們更為關注。我個人的感覺是，産品收入的意識和了解收入預測如何驅動産品計劃的決策對軟體開發團隊來說是有用的。但是，作為軟體開發團隊工作進度的度量，我更願意測量特性的傳遞、試用使用者到客戶的轉換率、産品bug數量，并且對使用者數和使用量保持關注。

總之，探索新的資料類型并嘗試使用它們不會帶來損失。我們應該樂于試驗新想法。也可以相信，其中非常有用的、合理的那些資料會顯現出來，而剩餘的部分可以舍棄。