我所亲身经历的CMMI3 [问题点数：20分，结帖人outer2000]--转载

很荣幸，作为某公司软件部门的软件项目经理，亲身经历了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启动大会，弄得挺正式，公司相关领导都出面，咨询公司的领导也来了，洋洋洒洒把把CMMI的必要性和带来的收益说的神乎其神，恩，那时候，俺看咨询师的眼神都是那样的…..景仰。
咨询师大概花了两个星期左右吧，才把CMMI3的20多个过程域给我们这些CMMI菜鸟培训了一遍，当时一个感觉：晕啊。培训完，咨询师就要我们开始干了，只觉得CMMI好复杂，简直是无从着手。这时候EPG小组的人开始从网上找一些资料，一些其他公司准备的文件模板。俺也找了一套，很不错，现在公司用的就有。
咨询师这时候也发觉了，对我们的期望似乎高了点，私下说，应该过CMMI2可能比较合适。看我们实在不知道做什么，就先让我们准备一个组织级别的WORD模板，还有缩略表等，挺多的，也记不清楚了。还让我们把软件过程按标准的瀑布模型进行拆分，越细越好。

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

会议连着会议,不记得那时候开了多少会,总之整天似乎都在和别人争论着...EPG将公司的某会议室整个包了下来，按照标准的瀑布模型,从最开始的项目招标,可研一直到项目的验收,售后维护全理了一遍.现在回头想想,这个过程整个是一个学习的过程,往往以为很简单的过程,可仍有那么多的迷惑和未知.举个例子,需求的过程,不是简单的与用户沟通,记录,而是要有确认,要注意需求的可测试,完整..各种特性,还要进行需求的跟踪,横向和纵向等等...这个过程一方面结合公司的实际,另一方面还要符合CMMI的要求,难啊.
从一开头,EPG就是一个争吵的局面,前面说了，公司的位置比较特殊,与客户有复杂的关系,比如说可以不签合同就开工,或者一个项目干N多年也没完,这么说吧,我们公司简直就是客户的亲戚,想怎么来，就怎么来.这对EPG分析软件过程产生了不可估计的影响...

看来关心此方面内容的大大不少,俺也就再写一段,给大家提提神.
其实CMMI本身也有两种模型,或者不用模型这两个字了,这个词汇听着别扭,简单说就是达到CMMI标准的方法有两种,其中一种呢,就是把CMMI的20多个过程域按1-5级划分,每一级都增加一些过程域,等到了5级就全满足了;另外一种不是这样,是按先实现组织方面的过程域,然后是管理方面的,然后是软件工程方面的，然后是支持的...道理一样，总之到了5级全部支持.
用软件生命周期模型来比喻这个可能比较合适,前一种呢就是叠代模型,1-5级每个级别都可以运行,只不过功能逐渐满足...而后一种就是完整的瀑布模型,先从需求做起..最后才能看到一个完整的系统.
我所在的公司选择的是分级的方法来实现CMMI,也就是前一种方法,把CMMI3级所包含的18个过程域一起都实现.

这几天要CMMI3评估了..紧张啊,不过也让我更深刻的体会到以前所做的工作..很多，但是真的对评估没什么用.
上回说到,EPG进行软件过程的分析,由于公司环境特殊,造成了很多困难,但是工作还得要开展,是不?当然，公司正常的项目还需要开展,对不?一下抽了这么多骨干,对正常的项目的影响也逐渐暴露出来了...有两个月吧,时间这时候大概到了07年初春节左右.
经过艰苦的内部斗争,EPG也算初步整理出一个按瀑布模型划分的过程清单,咨询公司根据这个过程清单,开始让EPG整理过程清单里中每一个过程的体系文件了,这个很好理解,就是把这些细小的过程都经过定义,包括过程的输入,输出,过程的步骤,一些关键的要求等等,举个简单的例子,比如开周例会这个过程,就需要先准备材料,发通知,进行会议记录,会议内容,会议纪要..等等,当然是越详细越好，还得与公司实际结合,咨询师当时甚至要求记录每个会议议题所花费的时间...
现在回头看看,这个过程,其实就是软件工程的一个过程,包括并符合了CMMI很多的过程域,如:需求开发,需求管理,系统解决方案等,通过这个过程,按照瀑布模型定义了一个详细的软件过程.

很不幸,在这么一个关键的阶段，本人被EPG无情的抛弃了,也不是被抛弃,春节后项目正常的工作越来越多,EPG的会议经常无法参加,记得那时我所负责的过程是可研的过程,包括准备PPT啦,准备技术建议书,与用户讲解系统方案,投标前准备等等..由于时间的确不够用,部门经理决定，将大部分项目经理重新还回到项目中,只保留了几个有限的人手,EPG的工作,也就正式进入了持久战.

从07年4月份开始,本人正式脱离了公司的EPG组织,这段时间由于没有亲自参与EPG的工作，一些细节只能通过EPG的其他同事来获得了.期间EPG创建了公司的CMMI站点,按照组织,管理,工程，支持分类,把全部的过程都编写好过程文件,并陆续发布到公司的站点,接受热爱此工作的程序员,测试，开发等各角色的建议.一直到07年9月份,将近有五个月的时间，EPG一直在辛勤的工作着,按照CMMI的目标和实践,整理我们的过程体系文件,真的非常辛苦.
要知道,过程体系文件只是一个工作，还有要创建各种MODEL,比如需求说明书,设计说明书..比如项目计划MODEL,配置管理计划，质量保证计划..比如评审单,过程检查单,会议纪要,个人周报..还要准备组织级别的一些规范,目标如编码规范,测试规范,工作环境规定,风险清单,资源清单,技能清单..还要进行公司内的CMMI培训..培训教材,很多，很复杂.

这些文件大体上分为四类,一种是规范和标准方面的,如编码规范,测试规范,角色职责等;一种是过程文件，告诉我们怎么执行过程;一种是指南类的,帮助我们执行过程，比如裁减指南,生命周期模型说明,估算指南等;还有一种是各种的审查单,任务单等,一般配合过程文件中使用的模板.这四类文件组成了整个的CMMI文档体系,粗略算下来，总共应该有2百个左右吧.

各位大大应该都比较喜欢看书，要是一本200多页的书，大概会看多长时间?
呵呵，没错，下面我要说说这些文件怎么使用的问题.这200多个文件要真正的应用的具体的项目中,恐怕产生的实际数量文件会比200多几倍,管理起来也是一个大的问题,后面我会说配置管理方面，现在先说说培训.
把这些文件一股脑交给项目经理,实际的去执行...感觉有些不现实,各位大大觉得呢?我所在的公司是这么做的,就是不断的培训,考试...再培训,再考试...

大概的统计下，为了在技术开发部门推广CMMI,公司组织的培训应该超过3次,各个角色[项目经理,QA,CM,开发,测试],全员的培训,由于俺早期参加了EPG,这些培训的考试应付还是比较轻松的..记得有次考试居然得分比EPG小组的某些人还高,呵呵,臭美了好几天.
通常来说,QA与CM的工作对大部分软件公司来说是一个的弱点,我所在的公司也不例外,配置工具也就是签入和签出用得最多,至于QA则更是基本上不设置,本人也重点学了学相关的两个过程域CM和PPQA,老实说,本人并不是科班出身,大学学机械,工作后进工厂,跳槽干了两年市场...才转到开发的.自认为经历还是比较复杂,呵呵,别拿砖头丢我啊..
不知道有没有大大喜欢下围棋,韩国,有个比较牛的人物..不是那小李飞刀,是一个叫刘昌赫的，也是半路出家,原来是业余选手..虽然很猛但有时会下一些很低级错误的棋...道理差不多吧,本人对QA与配置管理可以说是半知半解..也出了不少洋相.
学过CM与PPQA后,整体感觉工作严谨了很多,就象..流氓学武术啦,哈哈.

仔细想了想还是说两句这两个过程域的感受吧,CM,就是配置管理,讲了先要你弄一个配置管理计划，前提当然是配置管理员干,项目经理不用弄...而且不允许兼任.当然这个计划和整体的项目计划要有对应,比如项目计划1月1日做完需求,那配置管理计划也应该1月1日后几天弄个什么BASELINE基线吧.配置管理计划有个日程表,里程碑与项目计划对应上,啥时候该做配置审计...就是看看Y的项目组成员是不是按计划把输出物都签进来的..这叫物理审计..还有功能审计,就要看文件的内容是不是符合要求了..据说这个很难,还好，俺不是CM.
作为CM的配置管理计划，还要识别配置项..真难听，说白了就是那些比较重要的输出物文件如需求说明书什么的,一个基线..就是这些输出物某个版本的集合.比如项目需求完了，经过技术评审..就是开个小会儿,确定需求完啦,那这个需求说明书就要弄一个BASELINE,可就不能随便改了.有了基线的意思,俺的理解就是不能随便变更啦,要想变得CCB的批准才可以..权利大着呢..随着项目的进展,这些配置项会越来越多..当然不是所有的输出物都要做为配置项,否则..CM真的不用做了.
刚开始的时候,某CM居然把个人周报也弄配置项里啦..哈哈

再说两句配置管理...说下配置库与配置项,基线的关系..一般我们弄三个配置库,开发库..谁都可以随便签入签出..受控库,一般CM自己有权利..BASELINE库,基本上很少变化的;说配置管理太多了，有点口干舌燥.....不说了,想学自己看书去.
QA也就是质量保证员,公司弄9000的都晓得，也有这么个角色,可惜的是，9000与CMMI比起来,QA的角色差别还是很大的.

我也参加过CMMI3和CMMI4的这个评估，我当时还是一个小小的测试人员，但是因为开发的时候非常注重流程，反而给吸收进EPG了

而且也是从零开始一直就参加这些培训

学习一下CMMI流程是非常有用处的

这里面有些很死板的规定，看起来很繁琐，其实坚持下来最后能看到非常好的作用，这点深有体会

但是能做全也不是那么容易的

谢谢楼上的朋友，自己连续只能发三次，再发说发言太快，这经历还就写不下去了.
前几天说了CM,本来想说QA,看楼上的朋友说测试,也稍微说几句.有两个过程域主要讲这个,俺是没学好，记得叫验证和确认,咨询师讲了半天也没听明白，倒是EPG有个简单的说法,验证就是测试,确认就是评审.
回过来说QA,怎么都觉得QA象是EPG在项目安排的内奸和卧底,不光有事情可以直接向高层汇报,还要检查项目的过程是不是按CMMI写的执行了，一些输出物与CMMI的MODEL是不是吻合等...还有跟踪一些评审的问题和项目中的其他问题..
说这些真的很枯燥,可是不说清楚,后面的故事就没办法开展啦..回过头来说说俺的项目,9月中吧,参加了甲方的招标,自然,也是走走过场,虽然中标是一定的，但标书也不能马虎,该讲解PPT也不能省略,合同还得签定，不是?到10月份吧,确定了中标,然后是弄合同...俺这忙里忙外,却不知一场"阴谋"正在悄然降临...CMMI的魔爪终于成型了，向修真小说里的那样，练成内丹要出山,而我所负责的这个项目,就成为了检验CMMI的:实验品.

上面说到了EPG修炼出内丹,不过要知道是修炼的魔门功法还是仙家正宗练气之术,还得靠事实检验,弄个把项目操练一翻,自然有个分晓.
作为项目经理,在向部门经理申请到并不充足的人手后,开始了项目的漫漫征程.公司早在2003年左右就通过了ISO9000,对软件过程还是有一个基本过程要求的,比如需求，设计,测试,开发..等阶段的定义也算是清晰.2007年10月下旬,项目顺利启动,进入整理需求阶段.
今天思路比较混乱,CMMI3的正式评估正在进行当中...

EPG在整理这些过程文件当中,咨询师大概每个月都会到公司进行现场指导,就一些具体的做法与EPG进行商讨,说好听点是根据本公司的实际进行改进和修正,说白了就是COPY一套其他公司较好的流程,然后把不适应的地方裁掉...这纯粹是个人看法,EPG看到这些,恐怕会杀了我...
还好，这段时间咨询师正在就EPG的工作成果进行全面的审核,我的项目也按部就班进入了设计阶段.其实,CMMI之前,公司内部也在就软件过程进行一些改进,包括公司领导提出的开发与设计分离等方面,软件部门受此影响,也划分了开发\需求设计\测试等部分,而我的项目也受到了一定的影响,初期只安排了需求与设计人员.2007年底吧,我们项目设计完成,CMMI也终于发布了第一个版本.

记得应该是2008年的1月初,CMMI体系的正式文件发布,类似9000的发布,公司还搞了一个发布会,就此,EPG的工作进入了一个全新的阶段.按照CMMI的要求,发布后，要求至少有三个项目完全实施才能参与评审,根据公司的项目情况，呵呵，自然也为了通过CMMI的认证,选择了三个项目搞试点.
三个项目中有一个规模较大,其余两个规模比较小,这其中不幸当然包括本人所负责的,每个项目组EPG都派出一人做专门的指导,全程参与项目的过程.俺的项目到2008年初编码都开始了...回过头来,开始弄CMMI了...

原帖子链接：https://bbs.csdn.net/topics/280073485