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

TDD所强调的反馈和CMM的应该不在一个层次上，或者说，理想情况下(hehe，只能说是理想情况)，CMM可以通过对TDD过程的度量来改进TDD的过程，或者说使粗放的、个性化的TDD过程逐渐演化为团队一致的、较为标准的、有较多约束的那种，当然，这个目标的正确与否是个哲学问题，达到目标的途径也有很多。比如对于单元测试，通过对团队成员单元测试编写水平的度量和反馈循环来改进单元测试能力，而且这个度量并不需要开发人员做额外工作，当然这个取决于度量的粒度。
我一直很疑惑把CMM和XP,RUP等混谈的方式，文档并不是CMM的终极目标，文档为改进服务，但并不是说有一大筐合式的文档就等同于改进了。

CMM认为在在组织一级要建立这个循环，而对软件开发来讲，需要更频繁粒度更细的循环，比如TDD，比如Continous Build,比如On-site Customer.
我不觉得“度量，反馈，改进”这个循环有什么问题，关键在于我们把关注点放在构建那些循环上。

cmm是个管理范畴的东东，那么多人懂管理，中国软件业不用补钙了。

. 管理在于可度量，目标是过程透明化，可控制

. 度量的依据是过去的数据，让历史告诉你未来

. 数据的收集带来成本增加，小公司量力裁剪

. 度量，反馈，改进 来源于小日本盗版中国的'改善'二字，被honda成功推广到全世界

. 管理思想很复合西方的思维方式，凡事逻辑化，形式化，所以中国人不要被形式蒙眼，多研究形式化的目的

. 最后，管理问题不是技术问题，差别在于管理问题通常不可控，管理问题的可控化是管理学上的银弹传说

CMM是过程的东西。过程中管理只是一个方面，还有其他很多的东西。


我倒是经常听说管理是一种艺术。况且软件开发中的度量历来是一个困难的问题，从来没有人声称自己找到了最好的解决方案（当然有些头脑发热的人除外）。


度量的依据在于建立一个标准的度量衡体系，历史的数据只是一个陪衬。而且软件开发中的历史从来就不应该告诉你未来，因为那恰好说明你复用的不够，也就是你的过程目标不合乎软件工程的目标。

大公司是不是就没有成本问题呢？大的组织按照道理来说，其度量的数据应该更加多，度量的场合应该更加多，度量的成本也应该更加多。因为大的组织中交流的线路必然会更多，管理的环节也会比较多。
数据的收集关键在于你究竟收集什么。而收集之后的数据也需要很多的处理，并且究竟哪些可以作为对照，这也不是一个简单的判断。



这只是一种西方的管理思想。


你究竟要说什么呢？可控还是不可控？

死胖子驳的累不累

不可控，可控了就成技术问题了

我觉得,中国的大部分软件公司过CMM无非是想要接更多的项目而已,对于什么是CMM,到底怎么做,他们大部分不在乎

我觉得，如你所说你们部门不是不适合做CMM，而是你们还没有达到过3级的最低要求。欲速则不达就是这个道理了