关于过程改进CMMI的有效性思考

CMMI是一套过程成熟度的框架,也可以将CMMI理解为方法论,但不能将其理解为最佳实践.CMMI更多的是给出需要做什么,给出做一件事情的参考工具和方法,但究竟如何来做则组织完全可以采用自己的方法,也可以采用其他通过了CMMI企业在实施过程中的最佳实践.

 

通过了CMMI是否就说明过程一定有效?这个在CMMI的二级和三级是无法得到这个答案的.而在4-5级则开始对实际的组织能力效能进行度量.度量的指标有很多,但归到底都是成本和利润.软件是创造客户价值,但创造客户价值的最终目的都是为企业自身创造更多的价值财富.在初期企业为了获得一个通行证,为了过级而过级,这样过程改进带来的实际效果是微乎其微的.而且一般在过完级后管理者也不再重视,项目由于进度压力将CMMI好的东西全部抛弃掉,又回到老样子.企业实施CMMI唯一带来的就是一张证书.

 

做任何事情都要有目标,但实现目标的方法却千差万变,可以唯利视图,可以不择手段,可以不管过程,可以先学走再学爬.这些都可能实现预定义的目标.但我们考虑的不仅仅是实现一个简单目标,目标也是发展的要用长远的眼光来看待,考虑目标实现后对组织或项目后续的深远影响.因此重视过程而轻视目标不可取;但重视目标而忽略了过程同样造成严重和深远影响.这也是CMMI强调过程的一个重要原因.

 

建立通过过程改进提高成熟度,而实际的能够降低项目成本并赚取更大利润是CMMI实施的终级目标.任何子目标都必须围绕这这个来服务.在过2或3级的时候你可以讲先把过程或规则建立起来,暂时不考虑是否有效.但到了4,5级就必须考虑过程是否有效的问题.

 

让我们再来看下CMMI中不以效率为导向现象
1.明知无效的过程或过程中无用环节仍然在执行,沉默的大多数,极度危害的沉默
2.过程改进的建议不能够很好的采纳和实施,对无效过程沉默
3.局外人不站在项目和效益角度为了完成任务推一些对项目无用的过程
4.没有很好的方法来度量出过程是否真正有效,过程做了但没有效果
5.对于推行了的过程即使影响效率也没有人再愿意去改进,持续改进成为空话

 

让我们再来回顾CMMI2,3级相关的重要KPA

 

1.需求管理和需求开发
需求管理最重要是要使需求受控制,需求的变更受到控制.需求就是IT项目的范围,范围的蔓延往往对项目都是致命影响.需求应该是可追踪的,但实现方式可以完全简化,一个简单的Excel也可以实现而不一定采用RP等工具.需求追踪的目的就是说到一个功能需求能够方便找到相关的文档资料和代码,一个需求要变更时候能够方便知道会对其它功能模块造成什么影响.

 

需求开发重点是需求的挖掘和转化过程,一个是挖掘出用户潜在需求,一个抽取和整理出公用需求,需求开发做不好造成影响就是后期大量的需求变更和需求蔓延.

 

需求和架构是整个软件项目开发中是最重要文档资料,因此需求规格说明书是必须的文档,并且必须完整清晰,符合SMART原则.这里说明下不可省略的交付物.

 

需求规格说明书 必须输出(背景,功能描述,输入,输出,业务逻辑,界面,数据字典)
需求调研报告   可以选择输出
需求追踪       可以省略,小项目好的需求文档和源代码即可体现
需求变更控制   必须,最好在系统里面,无系统也必须有文档记录

 

2.配置管理系统和变更控制系统
这是IT项目必须具备的两个系统,目的就是要保证整个过程受控制,产出物一致性有保证.

配置管理系统    至少要有源代码管理系统,如VSS等
变更控制系统    至少要有Bug追踪系统,如CQ,BugFix等
配置和变更集成  可以选择

 

对于小型项目,即使一个人项目最好也有源代码管理系统,保证代码安全和可追溯性.而对于小型项目不一定要有Bug追踪系统,但对于测试独立了的项目都采用Bug追踪系统,方便Bug的跟踪和解决,同时也为项目后续版本积累数据.

 

3.验证和确认(Verify and Validate)
验证是判断是否符合当初定义的条件或标准.而确认是判断是否符合需求.因为事前预防总比事后补救要好,所以评审,Review,测试都是相关的验证和确认措施.确认的大部分内容指测试,因为测试用例会对应到具体的需求.

 

Review和系统测试是重要的两个环节.对于Review在小型项目中推荐的是代码互查和走读这种形式,既能够起到很好的作用,效率也比较高.而对于

系统测试一个重点就是事先要准备测试用例,而且测试不能是开发人员自己测,这是最基本的要求.

 

4.同行评审(peer review)
同行评审有效,但经常并不能起到很好的作用,见我Blog关于同行评审的其它文章.我们在推广KPA一般会辅助上相关的系统,收集和度量数据.流程定义繁琐是过程不能高效的一个重要原因.

 

很简单一个例子,一个需求文档组织过程规定必须走正式的同行评审,则从建立评审计划,安排会议,组织评审,修改,验证关闭一个单据走下来可能会花掉一周的时间,而如果走一种非正式评审的方式可能1天就可以搞定.对于非关键需求文档即使没有采用正规审查方式,而采用非正式评审也不会影响到工件的质量.

 

5.项目计划和跟踪控制
现在IT项目管理逐渐受到重视,IT项目管理领域是一个相对复杂的领域,除了项目四要素外,项目的干系人,风险,人员,沟通,团队等都是需要重点关注的内容.对于中小型项目,项目负责人的个人经验和能力对项目的成败往往起到重要作用.项目负责人既是管理者也是技术负责人,而且往往身兼数职.但对于大中型项目这是很危险的,因为项目的成败不能依靠某一个人,而应该依靠过程的成熟.

 

对于项目计划制定中必须的一些内容:项目的范围说明,生命周期模型选择,项目的假设约束,项目的组织结构和项目成员,WBS分解和估算,进度计划这些是重要的计划内容.CMMI三谈集成项目管理,项目管理计划也是一个综合计划的概念,包括质量,沟通,质量保证,配置,测试等诸多子计划.

 

EV分析最佳采用是大中型的项目,有明确的工作包和控制帐户.而且项目是采用增量开发的方式.在这种情况下EV分析就很有用了,很容易的了解到项目的进度和成本的偏差情况,并对后续进展进行预测.

 

项目的跟踪和控制中除了对项目进度,质量,范围和成本的跟踪外.还必须对干系人和项目风

险进行跟踪.

 

6.产品集成和解决方案(PI and TS)
对于基于组件的开发这种模式必须要考虑产品的集成和产品的配置.产品应该具备所需要的公用特性,而其它的功能特性应该是可以根据用户需求进行灵活配置的.因此对于软件项目谈以架构为中心,架构要考虑的就是整个产品的可扩展性,可配置性.

 

产品的集成必须和配置管理共同使用,项目的各种交付物必须是受到配置管理的配置项,配置项必须受到版本控制和基线控制.产品集成考虑了整个产品从单元,模块,组件组装和集成为最终产品的过程.

 

TS涉及到软件项目中采用的各种方法,工具和技术的内容.而这些恰好是敏捷开发非常强调的管理要素.一些项目一开始就注定失败,跟开始选择的技术解决方案有很大的关系,因此技术解决方案的选择是一个很慎重的过程,必要的时候必须通过DAR过程域的相关指导进行.

 

7.组织级培训(OT)
项目成员的通用技能的培训是组织的事情而不是项目的事情.员工出现流失后,新进入员工无法达到基本的技能要求,项目花费大量的培训成本对新员工进行培训,无疑是雪上加霜.

 

培训是有成本的,无视员工培训和技能增长给项目带来更多的进度和质量风险.