|
前不久，有个朋友在谈到实施GJB5000项目估计的时候，提到了一个大胆的想法：不再进行产品规模估计，直接估计工作量。 这个想法看似和GJB5000的要求有些背离，但仔细想想，也是可行的。 在GJB5000A中，项目估计基本上是三段式：确定项目范围（或者说制定WBS）、估计产品规模、估计工作量；但在GJB5000B中，以上三个实践合并为一个实践——估计项目参数。这个变化也就意味着在GJB5000B中实施项目估计有了裁剪的可能——只要满足基于估计结果制定出合理可行计划的目标。 那么，不做规模估计会影响这个二级目标的实现吗？ 工作产品规模估计，是基于产品WBS分解，将产品功能分解到足够细小的粒度，估计专家可以较准确地估计出每个分解功能的规模，最终获得整个产品的估计规模。而在获得这个产品估计规模之后，软件项目负责人可以根据规模来估计开发所需的工作量和资源，再据此安排进度计划、风险计划、利益相关方计划。 产品规模估计最大的用途就是为了后面工作量和资源估计服务的。 那么，如果不进行规模估计，直接根据WBS进行工作量估计，不一样可以得到工作量和资源的估计结果，不一样可以制定出进度计划、风险计划、利益相关方计划？ 既然如此，工作产品规模估计还有什么意义呢？就只是为了工作产品规模跟踪提供一个与实际规模做比较的计划规模吗？
GJB5000B中这一实践的活动实例中依然保持了“估计规模”，这是对GJB5000A的延续，也是和CMMI 2.0保持一致。但是，如果从我们实施GJB5000的实践出发，从符合国情融入我们自己的工程经验出发，我们的标准修订应当删除这一活动实例；目前也应允许裁剪这一活动。 当然，裁剪规模估计，仍然需要编制产品WBS，并且将其融入到任务WBS中，以便工作量估计更加准确。 这正是： 规模估计为了啥，估计资源工作量 如果直接去估计，规模估计可裁剪 作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。 |
|
|
