CMMI全称为Capability Maturity Model Integration，即能力成熟度模型集成。从去年开始，公司就一直在做CMMI lv3的认证。作为EPG小组成员，从学习模型，到定制过程，中间学到了很多知识，也学会了很多软件开发过程的方法。CMMI讲究的是，所有过程要有计划，要有文档，资料必需尽可能地面面俱到。从项目立项到结项，全部都有计划和文档。从而保证软件开发过程能够沿着正确地方向进行下去。例如、在作项目立项时，要有项目评估报告、技术预研表、还有估算的方法如：Delphi法或UCP法、项目计划、风险计划……非常多的文档，且这些文档是要经过评审会议的评审，高级经理签字后才能纳入配置库中去。为项目组配备专门的CM（配置管理员）人员、和QA（质量保证）人员。开发过程中，每一步都要按照规定的流程来走，由QA人员监督。

　　下星期开始，我就要带着团队做一个试点项目，这是一个非常小的项目，也是我曾经日夜加班赶出来的项目。主要是用ATM机上读卡、取款、打印小票等工作。由于没有设备，所有的测试都是以模拟仿真的方式进行的。从需求分析到集成测试，我和另外一个开发人员做了一个半月左右。在此期间，客户不断地提出各种各样的变更要求，导致我们的工作不断地重复修改。（应该说效率非常高了）。这次重走过程，应该说技术上面没有任何障碍了，所有的设计资料都已经非常齐全，现成的程序也有了，并且不会再有需求变更这样的情况，还有就是给我分配了两个开发人员。但我始终感觉工作量要比以前开发时要大的多。主要是项目经理在 CMMI体系结构中，占据的分量实在太重，几乎８０%以上的文档是由项目经理来做的。而我们公司并没有严格意义上的系统分析员、需求分析员、概要设计人员，这些工作理所当然的都是由项目经理来做了。所以，在以前的项目开发过程中，我不但要做需求、设计、帮助组员解决技术和业务上的问题、检查组员的代码、有时候，自己还要编码。当项目快要结束时，还要充当集成测试人员，要测试全部代码。要做的事情实在是太多了。这次，再加上CMMI为项目经理定制的各个阶段要做的文档、这种工作量是难以想象的。我想，上面的情况应该是国内很多公司都存在的情况吧。

　　不得不承认，CMMI确实能够保证项目有计划地进行，并且的确可以保证产品的质量。但有一点可能会将CMMI全盘推翻，那就是开发时间。软件这行跟其它研发行业或者制造业没有多大区别，都是在研发或制造产品。在竞争如此激烈的时代，如果不能在最短的时间内做出好的产品，市场就会被其他公司所占有。所以开发时间是每个公司高层和客户所必需考虑的事情。他们总是不断地压工期，甚至想把１００个人月的项目压到一个人月去。还有一点，就是需求的不稳定。CMMI说，我们要在前期的工作中，让客户把需求稳定下来。然而，客户没有看到东西，他是没有什么想法的，一旦有东西可以运行了，就会冒出各种各样奇怪的想法。记得以前开发过一个产品，为是尽快占有市场，高层对我说，先把功能实现投入市场、其它的以后完善。对于我们开发人员来说，只能硬着头皮去做。软件质量的好坏，我们也只能先放一放了。即使如此，还是不断的变更，变更。就在这样的一个大环境下，以往只做几份设计文档就开工的我们来说，时间都已经非常紧，若是用了CMMI，那真是不敢想象，老板会用什么样的眼光来看我，也许我会因为没办法完成项目而主动提出辞职的。

　　所以，Agile来了。因为有许多公司的软件开发团队陷入了这样的困境，业界专家聚集在一起概括出了可以让软件开发团队具有快速工作、响应变化的能力。它为我们提出了很多改变格局的思路。Agile认为：个体交互胜过过程和工具。可以工作的软件胜过面面俱到的文档。客户合作胜过合同谈判。响应该变化胜过遵循计划。难道不是这样吗？对于客户来说，他们期望在最短的时间内拿到可用的、高效的、安全的、没有bug的、甚至是完美的软件。另外，价格越便宜当然就越好。对于我们开发人员来说，就是要以最低的成本、最快的速度、最好的质量达到客户的需求。那么，我们有什么理由做如此多客户并不想要的东西、有什么理由投入如此之大呢？客户只想要软件，并不是文档。而钱就那么一点。

　　《敏捷软件开发　原则、模式与实践》这本书中有一个小品非常有意思。题目叫做《两个公司的讽刺小品》。说的是两个使用不同方法（其实就是CMM 和Agile）工作的公司，做同一个产品，最后不同的结局。当然，这只是一个典型的例子，不是绝对的。有兴趣的朋友可以买来看看，是本经典的好书。

　　只能说，CMMI是好东西，但在现在的大环境下，不实用。但每个公司都想通过他们的认证。Agile也是个好东西，实用，但没有公司愿意转型。也许，只是现在不愿转型吧。但愿只是现在。