1.2 度量是什么

1．度量是在一個特定組織上下文中形成的一系列共識。

司馬遷在《史記·秦始皇本紀》中寫道，秦始皇“一法度衡石丈尺。車同軌，書同文?！倍攘康囊粋€重要意義是統一思想、統一方式，從而使不同的人能夠在一致的基準上進行溝通，減少產生誤解的可能性。在一個軟件開發組織里，度量統一的不僅僅是度量單位、度量對象、度量手段，更重要的是統一對目標的認識。關于度量是什么、不是什么如圖1-4所示。

如果一個組織確定了提高質量的目標，每個團隊和個人就必須在如何度量質量上形成共識。在我曾經提供過咨詢服務的一個產品研發機構里，有的人認為，只有產品交到客戶手里后，使用過程中產生故障的數量和故障的嚴重程度才是衡量質量的依據；而另外一些人則認為，產品的代碼質量，甚至測試腳本的質量，也應該是質量的度量范圍，因為對于很多生命周期較長的軟件來說，代碼和測試腳本中的壞味道和技術債，是后續版本的質量陷阱和成本陷阱。雙方爭執不清，分析其根本原因，其實是在于對軟件代碼內在質量上的投入產出上有不同的意見。如果一個組織在這些方面缺乏澄清和共識，就無法形成統一的目標和手段，從而很難取得顯著的改進成果。

另外，度量體系可以幫助一個組織形成一套統一的術語。當人們在討論問題的時候，能夠在一定程度上確保大家是在用同樣的語言說著同樣的事情。幾個來自不同團隊的人在討論開發效率的時候，如果組織里都用的是相同的工作量度量單位，比如故事點，大家都應該知道這個數據是怎么得來的，是用的相對大小，還是絕對大小，考慮的因素有哪些，其優勢在什么地方，局限性又在什么地方。只有在這些方面理解一致，才能取得有效的溝通，減少誤解和不必要的爭執。

2．度量是將經驗模型向量化模型進行匹配的嘗試。

量化模型就是通常所指的硬數據、硬指標，這是大多數管理人員想看到的。當人們看到數字的時候，總會生出一種更加準確、更加靠譜的印象，覺得這樣的度量結果不容易受到主觀因素和人為操縱的影響。只要看看那些號稱7天美白的護膚品賣得有多好，就知道這種數字營銷對人的影響效果了。

不過說老實話，看看定期發布的CPI數據，對比一下我們對生活成本的直觀感受，我們就可以知道，量化與否，跟是否能夠準確反映度量的目標沒啥直接關系。以單位時間生產的代碼行數（SLOC）為例，作為生產效率的度量手段，這個指標現在仍然在很多大型的產品開發組織當中廣泛應用。我們在有些組織中觀察到的實際效應是：為了體現我的效率，一個特性可以用800行代碼完成的，咱絕不用500行，最好能用1000行以上才能體現我的辛苦。一位同事曾對客戶的一個遺留系統的某個模塊做過一次重構，將其代碼行數削減了將近80％，事后他告訴我，其實還有不少空間。這個客戶的研發團隊是用代碼行來度量工作量和效率的，雖然這種包含大量冗余代碼的系統，并不都是用代碼行來度量工作量所導致的，但至少度量并沒有對產生優化的系統起到有效的引導性作用。

雖然量化的不一定就是好的，量化模型確實有個非常重要的優勢——方便進行比較，這種比較有兩種類型。

●跟自己比較：持續改進，持續超越自己，就需要比較自己發生的變化。

●橫向比較：這對于擁有大量開發人員、團隊和產品的大型組織來說，是非常有吸引力的。在組織內部進行團隊和團隊之間的比較，是不少公司激勵大家提升績效的手段。另外，如果能跟業界的數據比較，也可以知道自己在行業中的位置如何。

可惜的是，軟件開發中的很多信息都難以用量化模型來描述。經驗性模型，也就是定性的度量，主要依賴文字來描述度量的依據，靠人對這些信息的理解和分析來判斷、還原情境的過程和結果，比如說：團隊經驗和能力、項目和系統約束、流程的可靠性和成熟度、用戶滿意度等，這類度量描述通常由于包含很多的上下文信息而難以量化。

這樣產生的一個問題就是，度量結果容易受到信息提供者和使用者的經驗和主觀意識的影響，也可能引入信息不對稱帶來的偏見。典型的例子就是任何兩個人對一個產品的用戶滿意度都會有不同的判斷。

由于包含了上下文信息，度量結果無法在個人和個人之間、團隊和團隊之間進行橫向比較。比如我們說有兩個團隊都很成熟，可能的情況是，一個團隊成熟是因為其成員經驗很豐富；而對于另一個團隊則是指其開發流程運轉十分順暢。

為了解決經驗性模型的局限性，業界做了各種嘗試，其中最著名的當屬CMMi模型。其實當前流行的各種成熟度模型都是將經驗模型向量化模型匹配的嘗試。我個人并不反對這種努力，不過在使用這樣的量化模型的時候，我們一定要注意量化模型本身的局限性。這種模型的度量結果來源于對大量上下文信息的匯總、過濾和抽象，這種簡化容易讓人們在度量中失去了度量發生的場景細節，迷失了度量本身的目標，以至于為了度量而度量。

3．度量是包含人、流程、組織和工具的一個動態系統。

如果把軟件開發組織看做一個動態的系統，度量實際是作為反饋機制來對這個系統產生作用的。

如圖1-5所示，假如我們把交付目標，包括交付時間和內容，作為系統的輸入，當我們想要呈現進度相關的輸出時，如果我們用的是瀑布式開發模型，那么得到的可能是哪些功能需求己經分析完成，或是代碼寫了百分之多少；而如果我們用的是迭代開發模型，得到的信息可能是以故事點為單位的燃燒圖（Burn up Chart），呈現的是端到端己經完成的特性。這些信息可能是某人手工計算產生，也可能是項目管理工具自動采集、匯總的，形式可能是一個Spreadsheet，也可能直接呈現在工具的頁面上。

系統的干預者，可能是項目經理、產品經理，或是某個領導，依據目標和當前環境情況（比如競爭對手信息），對照這些進度數據，判斷是否應該采取干預措施。如果發現跟預期有所差距，干預者可能會在交付內容或交付時間上有所調整，或是為團隊提供更多的資源來提升其交付產能，當然也可能是要求團隊開始加班加點……團隊對這種干預通常也會馬上做出反應，他們會根據干預行動和其他新的輸入，尋求并調整到一個新的穩定的工作機制，這種新的工作機制可能是找到一個更有效率的方法，也可能是馬上把設計、優化、驗證等活動拋掉，“裸奔”前進。

度量本身也會對軟件開發組織的人員、流程、組織和工具產生影響。在一些比較大型的產品開發組織當中，特別是實施SEI的CMMi模型的組織中，為了有效地管理過程質量，產生了質量保障（QA）組織。SEI的CMMi模型中強調的是軟件質量保障（SQA）的獨立性，組織的獨立性意味著，需要為不在一線團隊中的QA創造觀察和干預開發活動的機制，這樣的機制通常表現為圍繞開發流程創造出來的新流程，為了支撐這個流程的運轉，可能需要部署針對開發過程的數據的采集、匯總、報告一系列的工具。不過在實際的部署中，有些號稱重業務輕流程的組織里，QA組織形同虛設，只是為了獲取CMMi等資質而存在；而另一個極端是，在一些“成熟”的組織里，QA的影響力很大，原本應該承擔老師、醫生和警察責任的QA，最后只剩下了警察角色，揮舞著度量的大棒，跟開發團隊玩著貓捉老鼠的游戲。