度量的概念是從量化項目管理而來，主要用于項目質(zhì)量、進度、生產(chǎn)率等方面的管理。通常是由qa、epg、pmo來推進、整理項目組織的各類數(shù)據(jù)，作為基準來約束項目、產(chǎn)品研發(fā)的尺度。
度量有三個范疇，產(chǎn)品度量、項目度量和過程度量。
項目度量，反映項目狀態(tài)，關(guān)注實際結(jié)果與計劃或過程標準的偏差，用于項目監(jiān)督和控制。
產(chǎn)品度量，對軟件產(chǎn)品進行的、獨立于產(chǎn)品生產(chǎn)過程的度量，通常關(guān)注重點是產(chǎn)品質(zhì)量。
過程度量，量化了軟件過程或開發(fā)環(huán)境的屬性，對于成熟企業(yè)關(guān)注過程性能和能力的度量。
廣義的過程度量涵蓋了這三部分。我們今天講的度量泛指廣義的過程度量。
度量就是用數(shù)字說話。那么度量涉及什么?它涉及項目開發(fā)全過程，包括估算、需求管理、設計、編碼、測試等階段。
度量的第一基本法則：明確量化管理的目的及約束條件。
就估算來講，“功能點”法是比較復雜而且難掌握的軟件規(guī)模度量辦法，有可能在研究使用的過程中，才發(fā)現(xiàn)不值得用“功能點”法，大家再反過來看看目標：在一定的時間成本要求內(nèi)，提供估算的準確率，而不是：在一定的時間成本要求內(nèi)，用功能點法提高估算的準確率。這時，大家可以選用別的辦法，或者對“功能點”法進行改造。在制定目標的時候，不要把具體的方法寫進去，目標是很高層次的，把辦法寫進去，也就是相當于限制了思路。
有很多軟件企業(yè)，在項目過程中，須提交一些進度報告、總結(jié)報告，報告中可能會有進度情況、成本情況的一些數(shù)據(jù)。收集這些數(shù)據(jù)的目標也十分明確，就是想了解項目的進度、成本情況，并與計劃的情況進行比較，采取必要的措施。
也就是說，度量要明確目標。以cmmi為例，3級要度量的和5級要度量的是不一樣的，不能眉毛胡子一把抓。否則，就會出現(xiàn)過度度量。對于成熟度2級的即項目級，就是說項目交付可復制級別，可能在需求、質(zhì)量方面的度量更有意義。www.ltesting.net
1) 初級量化管理-感知級，相當于CMMI2級。
2) 中級量化管理-經(jīng)驗級，相當于CMMI3級。項目管理者聯(lián)盟
3) 高級量化管理-可預測級，相當于CMMI4級。
4) 超級量化管理-持續(xù)優(yōu)化級，相當于CMMI5級。項
下面談的度量，更多是面向2、3級的度量。4、5級的性能、效率離得比較遠，操作往往需要IT工具支撐，回頭再聊。
2、3級度量，哪些比較合適?下面我列一些要點。我們每做完一個項目，都要做這些要點的度量(過程中和結(jié)項后)
1、"項目基本信息"
包括開發(fā)平臺、編程工具、語言、操作系統(tǒng)、數(shù)據(jù)庫、業(yè)務單元數(shù)、架構(gòu)類型、并發(fā)用戶量、生命周期模型等等，是用于公司下個項目參考的基礎信息。
2、項目規(guī)模度量
可以用代碼行、也可以用功能點，要固定下來具備參考性?？梢詭椭覀冊诟麟A段都去看自己的估算偏差。其中，包括：
最大團隊規(guī)模項目管理培訓
平均團隊規(guī)模
計劃階段團隊規(guī)模
需求階段團隊規(guī)模
設計階段團隊規(guī)模
構(gòu)建階段團隊規(guī)模
測試階段團隊規(guī)模
需求階段結(jié)束估計規(guī)模
設計階段結(jié)束估計規(guī)模
構(gòu)建階段結(jié)束估計規(guī)模
測試階段結(jié)束估計規(guī)模
需求評審規(guī)模
設計評審規(guī)模
編碼評審規(guī)模
測試評審規(guī)模
其他評審規(guī)模
這些度量對你開展新項目有直接參考價值。
3、進度
需求階段計劃開始日期bbs.ltesting.net
需求階段計劃結(jié)束日期
需求階段實際開始日期項目經(jīng)理博客
需求階段實際結(jié)束日期
設計階段計劃開始日期training.ltesting.net
設計階段計劃結(jié)束日期項目管理論壇
設計階段實際開始日期
設計階段實際結(jié)束日期
構(gòu)建階段計劃開始日期bbs.ltesting.net
構(gòu)建階段計劃結(jié)束日期
構(gòu)建階段實際開始日期training.ltesting.net
構(gòu)建階段實際結(jié)束日期
測試階段計劃開始日期blog.ltesting.net
測試階段計劃結(jié)束日期blog.ltesting.net
測試階段實際開始日期
測試階段實際結(jié)束日期
實施階段計劃開始日期blog.ltesting.net
實施階段計劃結(jié)束日期
實施階段實際開始日期
實施階段實際結(jié)束日期
這里的構(gòu)建就是編碼。項目管理者聯(lián)盟文章
4、工作量(wbs分解，工時)項目經(jīng)理博客
計劃總工時
實際總工時轉(zhuǎn)自項目管理者聯(lián)盟
計劃階段計劃工時blog.ltesting.net
計劃階段實際工時
需求階段計劃工時
需求階段實際工時training.ltesting.net
設計階段計劃工時項目管理培訓
設計階段實際工時
構(gòu)建階段計劃工時
構(gòu)建階段實際工時training.ltesting.net
測試階段計劃工時
測試階段實際工時
實施階段團隊規(guī)模
實施階段計劃工時
實施階段實際工時
項目管理計劃工時
項目管理實際工時
配置管理計劃工時
配置管理實際工時
質(zhì)量保證計劃工時
質(zhì)量保證實際工時blog.ltesting.net
需求活動計劃工時
需求活動實際工時
設計活動計劃工時
設計活動實際工時training.ltesting.net
編碼活動計劃工時
編碼活動實際工時項目管理培訓
測試活動計劃工時
測試活動實際工時blog.ltesting.net
實施活動計劃工時項目管理者聯(lián)盟
實施活動實際工時
評審計劃工時項目經(jīng)理圈子
評審實際工時項目管理者聯(lián)盟
其他活動計劃工時
其他活動實際工時blog.ltesting.net
返工總工時項目管理者聯(lián)盟文章
需求階段返工工時
設計階段返工工時
構(gòu)建階段返工工時
測試階段返工工時
實施階段返工工時
計劃評審工時
需求評審工時
設計評審工時www.ltesting.net
編碼評審工時
測試評審工時
其他評審工時bbs.ltesting.net
這些度量，使得你能夠與客戶、老板要管理工時、返工工時，即，項目不僅僅是設計、開發(fā)。也幫助你分析為什么項目會delay，是哪些因素造成：評審工時省了?還是返工工時沒估計到?這些都是很關(guān)鍵的。
5、很關(guān)鍵的--質(zhì)量
預計缺陷總數(shù)www.ltesting.net
實際缺陷總數(shù)training.ltesting.net
預計致命缺陷
實際致命缺陷
預計主要缺陷
實際主要缺陷
預計次要缺陷
實際次要缺陷
預計遺留缺陷數(shù)
實際遺留缺陷數(shù)
需求階段預計發(fā)現(xiàn)缺陷
需求階段實際發(fā)現(xiàn)缺陷bbs.ltesting.net
設計階段預計發(fā)現(xiàn)缺陷
設計階段實際發(fā)現(xiàn)缺陷
構(gòu)建階段預計發(fā)現(xiàn)缺陷項目經(jīng)理圈子
構(gòu)建階段實際發(fā)現(xiàn)缺陷
測試階段預計發(fā)現(xiàn)缺陷
測試階段實際發(fā)現(xiàn)缺陷項目管理者聯(lián)盟文章
實施階段預計發(fā)現(xiàn)缺陷項目管理者聯(lián)盟文章
實施階段實際發(fā)現(xiàn)缺陷www.ltesting.net
交付后1個月內(nèi)發(fā)現(xiàn)總?cè)毕?/p>
交付后1個月內(nèi)發(fā)現(xiàn)致命缺陷
交付后1個月內(nèi)發(fā)現(xiàn)主要缺陷
交付后1個月內(nèi)發(fā)現(xiàn)次要缺陷
需求活動預計引入缺陷
需求活動實際引入缺陷
需求活動實際引入缺陷(需求時發(fā)現(xiàn))項目管理論壇
需求活動實際引入缺陷(設計時發(fā)現(xiàn))
需求活動實際引入缺陷(編碼時發(fā)現(xiàn))
需求活動實際引入缺陷(測試時發(fā)現(xiàn))項目經(jīng)理圈子
需求活動實際引入缺陷(實施時發(fā)現(xiàn))
需求活動預計清除缺陷
需求活動實際清除缺陷
設計活動預計引入缺陷
設計活動實際引入缺陷項目經(jīng)理博客
設計活動實際引入缺陷(設計時發(fā)現(xiàn))
設計活動實際引入缺陷(編碼時發(fā)現(xiàn))
設計活動實際引入缺陷(測試時發(fā)現(xiàn))
設計活動實際引入缺陷(實施時發(fā)現(xiàn))項目管理者聯(lián)盟設計活動預計清除缺陷
設計活動實際清除缺陷
編碼活動預計引入缺陷轉(zhuǎn)自項目管理者聯(lián)盟
編碼活動實際引入缺陷
編碼活動實際引入缺陷(編碼時發(fā)現(xiàn))
編碼活動實際引入缺陷(測試時發(fā)現(xiàn))項目管理者聯(lián)盟文章
編碼活動實際引入缺陷(實施時發(fā)現(xiàn))
編碼活動預計清除缺陷
編碼活動實際清除缺陷
測試活動預計引入缺陷
測試活動實際引入缺陷項目經(jīng)理圈子
測試活動預計清除缺陷
測試活動實際清除缺陷
實施活動預計引入缺陷
實施活動實際引入缺陷bbs.ltesting.net
實施活動預計清除缺陷
實施活動實際清除缺陷
項目在開發(fā)前就應該預估會有多少bug，根據(jù)bug的修改時間就知道要多少返工，以及測試輪次。這些數(shù)據(jù)也可以反映，因需求不清導致多少bug?引入bug的影響率?以及銷售、交付后有多少bug?這些數(shù)據(jù)有了，考核都有了。
例如，交付后1個月返工的bug，考核測試與開發(fā)、項目經(jīng)理、總監(jiān)等。
再例如，你前面有規(guī)模估計，自然能預估會有多少bug。以代碼行為例，標準如果是千行bug率在千分之3，那么你是10w行規(guī)模則會預計bug300個，測試1輪如果可以發(fā)現(xiàn)100個的話就要3輪測試。開發(fā)測試計劃中你制定2輪就不合理了，1輪1周，那需要3周，你給2周也就不合理了。
綜上可見，度量是項目管理的靈魂。如何根據(jù)當前階段能力，選擇最關(guān)鍵的度量點是qa、總監(jiān)要很清醒的。不能不度量，也不能度量過度。以上5點做好了，這家公司基本是正規(guī)的公司了。其他的，一些其他高級度量點等再成熟了就再度量
