从2002年开始接触国内军工所，2008年GJB5000A问世，这个基于CMMI1.2开发模型基础上建立的军用软件研制能力成熟度模型很快成了主导军品软件开发的指南。可以看到的是，这十年，无论从软件工程角度、质量控制角度、产品和项目规划管理角度国内军品开发都有了一个飞速提升。在软件质量意识、质量文化、过程文化等方面也有了很大改观。更为可喜的是，在推动5000A的历程中，各军工所培养了一批软件质量和过程方面的人才，为后续改进打造了一个坚实的基础。
如果我们拿国内实施5000A和CMMI做比较的话，不得不说，5000A做得更好！我认识不少5000A的主任评估员，他（她）们无论从经验、专业知识、沟通能力都可以和CMMI主任评估师PK。管理者对质量的认知及过程价值的认识也好于很多CMMI软件企业的sponsors。5000A评估的可信度更是远远大于CMMI的SCAMPI评估。CMMI 2.0评估方法中有些和5000A有类似之处。目前5000A面临向5000B升级，同时也开始准备接受四级评审，如果有一天5000在中国替代了CMMI我也不会感到惊讶。
这里我也想从几个方面探讨下5000A可以改进的地方。
5000A模型本身的不足
在“CMMI三十年”中我系统讲了CMMI的历史，上个世纪九十年代后期，在SEI准备将软件CMM升级到2.0版本时，DoD叫停了这项工作，要求SEI将精力投入到CMMI模型的建立上。因为DoD意识到，随着软件能力的提升，系统开发能力的提升，软件系统和其他系统的协调变得更加紧迫。CMMI不再是仅适用软件开发的模型，它可以用于系统产品开发。在这个前提下，CMMI纳入了一些来自于系统工程的实践，当将其用于纯软件开发场景时，需要清楚的理解这个差异。如PI（产品集成）这个过程域，其语言描述是站在系统角度的，就对纯软件场景造成了理解上的困难。PI讲的集成不能等价于软件常说的集成测试，对于软件开发来讲，我们必须把VER，VAL，和PI三个过程域放在一起规划管理，建立恰当的质量控制框架。
CMMI三十年（点击图片查看原文）
另一个模型本身的问题是其架构，当然这应归于CMMI 1.3和之前版本的不足。5000A的模型架构和CMMI 1.2 （或1.3）一样，不能支持及时融入新的优秀实践，任何局部变更可能会导致整个模型的修改。就架构而言，5000可以参考下CMMI 2.0的做法。
中国军工和美国军工的差异
CMMI 1.2周身散发着美国军工文化气息，从这点来讲，它确实值得5000A参考。但不能忽略中国军工和美国军工的差异，这些差异也会影响到模型的适用性。首先美国军工的管理模式基本都是以产品线为主导，和华为的模式很类似。其技术研发和产品研发的一体化能力非常强，人为造成的开发过程中的接力棒很少，能够有效管理数千人参与，跨领域，长周期的系统产品研制。而中国军工目前的机制则不然，一个大的研制产品开发会牵扯到多个所、工厂及其他机构。虽然一个集团人数众多，但一线资源总是不够，大量精力花在不必要的接力棒传递上。波音全球员工总数少于中航集团，但其产能远在中航集团之上。
另外美国军工文化和中国军工也有不小差异，如QA职能在美国军工是非常被认可的工作，军工客户也会支付其投入。换句话说，QA也可以赚钱的，其地位可想而知。而在中国军工体制下，质量保证如何做，需要找出一个符合中国军工文化特点的做法。
另一个显著的例子是同行评审，这个实践可以说是美国军工产品开发的一个增值亮点，这也是它一开始就出现在CMM中的原因。可是这个实践在中国军工成了群众演员混合饭，很少能看到通过评审能发现50%以上缺陷的单位。CMMI三级的美国军工组织往往可以发现80%以上的问题。也许5000A可以总结一下，摸索一套中国替代实践。顺便带一句，这个不足也会影响5000A高成熟度的实施。从我看到的来讲，接近百分之百的美国军工CMMI4级，5级组织都将同行评审纳入到量化管理体系中。
高成熟度过程域的问题
CMMI 1.2升级到1.3的最主要原因是源于高成熟度（4级和5级）过程域的问题，用当年SEI的话讲，“其描述让人很难理解，导致不同的评估师，不同的讲师会有不同的解释”。1.2发布后有近200个4级或5级评估，SEI的结论是大部分通过的企业都没有达到模型的要求。于是有了1.3，有了高成熟度主任评估师，有了三年严格的高成熟度评估稽核。而5000A的高成熟度过程域基本继承了CMMI 1.2，如果不注意，会出现十多年前同样的问题。
再议CMMI高成熟度的硬伤（点击图片查看原文）
而如何在复杂软件研制项目中有效实施量化管理，显然是个巨大的挑战。在我看来，CMMI也没有很好的解决这个问题。6西格玛有很多很好的东西，但盲目将其应用到需要创新的产品开发过程中，会造成很多问题。很想问一句，在众多引入了6西格玛的软件组织中，谁能有性价比高的成果可以拿出来分享？CMMI是经过验证的最佳（优秀）实践的集合，当年CMM的量化实践好像没有经过软件的验证吧？读过我前面文章的朋友都知道我是Humphrey的粉丝，但大师讲的不一定都是真理。也许代表中国软件开发制高点的军工组织，可以给出一套更有价值、更适用于研制软件开发的量化方法。
软件质量之父——Watts Humphrey（点击图片查看原文）
个别不正确的评估导向
正确把控模型要求和实施方法选择不是一件容易的事，军工软件也有许多不同的场景：系统级软件开发，嵌入式软件开发，不同产品阶段的软件开发，维护类软件开发，不同质量等级要求的软件开发等，很明显5000A的落地一定也是五彩缤纷的，不可能是单一色调。我接触的5000A评价员对此都有很好的理解，在评估时能考虑组织的约束条件，识别出危害风险的实践。但我也听说过个别过于僵化的评估，比如配置管理，一定要有什么基线，一定要做到什么程度，忽略了性价比，忽略了实践的目的，忽略了软件组织的特点。在CMMI 2.0中，配置管理成了唯一一个最高能做到2级的实践域，这就意味着，我们不一定强求组织的标准要求，让项目组可以根据自己的特点和需求实施配置管理，重要的是实现CM的目的和价值。
错误的评估导向往往导致错误的过程改进。
寄望于5000B
很高兴知道5000A也要做版本升级，我认为时机很好。希望能看到一个充满中国军工文化、特点、包含了最佳中国实践和适用于中国的实践的集合、具备可扩展性的模型。希望新版至少能够强化软件和系统及其他领域的接口管理（一步升级覆盖系统会有不少困难），希望新版能在高成熟度实施方面给出有创意的方法，希望新版突出强调价值驱动的改进、管理、决策，希望新版能够成为一个中国版的CMMI的标杆。
联系客服
