追求完美是CMMI和5000的天敌

许多朋友听我说过,“完美主义者不适合主导CMMI改进,追求完美的结果往往是建立了一套脱离实际的过程,导致CMMI/5000和团队日常工作脱节”。
最近给一家软件组织做过程诊断,在检查项目组同行评审记录的缺陷时看到了下面4个问题:
1. 评审者记录的缺陷和组织过程的要求不一致。过程要求记录所有问题,不论简单还是复杂。在实际操作中,团队仅仅记录了有争议的问题以及需要花些精力解决的问题。
2. 评审者明显在应付过程中关于缺陷分析的要求,如对植入阶段、发现方式、严重程度、优先级等多个维度的分析判定十分随意;我随机看了几个缺陷分析例子,明显经不起推敲。
3. 缺陷的统计和分析对项目的质量把控,团队和组织的改进并没有起到实质的作用。
4. 评审缺陷的定义没有工程、质量控制团队相关人员的介入,完全是EPG(更准确的名字应该是CMMI评估主导
组)强加给团队的。
和几位项目经理沟通后,对团队现阶段的做法我大概清楚是怎么回事了。他们和大多数实施CMMI的团队一样,面临着进度、资源、开发测试环境等的巨大压力,在执行组织过程时,对其认为不是核心的部分,能省就省。反正QA不会具体看记录的缺陷及分析内容,所以他们只记录了觉得应该记的问题,至于那些简单的,马上可以修改的问题就没有录入缺陷系统中,也成功躲避了对这些缺陷的分析工作。对于一堆“高大上”的缺陷分析要求,评审组织者也基本不过脑子,用了几分钟时间做了需要大半天完成的工作。
为什么这类问题屡见不鲜?其实有个很明显却往往被忽略的原因就是我们的EPG太追求完美了。在制定评审缺陷和分析要求时,希望能够做到360度全方面无死角的覆盖,恨不得把看到的“别人家”或教科书中的做法都包含进来。表面上看着面面俱到,实际没有充分考虑团队面临的各种约束条件,造成了评审缺陷数据的统计分析没有起到真正的作用。
在给组织领导和EPG的报告中,诊断团队就这个问题给出了下列具体建议:
1.    将评审缺陷统一定义为“没有达成共识或花时间解决的问题”。
2.    对所记录缺陷做如下分析:是否可以挂起, 问题的影响范围,何时必须解决、责任人。根据不同文档(需求、设计、测试用例、代码、手册等)及不同类别项目做缺陷类别判定,不同类别项目相关核心技术人员负责完善这些缺陷类别的定义。产品线定期(按季度)组织对占比最高的缺陷做必要的预防改进分析。
3.    将评审缺陷纳入测试缺陷管理工具以支持端到端的质量控制活动(细节省略)。
4.    组织层面如何使用这些数据的应用场景(细节省略)。
     
这些具体建议完善了团队已经执行的实践和一些他们认为有能力做并且值得做的事情,换句话说,做不做CMMI评估,管理者和团队也会愿意也应该做这些事情。这些建议充分考虑了项目和组织的约束条件,将重点放在最有价值的地方(问题的有效解决和问题驱动的改进),尽量让做有价值的事情简单、方便,而不是追求完美覆盖,让团队望而生畏。    
    十八世纪法国哲人伏尔泰曾经说过:
    Perfect is the enemy of good.
        完美是优秀的天敌。

    每一位从事CMMI或5000改进的朋友都应该牢记这句话。我们追求的是不断进步,而非完美。先有后优,在学习中成长,积小成大。

  

持续小的改进努力必将带来回报

    从根本上说,在CMMI和5000中追求完美也是一种惧怕:
     害怕考虑不全导致的错误
     害怕别人看低我们的工作,说我们的工作含金量不高
     害怕评估时掉链子、担责任
 
    CMMI

5000
都在努力消灭两张皮的现象,脚踏实地追求实效方可把我们带到柳暗花明的又一村。

追求完美是CMMI和5000的天敌》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/386.html