实施CMMI L3所遇问题总结

一、过程改进问题—组织级

1、领导的支持问题

在表面上来说，领导很支持CMMI标准过程的实施，但是支持是要付出成本的——需要资源的。

      第零点：公司为什么要过程CMMI（能力成熟度模型集成） 等级，因为有钱拿，区政府补助、市政府补助、省政府的补助、能拿外包证，对于过CMMI等级那领导们肯定鼎力支持了。如果我是公司领导不过CMMI等级，一定肯定非常的傻。就冲着这个原因导致其中过程真真假假，我敢说大多数公司过CMMI等级就是为了钱。伤心啦。。。

第一点：首先成立相关部门的工程过程组—EPG，EPG本来只是一个虚拟组织，但是在本公司来说不是了就是一个标准过程开发组，除了这些平时事还得继续做，QA的继续跟踪项目，项目经理继续监控开发项目，技术总监继续履行他的职责。也就是说标准过程得开发，本职工作还得继续做，那么EPG就得加班加点了。我们EPG组每日工作12小时，一直持续一个月。领导们太过于关心了，最大化利用公司资源。

第二点：培训我想公司领导都知道它的重要性——实现公司战略目标的必要过程。公司设定了培训专员，在整个公司收集了培训需求，制定了详细的培训计划，但是大多数重要的培训并没有开展。为什么？我想可能是领导们觉得培训培训态浪费成本了。

2、部门沟通问题

      当时编写标准过程文件时，咨询师就提出标准过程的确定不单是一个部门的或一个组的事，尽量抽调各个部门的负责人参与编写，如：工程类（RD、REQM、TS、PI、VER、VAL）、支持类（PPQA、CM、MA、DAR）由研发部参与，项目管理类（IPM、PP、PMC、RSKM、SAM）主要由研发部的项目经理负责，而SAM（供应商协议管理）采购过程则应由公司采购负责人确定。最后的过程管理类(OPF、OPD、OT)是整个过程改进的根源和策划，应该由EPG组长编写，其中OT（组织培训）是培训过程应由公司负责培训的部门编写。本该如此的分工，后来由于高层对文档的编写并不重视、EPG组的协调不够，导致最终的标准过程都由品质管理组编写了。问题很明显，一个组的想法即使考虑的非常周到，但是还是和实际过程有差距。最终执行的时候其他部门甚至不愿意去按照标准执行，第一个原因：和实际不符合，第二原因：而且他们认为没有必要执行标准繁琐过程，因就是当初过程改进思想没有根深蒂固在各位同事的大脑中形成，大家根本没有执行标准过程的概念。导致一个原因发生的是高层也属于支持力度不足，过程改进负责人没有履行好职责。如果高层拿喊喊口号的时间去深入了解过程改进，带头实施标准过程我想公司所有人都回去认真执行！

二、过程改进问题—项目级

    项目级执行力度是标准过程导入项目中我认为的最大问题。新过程发布了，培训完毕，放到项目中去实践了，这个是我最关心的事，因为太想知道接下去发生的事情了。做事相当卖力，积极配合项目经理去策划项目，认真指导项目组成员走标准过程。对于整个项目而言，在理想状态下按照标准过程走完肯定没问题，如果收到外在因素影响，肯定没戏。

当前我监控的一个叫客户关系管理的项目，一个项目的开始首先要立项，项目召集相关干系人（共利益者）讲讲项目背景、项目目标、项目的风险及人员需求等等，为下一步的项目策划做铺垫。对于这么一个重要的环节，研发主管给直接否决掉，原因是开会浪费大家时间。接下去的项目策划比较顺利（项目经理是个较强悍较开明的人），过程定义、风险分析、项目估算、做计划并且评审，这些都没问题，很顺利。但是把项目的培训给裁剪掉了，EPG也准同意了，裁掉培训本公司做项目的通病。做该项目的时候人手紧张根本没有老员工参与，基本是新招来的程序员不了解公司的开发框架。没有执行培训、考核，怎么能深入理解框架保证开发进度？

经过了项目策划，需求也开始分析了。众所周知需求分析的前提是市场调研，有了强有力的市场调研后，必然产出详细的需求，有了详细的需求接下来的一切都会很顺利：避免了频繁的变更，避免了频繁的修改、变更会议，保证了项目正常的进度。

然而我很奇怪的是公司有的是市场部，却没有去做市场调研（公司做的是软件产品需求都是内定的，然后却在这个流程上加个市场调研）。由于项目要参加评估，他们不得不自己写一份“市场需求调查报告”，站在QA立场上该问题1000%是不符合项，这个问题品质经理也是知道的，高层也知道，我不明白为什么知道了还不改呢？

目前CRM项目进行到了开发阶段，而且只有几个小变更，为啥呢？这里我要夸夸自己。《用户需求说明书》、《系统规格说明书》我是一页一页查看，保证文档完善的状态下，召集了3个技术总监再加项目经理分了3次用了约10小时的时间去评审它，需求人员又足花了一周时间修改整理，再审查，最终纳入基线。太奢侈了，没办法我不想看到像以前项目那样—变更20几个，到最后烂摊子一个。

经过了需求阶段后，项目功能点、人员需求基本上都很明确了，这个时候再进行一次估算，细化进度表。这个时候来一次估算，这次和策划阶段不同（策划阶段估算是项目经理自己拍脑袋的）采用是delphi方法估算需求阶段、设计阶段、实现阶段的工作量，单位是：人天。项目经理讲解规格后，研发主管、技术总监、项目经理共9人开始估算，第一轮需求阶段的偏差是197.1%、设计阶段93.8%、实现阶段145.0%，分分析了原因后接着第二轮、第三轮偏差偏差虽然变小了，但是仍然和设定的阈值相差很远，最后不得不中断估算，无果而终了。原因：估算组成员各个人经验、能力都不一样，从来都是拍脑袋的做法，导致了集体活动全部歇菜。接着还是项目经理一个人拍脑袋了~~~！

然后到设计了，这个不好沟通了，需求过程上定义了：“需求分析结束后由需求人员在设计人员看完规格的情况下在进行一次需求讲解，让设计人员深入理解需求”。然而设计人员并没有去完全按照规格做，而是在它的基础上扩充，这到底是好事还是坏事呢？我认为是好的，因为没有市场调研的需求让人感到心里没底。又作为QA角度来说这个肯定是不行，可惜俺较弱势了，没有办法抓源头。

实现阶段也最有意思了，开发人员必须写大量的文档（单元测试用例、测试报告、个人周报等），个个都很抱怨。认为开发就是开发干嘛写文档啊！？我也很理解项目进度紧，天天加班非常累。该项目的开发我也参与了，加班了快一个月了，人手不够QA也跟着倒霉~~！导致加班的原因这里说下：需求阶段估算了结项要到11月中旬，高层领导一定要9月30号完成项目。哎~~~，领导们既想尽快完工，又想过程漂亮，嚒的办法~~！!最后设计、开发、测试采用迭代的方式进行了（原来是瀑布模型），裁掉了产品集成。由于公司是web开发，不像传统的系统开发团队做好各自的模块后再进行集成。而web开发的集成是在项目开发的过程中就做了，搭好开发环境在自己的包下写代码如果要调用别人的接口、方法只要互相说下就行了，所以集成不是很明显。本来我想把集成过程认真做做，作为例子给其他项目参考可惜参与开发没时间，只能给裁掉了！编码的时候还要注意了，最好把该解决的问题都给解决（如：验证、国际化），别到系统测试的时候，会发现一些低级的错误，让人感觉不爽~！

项目执行过程中CM（配置管理）和MA（度量分析）这两个支持类的容易被忽视。我自己做过配置管理员和度量人员，理解这两块做不好，可能会导致项目的文档不齐全而且提交比较拖拉，项目经理的进度管理不及时等。

如果公司的管理体制健全，职责清晰分明，官僚主义作风影响小，提出的问题不怕没着落解决。