近年来敏捷逐渐演变为一个热门词汇，越来越多的组织和个人从观望敏捷，到开始接受和实践敏捷，敏捷的布道者们功不可没。但同时我也感受到一种氛围，有人觉得CMMi是一种过时的理论，拥抱敏捷而排斥CMMi。
首先，不管什么理论，到了实践的层面，各种操作总会五花八门，这其中“人”很关键。其次，各种理论本身也在演进，如今的敏捷已比当初丰富了许多，CMMi本身也在不断推陈出新，拥抱敏捷。
关于CMMi和敏捷的对比，业界已经有了很多文章探讨，参考任甲林老师的文章（文末有链接），了解和接受这些背景是我们继续探讨的基础：
1. 背景差异：CMMi最早是由美国卡耐基梅陇大学的软件工程学院，借助Watt Humphrey一生在IBM工作践行的软件开发、过程改进与质量提升理论与实践的基础上编制而来；它是用于帮助美国军方挑选和评估软件以及系统集成供应商的软件开发与服务水平的一套标准。而敏捷的诞生是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高研发效率和响应能力。（两者的出身一定程度上决定了其要解决什么问题，说某某是万能那是不可能的）
2. 理论层次的差异：CMMi是一个模型，而不是一种方法或者固定的实践，它强调的是要什么（What to do）。而敏捷却以实践见长，为人所熟知的就是Scrum或XP等方法论，他们更多的是告诉团队怎么做（How to do）。敏捷囊括了众多种方法论，有敏捷价值观和原则，个人觉得其理念比"怎么做"这层更高。
有人简单的把传统的瀑布式开发中的最佳实践简单的等同于CMMi，那是对CMMI模型的误解，如下图CMMi只对特定目标和通用目标有要求，而对实践这一层没有要求。为什么有人把CMMi等同于繁重的流程和无尽的文档？那说明是操作出问题了。
3. 要解决的问题：由于CMMi为了评估组织的开发能力成熟度，降低项目失败的可能性，以降低军方在挑选供应商的时候抓瞎的概率。所以CMMi的要求会大而全，面面俱到。而敏捷起源于团队，敏捷的诞生为了适应更快的价值交付，大而全从来跟敏捷扯不上关系。所以回归到他们产生的背景，才更容易理解他们更擅长解决什么问题。
4.对文档的重视程度：CMMi的每个过程域的目标在评估时，要从制品和访谈两个维度进行考察。但CMMi并没有要求文档一定要有多少个，一定要包含什么内容，一定要什么格式，一定有多么正式，只是有时候为了确保达到认证的目标，就会对文档做过多的要求，导致开发团队特别反感，所以从这点上来说要消除大家的误解，CMMi的工作者任重而道远。而敏捷强调可用的软件胜过复杂的文档，对可用软件的重视程度高于文档本身。其实这个矛盾可以通过工具有效缓解，我们后文会提到。
CMMi和敏捷在各自擅长的领域做着自己擅长的事情，但如今许多研发组织里，既需要CMMi来提升组织规范性，又需要通过敏捷迎合快速变化的市场需求，两者的碰撞必不可少。就如同当前的中美贸易冲突一样，这源于不同体系的不同的价值观，如何破？
2019年年初，我也是带着疑惑的加入了一个敏捷与CMMi L3过程改进的认证项目，经过近10个月的学习和实践，对CMMi有了更多的了解，如何符合CMMi要求的规范性，同时又通过敏捷帮助开发团队更快的交付价值？如何通过Scrum的活动快速满足CMMi的各种实践要求？哪些CMMI要求反过来又可以帮助规范Scrum活动？以下是一些个人感悟。
首先项目计划（万事预则立不预则废）
计划过程上来说：
CMMi要求先建立和维护项目计划的参数，并制定计划，包括工作内容的拆分（WBS），工作产品和任务属性的估算（规模估算）、基于规模估算的工作量和成本估算，具体进度表，要做计划评审，实施所需资源计划等。
敏捷Scrum的活动中有故事梳理会和冲刺计划会，这两个会议的产出物基本可以满足项目计划的要求。通常来说，在故事梳理会上，我们需要确定故事需求的优先级以及故事点，这个就是CMMi的建议的规模估算，它是后续工作量估算的基础。
冲刺计划会议上，通常需要确认下个冲刺的冲刺目标确认，把计划完成的条目拖入到相应的冲刺中；对任务的经办人进行一个预分配，由经办人确定具体的工作量是多少，比如3d；对完成进度有要求的，可以在故事或者任务上，设定一个计划截止日期；通过对比团队以往的速度图，了解团队的历史产能数据，作为新冲刺团队产能的基线；所有团队成员举手表决工作完成信心，以对冲刺目标达成一致意见和承诺，这也相当于冲刺计划的一个评审（PO和SM都要求与会）。
计划周期上来说：
Scrum团队一般是2周的冲刺计划，在SAFe的PI计划，最多也就2到3个月的预估，不会在项目初期就准备一个大而全计划。 当然CMMi也从没有要求在项目初期就建立一个长期的计划，并束之高阁。重要的不是计划，而是做计划这个活动本身，就像辩论的意义就在于辩论本身，而不是辩论的结论。
当然，以我个人经验，不管是一个项目一个Scrum开发团队，还是一个项目包含多个Scrum开发团队，一个中短期的计划（2~3个月）都是有必要的，这样给到团队一个目标，也给到相关干系人一定透明度。但这个计划一定不是承诺，所以这个计划一定是在不断修订与完善过程中的。
项目计划的元素：
CMMi对于项目计划的元素有较多的要求，比如计划应该包括项目风险的识别和管理计划，项目数据管理的计划，项目所需资源计划，项目集成计划，项目实施者的技能培养计划，干系人参与计划等方面。而敏捷中似乎对这些方面没有系统化的要求。
在一个规范化的项目里面，这些计划对团队都是有帮助的，他们是保障项目成功不可或缺的因素。其实在很多项目里，或多或少也有做，只是没有明示出来而已。比如，敏捷中建议培养一专多能的T型人才，这其实是对项目实施者的技能培养的计划。比如，故事梳理会和计划会议需要开发团队的PO参与，实际上也是对干系人参与计划的要求。比如，开发测试环境，开发测试人员，工具等在敏捷团队里也一定做了保障，否则开发活动是没办法开展的。比如，敏捷团队开展持续集成，对于集成频率，集成准入准出，集成失败修复是有要求的，这些实际上也是集成计划的重要元素。
所以，依我的个人经验，开发团队简单的建立一个管理文档，将这些支持性元素放置在里面，可能他无需录入事无巨细的录入到开发过程管理工具Jira里，也不需要频繁的关注和更新，但是它既能满足CMMi关键要素的要求，又能帮助到团队的规范化管理。
再来看看计划监控（不想失控就要控制）：
CMMi中项目监控过程域，要求对照项目计划实际进度的监控。比如：跟踪项目计划参数（规模，工作量，进度，成本等），跟踪承诺，跟踪风险，跟踪数据管理，跟踪干系人参与，跟踪项目进度，里程碑完成情况等等；一旦跟踪发现与计划发生偏差，就需要制定调整措施，并跟踪纠正措施直至关闭。
传统项目通常通过项目周报，月报等，进行监控和汇报，报告内会包含很大的信息量；相信没有工具的辅助，若全靠项目经理手工汇总，每周都要耗费数小时才能完成，而Scrum把项目融入到各种活动中和工具中，如每日站会、冲刺评审会、冲刺回顾会议，产品路线图、版本发布等活动，如电子看板、工时燃尽图、故事点燃尽图、版本燃尽图等工具。
每日站会：
在每日站立会上，需跟踪开发团队任务完成情况，对于有延期风险的工作制定风险缓解措施；对于已经发生的问题，可以创建相应的条目，在看板上监控直至完成；跟踪工时燃尽图和故事点燃尽图，来判断团队实际完成情况和理想完成情况的差距等。
冲刺评审会：
冲刺评审会通常主要为了向我们的产品负责人进行产品演示和验收，以便及时的调整产品方向。在我们的冲刺评审会上，结合CMMi的要求，我们融入了更多的有意义的评审项。比如：评审冲刺目标完成情况，测试缺陷解决情况，持续集成情况，人力资源投入情况等。
这样一份结构化的冲刺评审会议纪要模板重要的好处就是，可以有效的提醒我们的开发团队除了开发产品之外还需要关注的方方面面。比如：人力资源投入情况的汇总，可以帮助我们识别出计划的时间和实际完成时间有巨大差异的工作，以便我们回溯差异的原因。
冲刺回顾会：
CMMi要求监控并制定纠正措施，并跟踪到结束。我们可以在回顾纪要中，借助Confluence和Jira的联动功能直接创建Jira问题单，实时查看跟踪问题单的状态。
需求开发与管理：
CMMi要求开发用户需求（用户需求说明书），可以理解为敏捷中的史诗、特性及用户故事等，他们天然就从用户的角度描述需求；
CMMi要求开发产品需求（需求规格说明书），可以理解为为了满足客户需求，而分解出的各个模块的功能需求、非功能需求或使能需求。
CMMI要求挖掘干系人的需求、期望、约束及接口，并将这些需要转化为客户需求，可以理解为敏捷中对需求定义优先级，用户故事中验收的标准的描述，技术故事中对于接口的定义等。
CMMi要求要有操作概念与场景，可以理解为用户故事中梳理出来的用例（User case），可用give ...when....then来表达。
CMMi要求管理所有的需求变更，确保需求，计划和交付产品的一致性，采取纠正措施，维护需求与交付产品的可追溯性。可以理解在敏捷中，每次调整冲刺的范围，团队都需要讨论变更的需求影响是什么，是变动大小决定是否需要重新承诺；冲刺评审的时候，若发现冲刺目标没有完成，需要决定遗留的需求如何处理，产品的调整如何规划等。庆幸的是通过Jira以及配套的插件，我们可以很容易记录这些变更，以及导出需求的追踪矩阵等。
最后技术解决方案，验证与确认：
CMMi要做技术解决方案，就是所谓的设计与开发，可以通过敏捷中结对编程（Pair Programming）、测试驱动开发（TDD）、探针（Spike），重构（Refactor）等实践满足。
CMMi中要做验证，以确保我们交付的产品满足了既定的需求（Do the things Right），比如敏捷中的各种测试，如单元测试，集成测试，系统测试等，还有如各种评审活动也是验证的重要方式，如需求梳理中对于需求的评审，冲刺计划会对于冲刺计划的评审，冲刺评审对于交付成果的评审等。
CMMi中要做确认，以证明提供的产品能满足客户的预期(Do the Right thing)，确认活动采用与验证类似的方法（如测试、 分析、审查、演示、模拟）等，特点是由最终用户和其他相关干系人参与确认活动。可以理解为敏捷中的业务验收，以及用户手册，上线手册，培训手册等，虽然敏捷中要求简化文档，但是用户相关的文档必不可少。
其实只要做软件开发，针对需求、设计、开发、测试、发布，运营等工作，无论CMMi还是敏捷都不可或缺的，敏捷中的做法或多或少可以映射到CMMi在不同过程域的要求，也正好填补了CMMi在实践层面的需求。
【参考】麦哲思科技 任老师原文：https://measures.blog.csdn.net/article/details/98940870 也感谢王庆付老师的指导
关键词：敏捷转型，CMMi