聊聊CMM/CMMI认证的反敏捷
这是鼎叔的第四十四篇原创文章。
行业大牛和刚毕业的小白,都可以进来聊聊。
对于传统软件行业的QA(过程改进)和PM人员,CMM/CMMI知识是基本要求,但是在推行敏捷的组织中,CMM/CMMI并不被接受,甚至和敏捷转型理念背道而驰。CMM/CMMI如果作为一个过程改进的知识框架,本身并不会和敏捷研发产生冲突,但这篇文章我们会关注CMM/CMMI行业认证中的反敏捷之处。QA人员也可以对比思考,如何在组织中选取更符合敏捷价值观的实践方案。
参考文章:《CMM的不成熟之处》,《软件过程改进的竞争价值观》(IEEE工程管理汇刊),CMMI相关规范,《丰田之道》,《破除CMM迷信》,Barry Boehm,Mark Paulk《软件CMM》作者等。
CMMI并非是基于瀑布研发流程来设计的,并非需要大量文档。它和敏捷及精益没有根本上的冲突,但是其改进过程的范式差异比较大。CMMI对任何的特定实践并没有做出规范要求,但它引入了“持续改进”的重要理念。
CMMI和敏捷开发的表面冲突来自于双方产生的环境、目标客户和团队文化要素。例如CMMI早期客户,主要关注大型项目、复杂系统,而敏捷开发主要关注小项目、简单应用和灵活多变的系统;CMMI的假想市场和用户主要面向成熟市场,面向那些关注流程创新的企业,而敏捷开发主要关注在新兴市场和多变的市场环境;文化方面,CMMI强调流程和管理,而敏捷更强调高度信任的氛围中,被激励起来的个人之间的协作创新。
在整体上,CMMI和敏捷开发能够相互补充、相互支持。CMMI关注组织级或企业级改进,关注回答项目应该做什么,而不是具体怎么做的方法,而敏捷开发则更关注项目具体怎么做的方法和最佳实践,这使双方在定位方面形成相互补充的态势。
两者的有效结合,能够有效实现个人绩效向向组织绩效的转变过程。同时,团队可以借助敏捷实践,规避CMMI实施过程中重文档、重流程的不良倾向,让CMMI实施时更加关注组织的实际价值、关注客户和创新。
很多外包IT团队往往都有CMMI的认证。CMMI早期广泛用于美国国防部招标合同,领导者很多来自美国国防业。我们首先要澄清一些业界的误解,警惕根据CMMI鉴定来挑选远程外包公司的做法。
一个公司拥有CMMI证书,和它是否有高质量的代码,并没有关系。任何一个简单的数字,如果有利可图的话,那有人就开始要作假了。一个部门得到一次认证,可以被大而化之地广告为整个公司多年来都获得了五级成熟度评价。像一个开发组织的过程能力这么复杂精妙的事物,不可能用一个从0到5的数字来表示,就靠几个审查师在公司呆一周,访谈几十个员工得出结论?几天的认证培训并不会对改变思维模式或文化的能力有任何变化,这只是人事部门的一厢情愿。
度量容易之事,而非有用之事,这个普遍的反模式导致大家注重合规性,而不是创新,消除浪费和交付价值。如果不关心底层系统的改进,任何认证改进都毫无效果而流于表面。大型调研表示,CMMI是生产率最不重要的因素之一。最重要的因素是开发人员的能力,这就反映了人员高于过程的敏捷价值观。
当花大力气把CMMI提升到5级后的团队,转为采用Scrum后,各种类型的工作效能提高了一倍。至于CMMI和Scrum等敏捷框架是否能够一起在团队中使用,取长补短,业界暂时没有能证实的案例。
CMM最差之处,是粉饰模糊了软件工程的真正动态,压制了其他可选的模型,容易导致软件公司竞争潜力的崩溃。CMM哲学的流行,是因为给管理层希望和控制的幻觉,提供了一个循序渐进的计划完成明确的事情。CMM强调可重复的确定过程,不适合天生无重复性的面向学习的创造性领域。
CMM的价值观把过程看成最重要的永久因素,把人员当成临时因素给机械化了,这和敏捷价值观是完全违背的。
CMMI并没有正式的理论基础,也没有得到所有专家的广泛接受。它只是基于某些专家的价值观,他们有传统军事软件的开发背景。CMMI模型的假设是存在一个“最佳实践”,这和“泰勒主义”一脉相承,如果人们见过了最佳方法,那为何还要努力改变现状呢?
“有毒”的CMMI咨询师会把瀑布开发,大批量移交,繁重手册驱动和崇拜式合规仪式,作为CMMI的要求来宣导,真相并非如此。
如果你必须用CMMI模式来赢得政府合同,那就探索尽可能简单的实践方式,比如利用拍照和录音。
敏捷第一原则告诉我们,个人和互动高于过程和工具,人们会为了奖赏而和系统博弈。不管规范上如何写,只要对实际工作中的员工有用,那就继续实践并改进它,否则就不要做。
《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。