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

不是我反对软件工程，反对管理，反对度量。完全相反，我们这里不仅有管理而且也有度量。我反对的是一些人读了几本书以后盲目地相信管理万能论。我和 ozzzzzz 都认为其实在很多场合，技术手段是最直接和成本最低的解决方法。你说 TDD 究竟是技术还是管理？或者是两者兼而有之？其实做好 TDD 的技术含量是非常高的。我不关心你的那些管理理论，我现在只想把 TDD 真正做好，你能给点具体的指导吗？别跑嘛，为什么谈到了具体问题就都不吭声了？大家既然都是专家了，为什么就不能指点一下呢？

另外如 charon 所说的，橘生淮北则为枳。我想主要的原因还是国内一些做咨询的人品行实在太差，除了骗吃骗喝以外没有做多少实际工作，没有取得实效，而且还夸夸其谈带坏了团队的风气。这类人的数量是不少的，造成我现在总是带着一种有色眼镜来看待这类人。

其实对于严肃的讨论，我是很欢迎的。CMM 的问题很多，至少我现在还看不到它和敏捷方法有多少调和的余地。目前我们把敏捷方法认真实施好了已经足够做好我们的产品/项目了。也许将来某一天我也能看到 CMM 的某些优点。

总结一下：条条大路通罗马，不要在 CMM 一棵树上吊死。CMM 从来就没有成为过软件开发方法的主流。

to smallfox：
说句实话，你觉得心惊肉跳还是因为你自己的下盘不稳啊。

怎么说呢，CMM和XP focus的不同，用一个不太恰当的类比，就好像是生产线的组建和控制改进的关系。XP或RUP等类似于各种组建生产线和实施具体生产的方法，着重于工序的划分，机器的布局，人员的配备等等，而CMM则类似于以过程改进为目的的生产过程监控和数据采集的方式，比如配备水分仪、高精度温度计、湿度计、测速装置、以及一些人工的控制采集手段，没有这些东西，主要生产过程照样能运转，但是其运转状态(直接决定了产品质量)，是否存在改进余地，小范围改进如何评价等等都无从谈起。对于制造型企业，缺少过程监控和管理，对于在线质量控制和改进而言是个噩梦(不过，国内的大部分制造企业还没有发展到在线质量控制/改进这一步，或者说有设备无机制)。
在线质量控制的关键一个是度量，另一个是对度量结果和最终产品质量相关性的判断，从而引出改进这条线索。不论又没有上过CMM，现在国内企业做开发过程的在线质量控制的，基本没有，一个是成本问题，另一个也是从度量到改进再度量的闭环反馈机制还缺乏有效的认识和实现手段，绝大多数还停留在度量阶段，有些甚至把度量直接弱化为进度的量化和跟踪!!!(我就看到过一个CMM3的公司这么来搞)。
或者用TDD来类比，由单元测试组成的安全网是开发的重要保障，这个网是对功能实现的一个弱度量和强反馈，但是不用这种方式(当然未必是没有单元测试，而是指测试和开发的分组进行，此时安全网的意义极度减弱)，照样也有人搞出软件来。但是这类开发方式的优劣评判，恐怕更多的是在哲学意义上的。CMM和XP、RUP的对立或者亲和，也是哲学意义多了一点点。

对两边都有利吗？其实未必，这在双方管理和协调上的成本是相当高的，10天很可能只能改一两个小bug，只不过老外对这套还算比较熟悉，所以还能忍受。
用这种方法开发的项目仍然有很高的比率失败，否则也不会有人来倡导敏捷了。

最近参加了一些CMMI的培训, 这才认识到CMMI实际上并一定是那么重量级的. 它只是确定了一些在开发过程中必须要注意的关注点. 而这些关注点, 对于一个软件的成功开发是必须的. 至于你的项目具体采取什么流程来实际达到这些关注点, 是你自己的事情, 各个公司由于产品不同, 文化不同, 人员素质不同, 也不可能完全一样.

我理解, CMMI有点象meta-model而不是model. 同时, CMMI还关注过程改进, 就是你的企业必须有一个机制来改进你的流程.

国内许多CMMI顾问基本上不懂软件开发. 有很多误导. 并且为了给软件公司快速过级, 许多做法非常不负责任.

软件开发中几乎没有什么东西可以说是必须的，这一点真的叫那些所谓的软件工程专家觉得遗憾。而唯一被认为必须要做的好的事情是SCM，CMM恰恰在这个方面非常的不能夸耀些什么。
圣经上蛇对女人说：吃了不一定死。
今天某个顾问对你说：CMM不一定是重型的。

不要那么绝对嘛。:-) 软件开发中还是有一些东西是很重要的。比如需求分析，比如配置管理，比如测试，比如团队沟通等等。虽然可能由于面向不同的市场，做不同的产品，导致对这些关注点的关注程度和具体采用的方法有所不同，但我觉得这些关注点本身确实是存在的。如果你觉得某些关注点完全不适用，也可以不去理他。一句话，CMMI的模型是让人裁剪的，不是让人照搬的。CMMI的作者为了所谓"概念上的完整性"，把很多东西都加了进去。我们可以针对自己的需求和环境，"去其糟粕，取其精华"。

我感觉，从SW-CMM到CMMI, 本身也在不断修正。起码，CMMI的continuous模型的表达就比以前的staged模型的表达看起来舒服了许多。

我觉得真正愚蠢的事情，是政府中那些半懂不懂的人，拿这个东西作为政绩工具...然后就坑了整个行业...

很遗憾啊！你这句话就很绝对！

很重要==必要？
这个问题当然可以绝对的回答！不！
关注点存在==必须时时关注？
这个问题也可以绝对的回答！不！


有一个RUP的笑话：RUP需要裁减，但是只有Rational知道如何裁减。
去其糟粕，取其精华？
就如同很多项目一样，从头开始比保留修改要简单的多！
而且最重要的在于即便在CMMI中从低到高的级别依然存在，而依然存在一种强制性的要你必须达到的东西，而不考虑这些东西是不是确实需要在你的公司中执行。如果你可以把这些都去掉，那CMMI还能叫CMMI吗？


政府的人一点也不愚蠢，他们早就看到了这些问题。但是他们又能做什么呢？那些所谓的专家总是在叫喊一些东西，总是在推广一些东西。政府不可能成为学术和工程研究机构，他们也不会具有这个方面的能力。他们只能从基层得到信息来确定这个方面的问题，而即便是现在一样有众多的人在说CMMI有助于什么什么，有什么什么地方是好的。但是他们却有意无意的把CMMI不可裁减性给隐瞒起来。

可裁减性其实从另外一个方面来看，其实正是现在CMM评估刷把戏，玩手段，买证书的最大漏洞。

其实CMM如果作为一种学术理论是很有价值的，但是如果作为一种工程方法和模型，就只能是毒草。

按这个原则去裁减，什么都不可能被裁减掉。


要政绩的人是外行， 行业人士算是内行吧。
如果说内行被外行坑了，那不是搞政绩的人愚蠢，
只能说被坑的人太蠢。

汗~~ 这个东西是那么好裁的吗？虽然所有顾问都宣称这只是一个框架，可是，做起来你发现你真的被框起来了，跳都跳不出去。很多顾问也宣称和敏捷方法不冲突，可是真正做起来你发现冲突很多，你会被烦死的。

所以，很多东西只是看上去很美……

简直是不可思议啊
需求一完就开始编码了
这本身流程就有问题
初始设计应该在时间总量的50%-60%
而编码只需要10-15%
剩下的就是测试