基于CMMI的
软件过程改进策略及软件外包管理
基于CMMI的软件过程改进已经被越来越多中国的软件企业所接受，目前，在中国已经被越来越多的IT企业所认同和实施。但是，通过评估不是企业的最终目的，对软件企业而言其根本的利益是通过实施软件过程改进，提高企业的管理水平。笔者多年从事软件过程改善项目，积累了大量的经验教训，现概括出6条策略，供正在或准备实施CMMI的软件企业参考。
策略一：自低向上，主动改进
在进行软件过程改善的时候，通常有两种做法，我称之为自顶下与自低向上。在自顶向下的做法中，企业成立一个推进小组，一般称为SEPG（软件工程过程组），他们是企业里”开发大法”制定的组织者。SEPG组织一些开发人员成立各种任务小组，由这些任务小组根据进行过程改善参照的标准编写各种各样的企业的标准与规范，经过一系列的评审、培训，然后让开发人员去执行。在执行过程中最常见的阻力是来自于开发人员，他们往往会抱怨制定的企业开发规范不符合企业的实际情况，标准太高，无法达到。这一种做法，费时费力不讨好，大家的意见都比较大，标准定的比较完美，而且在评审时还要大家表面上都要认可，制定标准的人花费了很大的精力，对标准的评审浪费了大家的很多的时间，执行时还难以贯彻下去。后来我们降低了要求，抛弃了各种标准与规范，采用了一种简单易行的策略，自低向上的办法，即由SEPG找开发人员、项目经理让他们自我发现问题：你有什么缺点？你将如何改进？好，在开发人员、项目管理人员讲自己的改进措施后，让他们确保能做到。在这种办法中，不需要管理人员花费太多的精力进行标准的制定，改进的推动，这些工作都是由开发人员自己去做的，管理人员仅仅是起到了监督的作用，只要开发人员自己说到做到就可以了。再做下一个项目时，管理人员同样会问这2个问题：你有什么缺点？你将如何改进？然后管理人员监督开发人员说到做到。在这个过程中逐步完善形成标准与规范。
在上面的两中方法中，我们可以从几个方面进行比较：
当然采用第2种方法时，你一定要目标明确，你是要改进过程，而不是为了在短时间内通过评估。
策略二：循序渐进，由易到难，由粗到细，由松到严
CMMI的一个核心思想是分级改进，在CMMI模型中将软件企业的过程能力分成了5级，有很多企业很可能违背了分级改进的思想，搞了一场革命，期望短时间内提高管理水平，那显然是不现实的，我们要需要的是改良而不是革命。分级改进实际上就是要循序渐进，你能一步做到5级吗？不可能的，对于5级的每个KPA，可能你先实现了每个KPA的一部分活动，稳定了，再实施另外一部分活动，如果你现在2级，想一下子将3级的所有的KPA的所有活动都满足是不现实的。在实施CMMI的过程中一定要根据企业的实际情况量力而行，千万不要期望值太高，要一步一步来。先定出最基本的改进方案，然后逐步提高，要把握分级改进的思想。
要做到循序渐进，首先要对企业现状有一个明确清醒的认识，在分析现状时，下面的四个问题是必须要解答的：
- 当前我们存在哪些问题（当然，问题可能很多）？
- 哪些问题是我们迫切需要解决的？
- 哪些问题是我们目前能够解决的？
- 哪些问题是我们当前无法解决，需要打好基础后才可以解决的？
接下来要对照标准，提出解决方案。按照”力所能及，有所提？的原则对问题排出优先级。
以SPP、SPTO这2个KPA来说，你可能可以采取5次循环达到CMMI3级的要求：
- 第一次循环：从无到有，使项目组成员熟悉做计划的过程，熟悉项目计划跟踪的重要性。
第一步：要求每个项目组都要用Project做项目计划，该项目计划要满足一定的条件，如：
- 任务的颗粒度不能太大；
- 任务负载要均衡；
- 任务尽可能并行；
第二步：对每个项目组，按计划进度进行跟踪，在计划执行过程中及时发现问题，解决问题。
第三步：总结本次循环执行过程中存在的问题，如：
- 项目计划中任务识别不全；
- 计划的任务工作量估算不准；
- 在项目进行过程中，发现问题后采取措施不及时等。
- 第二次循环：增加完整的生命周期模型定义
生命周期模型是项目管理的管理的主线，定义一个好的生命周期是推行CMMI3级的一个最关键的基础工作。
第一步：要求每个项目组首先要定义出自己的生命周期模型，做出项目计划模版
第二步：要求每个项目组按照项目计划模版进行做项目计划
第三步：进行项目计划跟踪
- 第三次循环：增加规模、工作量等的度量
第一步：要对项目的规模、工作量进行正式的估计
第二步：按计划摸版做项目计划
第三步：进行项目计划跟踪
- 第四次循环：增加风险分析
项目的风险管理对于国内的软件公司而言，一般都是一个难点，可能风险很多，风险可以预见，但是没有很好的规避措施。所以建议将风险管理放在较后的循环中来改进。
- 第五次循环：体系化，制度化
开始时要求不要太严，对文档的要求要粗一些，要把握住实质而不是皮毛。
策略三：教育与培训并重
任何一种标准的推广总会将培训放在一个很高的位置上，我不太喜欢用培训这个词，我更喜欢用教育这个词，我们的一个关键目的不是告诉他技能，而是要改变他们的思想，因此，首先要做的工作是教育。要让各个方面的人都能够接受这些先进的思想，以便于主观上认可，客观上配合。进行教育有各种方式，需要配合起来使用：
- 观摩学习：看看别的做的好的企业是如何做的？和别的企业的管理人员多沟通交流。尤其是对企业的高层管理人员这点很关键。
- 请外面的专家来讲：俗语讲的好”外来的和尚好念经”，这句话屡试不爽，企业内的人说多遍可能效果甚微，外面的专家讲一句，一下就点透了，接受了。
- 自我反省：开发人员进行自我分析找出自己的不足，并提出改进意见，大家互相沟通交流这些经验教训，自己教育自己。
- 补上”教”：我们的很多软件工程师、项目经理的经验并不是很充分，也可能比较固执，不撞南墙不回头，没关系，允许他犯错误，但是要有人帮他记录他的错误，提醒他认识自己的不足，加深他的印象。
- 培训：培训可以分成多种：技术型培训与管理型培训，这是最基本的工作，思想工作做通了，培训起来效果就会比较好。
SPI不能仅仅定义为开发部门的工作，需要整个企业的所有人员的参与和重视，因此教育与培训的对象比较多，不要有遗漏，如：
- 高层管理人员：为什么要进行SPI？在过程中会出现什么问题？对公司有哪些正面与负面的影响？需要领导配合做哪些工作？要认识到工作的艰巨性。
- 开发管理人员：技术与管理知识
- 开发人员：技术与管理知识
- 市场人员：要认识到SPI的重要性，对市场的影响，在此过程中如何配合？
- 客户：对于一个项目而言，需要提出合理的进度、质量与投入的要求，并把握好需求的范围。
策略四：测试先行
尽管测试在CMMI中没有作为一个单独的KPA存在，但是，加强测试却是我们实施CMMI的一个很好的策略。在管理基础薄弱的软件企业里面，通过加强软件测试，可以直观地发现很多问题，从而使大家认识到质量的重要性，认识到进行过程改进的重要性，事实胜于雄辩；另一方面也减少了用户发现错误的概率。在很多软件企业里面并没有专职的测试人员，测试一般是有项目组自己进行，而且往往也是在项目结束时才进行测试，在项目进行过程中很少进行测试，这就是现状。
- 设立专职的测试，让他们在开发过程中参与测试，可以发现项目开发过程中的很多问题，如：
- 项目组提交给测试人员的文档太简单，测试人员无法看懂；
- 项目组提交的文档与实际做出来的软件不一致，测试人员无法测试；
- 项目修改了需求与设计，没有及时通知相关人员，测试人员按旧的设计测试，有的开发人员按新设计开发，有的开发人员按旧的设计开发；
- 不同的模块界面风格差别很大，没有统一的界面标准；
- 测试人员测试的版本与开发人员开发的版本不统一；
- 项目组成员的分工不合理。有的开发人员任务重，而他开发的软件缺陷特别多，有的模块缺陷就特别多，可能设计人员的能力比较弱；
- 项目组没有按计划提交测试，项目拖期；
- 软件运行速度很慢，怀疑系统的设计有问题；
………
通过对错误原因的分析，可以发现大量的管理问题、需求的问题、与设计的问题没，这些实在的统计数字对我们找出最关键的改进点、说服反对派、教育软件工程师、加快SPI的推进是一个有力的武器。
策略五：”因材施教，各个击破”
在一个企业内可能有个开发项目组或者开发部门，不同的组与部门原来就有不同的管理水平，在我们推行CMMI时，不要一刀切，不要希望每个队伍同时达到CMMI3级或更高的级别，应该区分对待。比如说做产品的部门，经常进行大大小小的各种各样的升级，产品的版本比较多，他们对版本管理的工作认识的很深刻，在工作中积累了一套行之有效的版本管理的方法，版本管理比较正规，对于这样的部门可以实施配置管理KPA的要求，进一步提高管理水平，而对于其他做系统集成的部门这方面的工作可能就差一些，没有很好的版本管理的基础。因此，如果一刀切，要求大家都在3个月内达到CMMI3级的要求，这个目标对系统集成的部门讲，就定的太高了。当然通过一场运动来提高管理水平是可以尝试的，但往往是不能持久的。
所以在进行改进时应针对不同的项目组、不同的部门定出不同的改进计划，如可以采用下表的方式来定义不同项目组、不同KPA的阶段计划：
策略六：充分利用管理工具
管理工具可以做为思想、方法的载体，他可以将管理有形化、客观化，降低劳动强度，解决手工无法解决的问题，易于为开发人员、管理人员所接受。充分利用管理工具来推行SPI的一个很好的策略。
很早我们就引进了MKS SI配置管理工具，Poject计划工具，SQA 测试工具以及QA monitor等其他的一些管理工具。开始引入的时候是有些难度，毕竟是对工作方法产生了改变，一旦熟练了，就习惯了，目前它们已经成了大家在工作中必不可少的工具。
对工具的选择与购买需要把握好”够用既可”的原则。软件开发管理工具一般比较昂贵，如果一次性投资购买了比较昂贵的软件，可能软件的80%的功能用不上，等企业的管理提高到工具软件可以支持的较高的管理水平，已经是2年以后的事情了，而2年以后的版本也需要升级更新了，所以，没有必要为用不到的80%的功能提前投资。
CMMI与软件外包管理
“任何企业中仅做后台支持而不创造营业额的工作都应该外包出去，任何不提供向高级发展机会的活动与业务也应该采取外包形式。企业的最终目的不外乎是最优化地利用已有的生产、管理与财务资源。”
这是管理学大师彼得·德鲁克的预言，同时也反映了现代企业运作的一条金科玉律——“利润最大化，成本最小化”。软件业是一个高速变化、新技术层出不穷的行业，同时又是人力资源、人力成本相对较高的行业，更需要采用外包服务形式来合理地配置资源，最大限度地从分工合作、资源共享中获益。综观软件产业的现状，发达国家的软件外包已经成为软件企业发展的必要手段，国际间的软件外包与转包业已经日渐成熟。因此，中国软件产业要发展，就必须大力发展软件外包服务，做到专业分工明确、协作配合良好，形成一个完整的软件产业链。
软件外包管理实际上涵盖了软件生命周期中的各个过程，任何一个软件外包过程都会涉及到需求管理、软件计划、质量管理、项目追踪、配置管理等内容，因此，不能孤立地看待CMMI的软件子合同管理，而应该将其视为能将其他软件开发过程从公司内部部分或全部延伸到公司外部的管理规范与管理技术。通过软件子合同管理过程的实施，软件开发机构能够有效地管理与控制他们的业务分包过程。
CMMI模型定义了软件子合同管理要达到的目标、实施时必须履行的承诺和需要具备的能力，定义了进行软件子合同管理应该进行的活动。但是，就像SEI对软件能力成熟度模型其他KPA的描述一样，只是给出了“应该做什么”，而对“如何做”这一关键问题并没有给出相应的指导，很多想实施软件外包管理的企业和组织都感到无从下手。我们参考了一些国内外的资料，结合具体的实践经验，提出了一个框架性的描述，它包括以下几个方面的具体活动：
- 按照文档化的规范定义和规划子合同；
- 按照文档化的规范，根据承包商完成工作的能力选择承包商；
- 把与承包商签署的协议作为管理子合同的基础；
- 评审和批准文档化的承包商软件开发计划；
- 以软件开发计划为标准,跟踪软件开发过程；
- 按照文档化的规范，对承包商的工作陈述、子合同条款、条件以及其他约定进行更改；
- 双方的管理者一起执行定期的状态或协调评审；
- 承包商参与定期技术评审和交流；
- 按照文档化的规范在所选择的里程碑处进行正式评审，评价承包商的软件工程完成情况与结果；
- 软件质量保证组按照文档化的规范监控承包商的软件质量保证活动；
- 按照文档化的规范进行验收测试，定期评价承包商的能力。
企业按照这些步骤，就可以初步开展软件外包管理活动。
