CMMI V2.0丨Scrum 与 CMMI 指南：使用 CMMI 提高敏捷性能（二）——背景篇

新世纪初发生的两个相互独立的事件，彻底改变了软件和系统工程的面貌。

第一个事件是发布卡内基梅隆大学在软件CMM 方面早期工作的成熟成果——能力成熟度模型集成 (CMMI)。它引入更加广泛、更加全面的模型，采取以过程为中心的方法，使运营机构与运营目标一致，提高了组织性能和产品质量。CMMI 的初始版本面向多个工程学科，但它在软件方面的根基是不言而喻的，并且在产品的早期版本中占据主导地位。今天，我们拥有 CMMI 研究所的面向开发的 CMMI、面向服务的 CMMI、面向采购的CMMI、人力 CMM 以及数据管理成熟度模型。它们共同构成了一个平台，来提升整个价值链上的企业性能并密切配合软件与系统工程社区的需求。

第二个事件是发布敏捷宣言。与 CMMI 的基于实验研究的方法相比，《敏捷宣言》的缔约者倾向于通过协作找到共同点，同时信奉以人为本的核心价值观，以支持开发相互独立的新技术和方法。创始小组内的倡导者提出了很多敏捷开发方法，但如今最常被采用的方法是 Scrum 和极限编程 (XP)。早期采用者在早期，采用者的文化背景不同，造成美国国内对 CMMI 和敏捷之间的关系理解混乱。CMMI 与方法无关，无论是使用传统的工作管理方法（例如“瀑布式”），还是诸如Scrum、看板、关键链或螺旋之类的其他方法，都可用于提高组织性能。

在全球普及以及被业内很多大大小小的组织用作平台之前，CMMI 一开始被美国国防和航空行业使用。后来，商业领域的很多大型组织亦纷纷采用，包括自动化行业和含嵌入式系统的产品制造商。这些早期采用者运用 CMMI 来改善原有的传统的“瀑布式”运作模式以取得显著成效。这引起了一些混淆，甚至是在使用CMMI 规范现有实践的组织内。一般人开始会将 CMMI 误解为其他方法的替代方法，而不是一种灵活的模型，无论组织采用何种方法，它都可将方法与组织目标保持一致、弥合价值链中的差距，并建立持续改进的文化来提升组织的战略一致性和性能。

在软件开发的其他领域，敏捷运动开始蓬勃发展。被视为改善协作与充分利用个体优势以及个人责任（“高信任”）的一种途径，敏捷采用率在过去十年间呈指数增长，大部分用于纠正当时大多数软件开发组织所偏爱之传统方法的“低信任”特点。敏捷方法规避了“瀑布式”组织喜爱的许多传统事件和行为，选择放弃项目审计和传统衡量标准，例如，利用结构化行为代替小型团队中员工的生产效率和高技能团队协作。目前，最受欢迎的敏捷方法是 Scrum，这种协作方法用于管理强调固定时间箱短期迭代（“冲刺”）工作、所分配的小型、稳定团队、短期策划以及严格的对等责任。因此，我们所得出的结论是Scrum的早期采用者当中有很多是小型组织或大型组织中的小团队。极限编程  (“XP”) 是另外一种应用广泛的敏捷方法，它起源于一家公司内部，就是后来成为CMMI最大采用者之一的克莱斯勒汽车公司。

幸运的是，随着敏捷方法的应用日益广泛，不受CMMI和敏捷历史遗留文化预设所羁绊的组织，开始使用CMMI来克服敏捷实施中扩展性、一致性、透明性、适应性和性能方面的挑战。而已经使用CMMI的组织则用它来井然有序地实现敏捷转型，实现它们所追求的稳定性和动态能力。


参考文献：
A Guide to Scrum and CMMI®: Improving Agile Performance with CMMI
https://cmmiinstitute.com/resources?searchtext=%20ResourceType:%22report%22