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

是的，现在大家的思想已经逐渐统一起来了。其实问题不是有没有认真彻底地执行 CMM，而是 CMM/PSP/TSP 这一套东西本身就是有很多问题的。否则他们也没有必要进化到 CMMI 了。一个有问题的开发过程还要去认真彻底地执行，除了“自虐式生存”我找不出更好的形容词来了。

你这样想方向就对了，我想对于过程改进，认真彻底地执行 XP 一类的敏捷过程才会有更好的效果。大家自己心知肚明，JavaEye 的朋友也都很清楚，不过去骗骗那些官老爷还是可以的。

其实这里就是两件事。对外，能捞的钱一定要捞；对内，一定要提高工作效率。所以就权衡吧，两者可以得兼。

不过可能没有怎么容易，第一，官老爷有官本位，喜欢管理，喜欢控制，喜欢数字,把敏捷这么一弄我觉得搞不好会成个四不像,就不像敏捷了，第二，新的过程风险谁愿意承担？在我们这个领域，大多是规模比较大的嵌入式系统的开发，C/C++可以用的技术和工具远远没有JAVA的丰富，而用JAVA做产品的开发平台FLATFORM，performance又有问题；按以前的过程走，没出大问题，用了新的呢？谁知道？老板愿意承担吗？
所以不是不要过程改进，而是过程改进要有策略,活学活用方为本。
饭得一口一口的吃啊！

你从事软件行业，本身就是要为你自己的选择而承担风险的。你说的风险更大程度上是从你自身而言的。确实，在 XP 方式下做开发很累人，你很难找到什么借口推卸自己应该承担的责任。而在 CMM 方式下做开发可以捣浆糊的机会则要多的多。

但是从产品/企业的角度，没有什么证据可以证明 CMM 对于产品/企业成功的风险就一定会比 XP 更小。事实上我看到的是 CMM 使得企业趋向保守、人浮于事，反而增加了企业的风险。

有道理，不过我想补充一点：
国内很多企业，采用的是coding-现场救火式的开发，用CMM来框一下，至少有些文档，而不是只是有一堆看不懂的代码，还是有些好处的,这个时候用CMM的大旗来扮猪吃老虎还是有用的。至于自己是不是认识到CMM的问题,把这些繁文放下，直指本源比如敏捷，那就看各自的造化了。

要是代码都看不懂，难道你还能希望看文档就能看懂？代码最坏也就是看不懂而已，文档常常会误导，比看不懂还要坏。

我并是推销和作评估的，我也是普通的开发人员

但是这些问题，诸如改进，技术风险等，在cmm5中是一个评估点，需要有专门活动来进行过程和工具的改进

xp和cmm不是矛盾的，但是在实施cmm中，往往很多公司都会使用V模型，而V模型和xp是很不协调的，所以造成大家觉得cmm和xp冲突了。

我觉得cmm最多的要求可以是几个“凡事”，凡事要计划，凡事要记录，凡事要review，凡review要有checklist，风险要标示跟踪，缺陷要预防；其他也没有什么。

CMM确实没有指定用V字型。但由于文档或流程负担太重，自然导致了是V字型的生命周期。因为V字型需要出的文档最少。如果把生命周期定成VVVV。。。那过程消耗会成倍增加。
至于积累经验，方法可以有很多，CMM充其量只能其中之一。

我也觉得cmm只是一种评估软件能力的方法，能够促进我们能力的提升和积累，但是既然用这个方法可以，那个方法也可以，为什么用这个办法就要被骂呢？是不是另外那个方法是中国人发明的，要支持国货？

在工作中，我觉得很多同事，包括我自己，会有不自觉的倾向，当A提出一个方法时，B就会说用另一个方法也行，于是A和B各用了各自的方法去实现，结果造成后来的麻烦，如果两个方法都可以，就调整一下，统一用一个方法。

这个就好像以前在论坛上经常看到有人喋喋不休的争论dephi和vb，很多都是刚刚入门的，也卷到里面，其实都是个工具，何必争论太多，用好一个，另一个也不会太难掌握。

也不是说用一个方法就不了解其他了，就排斥了，该了解的还是要了解，就象大家前一段时间用strtus，那么新人来了说webwork好，大家评估评估，确实好，再考虑工作量，老的产品是不是替换？还是新的产品采用新的技术？这些都没有问题，就是怕大家用一种封闭的心态，有了成见，报着自己的观点不放。

大多公司的cmm使能流程都有很多的文档，这些大概都是从印度来的，很多是为了评级而搞，或者是怀着朝圣的心情来做，都走远了

我喜欢XP持续集成和频繁发布，我在项目中也使用这些方法，这些和cmm并不冲突，但是这些内容和v模型的确有冲突，我反对v模型，尤其反对有些使能流程中的“不允许在编码阶段前编码”和“一次把事情作好”这两个说法。cmm本身是允许使用迭代的开发，并不一定是VVVVV。。的。只要在规程中定义好出口和入口，不要随心所欲。

你可以问问风舞飞扬在CMM下你怎么实施频繁发布，你又如何持续集成，你的SCM如何才能达到CMM的要求。