我所亲身经历的CMMI3[转]

梦想家

很荣幸，作为某公司软件部门的软件项目经理，亲身经历了CMMI3，以下就把整个改进过程，用自己的亲身体会，详述如下，文中一些观点与看法难免带有个人感情，还请各位酌情参考。

公司情况简单介绍下，因为是为某大型上市公司提供技术支撑，所以整体来说公司利润丰厚，更是因为与大型上市公司错综复杂的关系，很容易得到一些大的IT项目建设与维护。一般来说，做CMMI3认证的企业，大都不愁项目来源和利润。

大概是从2006年下半年开始做这个事情的吧，当时要先选择咨询公司，通过招标，最后确定了某家信誉不错的咨询公司，据说有多名主任评估师在该公司任职。说明下，参加过9000的公司可能都比较明白，这个CMMI3的认证过程与9000类似，最后都需要一个证书，CMMI呢就需要主任评估师签发，而且到美国的总部备案。

一般的认证过程是先找一家咨询公司，在该公司指导下进行相关的准备，然后准备好一些软件项目，最后再由该公司出面，动用主任评估师，对项目是否符合CMMI要求进行评估，当然通过后才能搞定。

不得不说，公司为了搞CMMI，刚开始就投入了巨大的热情和人力，记得那时候俺也成为了EPG的成员之一，听了不少咨询师关于CMMI的介绍以及相关过程域的培训。公司抽调了多名项目经理和业务骨干，组成了EPG，也就是公司的软件过程改进小组，负责整个CMMI的评估准备工作。这个过程域有必要解释下，说简单点，就是软件项目的某个方面，比如管理，比如配置管理，又比如需求等吧，大致上分了四个部分，为管理类的，组织类的，软件工程类的和支持类，总体看来，还是比较全面。

如果各位大大对PMBOK有所了解的话，就会发现CMMI比PMBOK的九个项目管理知识领域增加了软件工程方面的东西，其他的还是有很多相同之处。

EPG小组刚开始的工作就是要建立组织，也就是小组内按我们开发，设计，测试来分不同的角色。我们定的角色包括EPG的小组长，EPG的配置管理员，EPG的质量保证员，还有CCB等机构。这个CCB叫变更控制委员会，说白了就是软件项目的一些重大决定要由CCB来决定，而不是项目经理啦。

不得不说，公司为了搞CMMI，刚开始就投入了巨大的热情和人力，记得那时候俺也成为了EPG的成员之一，听了不少咨询师关于CMMI的介绍以及相关过程域的培训。公司抽调了多名项目经理和业务骨干，组成了EPG，也就是公司的软件过程改进小组，负责整个CMMI的评估准备工作。这个过程域有必要解释下，说简单点，就是软件项目的某个方面，比如管理，比如配置管理，又比如需求等吧，大致上分了四个部分，为管理类的，组织类的，软件工程类的和支持类，总体看来，还是比较全面。

如果各位大大对PMBOK有所了解的话，就会发现CMMI比PMBOK的九个项目管理知识领域增加了软件工程方面的东西，其他的还是有很多相同之处。

EPG小组刚开始的工作就是要建立组织，也就是小组内按我们开发，设计，测试来分不同的角色。我们定的角色包括EPG的小组长，EPG的配置管理员，EPG的质量保证员，还有CCB等机构。这个CCB叫变更控制委员会，说白了就是软件项目的一些重大决定要由CCB来决定，而不是项目经理啦。

迷茫中,CMMI3起航了...
培训完,EPG也成立了,这边EPG开始按照咨询师的要求,准备拆分软件过程,另一边,咨询师又开始了另一项重要的工作，那就是对公司的整个软件流程进行诊断,说白了，就是找软件过程中的各个角色进行座谈,包括项目经理,普通开发,美工,部门领导,人力资源部分,公司领导等等..问的问题很详细,举个例子,问开发人员的时候问到了一天能写多少行代码,问测试的时候问平均千行的BUG率,这个诊断过程大概有一个星期吧..咨询公司最后出了一个诊断报告,不过可惜的是，这个报告俺只看到了一部分,大致是说公司的软件过程还是不错的,当然也需要进一步的改进..云云..

不提那边诊断的事情,这只是必要的一个过程，并不影响我们EPG的工作,还是回到EPG的工作上来.

会议连着会议,不记得那时候开了多少会,总之整天似乎都在和别人争论着...EPG将公司的某会议室整个包了下来，按照标准的瀑布模型,从最开始的项目招标,可研一直到项目的验收,售后维护全理了一遍.现在回头想想,这个过程整个是一个学习的过程,往往以为很简单的过程,可仍有那么多的迷惑和未知.举个例子,需求的过程,不是简单的与用户沟通,记录,而是要有确认,要注意需求的可测试,完整..各种特性,还要进行需求的跟踪,横向和纵向等等...这个过程一方面结合公司的实际,另一方面还要符合CMMI的要求,难啊。

从一开头,EPG就是一个争吵的局面,前面说了，公司的位置比较特殊,与客户有复杂的关系,比如说可以不签合同就开工,或者一个项目干N多年也没完,这么说吧,我们公司简直就是客户的亲戚,想怎么来，就怎么来.这对EPG分析软件过程产生了不可估计的影响...