CMMI跟敏捷双剑合璧的一点点看法
每个软件企业和组织都希望自己的组织能成为成熟的软件组织，都希望在成长的过程中一点点的完善起来，以达到优化工作方式和开发流程，降低长期发展中的成本消耗，获取最大的利润回报，而CMMI（能力成熟度模型）成为大多数企业进行能力评定的标准。
公司也准备弄CMMI，看了同事写的方案，我对其中的观点表示认同，特别是提到CMMI和敏捷之间相辅相成的关系，我表示极大的认可，这也是我第一次看到传统的观点和流行的方法统一起来思考的先进性表现。
许多人认为敏捷与CMMI是极端对立的，彼此抵消对方的成效。在传统方式与敏捷框架之间一直持续的论战中，各自的支持者纷纷列举出与对方水火不容的观点。对待事物我们要一分为二的看待，各取所长，互补缩短，既保证持久的稳定性，又要具备与时俱进的先进性。而同事提出CMMI和敏捷双剑合璧的方案，我想发表一下自己的看法。
首先，CMMI和敏捷不是对立的。任何软件工程的思想和方法，目的都是一样的，都是优化流程，提高开发的效率，降低开发的成本，达到提高生产力的目的。只是随着环境的不同和时代的不同，一些方法在不断的优化和发展。
其次，我不太同意同事提到的CMMI=敏捷的说法。CMMI和敏捷都是软件工程的方法和工具，但是CMMI是能力成熟度模型，它更多的是一种评定标准，一个框架。而敏捷开发方法更加关注的是过程。一个是目标，一个是实施过程，它们是包含和被包含，相互补充的关系。我把CMMI和敏捷描述成敏捷是我们实现CMMI的其中一种方式，甚至都不是并列的来比较的。
最后，我想谈一谈如何实施CMMI，如何应用敏捷的一些想法。
既然CMMI体现了一种能力，代表着一个软件组织的成熟度评定，那么这个模型就是对我们有用的。（CMMI的好处看后文附），具体实施过程，摘一下同事的内容。
- 过程文档化
- 过程的裁剪
- 组织培训
从这三点来看，和敏捷开发的确没有什么太多的冲突。过程的裁剪，组织培训没有任何问题，对于文档，敏捷开发强调轻文档，而更重视要交付的产品（软件）。但是敏捷开发并没有排斥文档。
我将软件开发的过程大致分为三个过程：1、前期的需求、设计；2、中期的设计、开发；3、后期的测试、交付；敏捷开发的过程更多的是关注的第二阶段，而且和以前瀑布模型不同的是开发的过程需要和第一阶段和第三阶段要紧密的联动起来，越来越重视开发人员在整个过程的地位和能力的发挥。其实，这很好理解，越来越多的系统在需求阶段，用户都无法真正的描述清楚，增加各个阶段的交互和沟通，是对这些情况的一种改进。集中第二个阶段，最有价值的成果是快速构建的软件产品，在软件开发的过程，死板的、没必要文档会对整个开发过程造成影响，敏捷开发只是要消除这部分的文档带来的效率低下的问题，但是对软件开发人员提出了更高的要求，高质量的，文档化的代码。而对前后两个过程需要和用户进行紧密相关的部分，不管如何的开发方法，完整的、清晰的文档是必须的。从文档上来看，这点的冲突并不大。在此必须强调一个观点是：文档是手段，不是目的，我们关注的不是需不需要文档，而是关注的是我们需要什么量级的文档。
CMMI重视项目的计划，而敏捷提倡响应变化胜过遵循计划。计划是控制风险，保证项目进展的最好的方式，做任何事情都要有计划遵循。而敏捷倡导的事响应变化胜过计划，而不是不要计划，只是我们要丢弃那种自上而下的，死板的，不能灵活变更，毫无弹性的变化。在CMMI过程中我们要更加关注，如何制定合理的、有效的、有弹性的工作计划。
CMMI只是一个衡量成熟度的模型，在这个过程中，CMMI并没有限制我们的工作方法和思路，所以灵活的运用好这些软件工程的工具和方法是我们要不断去思考和探索的。并不是所有的项目都适合敏捷（比如外包项目），敏捷的方法有好多种，不同的项目，不同的团队都有适合自己的开发方法。敏捷是一种精神，是一种倡导人的力量，关注最终交付的产品，实施更加弹性更加有效开发过程的精神。
所以，在公司CMMI的过程中，我认为应该是一个框架，多种开发实践。我们首要做的是构建起符合我们自己的框架体系。
原文：http://www.po-soft.com/hi/yongtree/blog/2135