软件研发项目中如何开展“度量”(2)

　　实施活动计划工时项目管理者联盟

　　实施活动实际工时

　　评审计划工时项目经理圈子

　　评审实际工时项目管理者联盟

　　其他活动计划工时

　　其他活动实际工时blog.ltesting.net

　　返工总工时项目管理者联盟文章

　　需求阶段返工工时

　　设计阶段返工工时

　　构建阶段返工工时

　　测试阶段返工工时

　　实施阶段返工工时

　　计划评审工时

　　需求评审工时

　　设计评审工时www.ltesting.net

　　编码评审工时

　　测试评审工时

　　其他评审工时bbs.ltesting.net

　　这些度量，使得你能够与客户、老板要管理工时、返工工时，即，项目不仅仅是设计、开发。也帮助你分析为什么项目会delay，是哪些因素造成：评审工时省了?还是返工工时没估计到?这些都是很关键的。

　　5、很关键的--质量

　　预计缺陷总数www.ltesting.net

　　实际缺陷总数training.ltesting.net

　　预计致命缺陷

　　实际致命缺陷

　　预计主要缺陷

　　实际主要缺陷

　　预计次要缺陷

　　实际次要缺陷

　　预计遗留缺陷数

　　实际遗留缺陷数

　　需求阶段预计发现缺陷

　　需求阶段实际发现缺陷bbs.ltesting.net

　　设计阶段预计发现缺陷

　　设计阶段实际发现缺陷

　　构建阶段预计发现缺陷项目经理圈子

　　构建阶段实际发现缺陷

　　测试阶段预计发现缺陷

　　测试阶段实际发现缺陷项目管理者联盟文章

　　实施阶段预计发现缺陷项目管理者联盟文章

　　实施阶段实际发现缺陷www.ltesting.net

　　交付后1个月内发现总缺陷

　　交付后1个月内发现致命缺陷

　　交付后1个月内发现主要缺陷

　　交付后1个月内发现次要缺陷

　　需求活动预计引入缺陷

　　需求活动实际引入缺陷

　　需求活动实际引入缺陷(需求时发现)项目管理论坛

　　需求活动实际引入缺陷(设计时发现)

　　需求活动实际引入缺陷(编码时发现)

　　需求活动实际引入缺陷(测试时发现)项目经理圈子

　　需求活动实际引入缺陷(实施时发现)

　　需求活动预计清除缺陷

　　需求活动实际清除缺陷

　　设计活动预计引入缺陷

　　设计活动实际引入缺陷项目经理博客

　　设计活动实际引入缺陷(设计时发现)

　　设计活动实际引入缺陷(编码时发现)

　　设计活动实际引入缺陷(测试时发现)

　　设计活动实际引入缺陷(实施时发现)项目管理者联盟设计活动预计清除缺陷

　　设计活动实际清除缺陷

　　编码活动预计引入缺陷转自项目管理者联盟

　　编码活动实际引入缺陷

　　编码活动实际引入缺陷(编码时发现)

　　编码活动实际引入缺陷(测试时发现)项目管理者联盟文章

　　编码活动实际引入缺陷(实施时发现)

　　编码活动预计清除缺陷

　　编码活动实际清除缺陷

　　测试活动预计引入缺陷

　　测试活动实际引入缺陷项目经理圈子

　　测试活动预计清除缺陷

　　测试活动实际清除缺陷

　　实施活动预计引入缺陷

　　实施活动实际引入缺陷bbs.ltesting.net

　　实施活动预计清除缺陷

　　实施活动实际清除缺陷

　　项目在开发前就应该预估会有多少bug，根据bug的修改时间就知道要多少返工，以及测试轮次。这些数据也可以反映，因需求不清导致多少bug?引入bug的影响率?以及销售、交付后有多少bug?这些数据有了，考核都有了。

　　例如，交付后1个月返工的bug，考核测试与开发、项目经理、总监等。

　　再例如，你前面有规模估计，自然能预估会有多少bug。以代码行为例，标准如果是千行bug率在千分之3，那么你是10w行规模则会预计bug300个，测试1轮如果可以发现100个的话就要3轮测试。开发测试计划中你制定2轮就不合理了，1轮1周，那需要3周，你给2周也就不合理了。

　　综上可见，度量是项目管理的灵魂。如何根据当前阶段能力，选择最关键的度量点是qa、总监要很清醒的。不能不度量，也不能度量过度。以上5点做好了，这家公司基本是正规的公司了。其他的，一些其他高级度量点等再成熟了就再度量

原文转自：http://www.ltesting.net