| 度量的概念是从量化项目管理而来，主要用于项目质量、进度、生产率等方面的管理。通常是由qa、epg、pmo来推进、整理项目组织的各类数据，作为基准来约束项目、产品研发的尺度。
度量有三个范畴，产品度量、项目度量和过程度量。
项目度量，反映项目状态，关注实际结果与计划或过程标准的偏差，用于项目监督和控制。
产品度量，对软件产品进行的、独立于产品生产过程的度量，通常关注重点是产品质量。
过程度量，量化了软件过程或开发环境的属性，对于成熟企业关注过程性能和能力的度量。
广义的过程度量涵盖了这三部分。我们今天讲的度量泛指广义的过程度量。
度量就是用数字说话。那么度量涉及什么?它涉及项目开发全过程，包括估算、需求管理、设计、编码、测试等阶段。
度量的第一基本法则：明确量化管理的目的及约束条件。
就估算来讲，“功能点”法是比较复杂而且难掌握的软件规模度量办法，有可能在研究使用的过程中，才发现不值得用“功能点”法，大家再反过来看看目标：在一定的时间成本要求内，提供估算的准确率，而不是：在一定的时间成本要求内，用功能点法提高估算的准确率。这时，大家可以选用别的办法，或者对“功能点”法进行改造。在制定目标的时候，不要把具体的方法写进去，目标是很高层次的，把办法写进去，也就是相当于限制了思路。
有很多软件企业，在项目过程中，须提交一些进度报告、总结报告，报告中可能会有进度情况、成本情况的一些数据。收集这些数据的目标也十分明确，就是想了解项目的进度、成本情况，并与计划的情况进行比较，采取必要的措施。
也就是说，度量要明确目标。以cmmi为例，3级要度量的和5级要度量的是不一样的，不能眉毛胡子一把抓。否则，就会出现过度度量。对于成熟度2级的即项目级，就是说项目交付可复制级别，可能在需求、质量方面的度量更有意义。
1) 初级量化管理-感知级，相当于CMMI2级。
2) 中级量化管理-经验级，相当于CMMI3级。
3) 高级量化管理-可预测级，相当于CMMI4级。
4) 超级量化管理-持续优化级，相当于CMMI5级。
下面谈的度量，更多是面向2、3级的度量。4、5级的性能、效率离得比较远，操作往往需要IT工具支撑，回头再聊
2、3级度量，哪些比较合适?下面我列一些要点。我们每做完一个项目，都要做这些要点的度量(过程中和结项后)
1、"项目基本信息"
包括开发平台、编程工具、语言、操作系统、数据库、业务单元数、架构类型、并发用户量、生命周期模型等等，是用于公司下个项目参考的基础信息。
2、项目规模度量
可以用代码行、也可以用功能点，要固定下来具备参考性。可以帮助我们在各阶段都去看自己的估算偏差。其中，
包括最大团队规模
平均团队规模
计划阶段团队规模
需求阶段团队规模
设计阶段团队规模
构建阶段团队规模
测试阶段团队规模
实施阶段团队规模
需求阶段结束估计规模
设计阶段结束估计规模
构建阶段结束估计规模
测试阶段结束估计规模
需求评审规模
设计评审规模
编码评审规模
测试评审规模
其他评审规模
这些度量对你开展新项目有直接参考价值。
3、进度
需求阶段计划开始日期
需求阶段计划结束日期
需求阶段实际开始日期
需求阶段实际结束日期
设计阶段计划开始日期
设计阶段计划结束日期
设计阶段实际开始日期
设计阶段实际结束日期
构建阶段计划开始日期
构建阶段计划结束日期
构建阶段实际开始日期
构建阶段实际结束日期
测试阶段计划开始日期
测试阶段计划结束日期
测试阶段实际开始日期
测试阶段实际结束日期
实施阶段计划开始日期
实施阶段计划结束日期
实施阶段实际开始日期
实施阶段实际结束日期
这里的构建就是编码。
4、工作量(wbs分解，工时)
计划总工时
实际总工时
计划阶段计划工时
计划阶段实际工时
需求阶段计划工时
需求阶段实际工时
设计阶段计划工时
设计阶段实际工时
构建阶段计划工时
构建阶段实际工时
测试阶段计划工时
测试阶段实际工时
实施阶段计划工时
实施阶段实际工时
项目管理计划工时
项目管理实际工时
配置管理计划工时
配置管理实际工时
质量保证计划工时
质量保证实际工时
需求活动计划工时
需求活动实际工时
设计活动计划工时
设计活动实际工时
编码活动计划工时
编码活动实际工时
测试活动计划工时
测试活动实际工时
实施活动计划工时
实施活动实际工时
评审计划工时
评审实际工时
其他活动计划工时
其他活动实际工时
返工总工时
需求阶段返工工时
设计阶段返工工时
构建阶段返工工时项目管理培训
测试阶段返工工时
实施阶段返工工时
计划评审工时
需求评审工时
设计评审工时
编码评审工时
测试评审工时
其他评审工时
这些度量，使得你能够与客户、老板要管理工时、返工工时，即，项目不仅仅是设计、开发。也帮助你分析为什么项目会delay，是哪些因素造成：评审工时省了?还是返工工时没估计到?这些都是很关键的。
5、很关键的--质量
预计缺陷总数
实际缺陷总数
预计致命缺陷
实际致命缺陷
预计主要缺陷
实际主要缺陷
预计次要缺陷
实际次要缺陷
预计遗留缺陷数
实际遗留缺陷数
需求阶段预计发现缺陷
需求阶段实际发现缺陷
设计阶段预计发现缺陷
设计阶段实际发现缺陷
构建阶段预计发现缺陷
构建阶段实际发现缺陷
测试阶段预计发现缺陷
测试阶段实际发现缺陷
实施阶段预计发现缺陷
实施阶段实际发现缺陷
交付后1个月内发现总缺陷
交付后1个月内发现致命缺陷
交付后1个月内发现主要缺陷
交付后1个月内发现次要缺陷
需求活动预计引入缺陷
需求活动实际引入缺陷
需求活动实际引入缺陷(需求时发现)
需求活动实际引入缺陷(设计时发现)
需求活动实际引入缺陷(编码时发现)
需求活动实际引入缺陷(测试时发现)
需求活动实际引入缺陷(实施时发现)
需求活动预计清除缺陷
需求活动实际清除缺陷
设计活动预计引入缺陷
设计活动实际引入缺陷
设计活动实际引入缺陷(设计时发现)
设计活动实际引入缺陷(编码时发现)
设计活动实际引入缺陷(测试时发现)
设计活动实际引入缺陷(实施时发现)
设计活动预计清除缺陷
设计活动实际清除缺陷
编码活动预计引入缺陷
编码活动实际引入缺陷
编码活动实际引入缺陷(编码时发现)
编码活动实际引入缺陷(测试时发现)
编码活动实际引入缺陷(实施时发现)
编码活动预计清除缺陷
编码活动实际清除缺陷
测试活动预计引入缺陷
测试活动实际引入缺陷
测试活动预计清除缺陷
测试活动实际清除缺陷
实施活动预计引入缺陷
实施活动实际引入缺陷
实施活动预计清除缺陷
实施活动实际清除缺陷
项目在开发前就应该预估会有多少bug，根据bug的修改时间就知道要多少返工，以及测试轮次。这些数据也可以反映，因需求不清导致多少bug?引入bug的影响率?以及销售、交付后有多少bug?这些数据有了，考核都有了。
例如，交付后1个月返工的bug，考核测试与开发、项目经理、总监等。
再例如，你前面有规模估计，自然能预估会有多少bug。以代码行为例，标准如果是千行bug率在千分之3，那么你是10w行规模则会预计bug300个，测试1轮如果可以发现100个的话就要3轮测试。开发测试计划中你制定2轮就不合理了，1轮1周，那需要3周，你给2周也就不合理了。
综上可见，度量是项目管理的灵魂。如何根据当前阶段能力，选择最关键的度量点是qa、总监要很清醒的。不能不度量，也不能度量过度。以上5点做好了，这家公司基本是正规的公司了。其他的，一些其他高级度量点等再成熟了就再度量
|
