CMMI 与敏捷 DevOps

本文主要是介绍CMMI 与敏捷 DevOps，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前几天一位杭州总监级朋友说，最近Devops很火，给我发了一篇《CMMI 和 DevOps新旧时代的图腾辨识》微信文章。

我从事CMMI的评估、培训已经10多年,过去5年也开始学习敏捷—— PMI的 Agile Certified Practitioner (ACP), 也教过两三年的ACP课。

我看完这篇微信文章的第一感觉是: 从事CMMI的人真要自我反省，在市场的宣传、培训方面做得不好，导致很多人对CMMI有误解。

虽然我对DevOps不是很熟悉，但了解它是因为敏捷开发使得越来越多团队在用，触发需要有一系列的自动化工具(DevOps Tool Chain)，使集成与发布可以更快速、更自动。（也有一些CMMI客户开始使用这些自动化工具）。

常见误解

学生问:"如果我们用敏捷做项目,是否就不适合用CMMI来评估？因为CMMI好像需要填写很多文档，而敏捷却鼓励尽量少文档。”

我回应说：“恰恰相反。4年前，CMMI研究院发布了一个调查，在使用CMMI模型来评估的公司中，有超过70%是有使用敏捷，说明敏捷项目在使用CMMI的公司中很常见，不会不合适。为什么很多人误解CMMI是等同于填写大量文档？原因之一是，很多公司缺乏信息化系统，为了准备CMMI所需要的证据，没办法，只可以依赖填一些模板来实现要求，如果公司使用敏捷+DevOps ,用大量的自动化集成工具，对应很多 CMMI实践 (practices) 可以直接从工具上的报告截图，来满足CMMI的要求。”

比如很多公司用JENKINS来做自动化集成，就不需要填很多集成测试报告来满足CMMI的产品集成(PI Product Integration) 部分，这些工具也可以帮助定义集成的进入条件—— 自动跑对应单元测试，比手工跑好得多。

很多人把CMMI等同于传统的瀑布性开发。

我们在美国十几年前参加CMMI培训时，老师都会以3种的场景教我们CMMI的实践，包括军方要求 (最严谨)，整个工作任务分解 (WBS Work Breakdown Structure)便要做得很细，另外一边是敏捷的场景，（当时敏捷已经有十多年二十年历史）以工作任务分解为例，可能很简单在白板上写下、拍照，也可以达到工作任务分解的目的，所以我们常说CMMI只是把最常用、最通用的抽出，什么情况用什么方法，依据的事特定的场景需要，所以千万不要以为CMMI是个过程、流程，有个CMMI过程。

很多做软件开发的都对敏捷有兴趣，所以在我们的 CMMI V2.0 解读系列中，每一篇都会包括敏捷的章节，如果在敏捷场景如何解读CMMI实践的要求。

教CMMI时，学生问：“是否可以拿CMMI模型书回去当公司的过程吗？”

我说不可以，因为它只是个面面俱全的框架，不是某个特定过程，只是公司可以依据实际情况，利用模型制定过程，评审公司的过程是否漏掉了一些必备的元素。

还有很多人误解CMMI局限在研发、软件工程，虽然CMMI源自针对软件工程的改进，因为开始的时候，很多软件过程做得不好，导致超支，甚至被取消，所以开始发展出这个模型来帮软件公司进行改善，当时叫CMM，后来发现发现很多成熟度模型的原则可以通用，便扩大到系统工程、硬件上便是现在的CMMI。

相反的是，很多敏捷的方式都是集中在项目级，缺乏从项目级扩大到公司级的做法，它不像CMMI从一开始就有公司级的概念，可按照不同的项目需要定义过程的裁剪。

另外一个对敏捷的误解:

因为敏捷很多人在用，很多管理者以为敏捷就是一个万用的良药，什么都能帮上。在有效项目管理一书中(是ACP 的参考书），作者便详细列出什么样的项目适合什么样的方法 - 从传统(Traditional) 到敏捷(Agile) 到极限(Extreme)。（详见附件)

当我做敏捷培训时，会多次强调不是所有项目都适用敏捷：

1. 需要一个很有能力的团队——成员要面面俱全，能够兼顾很多方面，才能给客户更多的价值，反之，如果成员是刚毕业、没经验，没有规范可循，反而一团糟，这就是有些团队推敏捷几个月就告吹的原因。

2. 客户需要频繁参与整个开发。为什么团队可以有价值，在每个冲刺后，一直收到产品经理、业务部的反馈，如果没有这样，就达不到预计效果。

3. (与所有过程改进的必要条件一样)需要领导的支持 ——领导要有让团队发挥自己最大力量的胸怀，给他们独立空间，尽量支持团队做好，发挥最大效果，而不是家长式管理。

解读文中的一些误解

1、

原文： ......CMMI与DevOps是在不同的历史条件和技术背景下产生的，代表两种不同的开发文化，当然CMMI经历几十年的发展，被IT企业广泛接收并广泛应用。CMMI其实ISO标准一脉相承，其本质是软件管理工程的一个部分......

解读： CMMI 与 ISO （9000）的主要共同点是•过程改进，CMMI（ CMM）是最早源自软件工程的过程改进，但 ISO是为通用各行业设计（后面再细分到个别行业，例如汽车、IT等）

2、

原文： CMMI...其核心是软件过程改进，指导思想是：依赖一个严谨的过程标准管理体系，并能有效执行与过程控制，才能保证可持续地交付合格产品，且整个过程可重复、可度量、可审计。因此，CMMI的关注的重点是：软件过程改进，提升软件质量......

解读：误解CMMI是一套过程标准管理 - 不对。它是一个框架，所以才可以都不同的项目需要，配上不同的过程例如：需求不明确的项目应用敏捷管理；需求明确的合同项目采用传统瀑布式

3、

原文： 2000年左右，软件行业的主要工作是交付客户定制的软件应用，而软件研发团队被推荐使用像 CMM/CMMI、RUP 这样的大型方法论来组织生产，这些大型方法论效果并不理想，一方面甲乙双方在需求变更上的扯皮不是影响交付日期就是交付后的产品不能真正解决客户的问题，另一方面研发团队又需要花费大量精力在准备流程需要的文档上面。人们越来越意识到传统意义上的开发与运维之间存在脱节现象,从而导致冲突和低效,于是 DevOps 应运而生。

解读：作者可能把 DevOps 与敏捷 (Agile) 混淆了。因 DevOps 一词是 2009才出来（源自比利时一次以DevOpsDays 为名的会议）以上说的应是 2000 Agile Manifesto （在美国犹他州盐湖城）的背景。

4、

原文： CMMI更多的是软件工程管理框架，核心过程域包括：组织管理、项目管理、工程管理和支持管理过程，研发过程管理只是工程管理中的一部分。

解读：对CMMI理解有误，研发过程管理不只是工程管理中的一部分。例如，支持里的配置管理也是每个研发过程管理必备的一部分。

5、

原文：但企业实践中还是以传统为主，特别是对针对于规模化复杂业务、中后台系统、对质量要求高（缺陷零容忍）的核心系统、账务类系统的开发，质量的重要性远高于效率，主要以CMMI体系的强管控为主。 DevOps成长在敏捷文化之下，其应用场景以敏态为主。

解读：很多人还是把 CMMI等同与传统瀑布式开发，这点 CMMI几年前（还是SEI时代）已经说明 – CMMI是一个模型框架，包括敏捷 / 或传统瀑布式，按项目需要。

原文： DevOps模式下，更需要的是全能型团队，需求的是能力互补的T型人才，有助于生产协作。

解读：这也是一般敏捷团队的要求，却正是这原因，不是每一个团队都合适

用敏捷。

Reference 参考：

Reference: SEI 文章 "CMMI vs Agile – why embrace both"