早在大学时期就对CMMI有所耳闻，作为软件工程里面有关项目管理的经典模型，其在我心目中一直是 “高大上”、“只可远观不可亵玩焉”的存在。2015年4月，本人有幸作为EPG（过程改进小组）成员参与公司CMMI3级认证的评定过程，经过前期准备、差距分析、制定改进计划、标准过程定义、试运行、制度化、预评估、正式评估八个阶段，公司终于通过了CMMI3认证，而CMMI这座高山，在一步步的触碰中变得清晰起来。
CMMI是什么？
CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型），1994年由美国国防部（United States Department ofDefense）与卡内基-梅隆大学（Carnegie-MellonUniversity）下的软件工程研究中心（Software Engineering Institute，SEISM）以及美国国防工业协会（National Defense IndustrialAssociation）共同开发和研制的，他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型，集成到一个框架中去，申请此认证的前提条件是该企业具有有效的软件企业认定证书。
其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。
其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
CMMI做什么？
CMMI简而言之，就是把软件开发划分为具有普遍意义的多个方面，如果每一个方面都做好了，那么整个软件开发也就做好了，我们把某个方面称为一个过程域，CMMI共分为5个级别，22个过程域（Process Area，PA）。
各个过程域在个体上相对独立，这样保证其低耦合、客观中立、易于分工、实现难度降低，不同的人负责不同的过程域，大家需要做的就是把自己负责的过程域做好。从全局来看各个过程域又是一个整体，互有关联，相互促进，最终服务于同一个目标。
过程域分项目级和组织级。项目级作为一个特定的实践，根据项目的特性选择不同的过程域，按照标准的逻辑顺序执行，确保各个过程域的达成，服务于项目目标的达成；组织级服务于整个研发组织，而不仅仅是一个特定的项目，包括制定方针政策、人才培养、监督管理、量化分析等方面，为各个项目提供人才支持、技术支持、数据支持、工具支持。
CMMI能带来什么
CMMI不是公理定律，而是方法论，它告诉我们一种解决问题的思路和做事的方式方法，其不仅仅可以应用在软件开发的过程中，更可以应用在我们生活中的方方面面，比如吃饭。
作为新人的“小菜”，今天接到领导分配的一个任务，近期举办一次重要的部门聚餐。
接到任务的“小菜”有点懵，不知道如何下手，于是去请教在公司工作多年的“老鸟”。
“老鸟”说：“新人要多思考，你先告诉一下我你的思路。”
“小菜”想了一会，回答说：“先提前订桌，然后通知大家聚餐，到时候提醒大家一起过去吃饭。”（CMMI一级）。
“老鸟”听了后，说：“能想到提前订桌，已经不错了，但是有些问题你没有考虑：
1）大家想吃什么？（需求管理）；
2）领导的期望是什么？预算多少？（需求管理）
3）酒水需不需要另买？（供应商管理）；
4）有多少人去？（度量分析）；
5）大家忘了怎么办？（项目计划与进度监控）。”
“小菜”觉得很有道理，重重的点了下头。
“老鸟”接着说：“你回去再好好考虑考虑，列个计划出来给我看看。”
“小菜”回到座位，好好想了一会，开始列计划（CMMI二级）：
1）需求管理、需求开发：了解领导聚餐的目的和想法，了解大家的口味，了解部门预算有多少？
2）项目计划：制定组织活动的计划。
3）供应商管理：安排人进行酒水外购。
4）度量分析：了解以前类似活动的预算和安排，作为本次活动制定的参考。
5）项目监控：关键节点检查，看准备是否就绪。
6）技术方案：选择不同方案供选择。
7）配置管理：过程中文档输出，尤其是花销记录，有据可查。
8）质量保证：随时向老鸟请教，保证活动顺利开展。
当“小菜”将新的方案放在老鸟的桌上时，“老鸟”满意的点点头，“小菜，比上次好多了，就照此执行吧，过程中注意风险，有事向我汇报（风险管理）。”“老鸟”夸奖道。
活动结束了，领导很满意，活动场地环境好、口味很地道，大家玩的很嗨、很尽兴，整个活动期间气氛很好，达到了团结激励的作用，最重要的花钱还少，正所谓花小钱办大事。
回到公司以后，领导特地把“小菜”叫到办公室询问活动组织情况，听完“小菜”的汇报后，领导觉得很好，指示“小菜”说：“小菜，你回去对这次活动做个总结梳理，制定个组织活动模板，以后部门活动组织就按照你这个套路来（组织过程焦点和组织过程定义），模板出来后给大家讲讲（组织培训）。”
一周后，“小菜”制定的活动组织模板经过领导、“老鸟”等人的同意后（专家评审），正式发布（CMMI三级），从此部门组织重要活动有章可循，“小菜”也因为这件事受到领导表扬奖励。
结束语
CMMI是一个逻辑结构很强的整体性框架，囊括了软件开发过程中的方方面面，有效降低了企业软件研发风险。但也因为其庞大的体系要求，并不一定完全符合小公司、小团队的项目管理需要，完全复制使用无疑是灾难性的，更多的需要结合公司实际情况灵活应用。
移动互联网的快速发展，一种倡导“快速迭代、快速交付、重编码、轻文档、客户参与”新的软件开发模型迅速兴起，CMMI也准备在新的版本制度中适应这种变化。总之任何一种外来文化制度的使用，都要经历本土化过程，同时在使用过程中与时俱进、不断发展，这就类似“马克思主义”在中国本土化产生了“毛泽东思想”，与时俱进产生了“邓小平理论”。但是经典就是经典，其软件工程的思想和思考问题的方式方法，永远不会过时。
在公司CMMI三级通过评定的总结会上，就CMMI后续改进的建议中我提了两点：
1）充实样例库，现在虽然制度有了，但是能写好的人并不多，这一方面有待组织培训，更重要的是在执行过程中发现优秀案例，纳入样例库分享，大家依葫芦画瓢。切忌为了写文档而写文档，白白增加了研发人员的负担。
2）作为EPG（过程改进小组）团队，对外实时了解最新软件工程管理的思想，对内多往下走，去了解具体制度执行人员的真实想法，进而去优化我们的制度，保证对外不落伍，对内可落地。
（本资讯于2016-07-21首次发布）
