摘要：
這年頭IT界流行“用數據管理過程”、“用數字說話”，軟件度量成爲熱點話題！一方面一堆專家在“譁衆取寵”，而另外一方面企業在推行軟件度量的實踐中遇到了各式各樣的問題，軟件度量在軟件企業中的實施效果不甚理想。一個軟件企業應該從何做起度量工作呢？希望本文能給大家帶來有益的啓發！
形形式式的度量陷阱
N年前，老闆對我們過程改進工作曾指示：能量化的工作儘量量化，不能量化的就不要勉強。當時覺得這個指示非常好，我也相信這個觀點很多人都會認同。實際上應該是這樣嗎？軟件度量就必須用數字來說明問題嗎？量化的結果一定比非量化的結果更準確客觀嗎？
沒有一套好的度量工具，很難做好度量工作！這是很多人的認識。而一些度量工具的生產廠商，更加是大力渲染，目的還不是爲了更容易從軟件企業的口袋裏面掏錢唄！要做好度量工作，真的需要一套強大的度量工具嗎？
處於手工作坊的軟件公司，難以進行軟件度量，軟件度量只能在有一定過程基礎的公司進行。另外，對於小公司、小項目沒有度量的必要，度量更適用於大公司、大項目。是這樣嗎？難道小公司、不規範的公司、小項目就不能利用軟件度量來改善生產力嗎？
軟件生產活動是智力活動，要客觀度量是很難的，要做好將會是很花成本的事情，而且開始階段要忍受比較高的成本，軟件度量所帶來的效果，需要長時間才能體現。軟件度量難道就沒有立竿見影的效果嗎？難道軟件度量是大公司、有錢公司才能玩得起嗎？
形形式式的度量陷阱，還遠不止以上這些呢！
什麼是度量？
我一直想搞清楚度量的定義，在網上查了一大輪，只能找到一些讓人看了還不如不看的“學院派”的定義。搞清楚什麼是軟件度量，非常重要，將會讓我們少走彎路，直接發揮度量的價值。看看下面我對度量的定義：
度量是這樣的一種活動：基於一定的目的，採用一定的辦法或者標準，對目標事物進行觀察，得到客觀的評價結果，根據評價結果，採取適當的行動。
這個定義，反應了度量活動的四個要素：
1. 基於一定的目的。
2. 採用一定的辦法或者標準。
3. 得到客觀的評價結果。
4. 採取適當的行動。
下面我們以度量水的溫度爲例來體會一下度量的定義。
如果有人給你一個度量任務，要求你度量水的溫度，你會怎樣做？
你會不會馬上想到用溫度計？
不好意思，如果是這樣，你就落入了度量的其中一個陷阱了。你應該先問，爲什麼要度量水的溫度？不同的目的，做法是不一樣的。
如果度量的目的是爲了判斷煲水的時候水是不是開了。你還會用溫度計嗎？當然你可以用能測量一百攝氏度的溫度計來度量水的溫度，但我們更多的會用肉眼觀察水的形態，來判斷是否水開了，如果想更簡單一點的，買一個水開的時候會響的水壺或者是搞個飲水機就可以搞定了。
如果度量水的溫度，目的是希望水溫合適，好幫BB洗澡呢？有些媽媽會用溫度計，有些媽媽會用自己的手直接去感覺水溫，兩種辦法都可以。
一個小小的度量水溫的問題，都很有學問，大家發現，不同的目的下，做法是不一樣的。有些做法很簡單實用，不需要什麼專門的工具，直接用手感覺溫度，或者肉眼觀察就可以了。相反，如果我們搞不清目的，就很可能殺雞用牛刀，甚至是受到傷害，一個不小心，你就可能直接用手去感覺開水的溫度了。
另外我們也發現，度量的結果不一定都是數字來的，只要滿足目的，越簡單越好。水是否開的問題，我們只需要知道水是否開了就可以了，度量結果只有兩個：是或者否，我們不需要知道這水是攝氏多少度。度量並不需要很精確，滿足目的就好！
度量的目的不是光爲了得到一個結果，而是要根據度量的結果採取行動。如果媽媽發現水溫不夠，她會加入一些熱水，如果覺得太熱，就會加入冷水。這些行動的目的就是爲了讓BB有適合的水溫洗澡。
首先應該度量的指標——公司的效益指標
如果要做度量工作，最開始應該度量什麼呢？我建議應該首先度量公司的效益，度量效益的目的是對公司生產力狀況有一個準確的認識，更準確地分析出問題所在，爲決策提供更準確的依據。
那麼公司的效益該如何度量呢？
公司有兩大生產力指標，成本與收入。公司近一年的總體成本，包括人工、採購、水電費、房租費等全部費用加起來，財務肯定會有這樣的一個數字。公司近一年所有人員的工作時間，所有人員包括開發、測試、行政、財務等，凡在公司的工作的所有人，這些人上了多少天的班，一定也會知道，每個公司都有考勤請假的記錄嗎，就算沒有也可以大概估算。這樣我們可以得到公司全部人員一年的總體工作時間，單位是小時。這樣我們有這樣的一個指標：
成本指數 = 公司總費用/總工作時間，單位：元/小時
這個數字表明，在這個公司工作的每一位員工，每工作一個小時，其實是需要這樣的一個成本的。沒有算的公司儘快算算，你可能會發現，原來這個數字還相當大呢，遠遠超過這個人的時薪。
關於收入，我們有這樣的一個指標：
收入指數 = 公司總收入/總工作時間，單位: 元/小時
這個數字表明，在這個公司工作的每一位員工，每工作一個小時，爲公司帶來多少的價值。
如果收入指數大於成本指數，說明公司是在賺錢的。公司的生產力就可以看這兩個數字了，我們希望儘量降低成本指數，儘量提高收入指數，於是我們會得到下面這個指標：
效益指數= 收入指數:成本指數
企業最終追求的是提高效益指數，成本大沒關係，效益指數高就沒問題了。這些指標都可以繼續細化，如：可把成本分類，成本會分成人工成本、非人工成本，人工成本有可以分爲工程類人員人工成本、支持類人員人工成本等，經過細分，可以發現自己的成本構成不合理的地方，進行相應的改善。如：把收入細分，看看收入的組成，收入都是由哪些部門哪些人產生的，這些都能幫助企業提高收入。
公司的效益指標的度量是任何公司都可以做的，而且應該是第一時間就要做的度量，並且要持續地做的。公司所做的任何工作，市場活動、過程改進工作、度量工作等等，最終目的還是爲了提高效益指數！
每個軟件公司都可以並且應該做好的度量——缺陷度量
就算一個開發極不規範公司，我想總會對缺陷有一定的管理辦法吧？至少缺陷會被記錄下來（哪怕是各種方式），而不會只是口頭說而毫無記錄吧？
大多數軟件公司都會有一套管理缺陷的系統，我們應該如何把缺陷度量做得更好呢？
我們需要目標驅動地把度量工作做好，首先有兩個最基本的要求：
1. 缺陷被準確的記錄和跟蹤。
2. 客觀地依據缺陷狀況對軟件發佈進行決策。
根據這兩個要求，我們需要詳細定義缺陷的屬性，這些缺陷的屬性就是我們要度量的內容。很多公司都會定義缺陷的描述、嚴重程度等屬性，另外也會規定發佈的時候，什麼嚴重級別的缺陷不能超過多少個等要求。
以上兩個目標只是缺陷度量的兩個基本目標，如果更深入一點，我們希望能預防缺陷的再次發生，最簡單有效的辦法就是：直接讓項目組成員一起來分析缺陷的原因，讓大家避免重犯。
如果想做更系統更深入的分析，就需要考慮在組織層面來做這個分析工作。這時有必要增加缺陷一個屬性，叫做“缺陷來源”，就是說產生這個缺陷的源頭是在哪裏，是需求沒有分析到位，還是設計沒有做好，還是編碼出問題？按“缺陷來源”來分析公司不同類型的項目的缺陷情況，您就會發現公司的軟件開發過程最有問題的是哪個過程？哪些過程做得比較好？這些分析結果會很好的指引過程改進的方向。
缺陷度量有很多可以發掘的地方，這是每一個公司都應該做好也是最有條件做好的一種度量。
形形式式的度量陷阱
N年前，老闆對我們過程改進工作曾指示：能量化的工作儘量量化，不能量化的就不要勉強。當時覺得這個指示非常好，我也相信這個觀點很多人都會認同。實際上應該是這樣嗎？軟件度量就必須用數字來說明問題嗎？量化的結果一定比非量化的結果更準確客觀嗎？
沒有一套好的度量工具，很難做好度量工作！這是很多人的認識。而一些度量工具的生產廠商，更加是大力渲染，目的還不是爲了更容易從軟件企業的口袋裏面掏錢唄！要做好度量工作，真的需要一套強大的度量工具嗎？
處於手工作坊的軟件公司，難以進行軟件度量，軟件度量只能在有一定過程基礎的公司進行。另外，對於小公司、小項目沒有度量的必要，度量更適用於大公司、大項目。是這樣嗎？難道小公司、不規範的公司、小項目就不能利用軟件度量來改善生產力嗎？
軟件生產活動是智力活動，要客觀度量是很難的，要做好將會是很花成本的事情，而且開始階段要忍受比較高的成本，軟件度量所帶來的效果，需要長時間才能體現。軟件度量難道就沒有立竿見影的效果嗎？難道軟件度量是大公司、有錢公司才能玩得起嗎？
形形式式的度量陷阱，還遠不止以上這些呢！
什麼是度量？
我一直想搞清楚度量的定義，在網上查了一大輪，只能找到一些讓人看了還不如不看的“學院派”的定義。搞清楚什麼是軟件度量，非常重要，將會讓我們少走彎路，直接發揮度量的價值。看看下面我對度量的定義：
度量是這樣的一種活動：基於一定的目的，採用一定的辦法或者標準，對目標事物進行觀察，得到客觀的評價結果，根據評價結果，採取適當的行動。
這個定義，反應了度量活動的四個要素：
1. 基於一定的目的。
2. 採用一定的辦法或者標準。
3. 得到客觀的評價結果。
4. 採取適當的行動。
下面我們以度量水的溫度爲例來體會一下度量的定義。
如果有人給你一個度量任務，要求你度量水的溫度，你會怎樣做？
你會不會馬上想到用溫度計？
不好意思，如果是這樣，你就落入了度量的其中一個陷阱了。你應該先問，爲什麼要度量水的溫度？不同的目的，做法是不一樣的。
如果度量的目的是爲了判斷煲水的時候水是不是開了。你還會用溫度計嗎？當然你可以用能測量一百攝氏度的溫度計來度量水的溫度，但我們更多的會用肉眼觀察水的形態，來判斷是否水開了，如果想更簡單一點的，買一個水開的時候會響的水壺或者是搞個飲水機就可以搞定了。
如果度量水的溫度，目的是希望水溫合適，好幫BB洗澡呢？有些媽媽會用溫度計，有些媽媽會用自己的手直接去感覺水溫，兩種辦法都可以。
一個小小的度量水溫的問題，都很有學問，大家發現，不同的目的下，做法是不一樣的。有些做法很簡單實用，不需要什麼專門的工具，直接用手感覺溫度，或者肉眼觀察就可以了。相反，如果我們搞不清目的，就很可能殺雞用牛刀，甚至是受到傷害，一個不小心，你就可能直接用手去感覺開水的溫度了。
另外我們也發現，度量的結果不一定都是數字來的，只要滿足目的，越簡單越好。水是否開的問題，我們只需要知道水是否開了就可以了，度量結果只有兩個：是或者否，我們不需要知道這水是攝氏多少度。度量並不需要很精確，滿足目的就好！
度量的目的不是光爲了得到一個結果，而是要根據度量的結果採取行動。如果媽媽發現水溫不夠，她會加入一些熱水，如果覺得太熱，就會加入冷水。這些行動的目的就是爲了讓BB有適合的水溫洗澡。
首先應該度量的指標——公司的效益指標
如果要做度量工作，最開始應該度量什麼呢？我建議應該首先度量公司的效益，度量效益的目的是對公司生產力狀況有一個準確的認識，更準確地分析出問題所在，爲決策提供更準確的依據。
那麼公司的效益該如何度量呢？
公司有兩大生產力指標，成本與收入。公司近一年的總體成本，包括人工、採購、水電費、房租費等全部費用加起來，財務肯定會有這樣的一個數字。公司近一年所有人員的工作時間，所有人員包括開發、測試、行政、財務等，凡在公司的工作的所有人，這些人上了多少天的班，一定也會知道，每個公司都有考勤請假的記錄嗎，就算沒有也可以大概估算。這樣我們可以得到公司全部人員一年的總體工作時間，單位是小時。這樣我們有這樣的一個指標：
成本指數 = 公司總費用/總工作時間，單位：元/小時
這個數字表明，在這個公司工作的每一位員工，每工作一個小時，其實是需要這樣的一個成本的。沒有算的公司儘快算算，你可能會發現，原來這個數字還相當大呢，遠遠超過這個人的時薪。
關於收入，我們有這樣的一個指標：
收入指數 = 公司總收入/總工作時間，單位: 元/小時
這個數字表明，在這個公司工作的每一位員工，每工作一個小時，爲公司帶來多少的價值。
如果收入指數大於成本指數，說明公司是在賺錢的。公司的生產力就可以看這兩個數字了，我們希望儘量降低成本指數，儘量提高收入指數，於是我們會得到下面這個指標：
效益指數= 收入指數:成本指數
企業最終追求的是提高效益指數，成本大沒關係，效益指數高就沒問題了。這些指標都可以繼續細化，如：可把成本分類，成本會分成人工成本、非人工成本，人工成本有可以分爲工程類人員人工成本、支持類人員人工成本等，經過細分，可以發現自己的成本構成不合理的地方，進行相應的改善。如：把收入細分，看看收入的組成，收入都是由哪些部門哪些人產生的，這些都能幫助企業提高收入。
公司的效益指標的度量是任何公司都可以做的，而且應該是第一時間就要做的度量，並且要持續地做的。公司所做的任何工作，市場活動、過程改進工作、度量工作等等，最終目的還是爲了提高效益指數！
每個軟件公司都可以並且應該做好的度量——缺陷度量
就算一個開發極不規範公司，我想總會對缺陷有一定的管理辦法吧？至少缺陷會被記錄下來（哪怕是各種方式），而不會只是口頭說而毫無記錄吧？
大多數軟件公司都會有一套管理缺陷的系統，我們應該如何把缺陷度量做得更好呢？
我們需要目標驅動地把度量工作做好，首先有兩個最基本的要求：
1. 缺陷被準確的記錄和跟蹤。
2. 客觀地依據缺陷狀況對軟件發佈進行決策。
根據這兩個要求，我們需要詳細定義缺陷的屬性，這些缺陷的屬性就是我們要度量的內容。很多公司都會定義缺陷的描述、嚴重程度等屬性，另外也會規定發佈的時候，什麼嚴重級別的缺陷不能超過多少個等要求。
以上兩個目標只是缺陷度量的兩個基本目標，如果更深入一點，我們希望能預防缺陷的再次發生，最簡單有效的辦法就是：直接讓項目組成員一起來分析缺陷的原因，讓大家避免重犯。
如果想做更系統更深入的分析，就需要考慮在組織層面來做這個分析工作。這時有必要增加缺陷一個屬性，叫做“缺陷來源”，就是說產生這個缺陷的源頭是在哪裏，是需求沒有分析到位，還是設計沒有做好，還是編碼出問題？按“缺陷來源”來分析公司不同類型的項目的缺陷情況，您就會發現公司的軟件開發過程最有問題的是哪個過程？哪些過程做得比較好？這些分析結果會很好的指引過程改進的方向。
缺陷度量有很多可以發掘的地方，這是每一個公司都應該做好也是最有條件做好的一種度量。
成功的基礎——軟件規模度量
最近有這樣的一個辯論，功能點VS代碼行，辯論的焦點就是用哪一種來代表軟件規模更好一點。項目規模的度量大有學問，如果您想去聽聽專業的軟件功能點法課程，您可能要付上高昂的學費，並且有可能學了後還不知道如何用上這個辦法。這裏我不想談論這兩種辦法，這些方法可能僅是理論上可行，目前我也沒有見到過一個成功實踐這類方法的案例。
我們爲什麼要進行軟件規模度量呢？目的無非是：
1. 作爲報價或者決策的依據。
2. 安排具體的項目進度。
3. 可以作爲組織的生產力數據，可以有很多用途，如：各項目間橫向比較，供以後項目參考等。
如果是爲了投標報價，建議用Delphi法，功能點法、代碼行法太慢了，不能適應商戰社會，投標經常是沒有這麼多時間讓你去折騰的。Delphi法的大致方法如下：
1. 找幾名資深專家，一起對項目進行WBS，把項目的工作分解爲十幾條最多二三十條的工作項。
2. 全部專家各自估計每條工作項的工作量，並向其他專家闡述自己的理由。
3. 第一次各專家估出來的結果可能差異比較大，每位專家聽取別人的意見後，重新估算。
4. 按照上述辦法，各專家反覆估算幾次，一般次數就是2-4次，各專家估計的工作量會越來越趨近，這個時候取全部專家的平均值。
如果是爲了目標2，安排具體的項目進度，我建議用“傻瓜估算法”，而我們親愛的微軟，就是採用這樣的方法來估算規模的。這樣的辦法雖然原始，但有效，並且容易掌握。雖然這種辦法被扣上主觀成分大、項目間難以橫向對比的、難以積累歷史數據等多種“罪狀”，但不好意思，用功能點法或者代碼行法就很準嗎？我們親愛的軟件工程師們認可功能點法或者代碼行法嗎？搞功能點法代碼行法等這些“虛”辦法，還不如老老實實地WBS，直接估算每個工作的工作量。
第一步：把公司內部最有項目經驗最有估算經驗的工程們召集在一起，制訂組織級別的估算表框架。
軟件開發活動，可以分類以下幾類：
l 直接生產軟件的活動，如：需求開發、設計、編碼、測試等工程類活動。
l 項目管理類活動，如：編寫項目計劃、計劃跟蹤、發佈評審等活動。
l 項目支持類活動，如：配置管理、QA檢查等。
l 維護類活動，項目驗收後的數據整理、修改缺陷、系統維護等活動。
根據公司的實際情況，列出各類項目活動，可以根據不同的項目類別而列出不同的活動，儘量把這些活動種類細化，如考慮設計時，還需要考慮設計評審的時間，考慮編寫計劃時，需要考慮主計劃、子計劃的編寫等等。
把這些框架定好，並設計出估算表模板，供項目組使用。
據我的經驗，很多估算沒有做好的緣故，常常是忘記或者是沒有估算好管理類、支持類、維護類的活動。當一個公司的估算精英聚集在一起的時候，大家要列出公司估算中常常遇到的問題，全部考慮到估算表模板中，並寫上足夠清晰的指導。當項目組用這些模板的時候，相當於用了估算精英們的腦袋來思考本項目的估算了。
第二步：項目組選用合適的估算表模板，進行由底而上的估算。
項目組根據自己項目的特點，選用合適的估算表模板，然後項目組成員一起在這個模板的基礎上，繼續細化，進行詳細的WBS，列出要完成這個項目所需要的全部工作，並且把這些工作落實到具體的項目組成員身上，由負責該任務的人來估算自己完成這個任務需要多少時間，而不是由項目經理分配一個完成時間。這就是由底而上的估算辦法，這是微軟MSF中的估算辦法，這個辦法有以下好處：
1. 最終該任務是由這個人來完成的，他估計多少時間才能做完，這個時間纔是最接近實際的。
2. 負責該任務的人進行估算的時候，肯定需要認真思考這個任務的風險，需要做哪些具體的工作，這樣更容易在未開始工作之前就發現更多的潛在問題。相反如果由項目經理來分配時間，這個人就可能不會去思考這個任務了。
3. 做這個任務的人會有被重視和尊重的感覺，他會很重視自己承諾的完成時間，並且想法設法按時間完成。這樣會減少很多項目管理時間，因爲每個任務負責人都會主動地跟蹤好自己的工作。
第三步：持續完善模板，持續改進。
每個項目使用模板進行估算後，都可以對模板提出改進建議，把本項目的成功經驗融入到模板中，讓後面的項目收益。
“傻瓜估算法”非常直接有效，能很準確地估算出項目的工作量。學院派的人士會認爲應該先估算出規模，然後再由規模估算出工作量，但我想說的是，估算規模的目的還不是爲了估算工作量，如果有辦法直接準確地估算工作量，幹嘛還要去估算規模，幹嘛還要去想功能點法好還是代碼行法好？當時我們主任評估師也認可這樣的做法，他也認爲某些情況下工作量可以直接代表項目規模。CMMI也沒有規定非要用什麼功能點法代碼行法來度量軟件規模。
軟件的工作量估算是很重要的一項工作，是整個項目成功的基礎，用“土方法”也可以把工作量估好估準！
如果要滿足目標3，即作爲組織的生產力數據，應該如何度量呢？
滿足目標3之前，我們應該保證我們能滿足目標1和目標2，如果目標1和目標2都沒滿足的情況下，我們就去追求目標3，是有點“超前”，這種“超前”對公司來說可能是“拔苗助長”。當然我們希望有一種方法能同時滿足這三個目標的，但到目前爲止，我還沒有見到過這樣的成功案例。軟件規模度量還是要一步一步來，不要一開始就期望吃成個“胖子”了。
如果在“傻瓜估算法”的基礎上多做一步，我們是可以滿足目標三的。在第二步進行WBS進行由底而上的估算時，這些WBS其實是可以分解成功能點或者是代碼行數。我們可以利用這些WBS得到兩個輸出，一個是工作量，一個是功能點或者是代碼行數。如果積累了一定的數據，就可以建立功能點或者代碼行數與工作量的對應關係，這樣不僅可以用來衡量公司的生產力，也可以利用這些經驗數據來估算以後的項目。