建议拟升版的GJB5000B在二级成熟度优先安排工程类实践域

逍遥302 2017-09-10

展开全文

CMMI将与时俱进由v1.3升版到v2.0， GJB5000A(对应CMMI v1.2)也将升版到GJB5000B，升版过程必然会对标CMMI v2.0。笔者建议，GJB5000B在成熟度实践域安排上，不宜沿袭CMMI和GJB5000A既有的做法在二级成熟度安排项目管理和支持过程域（项目策划、项目监控、供方协议管理、需求管理、配置管理、测量与分析、过程和产品质量保证），而应优先安排工程类实践域（按CMMI2.0的术语和划分，含：需求开发和管理、技术解决、产品集成、同行评审、验证和确认）。

提这个建议的理由是什么呢？

一、工程类实践域是核心的，而项目管理和支持类实践域是附属的

1.始终不能脱离产品谈流程，产出软件产品的核心是研发工作，软件项目第一个层次要解决的问题是业务和技术正确，然后才是管理和支持。而且软件项目的问题首先是技术过程问题，其次才是管理问题。

2.为什么过程核心应该是工程而非管理？因为装备产品要的核心是软件产品，工程过程实践直接研发出软件产品，因此工程是核心。要保证把一个和多个项目做好，工程是首先的，而非管理、支持或统计过程。

3.CMMI是在把传统工业领域的全面质量管理方法过程引入软件领域而产生的，传统工业领域主要的任务是批量生产，项目管理和支持更重要。但软件主要解决的是单次的研发，因此面向研发的工程过程就更重要了。

二、工程类实践域比项目管理和支持类实践域更重要

1.以需求工程为例。需求决定方向对错。在高质量软件项目中，需求工程的作用举足轻重。统计表明，软件缺陷一半以上的原因来自于需求分析中的问题。仅凭这个数字，就足以告诉我们提升需求开发水平是多么重要，这正是在软件项目中，我们需要对需求分析下功夫的最大原因。也是首先要提振工程过程的原因。

2.再以设计为例。软件是复用率最高的行业，优秀的软件设计远比管理流程上的没日没夜更高效。大量成功的产品，并非管理流程的产物，而是需求创意和设计迭代的产物。软件设计人员是软件企业新产品、新技术体系的构建者，是目前软件开发中急需的高层次技术人才。其重要性也高于项目管理和支持。

3.做不好研发，业务目标就是空中楼阁。要反思我们打造流程的目的、意义和方法，切实以高效产出为核心。

那么CMMI出现这个核心偏离错误的原因是什么呢？

笔者的看法有二。

1.起初在把传统工业领域的全面质量管理方法过程引入软件领域时，CMMI编写者里做项目管理、过程管理和质量管理的人占了上风，而且认为软件项目的问题主要就是管理问题。但这是认知上的偏见。因为软件自身特点与很多传统流程工业并不相同。

2.不排除美国人后来也知道这个问题，但故意设置了战略欺骗陷阱，以误导超过十年以来CMMI应用量遥居世界第一的中国软件业。（门轩庭注）

为什么CMMI有这样的问题，却表现得并不明显。可放在GJB5000A，问题就变突出了呢？

原因一：美国的工程基础普遍较好，可以支持直接面向管理，走管理路径。国内装备业软件工程基础还有待夯实，不宜先抓管理支持。

原因二：在全球CMMI的应用中，以三级实施和评估为主，二级的量很少，这是因为大家纷纷觉得2级不够（只做管理支持也不够），就都直接做了3级（于是工程过程就做了，于是2级更像虚设）。而GJB5000A要求先做2级，使得工程薄弱的问题变明显了。

优先在二级实施项目管理和支持过程的弊端有哪些？

1.由于优先抓的方向错误，软件缺陷并未如预期般显著减少。

2.CMMI-DEV未以软件研发过程为核心和优先，二级成熟度安排项目管理和支持过程域。这使得软件企业做过程改进起步时搭建的基础与核心方向错误。这不仅影响实施二级的单位，也会一定程度影响实施三级的单位。因为这使得项目管理和支持变得优先，或者项目管理、支持、软件工程、过程管理4个板块容易平铺直叙，缺乏重点核心：软件工程。

3.软件研发过程既未成为核心，也未优先改进。又使项目管理和支持过程成了空架子和花拳绣腿，缺乏“灵魂支撑”，成了谁也不爱干的累赘活儿。

4.CMMI在二级成熟度等级的驱动力是项目管理、三级的驱动力是过程改进、四级的驱动力是定量管理、五级的驱动力是优化变革，所有成熟度等级的驱动力均不是本质的软件研发，属舍本逐末的方向性错误。

5.投入大，收效低，各实施单位负担重，效率低，拖累了装备中的软件研发。

支持GJB5000A的管理工具存在的普遍问题又是什么呢？

在配合GJB5000A要求时，配套的管理工具也优先提供了管理功能和支持功能。但往往弱化或没有提供工程功能，这也导致这些工具成了次要价值的设施，核心偏离，让项目人员不愿意坚持使用，或即便使用，价值也不明显。

优先在二级实施工程类实践的意义和价值会是什么？

1.所有军软过程改进收益更明显了，质量更有保障，装备效能提高，国防实力增强，国防安全等级提升明显，中国崛起加速，美国霸权衰落更快。

2.实施GJB5000A的人员劲头更足，心里的负担减轻，无谓的时间效率消耗大幅减少。

3.GJB5000A咨询师、评价员做得更有意义。

4.GJB5000A权力机构和人员升职效应更明显。

5.全国军品总节约量巨大，收益巨大，例如两千家、5万人负担减轻、效益提升。

6.CMMI并非可盲信盲从的标准，应该以此改进为起点，走出中国自己的标准。

CMMI和GJB5000A还存在什么问题，及相应的改进建议是什么？

以下举例列举部分模型问题。更多关于模型和评价方法的问题，另文阐述。

1.软件维护非常重要，CMMI-DEV却几乎没有直接涉及，未与软件研发统筹做改进，可能致使研发遗留的缺陷“拖累”维护，而投入在维护的资源消耗又削弱了研发实力，使研发和维护相互掣肘，进入恶性循环。（门轩庭注）

改进方案：

将cmmi-dev与svc融合做实施。另外吸纳DEVOPS，统筹维护和研发，设置过程域和实践。

2.产品集成过程域容易被理解为线性地或更多一次地组装了软件构件，导致复杂软件系统错漏百出。

改进方案：

将产品集成各实践明确调整成生成生长整体软件、持续集成，而非误以为的一次组装。

3.CMMI-DEV大量“正确”的实践却叠加成为错误的大“枷锁”体系。如显著增加的项目管理、过程审核、测量分析、配置管理、过程改进的工作量，使越来越多的非研发类专职岗位被增设。为了通过评估，增设临时和长期的文档记录编写员。这些显著增加了项目和企业的人力成本及负担。整齐的通用实践，让特定实践与过程域通用实践间的重叠重复增多。

改进方案：

删减价值不够大的特定实践和通用实践。给不同实践设置分值。不追求模型结构整齐，而是追求模型实用、高效。

4.CMMI-DEV中近四百条实践“平铺直叙”，初学者难以分辨哪些是软件企业要高优先级采用的。而且仅提及过程域间有相关，没有具体说明接口位置、目标实践间的关联。

改进方案：

给出实践的推荐分值，每次评估前可以根据企业情况做微调，在评估打分时，不同实践有不同权重。通常越核心的过程域实践，分值越高。

描述出各过程域、目标、实践的接口细节，让CMMI成为整体，而非散沙。

5.CMMI认为达到五级成熟度是“终极”目标，但处在一级的企业往往需要近五年或更久才能升到五级，这个过程中的“痛苦折磨”可能已让不少企业“精疲力竭”，而难尝“胜利果实”

改进方案：

在经过上述改进后，二级的软件工程研发即核心，企业按需升级。定量优化不再是终极目标。

6.模型是基于系统工程，而非完全针对软件工程写成。文本中解释补充性文字常常不知所云、言而无物、废话连篇。

改进方案：

删减、写直白明白、与软件研发密切挂钩，真举实例，而非举逻辑虚例。