如何快速通过CMMI评估

      终于访谈结束了，最近的几个月，进行了备受煎熬的CMMI认证活动，起初对这个东西非常的陌生，也没有很多的资料可供参考，经过几个月的摸索，也掌握了CMMI认证的一些道道，其实现在说来倒是觉得cmmi认证没有想象的那么复杂，但如果起初没有足够的经验可供参考，那么摸索的过程是很痛苦的，趁着现在头脑还比较热，把自己的一些体会分享出来，给后来人留个参考，我以后肯定是不会再玩这个了

 

      首先我觉得进行评估的企业要明白一点，不能太“实在”，如果真的按照整个CMMI的流程来，项目很容易被拖垮，是否值得真的按cmmi流程来做项目先不讨论，这里仅仅讨论如何以最小的成本去通过这个认证。

 

      那么我还是想最通俗的解释一下cmmi，就是定义了一些流程，你要是想过这个东西，你就得去满足这些过程，这些过程需要企业有一个专门的组织去维护这个东西，这里的维护指的就是改进，但这些改进都是小打小闹，大的过程不会变，这个过程就是标准过程，维护这个标准过程的组织就是EPG。现在标准过程有了，是一个总的提纲，那么做项目的时候就按照这个提纲来，所以项目中的一切东西你都要往标准过程上扯，这样就说明你做事是有依据的，不是拍脑袋的，说明你的企业的流程不混乱，都是按照一套统一的标准来的。

 

下面我们谈谈最主要的一个环节-------------访谈。

 

     偶们来看看访谈需要知道哪些东西，我觉得单纯的背问题没有多大意义，自己把项目的过程梳理清楚才是王道，因为这样随便LV怎么问，你都不会离开你的主线，LV问你问题也不是乱问的，他是每个点问你一个，基本每个点都会问到，其实单纯的回答这些点相当的简单，但，难就难在你的这些点需要相互呼应，不能自相矛盾。

 

   偶们就这些点需要注意的地方来一一清理一下，按照由简到难的顺序

 

偏差：这个写个偏差表就可以了，找1-2个时间点出现偏差即可，再写个解决措施就可以，没啥好说的

 

风险：按照风险库里面风险在项目出奇识别出来，写到风险跟踪表里面的，注意说一下，在每个里程碑重新识别了风险即可

 

项目周会：就是每周做了啥事，出现了啥问题，找1-2周捏造几个问题，注意在下一周体现出跟踪，就说上周问题通过加班什么的解决了即可

 

度量：通过收集相关人员的个人周报的数据汇总出来的，所以个人周报需要填写个人的进度和工作量之类的，注意时间点可偏差表对应起来即可，项目结束的时候把这个数据在提交给EPG，然后他在去改进标准过程，和PM没啥关系了。

 

项目进展，这个就是体现出对项目的跟踪，每个里程碑汇报给项目组的人以及高层，注意进展报告的内容要体现出相关干系人和数据管理，这个没啥好说的，相关干系人就是每个阶段有什么人参与了，比如需求阶段看看需求人员有没有介入，你就说全介入了，并罗列上去。数据管理就说谁谁谁借了本，并且上个阶段谁谁谁借了个什么资料，并且如期归还了，每个阶段写1个可以了。

 

需求：这个地方最难理解的就是接口需求的管理，其他的也没啥好说的，接口需求其实没有一个硬性规定，随你怎么写，你只要做了这件事就可以了。按我的理解就是内部接口，你就说你的项目需要分成开发，有统一的DAO接口，还有项目需各个模块之间通过service相互通信，还有就是后台代码可以和前台以html的方式交互，DAO可以支持多个数据库，白痴吧？ 。外部接口我写的是需要有外部的RSS订阅功能，有调用豆瓣api的需求，有超级链接可以链接到其他什么网站，就写那么多完全可以了。不过需要注意，你最后的概要设计和详细设计需要体现出来，比如设计了DAO、service层、设计的ORM支持随意切换数据库（当然你说你框架帮你做的）、设计了RSS读写模块，设计了jsp，等等。需求完了你就需要写个总结报告，识别哪些是关键的、哪些是可以接受的、哪些是不建议实现的，你就都说可以就完了。

 

下面最容易出漏洞的是前期的计划、估算之类的，这个对于很多人来说就是一笔糊涂账，整个过程如下：

 

第一步：立项，召开立项会，确定哪些人参与，依据就是拍脑门，说得好听点是群体决策的方式，这样哪些人确定了，乘以工资，这样你的人力成本的估算出来了

 

第二步：制定项目过程定义书，这个是个啥东西？就是项目做项目要按照EPG维护的那个标准过程来，不是你随意所欲的想怎么定义就怎么定义，这里涉及到一个裁剪问题，其实这个裁剪也没啥好裁的，因为你裁多了就不符合标准过程了，就不满足cmmi的流程了，然后你就过不了了，我前面也说了就是一些小打小闹，真正的过程应该是，依据裁剪指南，裁剪指南里面规定了，根据项目的签单额或者参与的人数等等有那么几套大同小异的过程，你选一套就可以，具体是怎么裁剪的，那是EPG的事，好了，项目的过程中的东西有了，那么这个过程的顺序是什么样子的呢？所以还有一个生命周期模型选用指南，还是依据那几条，尽量选瀑布模型，因为简单。最后按照这么2点就制定出过程定义书了，里面有我该写哪些文档，生命周期是啥样子的，然后更具周期制定里程碑，时间点暂时可以不要，因为项目的工期还没有估算出来。

 

第三步：估算表。前面的项目过程定义数已经定义了要写哪些文档，然后人员你有了，你就安排这些人去写这些文档，一个人写某个文档需要花几天，这个是你拍脑门想出来的，说的好听点，叫做专家决策法，这样一累加，你的总工作量就出来了，单位就按人日来吧。好，下面偶们来看看工时的估算，意思就是我每个阶段要花多少时间，这个注意和工作量区别开来，这个是纯时间问题，因为你在做估算的时候，需求也在进行中，或者说大致的需求出来了，因为没有一个大致的需求去做估算说出来鬼才信！这些大致的需求的就是功能点，然后你在想办法把这些功能点转换成代码行，你就随便搜一个算法一乘一加就可以了，注意这个方法需要有EPG写在估算指南里面，到时候你就说你是选用估算指南里面的方法。这样代码行出来了，然后在寻在组织的度量库-----就是你每次做完项目都会向组织提交你的本次项目的度量数据，然后EPG把每次的汇总成一个库供你参考，里面肯定要记一个人均代码行数，然后你一除，你得到了你开发阶段需要多少时间，其他阶段咋办？还是寻找组织度量库，里面肯定还有这么一项，每个阶段所占整个工期的比例，现在开发阶段有了，你在推断出其他阶段的，这么简单的数学公式我就不多说了。还有资源的估算就是按人手来的，并且是参考了组织级的工作环境标准，其他的几项估算就比较简单啦，不说了

 

第四步：项目计划，把以上的结果汇总进来就ok了

 

 

下面我们谈谈另外一个环节-------------文档，刚开始我们并不知道要写啥文档，文档里面该写啥内容，我的建议是一开始花半个月就写piid表，然后根据pidds表花一个半月补文档，再花一个月准备访谈，这样3个月就搞定了。

 

总体感觉cmmi评估很庞杂而已，但并没有想象的那么复杂，以上是我所知道的一些比较重要的地方，具体的细节可以单独进行讨论