每个软件公司都可以并且应该做好的度量——缺陷度量
就算一个开发极不规范公司，我想总会对缺陷有一定的管理办法吧？至少缺陷会被记录下来（哪怕是各种方式），而不会只是口头说而毫无记录吧？
大多数软件公司都会有一套管理缺陷的系统，我们应该如何把缺陷度量做得更好呢？
我们需要目标驱动地把度量工作做好，首先有两个最基本的要求：
1.缺陷被准确的记录和跟踪。
2.客观地依据缺陷状况对软件发布进行决策。
根据这两个要求，我们需要详细定义缺陷的属性，这些缺陷的属性就是我们要度量的内容。很多公司都会定义缺陷的描述、严重程度等属性，另外也会规定发布的时候，什么严重级别的缺陷不能超过多少个等要求。
以上两个目标只是缺陷度量的两个基本目标，如果更深入一点，我们希望能预防缺陷的再次发生，最简单有效的办法就是：直接让项目组成员一起来分析缺陷的原因，让大家避免重犯。
如果想做更系统更深入的分析，就需要考虑在组织层面来做这个分析工作。这时有必要增加缺陷一个属性，叫做“缺陷来源”，就是说产生这个缺陷的源头是在哪里，是需求没有分析到位，还是设计没有做好，还是编码出问题？按“缺陷来源”来分析公司不同类型的项目的缺陷情况，您就会发现公司的软件开发过程最有问题的是哪个过程？哪些过程做得比较好？这些分析结果会很好的指引过程改进的方向。
缺陷度量有很多可以发掘的地方，这是每一个公司都应该做好也是最有条件做好的一种度量。
成功的基础——软件规模度量
最近有这样的一个辩论，功能点VS代码行，辩论的焦点就是用哪一种来代表软件规模更好一点。项目规模的度量大有学问，如果您想去听听专业的软件功能点法课程，您可能要付上高昂的学费，并且有可能学了后还不知道如何用上这个办法。这里我不想谈论这两种办法，这些方法可能仅是理论上可行，目前我也没有见到过一个成功实践这类方法的案例。
我们为什么要进行软件规模度量呢？目的无非是：
1.作为报价或者决策的依据。
2.安排具体的项目进度。
3.可以作为组织的生产力数据，可以有很多用途，如：各项目间横向比较，供以后项目参考等。
如果是为了投标报价，建议用Delphi法，功能点法、代码行法太慢了，不能适应商战社会，投标经常是没有这么多时间让你去折腾的。Delphi法的大致方法如下：
1.找几名资深专家，一起对项目进行WBS，把项目的工作分解为十几条最多二三十条的工作项。
2.全部专家各自估计每条工作项的工作量，并向其他专家阐述自己的理由。
3.第一次各专家估出来的结果可能差异比较大，每位专家听取别人的意见后，重新估算。
4.按照上述办法，各专家反复估算几次，一般次数就是2-4次，各专家估计的工作量会越来越趋近，这个时候取全部专家的平均值。
如果是为了目标2，安排具体的项目进度，我建议用“傻瓜估算法”，而我们亲爱的微软，就是采用这样的方法来估算规模的。这样的办法虽然原始，但有效，并且容易掌握。虽然这种办法被扣上主观成分大、项目间难以横向对比的、难以积累历史数据等多种“罪状”，但不好意思，用功能点法或者代码行法就很准吗？我们亲爱的软件工程师们认可功能点法或者代码行法吗？搞功能点法代码行法等这些“虚”办法，还不如老老实实地WBS，直接估算每个工作的工作量。
第一步：把公司内部最有项目经验最有估算经验的工程们召集在一起，制订组织级别的估算表框架。
软件开发活动，可以分类以下几类：
l 直接生产软件的活动，如：需求开发、设计、编码、测试等工程类活动。
l 项目管理类活动，如：编写项目计划、计划跟踪、发布评审等活动。
l 项目支持类活动