什么是CMM真正的价值？

此文系 www.javaeye.com 论坛一篇长文“CMM到底给我们带来了什么”的读后感

看了大家关于CMM的讨论，挺有感触的，在此也发表自己的一些观点

个人背景－2004新加坡国立大学毕业，现在一家本地公司(CMMI-4)工作，工作经验8个月，资历尚浅。

团队背景－－个项目经理，经验十余年，手下三个四年工作经验的project leader。
leader A负责文档管理(Librarian)，业务逻辑谈判整理及所有数据库相关的任务(DB design & data migration)。
leader B负责架构设计，系统集成和所有Security相关的处理。
leader C负责编写跨项目的可复用代码，并和leader B负责所有技术相关的事务
下面平均有4－5编程人员，包括我在内，平均工作经验1年，说平均是因为人走得很快，来来去去很不稳定

项目背景－这是一个WebApp. 团队管理基本遵循CMM规范，项目从Requirement Gathering到交付为一年整，原来设计外包给中国分公司，后来因为分公司赶不上进度，在几次内部Testing负面反馈较多的情况下，改成一半外包一半自己做，最后外包的那块质量还是不行，在项目进度无法保证时，新加坡总部担起了外包那块的UAT和最后系统测试及调试任务。项目总共约50-100，000新元

项目进度表－
Nov2003-Mar2004 3－4个月需求收集，一系列仿真的界面设计，客户在确定需求并看过界面原型后签字，此阶段告一段落
Mar2004-Apr2004 1－2个月分公司开始写代码，具体情况我了解得不太清楚
Apr2004-Jun2004 一半任务被总部收回，两边都开始赶进度
Jun2004-Aug2004 分公司不再负责代码编写和调试，赶进度到了最高峰，几乎天天加班
Aug2004-Oct2004 编程任务赶完了，系统测试开始，连着三个月
Oct2004-Now     零零碎碎的事一直做不完，UAT,培训，兼容性测试，调试优化 等等。。。

项目现状－在这样一个人员快速流动的公司，在外包基本失败的情况下项目现在基本接近尾声，没有拖延太多时间，虽然在七月份的时候大家基本每天都在熬夜到至少11点赶项目。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

lucifer在一开始就发问“难道文档和流程可以大于人的因素吗”。我觉得在现代软件工程的思想还是围绕在人，这不容置疑，强调流程是因为人会犯错，会不知不觉犯错，而有一个规范的可遵循的模板提供了一个及时发现各种错误的机会，并提供了纠正错误或挽救项目的建议。这些行为的最终执行者还是人，所以我觉得就这点而言，CMM并没有错，CMM要求写一大堆文档的初衷很好目的也很明确，具体到项目中自然有执行上的限制和区别，但它的核心价值不可抹煞。其实用其他方法一样可以借鉴CMM的规范，可惜似乎很多公司提到CMM就只在文档上打转，而毫无利用其中的资源，我个人觉得挺可惜的。对于有些网友说的CMM只适用于外包，说实话我不太理解其中缘由，我觉得在mindset上对CMM的应用不应有如此限制。

话说远点，通过SCEA的学习，我认识了一个国内的朋友，我们经常交流在项目管理上的问题，据他说，和客户谈需求只到UserCase级别，最多到module级别就停下来了，此后团队开始架构设计和编程调试，客户在这一过程中会不时提出/完善需求，很自然的，有相当比例的代码要重写，最后几乎没有按时完成的项目。反过来看，在我所在的公司，公司和客户有着完全不同的需求采集过程，相当详细的业务逻辑和界面设计在第一阶段就被反复讨论直至确认，客户签字，然后真正的设计编程才开始，所有的会议都有记录并抄送双方，以便以后有争论时做证据，这些都有利于项目组的进度和资源管理。在另一方面，拖延项目进度有着非常非常高昂的代价，这也保证了客户的利益。因为所有的过程有凭有据，所有的合同都详细记录了双方的责任和义务（客户不能随便任意加需求，我们也不能无代价地拖进度），相关的文档（基本都是CMM规定的）就成了项目不可缺少的一部分。Money is the key! No Money, No Talk, isnt it? 写到这，我觉得如果有些公司的流程正如我这位朋友所经历的，那么一大堆CMM文档确实显得毫无必要，但缺少这些文档的支持，项目后期的维护和既定scope的控制就变得不可预知，更不用提如何控制进度和支出了

我最近在上一门课，讲SE的，老师来自英国，他说在那种大型项目中(欧洲防御智能系统)，mangement所占的比例有50-60%，如何协调各个方面的资源，包括人力资金时间，还包括如何控制项目的进度质量后期维护，都不是一件简单的事情。我想说的是，即使不是这种上十亿英镑的项目，中小项目也有它自己难控制的地方，而他们所需要的正是CMM所提倡的Identify it, Control it的思想。或许5人的小项目根本没必要用CMM,但如果我们没有将CMM的概念刻在脑里，用了XP也同样保证不了项目最后的成功。

我赞成这样一个观点，CMM的观点能保证项目在正确轨道上运行，更能保证一个软件公司持久地有条理地运作。很多概念如Function Point都可以用来衡量一个项目最终执行的效果, defect rate, man-day cost per module等等，它们将作为很重要的指标为下一个项目提供方向。不要说每个项目都不一样，所以measurement毫无用处，我认为恰恰相反，每个项目都有它的特点，也有共性，在管理层次它们的共性提供了跨项目的衡量标准的连续性。这些数据是珍贵的，是一个从来没有执行过类似规范的小公司不可能拥有的。从文档上看，已有成功项目的模板确实很重要，我周围很多后继项目很快就上路了，一定程度上就是得益于这些模板的帮助。

dlee说“软件开发的中心永远都不是过程，而是有创造力的人本身。” 作为一个开发人员，我看了这句话很激动，我赞成这种说法，但这句话还能再改进一下。软件开发本身未必代表了一个项目的唯一价值核心，是正确合理的过程将那些有创造力的人聚合在一起从而创造利润。或许正是极限编程在这方面做得很好，使得它广受赞誉，但说实在的在几乎所有的跨国公司里，还没有一家用XP维系自己IT部门的命脉，这从另一个方面说明了CMM的不可取代的价值。

dlee还说"确实，在 XP 方式下做开发很累人，你很难找到什么借口推卸自己应该承担的责任。而在 CMM 方式下做开发可以捣浆糊的机会则要多的多。" 这句话很有意思，我想在这也谈谈我周围新加坡人，简单地说，他们非常敬业！负责写UAT plan的人，花了一周就写出了百页的plan，那百页可都是实打实的家伙；还有负责做Testing的，每次都会认真记录bug；也有人专门负责系统集成，反复测试，没有怨言；我觉得这都是作为一名程序员非常重要也非常基本的素质，恐怕我们中国的程序员能做到这一点的不太多，面对冗长的文档，我们或许更多地抱怨或舍弃它，即使更新文档并不是想象中那么花时间。

最后简单总结一下我的观点，
1 CMM强调的Process Control的观点非常重要且绝不过时
2 CMM究竟是轻量级还是重量级取决于你怎么用它
3 不同国家地区文化和思维方式的不同导致了对CMM理解上的偏差
4 CMM对项目有好处，对组织公司更有好处
5 人和过程只有结合，才有火花
6 人－素质－敬业精神－工作态度！

大家随便抛砖，小的不介意。另外欢迎大家光临我的blog (不是经常更新不好意思)

希望和我讨论软件工程,SCEA认证(正在考)的 请加 QQ 2387763 (注明SE/CMM/SCEA等等)
有意和我*长期*交流IT相关的资讯并结交朋友的 请加 MSN [email protected]