为什么软件能力成熟度模型把实践称为期望部件?

我们在实施GJB5000的时候,不要把眼睛只盯着有多少个过程域/实践域,每个KPA有多少个专用实践上面,标准的概述/总则当中对标准框架、过程域/实践域的组成、相互关系等内容对于更好地实施GJB5000尤为重要。

其中,关于过程域/实践域的组成部件有如下说法:

本标准的模型部件分为必需的部件,期望的部件和解释性的部件三类,其中: 
a) 必需的部件是组织为满足实践域必需关注的目的以及达到的等级目标; 
b) 期望的部件是组织为了实现必需的部件推荐实施的实践; 
c) 解释性的部件是帮助组织理解必需的部件或指导实践实施的资料性说明。

这明确地表明我们实施GJB5000应当以实践域的目标达成为首要目的,而标准中给出的每个实践域的各级实践只是推荐的、期望的部件,意思就是无需照搬这些实践,每个实施GJB5000的组织都可以为了实现某个实践域而使用不在标准中的但又合适的替代实践。

那么,为什么GJB5000标准中把这些推荐的实践仅作为期望部件而不是必需的部件呢?

  1. 软件开发只能秉持务实的思想

我们推行GJB5000的初衷是提高组织的软件工程能力和软件产品的质量,而实施GJB5000能否带来这样的效果,最终是以软件产品的质量来说话的。推荐的实践再好,如果在组织实际应用中并没有产生相应的效果或者性价比太低,那它也不值得组织原样实施。

软件开发没有银弹,GJB5000也不是神学。我们不必把GJB5000作为真理来膜拜,与它稍有偏差即被认为是亵渎神灵。

  1. 经验只是拿来借鉴的

几乎所有流行的软件工程方法学都来源于软件从业者的经验,而不是基础性研究。

GJB5000当中推荐的实践实际上也是前人的经验。那些善于总结的软件开发人员把他们项目里面一些有效的东西记录下来,并且把他们传递给更广泛的群体。

对于这些经验,大家公认:

  • 这些经验来源于特定的领域或者项目规模;
  • 这些经验从来没有被期望用在所有可能的环境中。

所以,我们对GJB5000中的这些实践应当只是参考和借鉴,而不是盲从。

这正是:

实施五千要务实,实践原本是经验

是否好用看实际,杜绝无脑去照搬

参考书目:项目百态:深入理解软件项目行为模式,作者:(美)Tom DeMarco等,译者:金明,出版社:人民邮电出版社


作者简介:王小双,长期从事GJB5000推广、实施、评价、改进的工作,创建《软件工程之思》微信公众号,一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。

发表评论

登录后才能评论
联系客服
联系客服
分享本页
返回顶部