CMMI评估那点事
2020-10-12 15:04:35
郑乔尹
  • 访问次数: 104
  • 注册日期: 2020-07-08
  • 最后登录: 2021-09-28
  • 我的积分: 306
  • 门派等级: 无门派

本文转载自公众号:老丛讲桌(laocongjiangzhuo) 作者:丛斌博士

原文链接:   https://mp.weixin.qq.com/s/rCKlb6vrpeED3bzVFPmy0A


虽然中国目前是是全球CMMI评估第一大国,CMMI研究院官网列出的CMMI组织一大半都是中国企业,但真正理解评估目的、核心价值并不很多。这里和大家聊聊CMMI评估的进化史,帮助大家更好的理解评估。


CMMI之父Humphrey早在多年前就识别出许多管理者的一个通病:没有耐心定位关键问题,上来就要问题解决方案。“别讲问题,你就告诉我怎么解决。”这类霸道总裁的标配语言在职场司空见惯,但大多数这种情形下的方案并不能解决问题。所以从一开始,CMM评估的定位就是针对软件公司的老板们。当一个老板意识到软件开发过程存在问题时,可以请些专家来帮助做个诊断,找出关键问题及初步改进建议。所以CMM/CMMI评估的最重要角色并不是评估组长(主任评估师),而是被评估组织的Sponsor(评估发起人,公司高管)。


从Humphrey初衷来讲,评估能发现真正弱项才是钱没白花。但可惜的是,国内许多Sponsors们并没有真正介入到评估过程中来,除了一纸证书,再无其他期望。当然作为评估组长,工作量倒是大大降低。


最早CMM评估诊断是以访谈为主,文档为辅;CMMI评估方法改为文档、访谈并重。但今天的CMMI 2.0的评估方法基本上还是遵循了Humphrey制定的评估框架和原则,最重要的评估着眼点还是放在后续的改进上,评估过程的相关规定也是为了支持实现评估目的。


如评估保密要求,是为了让参加访谈人员不必担心讲真话的后果,让评估组能够基于项目的真实情况给出一份对Sponsor有价值的改进报告。
软件过程评估不同于其他领域的审核,Humphrey下面这段话值得每个评估组成员仔细体会:“一般来讲,软件过程的评估、审核是确保组织批准的过程得到执行。执行中偏离过程有可能不是因为自以为是,而是希望能在实际情况下更快、更有效的完成任务。过程执行者有可能会发现一些官方过程内容过时、不适用,他们克服组织过程中的官僚障碍,找到有效的捷径。评估组要注意这些情况,否则评估审核可能是弊大于利。一个适用的、已定义的软件过程能是一个高效评估的基础”。


评估发现的弱项不一定都是执行中过程的偏离点,也有可能是定义过程的问题。不论什么弱项,相关做法一定有可能导致一些负面的后果。


一些评估背书式的访谈准备也偏离了CMMI的评估原则,CMMI评估不是CMMI考试,不要求所有参加访谈人员都要了解CMMI。评估前准备好访谈问题清单是一件好事,这样可以确保模型实践的覆盖,让问题本地化便于理解。但如果参加访谈人员根据问题事先准备好“标准答案”那就把评估变成了一场表演,参加访谈的同学在乎评估组想听什么,而不是组织内部实际的做法。还是那句老话,“评估访谈没有正确答案或错误答案,只有可接受不可接受的答案,实际做法就是可接受的回答,反之就是不可接受的”。


由于证书压力和对评估的错误理解导致一些评估希望抹平所有弱项。有弱项不代表模型中的要求一定没有实现,只要模型中核心要求(1.3PA中的SG/GG(目标);2.0PA中的PGs(实践级别))得到满足即可。面临各种压力的项目在实际开发过程中,很难有效点到几百条实践要求,在满足核心要求前提下,有些不足也属正常。在评估前的就绪检查中,明确影响目标实现的问题,通过这些问题的整改,降低通过评估的风险。


由于评估识别的强项和建议与评估是否通过没有关系,如果Sponsor也不提要求,评估组自然敷衍,写些不疼不痒的通用强项、建议,让评估价值大打折扣。


最后希望大家不要忘了Humphrey给出的三个简简单单的评估目标:

  1. 了解组织的工作模式。
  2. 识别其主要问题。
  3. 把组织内有影响力的人拉入到过程改进的工作中。
郑乔尹 最后编辑, 2020-10-12 15:05:16