很多软件公司都设有QA（Quality Assurance）部门，特别是那些通过了CMMI认证的企业。绝大多数企业设立这个部门都是因为CMMI体系里面有个PPQA这个过程域，需要这么一个角色来“保证”软件的质量。
扪心自问，有多少企业的这个部门又真正起到了保证质量的作用呢？ 关于其中原因，可以看我先前写的【我眼中的CMMI 】系列。这里谈谈如何化解上个系列中提到的问题。
项目管理的核心其实就是目标管理，从范围、成本、进度到质量无一例外。但是，纵观软件项目经理，绝大部分都只盯着成本和进度的目标。觉得对客户按时把东西交出去了，对公司在交付前成本控制在预算以内了就算项目做好了。诸不知，绝大部分国内软件项目，交付才是噩梦的开始，交付后的成本会急剧飙升，真正上线日期会一拖再拖。导致这种状态的一个重要原因就是质量问题，没有质量目标的项目就如同顺水漂流一样，漂到哪里算哪里，运气好的就没事，不好的就翻船。
质量是个软性的概念，不像成本和进度那么直观，所以制定起来会比较难，这也正是诸多软件企业所不愿意投入大量精力去改进的客观原因。我这里先列举一些典型的场景，并附上制定质量目标的方法，供大家参考。（如有未列出的场景，大家可以留言，我会后续附上方法）
场景一：企业已运作稳定，有较多项目已完成。
分支场景1A：如企业在项目实施过程中已收集了规模和缺陷的相关数据，那么就是最容易制定目标的一个分支场景了。在此情形下，我们可以有两种方法来制定目标：
方法1：简单的做法就是选定所需设定的质量目标（选哪些质量目标后续会有说明），将收集到的数据分类，然后求的均值（所有数据的和除以数据个数）和极值（所有数据中最大和最小的值）。均值可以粗略的表示也完成项目的平均水平，极值可以粗略表示已完成项目的水平上下限。通过这两个值，再结合该项目的实际情况，即可初步制定出各质量目标。
---- 此方法的优点是计算简单，对数据和数学知识的要求都不高，便于企业开始实施制定质量目标这个活动。 不足是从数学的角度上说数据没有检查正态性，准确度不高。
---- 从我实践的经验来看，纯数学理论的方法不一定适用软件企业，在绝大多数中小软件企业刚开始做这件事的时候，还是很推荐此方法的。
方法2：复杂的做法就是将项目分类，各类项目找到至少6个符合正态性分布的数据，使用统计学的方法计算出均值、极值、方差、置信区间等数据，再进行假设检验，将通过假设检验的数据做为基线来做为制定目标的依据。
---- 此方法的优点是有统计学严谨的方法为基础，从数学角度上保证了数据的精确性。 不足是很少有企业能收集到符合统计学要求的大量有质量的数据，如将垃圾数据混合计算，出来的结果也必将是垃圾，就如丛斌博士经常给我提到的：Garbage in garbage out。
---- 从我个人的经验来看，此方法不太适合中小型软件企业，就算是大型软件企业，如果度量工作不够严谨也不会得出准确的结果。而且还对数学知识有较高的要求，计算的复杂度和时间消耗也很大。实施起来还不如上一个方法。
分支场景1B：如果企业在实施项目过程中没有积累数据，同时也没有办法通过复盘等方法来找回数据，那么可以使用专家法（也称为DELPHI法）来制定，具体操作如下：
操作1：如果企业的人数不多，则将项目经理集中在一起，对选定的质量目标项根据各自经验估算出一个最高值、一个最低值、一个最有可能值，并且附上估算各值的约束条件。将每个人的约束条件列举出来，通过讨论统一约束条件后，通过公式： （最高值+最低值+4*最有可能值）/6，即可计算出某一个人的目标估算值。再求所有估算值的均值和极值，即可得出目标值。
---- 此方法是较常用的方法，毕竟不是每个企业一开始就会关注数据积累这个活动，但是没数据不代表不能制定目标，起步总是艰难的，起步后再逐步收集数据也是可行的。
---- 以上的专家法与很多教科书上的专家法有一点区别，那就是要统一约束条件后再估算，而且要不受互相影响的独立估算。这样的估算值会更准确一些，这也是我在日常的项目管理活动中自己总结出来的。
操作2：如果企业的人数较多，则可以将项目经理、组长、测试经理分成3组，每组按照以上方法计算估算值，然后再求总的均值和极值。
---- 此方法从不同角色的人员来估算会有更全面的考虑，数据会更准确。但需要较多人员投入，组织和协调工作量较大。
今天先完成这2个场景，后续再补上其它场景。
相关文章：
