前言
这段时间公司要进行CMMI的评估，而我们团队一直以来都是敏捷开发的模式，于是就要求我们以敏捷的姿势通过CMMI的三级评估，通过一段时间的了解和准备，关于敏捷和CMMI的关系有了更深层次的认识，于是在这里先介绍一下我们的一些想法和实践，如果通过了再看情况是不是需要补充。
首先要说一句话，纯粹的敏捷是无法通过CMMI的评估的，这取决于敏捷和CMMI的本质，具体的后面会讨论。
CMMI与敏捷的矛盾点
要明确CMMI与敏捷的矛盾点首先要确定这两者的基本原则都是什么。
敏捷宣言
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
CMMI的目的
目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。
核心矛盾
敏捷是以人为中心，而CMMI是以规则为中心。
更加实际的例子就是，如果一个敏捷团队的人全部都换掉，那么这个团队肯定就不是敏捷的了，但一个过了CMMI评估的团队的人都换掉，从理论上这个团队还是能过CMMI的评估。
具体如下：
1.CMMI要求设立独立的QA职位，而敏捷里完全没有这个角色，这个角色本身就是跟敏捷的核心理念相冲突的
2.CMMI讲究的是做事有计划，留证据，评审和确认。敏捷则讲究的是小步快跑，持续迭代，勇于试错。
3.CMMI一切都围绕着能够固化的资料而展开的 ，你需要证明你做过这些事，而敏捷一切都围绕着最后的产品而展开的。
调和矛盾的思路
1.建立缺少的职位和角色，这个是CMMI的硬指标，没办法，必须添加
2.将敏捷中的元素与CMMI中的要求建立映射，必要的时候进行适当的调整，比如
1）将fitness的测试用例用作确认测试说明
2）测试结果作为测试报告
3）javadoc作为设计报告
4）PB作为需求说明的一部分
5）任务板作为任务分解的过程等
3.计划会议和回顾会议，评审会议等活动留下会议纪要和音视频资料，并增加度量值以及风险的追踪等
4.适当增加检查点和检查单
总结
虽然敏捷和CMMI存在着本质上面的不同，但其出发点都是一样的就是为了保证软件技术团队能够更好的完成开发任务，我们可以对敏捷进行适当的改造来通过CMMI的评估。
总的来说
敏捷不是目的，CMMI也不是，明确我们目的地才能让我们更好的完成工作，创造价值。