什么是CMM真正的价值 & 项目的具体实施过程讨论

讨论到这里就可以打住了。对于现代商用软件，没有频繁迭代的方法就是扯淡，这就是定论。除非你是做航天飞机或者火控，只要你是做商用软件，需求就不可能“定得很早，非常细”，甭管你是和对方的什么人讨论，你都不可能做到，而且也不可能做到无变更。即便你做到了，这也不是一种值得推荐的方法。

变更对于CMM来说是可怕的，如果是频繁的变更的话，天哪，简直就可以看作是一场灾难。CMM很高兴的看到你的项目按照既定的步骤和谈好的需求按部就班，如果很不幸的，你的客户改了主意，那你会感觉到整个世界都会崩溃掉。

ok，CMM是有CM，是有SPTO，是有RM，可实施起来我怎么就觉得变更是那么的难呢？变更一次实际工作量没多少，可是额外的工作量：CCB会议，评审哪，文档等等就可以耗尽我的精力了，55555555

还好，我们的客户比较好打发，如果遇到一个难缠的客户，那我可真要哭了。

初看完CMM，我觉得软件开发原来如此规范，如此美好，可是实际去做，却觉得怎么这么彷徨。仔细想想，原来这是一张很大的饼，飘着香味，可是你去吃的时候，发现原来是画饼。

可能NASA会觉得CMM好的不得了吧，我是没感觉到

不一定，如果该公司商务上非常牛的话，还是可以考虑这种方法的。
说白了就是以一个冠冕堂皇的名义削减客户利益，强迫客户承担早期细化需求的工作，并要求客户为后续的变更付钱。

敏捷 vs cmm也很有可能成为吵架贴，当然这个帖子暂时没有。

重量级方法和敏捷方法的一个重要区别是：
重量级方法更多地借助于管理的手段来解决软件建造方面的问题。
敏捷方法更多地借助于技术的手段来解决软件建造方面的问题。

CMM 的创始人是 Watts S. Humphrey，我相信他完全是一个称职的职业经理人，他肯定可以管理好一个有上万人的钢铁厂、一个有上万人的水泥厂。但是他在技术方面的建树我并没有看到，似乎是 0 吧（又是一个不乏恶意的揣测！）。饶恕我的孤漏，如果有哪位网友指出我会非常感谢的。

但是敏捷联盟有哪些人呢？Kent Beck、Martin Fowler、Peter Coad 等等技术方面的大师级的人物。我还可以合理地推断 Erich Gamma 也是支持敏捷方法的，他和 Kent Beck 关系这么密切，不可能不受到 Kent Beck 的影响。TDM 已经多次表示过对于敏捷方法支持。Grady Booch 响应敏捷的潮流，推出了经过简化的 RUP——dX。

如果说有了一把锤子看到什么都是钉子，那么我是不是可以合理地推断两方面其实都是有了一把锤子（管理 or 技术）看到什么都是钉子呢？那么是不是两方面做到极至都能达到相同的目标呢？我的看法并不是这样。根据我的开发经验，以及和 ozzzzzz、potian、gigix 等朋友的讨论，我有足够的信心相信技术手段在大部分场合下是最有效和成本最低的解决方法。

我这里说的是传统行业中的管理手段，当然敏捷方法也有管理，但是这些管理很多是和技术相结合的，所以我认为这些手段属于技术，不把它们称作管理。

《软件研发》第一期上面有很多很好的文章，其中有一篇文章：
可我们已经是 CMM5 级了
建议大家找来读一下。

第一感觉就是形而上了，非要在一个方面体现出二者的让人认为最大的区别。

to ddd：
走着看吧，CMM 和 ERP 差不多，也是一个浆糊桶，有的好争论了。
我们还是抓紧时间做好自己的事情吧。

不太清楚什么是"技术方面"的建树， 。在我看来，Watts S. Humphrey是一个开发过程管理者，而Kent Beck、Martin Fowler更加像是开发者，两者思想的强调重点不同，其"技术"是不可比的。而且，我一直觉得CMM和XP重叠和矛盾的地方不多,XP团队里面基本上都是开发者，而CMM团队中杂七杂八的人多，这些人干了很多开发之外的事情，作为一个开发者，我也认为很多这类事情没必要，但可以理解，hehe
至于CMM认证，其实不管是什么东西，比如ISO9000系列，还有那么多的技术认证之类的东西，只要到了国内，总会变质烂掉，那是橘枳的问题，和这类东西本身到没太大关系。好在XP没有搞一个企业认证机制(至少我现在还没看到)，二是采用口耳相传的方法，否则，在国内迟早会和前面那些一样。

两者解决的问题不一样。
我觉得敏捷是建立在一定基础上的，如果每个开发人员都是不成熟的化，敏捷无从谈起。
Watts. 在他的《A discipline of Software Engineering>>有一些关于FORMAL design spec方面的论述。不知道这是不是技术上的，毕竟他的经验来源于70年代的一些开发经验。那个时候大家对软件工程的认识还并不是很丰富。

嗯，很有道理，不超过3个Man-day的需求变更一般就认了，不要求ChangeRequest, 超过一周的那一定是要客户多给钱，因为是给政府做事，所以他们或许不像一般商业公司那样"抠"。另外，我想介绍一下这里的IT环境，开发方必须在规定时间内交货，如果延迟按一个特定的比例罚款，我所知到的是某项目的Change request延迟的代价就是一天罚该CR总额的10%,换句话说延迟10天后这个CR就算白做了，很可怕是吧，不过这就是现实。通过对双方的约束，软件开发能按时结束，这对两边都有利。或许就是这种大环境的不同使得了CMM在这里比国内适用吧。。。

这几天和一些朋友在msn上聊起技术和开发，感觉挺好的，让我了解了很多国内软件开发的现状，谢谢大家！


希望不会。java视线有些帖是有点火爆～ 看得心惊胆战的 呵呵