如何理解IPD+CMMI+Scrum一体化研发管理解决方案之CMMI篇

CMM/CMMI的历史

信息时代，软件质量的重要性越来越为人们所认识。软件管理工程引起广泛注意源于20世纪70年代中期。当时美国国防部立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论：管理是影响软件研发项目全局的因素。1987年，美国卡内基.梅隆大学软件研究所（SEI）受美国国防部的委托，率先在软件行业提出了软件过程成熟度模型（CMM），随后在全世界推广实施，用于评价软件承包能力并帮助其改善软件质量的方法。

CMM发布后，不但在单纯软件行业得到很好的实践，同时在系统工程领域、硬件领域、集成产品开发领域也有很大的借鉴价值，当年华为印度所推行CMM后，将软件CMM的方法嫁接到硬件项目开发管理中，形成了HW-CMM就是一个很好的例证。为此SEI推出CMM的升级版本CMMI，从而支撑更多领域的开发管理规范化。

CMMI的核心思想

CMMI，全称为“过程能力成熟度模型集成”，核心目的是用于衡量和改善组织过程能力的，虽然强调“人+技术+流程”三个方面共同决定开发项目的成败，而实际CMMI实施更多还是关注流程，强调过程规范性，最终达到保证开发交付质量的目的，CMMI的核心思想为如下2个方面：

1、过程质量决定交付质量。CMMI将开发活动划分为22个过程域（PA），每一个过程域是关注研发项目中某个方面（PA），并且在CMMI标准中也定义和相应的工具方法，例如需求跟踪矩阵（RTM），强调组织只要严格按照规范化的过程去开发，开发最终交付的质量应该是可以保证的。

2、组织能力需要持续改进。CMMI将组织的研发能力划分为5个等级，每个等级有详细的标准，建议组织根据自身能力、实际商业需要、组织资源多少灵活决定组织优化改进的目标。这一点本人深有感受，完全没有必要看别人已经过CMMI L5了，自己就着急，也要搞什么4级、5级，作为系统产品（涵盖软件、硬件、结构）的产品化公司，达到CMMI L3就完全够用了。

CMMI的4类管理领域

CMMI将开发活动划分为22个过程域（PA），同时这22个PA分别隶属4大管理领域，分别为：项目管理、流程管理、工程管理、支撑管理，而与产品开发组密切相关的主要是项目管理、工程管理、支撑管理三个领域：

项目管理：本质没有脱离PMI标准的项目管理体系，例如项目策划、项目跟踪与控制、风险管理、供应协议管理这些内容在PMBOOK中都有详细的定义，所以可以理解为CMMI的项目管理是MiniPM，偏向开发化的PM。

流程管理：流程管理描述的也是非常通用化的流程优化与改进的方法，识别组织流程改进点，然后召集团队进行未来业务流程设计，全面推行前先试点，试点后修正，确保没有大的风险后，再全面推行，所以CMMI的流程管理没有脱离业界流程改进、流程优化的范畴，说实话没有什么神秘的，这些方法早在上个世纪80年代，在制造行业都已经普及了。

工程管理：不同行业的工程技术方法存在比较大差异，虽然都叫软件编程，C语言与Java就有很大的差别，都叫可靠性设计，汽车行业与手机行业的差异也是显而易见的，所以CMMI针对工程管理只是定义最通用的方法，例如需求收集的方法就给推荐了一堆，什么访谈法、头脑风暴法、市场调研法、原型测试法、业务分析、Usecase法、逆向工程法、客户满意度调查法等，基本涵盖了人类可以想到的所有方法，而每种方法该如何做呢？哪个方法适合呢？CMMI没有告诉你，自己去修炼吧！所以针对工程管理，本人感觉CMMI定义的比较粗浅，只告诉做什么，但怎么做，几乎没有说明。

支撑管理：个人认为支撑管理领域是CMMI 4个领域中定义最具有可操作性、最完备的部分，由此可以推测，估计当时CMMI定义小组，大部分成员是质量管理人员，尤其配置管理、度量和分析、质量保证定义的非常不错，能给实施CMMI的公司以非常具体的指导。

CMMI的局限性

从CMM/CMMI的出生就决定了CMMI作为研发管理体系的局限性，美国国防部为确保外部开发机构交付产品的质量，而资助SEI形成CMMI开发管理体系，所以CMMI的核心局限有2点：

1）本身不谈如何赚钱的问题。作为美国国防部的外包方往往有充足的人员、资金、时间来从事产品研发；同时只要确保质量、按时交付，至于交付后产品怎么卖、怎么盈利不用关心，所以CMMI通篇规范几乎没有涉及竞争分析、财务分析、市场分析、上市推广；同时对产品的量产交付能力、量产采购供应风险也基本没有考虑，如果是产品化公司，单纯靠CMMI就很难确保市场成功，往往会进入为了流程而流程、为了量化而量化、为了质量而质量，这样的境地是非常危险的。

2） 更多关注的是开发活动，没有将产品开发上升为涉及多个业务领域的系统工程。作为一个成功的产品往往涉及策划、实现、运营；及时在实现阶段也需要涉及市场调研、竞争分析、可制造性、可服务性、制造策略定义、服务策略定义，同时研发时，要充分考虑批量交付的可行性；CMMI针对研发项目团队的定义也更多局限在技术层次，如何让市场部门、采购部门、制造部门等相关领域的人员有效参与到产品开发并承担责任，CMMI没有明确的解决办法，没有设计一个贯穿整个产品生命周期的团队和角色存在，也没有横向交叉管理机构，而整个产品开发被分成一节一节的“封闭车厢”，这样往往导致局部最优，整体不优的结果。

 

IPD与CMMI的差异

IPD与CMMI起源和出发点的不同，决定了两者具有很大的区别。

1） 管理层面不一样

IPD是企业层面的一套产品开发管理的思想、模式和方法，本质上是一种产品经营管理的模式。CMMI是面向研发的，而且更多是面向软件、硬件、结构模块级开发的。

2） 思想高度不一样

两者目的的不同也导致了思想的不同。IPD是从投资、竞争、经营层次看待产品开发；CMMI主要倡导通过过程和活动来保证质量，更多是从过程、操作、实现方法层次出发。

3）管理的范围不一样

IPD对所有的产品开发活动进行管理，横向上涉及市场、设计、测试、试制、制造、采购、服务、销售、财务各功能部门在产品开发中的活动，纵向上涉及决策、管理、执行三个层面。而CMMI主要是面向研发部门的活动，如软件开发、系统集成、项目管理等。对于软硬件相结合的高科技产品而言，软件开发的工作量往往占整个开发工作量的50－60％，而硬件开发又可能占到15－20％，所以CMM可以管到50－60％的开发活动，而CMMI可以管到65－80％的开发活动。

4） 关注重点不一样

IPD不仅关注把事情做正确（do the things right），同时更关注做正确的事情（do the right things），所以IPD既强调执行的重要，也强调决策的重要。CMMI主要关注执行，即把事情做正确（do the things right），而且CMMI对如何执行好开发活动要求更规范、更细。

IPD与CMMI的融合一体化

作为研发高科技企业，不但要做正确的事情，同时还需要确保把事情做正确；IPD能有效帮助企业确保产品研发方向的正确性，强调市场驱动、投资回报，将市场、财务、竞争、技术有效融合为一体；CMMI强调规范化、精细化管理，落实为具体的计划、流程、制度、模板、控制方法，能帮助企业把事情做正确；所以企业需要构建IPD+CMMI融合一体化的研发管理体系。

IPD管得“宽”（从市场管理到产品开发，再到产品生命周期管理）、定位高（公司级的决策与开发组织与架构、公司级产品开发流程等）；而CMMI把流程分解为一个个关键过程域（KPA），相对离散地来定义流程的，在细节上力求更精更深。尽管IPD与CMMI有众多的不同，但就对具体流程和活动进行管理而言，两者所依据的原则、方法和实践是相通和一致的，所以我们可以形象地将IPD看作产品研发管理流程“十”字的“横”，将CMMI模型看作“十”字的“竖”，“IPD+CMMI”将是企业产品开发管理体系完美的“十”字组合，从而优化产品开发体系，规范产品开发流程。

案例分享：华为技术IPD+CMMI一体化研发管理体系

整体产品开发过程按照IPD来运作，从产品立项开始到量产发布结束，涵盖概念、计划、开发、验证、发布5个阶段，4个商业决策评审点，7个产品级技术评审点；TR2（技术评审2，总体方案+设计需求评审）后，产品划分为多个子系统、模块，每个子系统、模块进入相对独立的设计、实现、验证环节，这些工作就严格按照CMMI的规范要求进行；TR4（技术评审4，开发完成评审）后，CMMI过程结束，子系统、模块集成为整机，按照IPD的流程规范来执行；华为的产品开发过程可以概括为IPD-CMMI-IPD的过程。

后记

IPD确保方向的正确性，CMMI强调规范化、精细化管理，确保把事情做正确；在这个“快鱼吃慢鱼”的时代，如何加快开发与验证的速度？这就需要开发工作和测试工作能够并行展开，从而实现及时发现问题、及时修复、及时交付，实现降低质量成本，缩短开发周期，提升竞争优势的目的，这就需要借助敏捷开发的方法。