CMMI评估那点事

虽然中国目前是是全球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.   把组织内有影响力的人拉入到过程改进的工作中。

文章来源于丛斌博士