CMM到底给我们带来了什么？

这是普遍现象。越是经验丰富的人，越能尽早发觉 这样干不行。
剩下的活跃人员，基本都没什么经验，而又觉得自己真理在握，
其他的人都是认识不到位，需要被教育。

嘿嘿，这段话比较精辟。仔细想想，确实是这样哦，敏捷的思想似乎就是抛弃所有那些过场化的东西，以交流和产品代替费力不讨好的文档。
文档的用处似乎是在进行大型开发时，团队之间的交流由于人员的数量引起信息的流失时，用详尽的文档来在一定程度上进行交流。可目前大多数项目的情况似乎是文档成为了形式上的东西，没有多少人会通过文档来了解其需要得到的信息。因为在一个小型甚至中型团队里面，人员之间的交流很方便，而且由于规模的问题，人员之间的角色并没有很清楚的界限，大家对于项目的情况都有一个比较清晰的印象。这样的话直接交流比用文档来表述的代价要小得多。

一个问题，由于有些客户要求运作这个项目的团队必须拥有CMM认证，比如我们现在的情况。那么，如何避免过程中产生的文档成为一些形式化的，被束之高阁东西呢？

关键在人。需要真正对软件开发过程和业务流程了解的人来担任过程改进的相关角色，比如SEPG,SQA.老板要有长期的对过程改进的承诺。
让过程改进 － 软件开发生产率提高，软件质量提高 － 更有市场竞争力 －企业战略的变化，业务的变化 －对过程改进提出更高的要求。 从而形成一个良性循环。

其实这往往就会落入一个高度依赖精英的开发体系，也就是所谓真正懂的人。而敏捷的的做法则是更加强调组织和团队，强调人在组织中的作用，强调组织的自组织。

过程改进和敏捷并不矛盾啊.
敏捷也许更在于是一种方法,LEAN, AGILE,分布决策，自组织。对XP来讲，也不排斥过程改进，比如结对编程的改进，环境的改进，测试，配置管理，集成自动化这些都可以看成是某种程度的过程改进。关键是改什么，怎么改的问题。

敏捷的事实上是一种持续的过程改进，这是敏捷原则的最后一条所说明的。但是敏捷的改进同CMM的过程改进又本质的不同，方法和指导思想都完全不同，时机也不同。

这是一个团队的最高境界了，在这样的团队中，任何过程和方法，几乎都是可以实现的，而且都会有非常好的效果。

不知道，现实中，有没有这样的范例团队，可以参考和学习。

完全同意，所以考虑改进的时候要注意时机和实际情况。不是听到一个敏捷的就可以敏捷的。做不好画虎不成反类犬。不过敏捷应该是趋势所向，因为软件是软的，是以人为本的。

不太同意以上的观点！CMM的存在有它一定的优势，能够给我们持续的开发带来很多的好处，否则他也不会长期的发展，并产生CMMI，但是我们开发中也不能依赖于它，一位评估师说CMM中没有没用的东西，但是我认为根据公司的具体情况还是有不适合的东西。

楼上的有CMM实际经验吗?