博弈 – CMMI和Agile

1984年，美国国防部出资在卡耐基.梅隆大学设立的软件工程研究所（SEI，Software Engineering Institute），SEI于1991年正式推出软件过程能力成熟度模型（CMM，Capability Maturity Model），2001年发布CMMI (Capability Maturity Model Integration, 能力成熟度模型集成) ，这是美国国防部为了确保军方大型软件项目的开发成功而诞生的。

2001年2月11日至13日，在美国犹他州瓦萨奇山雪鸟滑雪胜地，17个人聚到一起，交谈、滑雪、休闲，当然还有聚餐。他们试图找到共识，最终的成果就是《敏捷软件开发宣言》(Manifesto for Agile Software Development)。参会者们包括来自于极限编程、Scrum、DSDM、自适应软件开发、水晶系列、特征驱动开发、实效编程的代表们，还包括了希望找到文档驱动、重型软件开发过程的替代品的一些推动者。

在新经济环境下，公司最担心的显然已经不是万无一失，而是担心慢人一步，担心没有创新，担心开发人员没有被激励、不能发挥出最大的价值。

CMMI从一出生就被赋予的使命是要确保万无一失，是以把软件开发过程变成象生产线那样可控为目的，软件开发过程中的每个步骤、每个过程域、每个行为都被识别和定义，所以成为重型软件过程也就成为了必然。

敏捷的提出者就是工程师，他们非常清楚软件开发是一个创造性的工作，而完成这项创造性工作的主角是人，所以敏捷软件开发中把人放到了首要的位置。

前面已经说了是由SEI研究和发布的，所以CMMI是有组织有计划的不断发布新版定义，那套模型定义的圣经厚达700多页，把整个开发过程分为24个关键过程域，对每个关键过程域，详细定义了：

– Generic Goal (GG) 通用目标

– Generic Practices (GP) 通用实践

– Specific Goals (SG) 具体目标

– Specific Practices (SP) 具体实践

敏捷的方法论充分体现了以人为本，鼓励创新，没有一个统一的组织发布完整的模型，只有统一的敏捷宣言、敏捷原则，而各种方法论根据不同的场景、不同的关注点、不同的目的如雨后春笋般产生，这里随便列几个大家比较熟悉的：

1. XP – eXtreme Programming (XP) [Beck]：极限编程，关注于开发人员和强调团队工作

2. FDD – Feature-Driven Development [Palmer]： 特征驱动开发，需求驱动开发方式的一种

3. Scrum [Schwaber]: 迭代式增量软件开发过程，关注于具体的管理框架和实践 

4. Lean Software Development [Poppendieck]: 精益软件开发，来自于丰田的产品开发实践

CMMI包含了产品开发、维护及服务完整的实践做法，覆盖了从开始到交付和维护的整个产品生命周期，它对于所有关键过程域和关键实践的定义，可以让软件开发过程可控、可预测、可追溯，可以让组织可以量化的知道自己的能力成熟度，也可以给甲方一个清晰的产品、服务提供方的能力度量，所以CMM/CMMI发布后不仅再限于美国军方项目而被快速的广泛应用，企业也会因为有个CMMI几级的头衔而大力宣传。

敏捷方法通常会带来更高的开发效率并且快速适应变化。敏捷原则只是一个方法论，并没有给出完整、具体而详细的流程，具体如何操作、采用什么样的具体实践，同样的实践在不同的组织、不同的产品、不同的团队如何落地都有可能千差万别。这极大程度的迎合了快速发展、变化无处不在的市场，近十年来它的热度不用我多言了。