关于项目过程能力基线的几个讨论

关键词： 过程能力基线

说到过程能力基线，了解CMM/CMMI的人都不会陌生。一般是指组织的过程能力基线，通过数字反映了组织的能力。比如一个组织的生产率是每人月生产代码行2000行。当然现在一般用功能点来计生产率，比如每人月平均生产8.5个功能点，西格玛是多少。

但是如果在项目一级上提出项目的过程能力，就让我犯难了。当前的思路是从项目的大目标来分解。

项目的大目标一般有一按期发布，二缺陷要少。

从 工期上而言，有不少组织采用挣值管理的，完成可以采用挣值中的CPI和SPI来管理，这样不仅管理了工期，成本也得到了管理。但是我所在组织没有采用挣值 管理。只有工期偏差。每阶段都有实际的工期偏差，每周的工期偏差是当时的预计值。虽然没有挣值更为准确，但足以为项目提供支持。这样利用每周和每阶段的工 期偏差可以生成项目工期偏差的过程能力。

从缺陷上而言，我当前还没有想到合适的办法。由于每阶段的工作产品不一样，每个工作产品的规模度量也不一样，比如开发计划书是按页数的。需求分析是按功能点数量的。这样想来，每个阶段都有的度量只有工作量是合适的。同行评审缺限数量与工作量的比值是每个阶段都可比的吗？

这好象很有疑问。谁能告诉我，如何在项目中就缺陷控制生成控制图？
---------

在CMMI5过程改进中，Baseline和Baseline model是两道很难逾越的“坎”。

缺陷控制图是Baseline和Baseline control的方法之一。其中的难点还在于组织级是否已建立缺陷的Baseline（包括质量区间）。我想我们遇到的难点是，如何识别工作产品，并建立缺陷分类，以建立基线。

一般来讲，我们可以从CMMI V1.2 项目5个阶段着手，从开发中、交付前和交付后，对“评审发现的缺陷”、“测试发现的缺陷”和“系统运行中的缺陷”进行分类管理，其中“评审发现的缺陷”主要是“业务解决方案”、“技术解决方案”、“代码”等中间产品。

同时，缺陷密度一般是缺陷数量和项目规模的比值较为合理。按照第二代FPA（Function Point Anaylis）方法，我们可以忽略“缺陷的颗粒度”干扰因素（据说经过数据统计，颗粒度综合印象系数分布在1附近），用FPA方法统计项目规模，从而得 到无主观因素干扰的“缺陷密度”。

欢迎交流。MSN：yangfl761123@hotmail.com

-------------

上面 Carl 回答了一些，我这里补充一些。

Process Performance Baseline 和 Process Performance Model 是两个很重要的过程改进的标志。

Process Performance Baseline 可以理解为 过程在某个方面的 Benchmark，是以后项目用来参考和对照的，它是一个范围值，在低成熟度级别的（如ML2 和 ML3）项目管理中，我们经常用的 threshold （阈值）跟这个意思类似，但是threshold 更多的依赖于项目经理和成员的经验，是比较 主观的；但是Process Performance Baseline 是个比较客观的值，它是需要一定量的 相同性质的（homogeneous）数据通过统计方法得到的。这个值的得到需要时间（也就间接告诉我们 达到 4级 是需要时间的），也就是需要不少类似项目数据支持，从而提高了过程的客观性和透明度（数据管理），也提高了项目管理能力，所以这个概念是在 四级（不论是 ML还是 CL）中提出，这也才真正体现“过程控制”的概念，如果把 ML2和 3 认为只是工程概念。

对于 缺陷来讲，我建议首先 分项目类型，目的是采样数据时能够满足数据的要求之一（homogeneous），然后 建立 phase containment，对各种缺陷数据进行再分类，同时主要 缺陷引入（injection）和消除（removal）概念，这些数据在识别过程问题和提高过程能力方面很重要，（CAR和四级都要求剔除 过程中的问题，不同的在于common cause 和 special cause，）；然后根据各个项目不同工作产品的规模（如 页数、FPs、模块数、测试用例数等）进行 normalize，就可以得到该项目的不同产品缺陷律，这样与同类可以比较，数据多了，也可以考虑建立 baseline。一般的方法是数据少时就用平均法，多了就要用一些专业的control chart 来描述，对软件来讲，这个 baseline 永远是相对客观的，因为你总在不停的改正你的过程，原因是你的项目不会等你的过程稳定了才去调整你的过程，别忘了过程改进的目的是为了项目管理，是为了达 到一个 的核心目的 － control，这个就是所有管理的终极目标。

一个公司对 同一个过程的 baseline 可以有多个，别忘了 裁剪在这里仍然是适合的，因为这个的情况的根本（common cause）是背后不同的项目类型决定了这个数据。

只是薄见而已。

---------------

Process Performance Baseline（PPB） 和 Process Performance Model（PPM） 是两个很重要的过程改进的标志。

Process Performance Baseline 可以理解为 过程在某个方面的 Benchmark，是以后项目用来参考和对照的，它是一个范围值，在低成熟度级别的（如ML2 和 ML3）项目管理中，我们经常用的 threshold （阈值）跟这个意思类似，但是threshold 更多的依赖于项目经理和成员的经验，是比较 主观的；但是Process Performance Baseline 是个比较客观的值，它是需要一定量的 相同性质的（homogeneous）数据通过统计方法得到的。这个值的得到需要时间（也就间接告诉我们 达到 4级 是需要时间的），也就是需要不少类似项目数据支持，从而提高了过程的客观性和透明度（数据管理），也提高了项目管理能力，所以这个概念是在 四级（不论是 ML还是 CL）中提出，这也才真正体现“过程控制”的概念，如果把 ML2和 3 认为只是工程概念。

对于各种PPB，它的建立过程类似，都是要进行数据收集、分类（这个非常关键，按项目类型是主要的一个分类）和处理，这个可以参考MA 中的SPs。

对于 缺陷来讲，我建议首先 分项目类型，目的是采样数据时能够满足数据的要求之一（homogeneous），然后 建立 phase containment，对各种缺陷数据进行再分类，同时主要 缺陷引入（injection）和消除（removal）概念，这些数据在识别过程问题和提高过程能力方面很重要，（CAR和四级都要求剔除 过程中的问题，不同的在于common cause 和 special cause，）；然后根据各个项目不同工作产品的规模（如 页数、FPs、模块数、测试用例数等）进行 normalize，就可以得到该项目的不同产品缺陷律，这样与同类可以比较，数据多了，也可以考虑建立 baseline。一般的方法是数据少时就用平均法，多了就要用一些专业的control chart 来描述，对软件来讲，这个 baseline 永远是相对客观的，因为你总在不停的改正你的过程，原因是你的项目不会等你的过程稳定了才去调整你的过程，别忘了过程改进的目的是为了项目管理，是为了达 到一个 的核心目的 － control，这个就是所有管理的终极目标。

一个公司对 同一个过程的 baseline 可以有多个，别忘了 裁剪在这里仍然是适合的，因为这个的情况的根本（common cause）是背后不同的项目类型决定了这个数据。