敏捷开发方法和CMMI最佳实践常常被认为是相互冲突、不可共存的，本文将通过CMMI和Agile的2个极端起源说起，探讨CMMI和敏捷之间的误解和真相，向大家展现CMMI和敏捷协同工作的价值。
对CMMI和敏捷的误解
导致人们认为CMMI和敏捷不可共存，主要有两个原因：
一是，CMMI和敏捷的早期采用者都是软件开发范例的极端例子。
CMMI来自于合同驱动的大型组织组成的市场，早期CMMI采用者一般是低信任度、高风险、合同驱动（更多的是政府承包合同）、大规模、任务关键型（如果失败，生命就会丧失，如武器、飞机、医疗设备）的开发系统，开发者和客户之间必须依靠合同关系，按标准交付产品，这样的系统拥有高度的管理监督需求。
敏捷来自于快速变化的小型组织组成的市场，从迭代、增量式开发发展而来。敏捷的早期采用者是小型快速开发的团队，开发者与客户、团队内部高度信任，通过高度的人员互动来进行项目协作、频繁交付来应对市场需求的不稳定。这两种极端情况为接下来的一切定下基调。
二是，关于CMMI和敏捷的误用和不准确信息导致了两个阵营之间的误解。
误用：
关于CMMI的误用，比如把CMMI当作标准，把过程域实践当成流程、程序；再或者组织急于证明达到了某种级别的成熟度水平（等级评估），忽视CMMI是通过持续改进以提高组织级过程能力的本质。因此，一方面，施加错误的标准流程和裁剪准则，而导致标准流程可能过度规定，进而过度限制项目，最终阻碍了项目的成功。另一方面，裁剪准则可能不允许项目具有定制标准流程以满足项目特定需求和优先事项所需的灵活性。这种误用，为CMMI批评者指责CMMI提供了理由。
关于敏捷的误用，比如把敏捷宣言中提到的4条价值观解读为敏捷不需要流程、不需要文档、不需要计划，不需要记录他们的工作，这种解释也给敏捷批评者抨击敏捷“散漫无纪律”提供了理由。
缺乏准确的信息
敏捷社区中缺乏对CMMI准确的信息，CMMI社区中缺乏对敏捷的准确信息。比如，术语困难。在CMMI中使用的术语(例如，原则，质量保证和可预测性)和敏捷中的术语(例如，持续集成、测试驱动开发和集体代码所有权)，都带有各自的上下文相关的含义，因此很容易被误解和滥用。
有这样的困难放在我们面前，我们更应该探究CMMI和敏捷的本质，然后会发现这些不相容并不存在。当两者被适当正确的使用时，可以极大地改善组织性能。
CMMI与敏捷真相
CMMI以流程管理为中心主题，是一种模型，而不是过程标准。CMMI模型为制定组织流程提供了框架、指南，CMMI模型并非流程或流程描述。组织所需要的实际流程取决于很多因素，如应用领域、组织架构、规模等。因此在制定组织流程时不能把组织流程与CMMI过程域、过程实践进行一一对应。CMMI中的实践不是组织标准过程中的步骤，也不是在特定业务过程中必然发生的活动。CMMI中所列举的典型工作产品清单，不是过程输出必需的清单，也不排斥其他可能的过程输出。CMMI是一个模型，我们需要学习并与实际情况结合去改进一个组织的过程，提高组织过程能力。
我们在接受敏捷概念时，除了关注其中的4条价值观，如下：
还应该理解敏捷宣言的最后一条：尽管右项有其价值，我们更重视左项的价值。我们选择左边的价值，但不是忽视右边的价值。“敏捷没有文档”，“敏捷没有流程”，“瀑布和敏捷势不两立”都是不正确的认识。当敏捷中缺乏流程、缺乏计划时，敏捷是不成功的。在敏捷环境中，我们会根据敏捷特点，结合项目情况，用和传统开发环境中不同的活动形式来达成CMMI目标。如敏捷中有高层的发布计划、迭代初的迭代计划，以及每日站会中对计划的及时跟踪和调整。再如敏捷中对风险的管理是通过小周期迭代，尽早交付，及时反馈来进行风险缓解的。
CMMI和敏捷都不能解决的问题
CMMI认为组织改进业务的关注点应集中在3个重要方面：流程、技术、人。
CMMI毫不掩饰地重点关注流程，并通过过程将流程、技术、人协调起来，为组织提供必需的基础与稳定性，来最大化人们的生产力，并运用技术赢得竞争优势。同时，敏捷明确关注人，并允许人来确定技术和流程。但是，不管是CMMI还是敏捷的关注点，都不能完全防止简单的人为错误，关键人员的离职，不合格人员的影响，主动或被动的不服从或者故意破坏，也不能阻止员工个人生活对其工作表现的影响。不管是CMMI还是敏捷都可以有机制来捕捉和管理这些问题，但是并不能阻止这些问题。
CMMI或敏捷能够帮助建立高质量的过程和实践，有助于项目成功的达成，但是影响项目成功的因素方方面面，包括组织使用其他模型中的实践等，都会对软件开发产生影响。因此，CMMI和敏捷并不是解决产品开发一切问题的灵丹妙药。
SCAMPI（CMMI评估方法）中如何更有效地识别和接受敏捷，未来需要有更多的文档资料说明，如一本针对敏捷实施实践如何达成CMMI过程域目标的指导书。
CMMI和敏捷的误用，以及对实施CMMI或敏捷不切实际的期望，不合理的实施方式，如组织只是强制性的要求实施CMMI或敏捷，改进目标不明确，缺乏变革相适应的组织文化，此种种状况是CMMI和敏捷都不能立即解决的。
总结
CMMI是一个成熟度模型，为企业级过程改进提供框架，敏捷是一种理念、一种思想，二者关注点不同，但是互有助益。CMMI提供了在大型高风险项目中经常需要的系统工程实践，CMMI还提供了过程管理和支持实践，如CMMI相关的流程定义、度量、反馈、培训和改进机制，帮助组织敏捷方法的部署、实施、改进。敏捷提供了特别适合小项目团队的软件开发方法，如Scrum、XP。敏捷还提供了很多优秀的开发实践，如持续集成、站立会议、结对编程、TDD等。
在仍然遵循敏捷原则的情况下，一些敏捷方法的伸缩性限制还没有被克服。对于地理或组织分散的大型项目团队来说，敏捷原则存在一定的挑战性。大项目团队跨越距离、时间的交流必然比面对面、实时、动态的交流更慢、花费更多的投入。针对此种情况，敏捷中的Scrum允许“Scrums of Scrums”（即，将大型项目团队拆解成多个协作式的Scrum团队），但是这种方法仍然需要项目团队有很强的凝聚力以及团队协作，这种大型团队的复杂性对管理提出了更多的需求。在此种背景下，部分组织误用CMMI，制定繁琐流程，出现以牺牲生产力为代价的不平衡的生产，忽视了敏捷方法“帷幕”后，真正关注项目工作是否敏捷的本质。这是流程改进中过度工程的一个常见问题。
在选择CMMI的同时遵循敏捷原则，可以制定出更适当的流程活动。此外，将CMMI目标整合到敏捷团队的项目活动中，可以让这些团队有更成熟的过程能力。在采用敏捷方法的CMMI组织中，要保持对敏捷原则的忠诚，从而达到产品开发过程中的精益和高度信任。
理解并接受CMMI和敏捷之间的差异，并探索另一方的优势，去寻找合适的方法将两者结合起来，我们将能把改进提到一个新高度。要做到这一点，我们需要深刻理解CMMI或敏捷本质、原则、技术等，并将这些内容根据实际情况应用到实际工作中。
参考文献：
[1]TECHNICAL NOTE CMU/SEI-2008-TN-003: CMMI or Agile:Why Not Embrace Both!
先做起来
在过程体系建设方面，我们经历了先做顶层设计的野蛮过级，对照顶层设计，会发现我们有很多问题。是我们错了还是顶层设计错了？其实都没错，只是理想和现实不一致。改理想还是改现实呢？当然都要改，但是以现实为基础先做起来，才是根本。因为理想再改还是理想，而现实可以通往理想！
党的十九大报告中明确指出“坚持在发展中保障和改善民生”。发展中的问题只能在发展中解决。问题解决不可能一蹴而就，过程改进亦然。本来就是先有过程然后才有过程改进，所以做起来是根本，纸上谈兵，永远得不到真正的问题，永远不会有大的进步，也永远不会有质量的提升。先做起来，关注产出，在过程中分析一个问题，解决一个问题，就是进步！做的越多，迭代的越快，进步才会越快！
