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

呵呵，最近又想到一点东西。

上次提到CMM及类似的质量管理的思想不鼓励员工的偏差（包括负偏差和正偏差），这次扩展一下

我们通常凭经验认为，一个优秀的程序员和一个一般的程序员之间的开发效率很可能差10倍
CMM的思路是通过一套完整的质量机制，定出一个合理的开发效率，然后对负偏差进行分析和提高。
然而事实上这样做的结果往往是把团队的一般水准定为基准，很多时候可能比一般水准还要低，而不是比一般水准略高。

换句话说，CMM对程序员的工作效率有双重影响，一方面其本身的繁复工作会要求程序员付出成本（这个倒是比较正常的，只不过是比率太高而已），另一方面是由于这些要求，降低了程序员自身的积极性，从而强迫团队在一个稳定的但是较低开发效率的基础上进行。

这句难道不是应该特别单独提出来吗？

实施CMM不要犯教条主义，我们在CMM的指导下要能更加注意和重视我们自己的实践，总结经验不要吊死在CMM上。

也许在CMM上还要加点什么东西。

但主要的还是解决实施CMM的问题，而不是革CMM的命。

对于这种谬论我们已经澄清过很多次了，最好不要老是重复这种错误的老调重弹。

嗯，我就是有些担心初来者不喜欢翻阅以前的讨论内容，最终让以前精华的讨论成果沉下去。而以前的参与者也因为问题已经完全讨论清楚而不再参与相关的讨论。robbin 会多做一些整理工作，让这种情况不至于发生。不过初来者翻翻以前的讨论内容确实是对这里其它网友的一种尊重。
以前跟 o6z 聊天，达成共识认为这种大谈而特谈过程改进的软件企业是非常不成熟的软件企业，完全没有找到适合自己的开发套路（即使是我所称之为的野球拳）。o6z 也认为首先应该找到适合自己的套路，知道自己真正需要什么然后才好谈过程改进。这样才不容易上当受骗。
那么我们应该大谈而特谈什么？过程改进并不能保证软件企业的成功。什么可以保证？是不是应该开始大谈而特谈我们能够带给客户哪些商业价值了？哪怕是仅仅改善了应用的交互和界面。无法带给客户商业价值的软件企业即使通过了 CMM5 也是注定要失败的，哪怕他们的管理规范文档真的如同脑白金生产厂家一样达到 5 米厚。同时客户也应该充分认清楚，繁琐的管理规范与能为他们创造的商业价值并不是正比关系（也许有一点关系，这种关系是什么，我也说不清楚。但是肯定不是管理越繁琐，带给他们的商业价值越大），这样才能认清楚什么是宣传和市场炒做，什么才是他们真正能够获得的利益。

其实大可不必这么执着。
我看到过的实施CMM的软件企业，大多是知道自己需要什么的，至于是否认同CMM的理念，那就另说了。没有一个企业是傻瓜，会把自己的钱不当做钱。
这个就好像以前的iso9000系列认证一样，别太当真。

to charon：
不是我们一定要唱衰 CMM，而是 CMM 确实存在着很多的问题。上次 ThoughtWorks 的 Martin 和 Sidney 来到中国，谈了非常多关于 CMM 和敏捷的比较。我觉得不能简单地认为他们都是做咨询的，存在着利益冲突，因此就互相攻讦。

CMM 也有适用的场合，例如外包行业，目前这个行业火的厉害。但是这并不是说敏捷就不适合外包行业。据我所知，日本也有很多软件企业实施了 XP，他们如果把一些工作外包出去，单元测试覆盖率我相信是最优先考察的一个方面。

hehe, 我见到过的那些过了CMM X的公司，初衷或多或少都与外包有关,就像10年前制造企业为了出口哭着喊着过iso 9000以及一些欧洲标准一样。
但是，实际的项目管理，我还真没见到作我们这一行的软件企业对于过程和质量有象莫像样的管理。虽然我非常赞同CMM内涵的那种"度量、反馈、改进"的循环过程，但是现在国内的企业，有太多的为了CMM而CMM了，搞定之后把所有相关的东西都扔之脑后。
所以，我并不认为CMM的方式适合外包行业，只是有一些有钱有势的人这样认为，而且他们没有想到国内企业可以这样对付CMM，haha,所以，大概CMM只能适用于某些"海外外包"
很可能某个公司为了"外包"而去过了CMM评估，但是为了提高团队的整体开发水平，又采用某些敏捷或者不那么敏捷的做法。不过，我觉得现在敏捷也快开始烂大街了，很有可能也将变成吸引客户的另一个噱头。

没有人会仅仅因为 CMM 思路正确就去采用 CMM（还要考虑成本、效益等等诸多的方面）。从敏捷方法的角度来看，单元测试的覆盖率是一个很好的度量标准，而严格的 TDD 可以提供比任何其它方法更多的反馈，重构就是改进软件质量的最佳方法。在我看来，如何切实做好单元测试才是开发团队应该打好的基本功，其它的方法都有点类似于旁门左道。

确实是这样，我的一位朋友在大型国企背景软件公司做管理工作，他们就是这样做的。“内用黄老，外示儒术”。反正不管怎么样 CMM 在中国都是做给外面的人看的。为什么会这样，也不能单纯从中国人的劣根性上面找原因。

呵呵，我就是认为CMM内涵的“度量、反馈、改进”的循环过程不适合软件行业。