每个组织对一个过程的接受都要经过一个过程,总结为ABO阶梯:Awareness、Buy-in、Ownership,了解-接受-拥有。也有人称为僵化、固化、优化。SPI开始是软件过程创建。
在研发过程的改进中以CMMI为主,这是工作思路的明确;在实际执行中,按照CMMI对于项目管理的规范进行,各阶段目标明确,责任清晰,跟踪及时,所以成果凸现。
要做过程改进首先要回答的是为何要做过程改进的问题.只有自主,自发和组织自我需求驱动的改进才能够真正达到改进的目的.过程改进是一种氛围,是积累组织中的每个人不断创造价值的氛围.因此请尊重人,重视人,激励人,善用人,但又不能过度的依赖人.否则你依赖的是经验,而非过程.
中国的软件企业发展的时间还比较短,但是发展的速度非常快,如何在快速发展的过程中,让企业健康的成长,这一直是软件工程领域和项目管理领域所关注的一个课题,CMM/CMMI是来自于美国军方为判定承接国防部项目的分包公司的开发能力的一个标准,后来被开发应用为指导一个企业不断发展成熟、提高能力和建立组织构架的一个模型,对于国内软件企业的发展具有很好的指导作用。
根据2008年3月美国国防部直属的软件工程研究所(简称CMU/SEI)公布的年度数据显示,中国通过CMMI(能力成熟度集成模型)认证的企业总数达到448家,已超过印度(311家),居世界第二位,仅次于美国(847家)。但是许多人还不知道,在软件过程改进领域,还有一个目前在欧洲和大洋洲很流行的国际标准ISO/IEC 15504,也称SPICE。
在公司高层领导角色方面可能存在的风险分析;在CMMI项目管理过程中可能存在的风险分析;在开发团队实施CMMI过程中的风险分析。
CMMI过程改进中过程的推广活动是非常重要,也是历时最长,使得新的过程能够形成一种习惯,其困难也是最大的。不言而喻,这其中,SEPG的作用是举足轻重的。在新的过程导入之初,只有SEPG对过程掌握得最好。他们要担任过程推广支持的工作。通过我们自身的实践,摸索出一套过程推广的方法,来帮助SEPG改进过程推广和支持。
软件系统开发的基本问题是如何管理开发过程。SW-CMM的第一个进行目标(即第2级的目标)就是通过建立关键的管理过程域,使得开发过程可控且可重复。SW-CMM2级共有6个关键过程域(KPA)。
文章以笔者参与的上海某公司CMMI4级项目为例,总结几条确保项目顺利实施的经验。目前,该项目已经历了差距分析阶段和过程定义阶段,即将进入过程部署和实施阶段。
所谓"定义"过程是将目前的实际的最佳实践记录下来、写下来、文档化下来。过程标准的定义是经验教训的知识积累过程,是隐性知识向显性知识转化的过程,不是CMMI模型"实例化"的过程。
我们的目的很明确,流程为了项目服务,我们不会为了应付性地去写一些文档或实施一些不必要的流程,流程的规范,是为了减少人为因素的影响,更及时提交高质量的软件产品。在即将开发的2.0.1版本中,CMMI5的精简流程开始实施了,尽管仍然不够规范,但我看到了进步,也看到了管理层的决心和团队成员的共识。
在CMMI中过程被定义为一系列能够被识别和在实践中执行的活动。但是过程要能够最终产出产品和服务,不可避免要涉及到人,材料,设备,工具等一系列的要素。
在一些公司,最优秀的人永远都在最紧急的位置-作为救火队员,去处理最紧急的突发维护任务,而却不知道去追根逆源,追寻解决之道。业界已经证明,越在软件开发前期发现缺陷,越能节省成本,这大道理谁都知道。但知道和实际做起来是两回事,因为这涉及项目成本的投放策略,不少公司基于进度、成本的考虑,对开发阶段的质量关注不足,而后期付出惨重的代价。作为质量保证有两道关口,一是评审,二是测试。如果两方面都做不好,我想公司迟早会关门,因为客户的索赔,是无穷无尽的,公司维护的成本是极其高昂的。
CMMI每个PA需要做的事情,CMMI不会告诉你怎么去做,但是你必须要首先搞清楚的是为什么要做这件事情,其意义何在?我们在进行软件过程改进的过程中必须是目标和问题驱动的,这样才能够有批判的主动去改进。
本文总结作者数年来从事软件质量改进工作的经验和教训,归纳成软件质量改进的“六要六不要”,一方面作为对前述问题的进一步阐释,另一方面也期望能给广大正在和将要从事软件质量改进的同仁提供参考。
在很多企业的EPG(过程改进团队)成员和QA(质量保证)团队成员经常都会问一个问题:“我严格地执行流程,却经常得不到大家的理解,也得不到高层的认可,看不到发展前进方向?”同样很残酷的现实是,在一些公司,当公司CMMI评估通过之时,也可能是EPG/QA要离开公司的时候,为什么会出现这类问题?