我看CMMI

我看CMMI

文／李红

        

企业面临的机遇和挑战

    随着国家重大信息化工程建设的加快、信息技术在传统行业的应用以及社会、文化、政府领域信息化水平的提高，软件产业已经成为了信息产业的核心，而软件产品质量无疑已经成为了软件产业的重中之重。与此同时，一些国际化的跨国公司也纷纷在中国建立研发基地，

中国的外包业务也正在日益蓬勃的发展。众多的发展机遇已经告诉我们，中国的软件企业必须朝着规范化、国际化的方向发展，否则就会被时代的步伐远远得甩在后边。

提高软件质量的必要性

    面临众多的机遇和挑战，如何提高软件产品质量，保证软件产品按时按质进行交付已经成为我们每个软件企业追求的目标。在前进的道路上，我们曾兴高采烈的谈论：如果将来有一天，我们的软件也能像硬件那样实现模块化生产、流水线作业，每个人负责一部分，然后进行模块组装，每个模块只要符合标准就完全不会出现问题。然而，梦想归梦想，好像那是个非常遥远的时代，于是，我们就说，软件业还属于新兴产业，要想达到标准化水平，可能还需要走很长的路。可这段路我们却走了很长时间，而且走得非常辛苦，遇到了很多困难，经历了一次又一次的失败，我们不免发出这样的疑问：有那么多的高级技术人员，我们也有很多很好的软件开发工具，但是，为什么我们的软件开发还是会延期？为什么软件质量还是无法保证呢？问题出在哪里？软件到底有什么特殊性呢？为什么会有那么多的不可预料的复杂情况？

直到有一天，印度出现了软件蓝领，据说高中毕业的学生就可以编出一套非常规范的代码，而且不同的人编出来的代码就象是一个人写的。这让有心之人又陷入了沉思，难道是我们把软件开发想象的太难了？难道是我们走错了方向吗？软件的特点究竟在哪里呢？为什么软件开发会有那么多的不确定因素呢？

经过痛苦的思索，终于发现了原因所在：软件在开发出来之前是个看不见、摸不着、完全在人脑海中的抽象概念。而要将抽象概念转换成一个可以运行的产物，就要靠人的脑力劳动。每个人的大脑思维方式不同，同样的一句话，不同人说出来，不同人听起来可能都会有不同的意思。不同的人，在完成一项任务的过程中，又增加了很多个人色彩。往往一句话可以听出多种含义。老祖宗也曾多次教导我们“锣鼓听声，听话听音”，这似乎是我们的一个长处，但是如果用在软件开发上可就大错特错了，软件开发最怕的就是引起歧义的语言，一定要避免沟通和交流的二义性。所以，如果没有规范化的要求，我们确实会有非常大的想象空间。而且有些时候，我们很想去追求这样的个人特色。由此看来，如何规范软件开发流程，提高软件产品质量是我们亟待解决的问题。

CMMI走过的弯路

在寻找规范化的道路上，我们仍然处在不断探索的阶段，在苦苦追求的过程中，在经历了许许多多的失败和痛苦之后，我们开始寻找一些解决方案。 ISO9000，CMMI，敏捷、测试驱动开发……众多的软件开发方法和理论的引入，使我们看到了很多希望，尽管大家对这些思想众说纷纭，有人还持非常反对的态度，但是我总觉得，不管企业实施的效果怎样，懂得去尝试，首先就是一种进步。与此同时，国外一些大的软件厂商也纷纷推出自己全套的软件开发解决方案，什么配置管理工具、需求管理工具、代码管理工具等等，希望通过工具来帮助企业实现软件规范化生产，从而解决软件质量问题。但是这样的软件价格一般都比较昂贵，对企业现有流程的影响也会比较大，而且这样的软件能否真正的实现规范化生产，能够真正的提高软件产品质量，谁也不想先花上几十万甚至几百万去尝试一下。而ISO9000、CMMI单单从提升企业行象这一个目的来看就已经让我们看到了希望，因此，我们很多的企业还是选择了后者。然而，在沿着这个方向前进的道路上，很多企业又走了很多弯路。于是很多人就说ISO9000、CMMI到中国就变味了，ISO9000的含金量也是大大的缩水，还有的人说ISO9000、CMMI根本不适应中国的土壤，也有人说中国人过CMMI的目的不纯。我想不管目的纯不纯，企业老板目的肯定是很纯的，我相信大多数的企业老板绝对不只是为了拿证书而拿证书，他肯定还是非常希望通过实施ISO9000、CMMI来真正提高软件产品质量的。难道，企业花那么多钱只是为了能给企业挣点面子吗？

那问题出在哪里呢？原因在于我们对 CMMI没有真正的理解，时间问题当然是一个方面，要想真正通过CMMI3级、4级甚至5级，不是短时间就可以达到的，需要经历一个找差距-改进-再找差距-再改进的过程。而且往往这些差距都是企业多年来形成的老习惯，这些习惯会体现在组织结构、考核制度、管理方式、开发习惯等等各个方面，而这些制度和习惯都不是在短时间内能够进行改进的。如果没有认识到这一点，过于心急，那么多多少少会有揠苗助长的危险存在。除了时间问题之外，更重要的是在改进的过程中要选对推动过程改进的主力军，这个主力军应该是企业的老板、各个部门的领导、项目经理、开发经理。如果单单靠公司SEPG [B.Z.1] 成员去推动，未免有些身单力薄，为什么这样说的？不管 ISO9000还是CMMI，本质是为了提高软件质量，如果从事软件开发的管理人员和开发人员不是过程改进的积极推动者和参与者，没有心服口服地认识到改进的真正好处，又怎么能够达到真正的改进效果呢？软件质量又从哪里来提高呢？

当然，要想转变大家的思想，让大家认识到 CMMI的好处，确实不是一件容易的事情。所以，实施CMMI过程改进，企业首先需要的是一批即懂技术又懂CMMI的中高级管理人才，如果没有这样的一批人带头来改进软件开发过程，不管应用什么测评方式，拿到什么证书，软件质量还是不会有质的飞跃。结果只能是你说你的，我干我的，井水不犯河水。然而，这样的人在企业真的是太难找了，每个企业都可能有，但是比率可能只有3%。有的企业走地比较超前，可能相对会多一些。因此，企业过程改进的当务之急是要培养出这样的一批中间力量。然而，IT领域的中高级领导往往都是技术出身，一般都是那些对技术比较精通，但又不善言辞的人。我觉得这也是理所当然的事情。如果管理人员不是技术出身，对软件一窍不通，又怎么能领导整个团队开发出成功的产品呢?团队领导必须要懂技术，而且必须要有多年的开发经验才行。那问题出在哪里？问题出在角色转变的过程中，没有认识到软件管理的重要性，因此忽视了软件管理方面的学习和深造，没能使这些优秀的技术人员顺利转变成一名优秀的管理人员。

 

CMMI与软件质量

看到这里，大家可能还是对 CMMI存在怀疑的态度，CMMI真的可以帮助我们规范软件开发过程，真的能够提高产品质量吗？

“ CMMI无非就是写很多文档，即浪费了我们的时间，又没有任何用处！”这是我们大家常说的一句话。其实，这是对CMMI的误解。可能大家接触CMMI都是通过写文档这个环节开始的。不管是知道还是不知道为什么要写这样的文档，只好照葫芦画瓢了。

呵呵，文档可不是 CMMI的真正目的啊。文档只能作为检查工作的一种证据。记得大学的时候为了保持宿舍卫生，经常会有学生会的人到各个宿舍去检查。为了得一个高分，我们宿舍的成员经常把桌子上、地上，所有能看到的地方打扫的干干净净，所以我们宿舍卫生检查经常得第一。可是，我们自己非常清楚我们宿舍的卫生情况，因为那时候每个宿舍都有一个行李床，专门放一些行李，箱子什么的。而那个行李床成了我们隐藏杂物的好地方，为了表面看着整齐干净，我们给行李床买了一个非常漂亮的床帘，有时候起晚了又赶着去上课来不及收拾，就把一些杂务统统都堆到里边，拉上帘子什么也看不出来，这也是我们经常得第一的秘诀。可是，我们宿舍的卫生质量真的能过关吗？我们自己都非常清楚，因为，我们宿舍的人都特别懒，所以才会想出那样的一个办法来蒙混过关。不知道检查的同学是没有时间还是太信任我们了，大学四年，竟然没有被他们发现我们的秘密。

行李床的故事跟现在很多企业实施 CMMI有相通之处：如果参与实施的人只是为了交差，敷衍一下领导安排下来的任务，当然不能真正体会到CMMI带来的好处了，也就不能从过程改进中学到很多软件管理方面的好的思想。CMMI还不同于卫生检查，毕竟，企业是花了很多钱的。

“ CMMI真的能帮助企业提高软件产品质量吗？如果我们认认真真的完全按照CMMI的过程去做，就一定能提高产品质量吗？”这句话同样也是错误的，因为CMMI只是用来衡量企业能力水平的一种检查体系，只给我们指出了对于软件开发过程而言，哪些域、哪些过程是重要的，是我们必须要做好的，如果做不好会产生哪些危害。但是具体怎么样才能做好，是需要企业根据自己的实际情况采取一定的措施去改进的。如果我们只知道过程域的重要性，而没有采取正确的措施进行改进，或者采用的改进方法不当，都不能真正的提高我们的软件质量。例如，CMMI中的 Requirements Development(RD)需求开发这个域。这个域的目的是为了生成和分析用户、产品和产品部件需求。该域又分为以下三个子项：

SG1：开发用户需求。干系人的需求、期望程度、环境局限和接口被收集并转换为用户需求。

SG2：开发产品需求。客户需求被精确的转换成产品需求和产品部件需求。

SG3：分析和验证需求。在需求被分析和验证过程中产生模块功能。

他们之间的关系可以用这个图来表示：

我们不妨具体分析一下这个图能给我们带来哪些启示。

先来分析“干系人的需求”。为什么用干系人这个词呢？干系人就是与项目有关系的人，哪些人属于干系人呢？花钱做软件的企业老板，当然是干系人；软件上线之后的真正使用者，当然也是干系人；还有软件的管理员和维护人员，也是干系人。 CMMI用干系人这个词，确实非常恰当，也就是说我们需求调研的对象必须是与所开发的软件有关系，如果没有关系的话，我们得到的需求就不是用户真正的需求，有可能就会偏离用户的初衷，做出来的软件也不会得到用户的认可和好评。这是CMMI告诉我们的风险信号。这个信号告诉我们，在做需求调研之前必须先识别项目的干系人，而且需要区分哪些是重要干系人。但是如何识别，CMMI没有告诉我们，那就靠我们敏锐的观察力以及做项目的经验了。如果我们只注重过程，按照CMMI的要求有了选择干系人的过程，但是选择的方法不对，导致没有选对干系人，那么我们还是不能得到用户真正的需求。同样的，用户需求开发、产品需求开发、验证用户需求等等我们可以识别出来很多的风险信号，例如为什么要区分用户需求和产品需求呢？为什么要验证用户需求呢？这里就不一一解释了，在以后的章节中我会陆续向大家介绍。 [B.Z.2] 

    由此看来， CMMI好比飞机的雷达，船舶的舵手，野外探险的指南针，给我们指明了前进的方向。CMMI又好比黑夜中的灯塔，告诉我们哪里有暗礁。有了它的指引，我们可以绕过险滩，少走弯路，用最少的成本达到最大的效益。但是CMMI并不是飞机和轮船上的发动机，也不是野外的探险者，如果发动机发生了故障，或者探险者根本不相信指南针，都不会顺利完成任务，到达胜利的彼岸。

    那么什么才是软件开发的发动机呢？软件的发动机就是我们的专业技能。软件开发需要各种不同角色的人一起工作，不同的角色需要有不同的专业技能，例如：系统分析员和项目经理就需要有识别干系人的能力；系统分析员还要有良好的沟通能力，能够充分理解用户需求；还要有良好的分析能力和技术能力，能够把用户需求转化成产品需求；还要有良好的控制能力，能够很好的进行需求管理和控制需求变更。同样，设计人员就要有良好的设计能力，设计出来的技术架构和程序框架要有良好的扩展性、可复用性、可维护性、可移植性等等。如果这些技能达不到，就是采用再好的过程，也起不到很好的作用，因此在进行 CMMI过程改进的过程中，一定不能忽视了专业技能的锻炼、培训和提高。只有发动机和雷达都能正常工作，飞机才能顺利的到达目的地；只有船舶发动机运转正常，舵手经验丰富，能够轻松自如的把握方向，才能绕过暗礁和险滩，船舶才会顺利完成远航，到达终点。

然而， CMMI内容博大精深，包括了25个过程域，每个域又有很多子项，每个子项之间又有着千丝万缕的联系。要想真正弄懂其中的含义还真不是件容易的事儿。国外对于CMMI的书籍和资料很多，可都是英文版的，国内目前完全针对CMMI，尤其是实践应用方面的资料还是非常少的。因此，我想在以后的章节中把我在CMMI实践应用方面的所见、所感以及所想记录下来，希望这些内容能够引起大家的共鸣或者给大家带来一些思考和灵感。

怎么样？看到这里？您是不是对 CMMI有了新的认识了呢？是否也有那么一点点兴趣了呢？那就和我一起去畅游CMMI的神奇世界吧，在每个关键域我都会带您去领略一下CMMI带给我们的关键点，CMMI的检查标准，在改进过程中我们经常会遇到的困难，以及应该采取什么样的改进方式？准备好了吗？那就和我一起出发吧！

---