什么是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 http://blog.csdn.net/smallfo (不是经常更新不好意思)

大家都说说自己的项目大致是怎么实施的吧 遇到困难如何克服的 希望能引起更多类似的讨论

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

项目总金额才50-100000新元，是不是写错了？
即便按照国内的行情，稍微像样一点的软件公司，摊进管理费用以后2万人民币/人月是一个及格线，这个项目即便按照上限，100000新元=500000人民币，也就折合25个人月，让这样一个团队(一个老大，三个小队长，12个PGer共16人)来干一年，还外包过一部分，亏死了。考虑到新加坡的人力成本，所以我估计你这个项目的总金额应该在50-100,0000新元，而且，即便按照国内价格估算，也要中线以上才有可能挣些钱。

500万16人？也还是挣不了什么钱啊……
怪不得国内的外包现在这么红火……

大家这么仔细啊 我去问个清楚 有错回头再更新 谢谢关注！

纸上谈兵，书生意气。
有本事我们来做同样的一个项目，看看谁的成本更低，看看谁做得更好，用户更满意。

是不是够愤青啊？其实我现在对于这些争论已经没有任何兴趣了。
你可以认为无论侧重于技术还是侧重于管理，做到极至可以殊途同归。不过我还是认为技术的比重更大一些。当然你可以说我只做一些“小”项目，我目前确实是靠做这些“小”项目来讨生活的。而你们的 50w RMB 的项目我看也很小嘛，如果我们按照你们这种方式做下去，最多两年就关门大吉了。实际上 50w RMB 的项目我们大概 3、4 个人做半年时间就差不多了（基本上就是按照 charon 说的 2w/人月的方式来算，前期 1 个多月的需求搜集和设计还不需要投入全部的人力），这个差不多就是我们所能承受的极限了。

我也不想争论，因为至少在年前我没有多少时间来写这些无聊的文章。

是50w16人呀，人年均才3w

嗯 我问了一下，大约在2-5million singapore dollars （乘以5就是人民币了）, 没有更具体的数字，但比起前面提到的不实数据，至少是漏了个0，不好意思



呵呵 刚毕业嘛，在大家眼里估计偶就是典型纸上谈兵型，所以文章一开头就说清了我的背景。其实发此文的目的根本不在于评价XP，而在于我觉得CMM的一些观点还是有价值的，仅此而已，不想做愤青，更不想和大家争论CMM和XP的优劣。
dlee兄，我没那么大本事哦，呵呵，上坛子发发帖而已，不是来单挑的～


对，呵呵，说实在的，就是瀑布啊，在这里需求定得很早，非常细，（顺便提一下，我们的需求是和对方公司有IT背景的人讨论的，so called "technology agency"，而且明确需求也是双方的共识和要求）所以迭代不多，总趋势还是瀑布，我也没觉得有什么不对的。只是在这里说说不同地方不同的开发方法，大家交换一下看法多好啊，为什么“没有任何需要讨论”呢，不明白。（或许这坛子这类言论发表过多，大家看烦了是吧，那就对不起了嘿嘿）

我不同意裸奔的比喻，和这文章没啥关联吧。倒是很同意dlee兄的这句话“无论侧重于技术还是侧重于管理，做到极至可以殊途同归”其实就是这样，如果你在用XP不妨不时参考借鉴一下CMM的一些做法，当你在用RUP等也学学XP，这才是本文主旨，谢谢大家抛砖，我会虚心学习天天向上的 ^_^

to smallfox：
你又在打马虎眼了。你要是真的想认真研究软件工程的话就一定要好好研究清楚这个开发过程如何更好地支持迭代。不能很好地支持迭代的开发过程都是没有前途的开发过程。这个即使不是公认的定论，就算是我 dlee 说的定论吧。我们过两年再来这里看看我是不是说错了。

另外与你想象的不同，其实敏捷方法有着比 CMM 更加严密的理论体系，对于保证软件的质量有着行之有效的套路，建议你先认真看一些 XP 方面的书籍再来讨论吧。说句实话，我很反感那种对于 XP 和敏捷方法没有多少了解就信口开河的态度。从你的这么多话中，我根本就看不出你在支持什么反对什么。最后又来了一个无可无不可的中庸姿态。至少我感觉对于我本人的帮助并不大。

我对以 CMM 为代表的重量级开发方法和以 XP 为代表的敏捷开发方法做个比喻，各位看官看看是不是恰当：

我们小的时候都喜欢听评书，评书里面的武将使锤的往往是最牛x 的。
兴唐传里面有个使锤的祖宗叫做李元霸，隋唐排名第一条好汉。还有一个叫做裴元庆的，排名第三条好汉。
岳飞传里面有八大锤大战金弹子，这个金弹子使什么呢？也是使锤的。那么就是 5 个使锤的人混战。但是有趣的是最后干掉金弹子是一个使双枪的人叫做陆文龙。
除了使锤的，使斧的人一般也都是厉害的角色。
三国里面的许褚、兴唐传里面的雄阔海、杨家将里面的杨五郎，都是很厉害的角色。
关云长是使大刀的，这个没有什么稀罕，稀罕的是他这柄大刀有九九八十一斤重。

但是根据考证，实际上古代作战几乎没有人使用这些神奇的兵器。古代作战用的最多的就是长枪和剑，因为这两种兵器轻而且杀伤力又大，是最实用的兵器。如果一个人真的拿着大锤或者大斧上战场，那简直和送死差不多了。

我对重量级开发方法和敏捷开发方法的印象，就象对评书中的八大锤和正史中的长枪的印象差不多。

惭愧啊惭愧 我确实对XP没有太多的实战经验 回头再好好研究研究 也会多翻翻旧帖看看先 希望在javaeye看到大家更精彩的讨论~~

团队大小是 1+3+5 = 9人， 不是1+3*5=16人，我表意不清 sorry.