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

我也有这样一个模板，你干脆就不用懂Hibernate，只要认识几个单词就可以了。

半天就上手了

看到你的观点我十分的赞同，特别引起我共鸣的是你提出了一个非常有价值的观点，即CMM不鼓励出现正偏差。这一点也是让CMM引起很多软件开发人员反感的地方。软件开发活动包含了大量的创造性劳动，然而对于一个类似制造行业的流水线生产来说，出现正偏差也会对规模化生产产生破坏力。

软件行业发展的未来趋势我无法预测，但是我看到越来越多的项目型软件公司都在努力尝试将软件生产活动向规模化的软件制造流水线方向改造。原因也很简单，因为现在项目利润很微薄了，必须在成本控制上下功夫，他们想的唯一的办法就是规模化的生产，批量化的复制，CMM正是顺应这种需求的产物。

你说中国有自己的制造业吗？ 上海的制造行业都是德资公司；
你说中国有自己的电子产业吗？苏州的电子产业都是台湾公司；

软件行业在中国其它地方我不清楚，但是在上海，外包型软件公司（包括欧美跨国公司）正在以惊人的速度成长，上海的IT行业就快变成一个世界软件工厂了。

http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!203.entry

这是Javaeye的一场超长讨论，从2004-12-10由lucifer发起的《CMM到底给我们带来了什么？》到现在已经讨论了244贴，共有8200多的阅读次数了。关于CMM讨论已经极为深入，甚至可以算得上深刻了。

最近又来了两个CMM的支持者，一个是askycn，一个是青海渔风。我问了他们一个问题：
你认为推进企业实施CMM，最重要的能力是什么？

青海渔风的回答是：


说实话，这已经是我见到的，推广CMM的人员中，最有水平的回答了。然而，这也恰恰最明确的显示出了CMM的支持者与反对者之间的最大差别。

我在后面的回答是这样的：


青海渔风在他的最后一个帖子里，非常委婉而巧妙的表达了他的观点：“不跟你们玩了，你们连CMM是什么都不知道，不但你们不知道，而且中国软件从业人员大多都误解了CMM。”————“这么多年下来，还有这么多人不理解‘真正的’CMM，这难道不是CMM体系本身需要反思的地方吗？”

接着说askycn的观点，这个小伙子似乎更为“稚嫩”一些，坏就坏在，他不但稚嫩，而且“只知道辩论，不知道交流。”他的回答分为两段：



下面是我的回答：

我的一些朋友现在在美国，他们都是很陈旧的程序员，他们用的语言都是cobol这类的东西。但是最近他们的队伍在快速的扩大，不过他们明确的告诉我，这只是目前又到了一个程序的更新换代期，那些组织由于种种原因不能进行彻底的更新，只能选择在原有系统上的升级，因此带来了短暂的繁荣。实际上外包的问题也是类似。

究竟什么样的项目可以外包，这个我们可以分析robbin提供的那些外包企业的运转情况。首先外包的项目往往都是那些已经成熟的项目，期限相对宽松，需求变化小，而且往往是已经实现过的项目。如果不是如此，使用详细设计到细小单元，进行代码工厂组装就会带来质量的严重不可保障，调试周期的不可控制。原因很简单，一个单元的测试是简单的，但是各个单元内部的无bug并不能保证组合后的集合体也没有bug。而这些集成中出现的bug由于其单元的实现者无法从整体上把握系统，因此只能有那些设计者进行调试和修正。我们只要稍微有一点编程经验的人就知道，花费最大资源，耗费最大精力，最不可控制的事情，也就算这些了。而问题在于那些集成中出现的bug往往是最难以琢磨的bug，往往是不经过集成就不能发现，而还有一些是不经过上线就不会被发现。而一旦这些bug不能被早期发现，其造成的资源消耗就将是巨大的。而要早期发现，不通过测试我想是任何的评审也未必可以发现的。而我看到的对于这些组织的描述，往往就可以发现，其使用的软件生命周期模型往往是瀑布式的，其后果就更加严重。当然存在一些方法引入迭代，不过其产生的消耗也将式比经典迭代方法巨大的多。因此说成本更低我看是有问题的。

而我们还可以设想，一个组织有那么多人力，其组织的管理和办公的费用将不是巨大的。而往往是那些低水平的程序员的合作其效果是1＋1<1。

同时我们还应该知道一个高水平的程序的的效率，往往是低水平的程序员的10倍以上。而10个低水平程序员的组合往往大大低于一个高水平的程序员，同时随着人员的增加，往往在一个鞍点之后带来的只能是总体能力的快速下降。其带来的成本后果将是灾难性的。这也是一些组织测试人员和开发人员的比例大大失调的一个原因。

而我们还应该明白可以外包的项目是有限的，并且随着时间的发展会在一个时期之后越来越少。而同时我们也可以看出，其实那些低级的程序员的工作，往往是可以使用工具来替代。当那些外包的组织发现开发一个工具，比使用代码工厂的成本大大减少的时候，他们早晚会选择使用工具而非人力的堆砌。

其实我们可以从Grady Booch的著作《面向对象项目的解决方案》中对于文档驱动开发的论述中看到，那些使用笨重管理模式的组织往往是金融和政府机构。他们的组织结构和管理方式的改变要大大落后于社会的总体环境。不过他们早晚会进步，对于原有软件的使用方法也会随之而改变。这个时候使用原来系统就将变得成本过于高昂。因此对于他们来说外包也只是目前的一个时段的选择。

而同时我们还应该发现，在美国国内众多的政治人物都在说应该限制软件外包，并且这样的声音越来越大，并且得到众多美国本土软件组织的支持。

现在他们选择外包项目，一个很大的原因是成本考虑。而这些项目正如我前面所说，都是原有项目的升级。其对于成本的核算也只是以在美国本土的成本进行的核算，而这些组织的原来开发的成本是让人不可理解的高（大家可以查一下NASA的每行代码的造价），因此选择这样形式的外包，他们觉得是便宜的。当时成本的压缩往往在他们看来是无限制的工作，他们早晚会选择更加低廉的成本模式。而这样的选择需要一个过程，但是这个过程早晚会进行结束。

同时我们也应该看到，目前外包项目的价格已经不前几年低的很多了。早晚会降到一个使用低水平程序员进行开发也不能完全满足需要的地步。而实际上目前已经存在这样的趋势，比如大陆最早的CMM公司就已经出现了问题。而北京现在外包也在快速发展，但是其主要的发展不是那些代码工厂，而是测试。而测试的外包也在逐渐从单纯的使用外方提供的测试案例，到自己设计测试案例的分析发展。这样的趋势必将造成低水平的程序员的组合变得无用武之地。而测试可以说是自动化难度最大的一部分。

所以现在外包企业的快速发展只是一个短暂的现象，而国内的的管理水平是否能够负担这样的组织我深表怀疑。

不过说不定十一五的免税就落到某种敏捷方法上，不过到那个时候我相信敏捷也会被搞坏。总而言之政府推什么就毁什么，不过敏捷方法就算走走过场也比CMM有效果，起码单元测试和配置管理不会是“可裁剪的”。

hehe,看了大家吵得沸沸扬扬，我也来凑凑热闹,
贴一段Agile Project Management with Scrum 附录的话

Capability Maturity Model (CMM)
CMM is a framework that describes practices that an organization employs in developing software. CMM consists of five levels, numbered 1 through 5. Level 1 means that the organization doesn’t have any defined, repeatable, or improvable approach to building software; basically, developers hack their way to a solution. At level 5, an organization has a defined, repeatable, and improvable set of practices for developing software. Level 1 is considered an immature organization; level 5 is considered a mature organization. At each level, the practices that should be employed are defined as key practice areas (KPAs). Bill Curtis and Mark Paulk from the Software Engineering Institute (SEI) at Carnegie Mellon University developed CMM in the early 1990s.

If an organization believes that it has thoroughly implemented the KPAs for a specific level, it can engage someone who has been certified by SEI to assess this. If the organization is compliant, it is so certified. Certification is a big deal, because some companies and governmental agencies won’t hire any professional services firm that isn’t certified to at least CMM level 3.

CMM at MegaFund
I introduced MegaFund in earlier chapters. MegaFund spent three years and over $40 million to improve its software development practices until it was certified at CMM level 3. At this level, MegaFund not only had a repeatable approach for managing any conceivable software development project, but it also had formally defined these practices. We looked at how MegaFund scaled a project to quickly support its entry into Web, telephone, and other advanced management of funds by its customers in Chapter 9.

Unfortunately for MegaFund, it had not defined practices that addressed a time-critical project that would automate ill-defined requirements on advanced and untried technologies like the project in Chapter 8. When MegaFund brought in Scrum for this project, the project had already been stalled for over nine months while team members tried unsuccessfully to jump the procedural and bureaucratic hurdles the CMM level 3 imposed on progress in unforeseen and undefined circumstances. I gained an unfavorable impression of CMM from this and later encounters with CMM implementations. However, as I was asked more frequently what I thought of CMM and how it related to Scrum, I realized that I needed more information and knowledge. To this end, I set up a meeting with Mark Paulk at SEI in the fall of 2002.



SEI, CMM, and Scrum
Mark was familiar with Extreme Programming, another Agile process similar to Scrum but more engineering focused and less management focused. However, he had only heard about Scrum. Throughout the first day, Mark taught me about CMM, and I taught Mark about Scrum. On my side, I was quite surprised and impressed by CMM. Mark related that it was only a framework describing an organization’s maturity for developing software. How an organization satisfied that framework was up to the organization. Assessors were supposed to determine whether the manner in which the organization satisfied the framework was adequate. This enlightened me. Because almost every organization prior to 2001 used defined software development processes, CMM would of course build rigid, prescriptive, and defined methods for fleshing out the framework. These practices would suffer the weaknesses of all defined approaches—they would work only for situations that had been foreseen by those defining the practices. Since software development is a very complex process, there would be very few actual projects to which these practices would be applicable.

Mark then went over KPAs for the various levels with me. We then assessed how Scrum fulfilled the KPAs for each level. Mark was pleasantly surprised. Even though Scrum took an empirical approach, someone employing its practices would satisfy all of the CMM level 2 KPAs and many of the level 3 KPAs. The KPAs that weren’t satisfied at level 3 were those that addressed institutionalizing the practices. These KPAs were addressed in 2003 when the Scrum Methodology, the Certified Scrum Program, and Project Quickstart were made available as products. Figure E-1 shows the degrees to which Scrum addresses the various KPAs in level 2 and level 3. A double check mark means fully compliant, and a single check mark means mostly compliant.


Figure E-1: Scrum and CMM
To see how Scrum’s practices implement one of the KPAs, let’s take a look at KPA 2, “Requirements management.” The definition of this KPA is “The purpose of Requirements Management is to establish a common understanding between the customer and the software project of the customer’s requirements that will be addressed by the software project.” The Scrum mechanism for meeting this KPA is the Product Backlog, an openly visible listing of all functional and nonfunctional requirements maintained by the customers that is used to drive development, Sprint by Sprint. The emergent nature of the Product Backlog, with focus on only the top-priority items, maximizes the probability that investment in detailing requirements is of value. Lower-priority Product Backlog that might never be implemented is ignored until and unless it rises to the top of the Product Backlog list.

This KPA is often interpreted as demanding requirements traceability, the ability to show how requirements are fulfilled in the delivered system. The manner in which Scrum addresses this interpretation is by demonstrating within 30 calendar days how every Product Backlog item that has been worked on during the Sprint operates as business functionality. The proof is through an actual demonstration of the functionality. As the customer accepts the functionality as complete, that completed item reduces the Product Backlog.

This completely empirical approach to requirements traceability fully meets the requirements of the KPA without extensive documentation or overhead to the development process. It also provides complete flexibility to manage and trace changes in requirements anytime throughout the project. Scrum addresses the rest of the KPAs for level 2 and 3 similarly, empirically and with a minimum of documentation and overhead.

大意就是说，CMM比较适合成熟的过程，对于无法预见的冬冬无法处理。而CMM
那些KPA通过其他办法也可以达到，而且没有什么overhead,这可是Scrum的高手和CMM的高手对话得出来的结论呵呵

不管是CMM还是RUP、或者XP等等流程，关键都是两个词：review和test。

大家对外包也不要有偏见，外包一样做新项目，大项目。

华为的外包人员，有好几千号，产出软件产品的产值以亿计，用得还不是IBM的流程，CMM的标准。不过，每个项目/产品有对CMM的使用程度不同有一定的裁减。视项目大小而定。

CMM有用吗？有用，关键看你怎么用。

“人”关键吗？关键，但是要求一个项目组里都是牛人也是不现实的，也花不来，太浪费，有那么一两个搞定项目的关键部分就行了。

"你说中国有自己的制造业吗？ 上海的制造行业都是德资公司；
你说中国有自己的电子产业吗？苏州的电子产业都是台湾公司；

软件行业在中国其它地方我不清楚，但是在上海，外包型软件公司（包括欧美跨国公司）正在以惊人的速度成长，上海的IT行业就快变成一个世界软件工厂了。"

上海是进入中国的大门条件比较特别 和其他地方还有有差别的.

大家也谈了很长时间CMM, 外包这样的东西是很容易转移 国际上一有风吹草动 外包这样的行业最先受影响.

中国的软件要真正壮大 还是要靠和其他行业的紧密配合 也就是应用. 比较一个国家的IT实力 关键就是看应用水平. 单纯的软件不会带来任何作用 只有和具体的应用结合 软件才能发挥其价值. 没有灵魂的躯壳 和没有身体的鬼魂 是一样的.

但为什么中国的IT并没有很好的进入到应用领域那 ? 而是被导向了外包 ? 我个人认为是价格决定的 按照国外的价格 中国的企业是无法接受的. 同时国外的专利制度 版权制度在中国也永远行不通.

中国需要的是 无版权的 实用的 廉价的 可再开发软件. 也就是源代码开放这样的模式比较适合中国的实情. 

但一个真正开放源代码的 透明的公司 如何才能生存哪 ? 这才是我们应该研究的问题.

一旦这样的公司有了可赢利的模式 就会迅速膨胀  就象20世纪初的超市 不仅仅能使中国的软件业繁荣 而且会蔓延到所有的发展中国家 甚至是全世界. 最终会将现有的IT模式kill掉 全球的的IT业将从新洗牌.

这个贴子至少证明，中国的软件开发开始“突出重围”了。
已经有了相对大量成功和失败的经验，反思和总结总是必然的。
期待javaeye产生出相对系统性的文章(群)。