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

to:ozzzzzz

看了你的话，再回忆前面他们的话，就发现：“一方面他们在强调CMM其实是足够灵活的，一方面又告诉我CMM是体系严谨的。”

问题在于，一个科学、完整、严谨的管理体系，在实行的过程中究竟能够如何灵活？是由操作者自行掌握的吗？

to:青海渔风

我始终认为目前的软件开发管理还不能称之为科学，不同的流派的支持者都是依据自己的信仰在作战的。区别在于推销自己的信仰时，是将别人当成潜在的“异端”呢？还是潜在的“信徒”。

直接一点说吧，大家都是凭着信仰说话，没有谁比谁傻多少，不能有这样的逻辑在背后：“你不同意我的观点，因为你的理解力有问题。”

to:askycn

青海渔风的回答是：“最重要的能力，其实是推行人员自身的CMM修养及表达与推销能力。”我不客气的说，这正是你欠缺的。

但是，我并不认为这事推广CMM最重要的能力，如果你了解霍桑试验的经过，就会了解，在企业中推行改革，最忌讳的就是把别人当成需要“再教育、再培训”的对象。同样的原因，你到这个论坛来，潜意识里可能就认为这里的一帮家伙需要接受“再教育”，“我教育不了你们，就让我大哥来教育你们”，这个思路自然引起了这里的朋友们的抵触。

再补充一句：
由软件工程而来的CMM，骨子里就有将技术人员当成可替换的零件的意识，这也是技术人员最容易抵触的地方。

to 庄
实际上我历来的对于CMM的发言都是非常系统的，既便随着时间的出去，有些问题已经前进了许多。但是基本的框架完全没有改变。所以你才会看到其实他们所说的问题，在很早以前我就已经说到了。这也是没有办法，毕竟年纪这么大了。
问题在于有这样能力的人是否会选择去推销CMM。或者说CMM是不是那些能够很好实施CMM的人的最佳选择，进一步说能够很好实施CMM的人真的需要CMM吗？而CMM如何保证其能够找到合适的推销者，或者其如何保证其培养出来的合适的推销者，在具备相应的能力后不会脱离CMM。
实际上就如同我早就阐述的，CMM目前遇到的最大问题是人的问题。他们没有一群有号召力的推销者，也没有一种能够吸引有能力的推销者的方式。实际上CMM强调的所谓规范化和文档驱动，以及标准等说法，早就让具备推销CMM能力的人远远的躲开。你想有什么样的人会选择将一个过程由有能力的人和精英为核心的过程，改造为一个以过程为核心的过程。至少我见到的人都是会从潜意识中进行自我利益保护的。
实际上这一点也是企业核心人员不愿意参与CMM推广工作，并且往往是CMM最大绊脚石的原因所在。

问题在于在很多企业中一些负责人员往往带有一定的官僚性，他们并不想真正的了解到项目的进展。因为实际情况往往是复杂的（简单的过程往往会产生复杂的结果）。
他们需要的是简化的结果（正如CMM号称可以提供的一样），以使得他们的理解力足以理解，而不是正确的事实。

事实上，你应该注意到，对于没有实务经验的人来说，了解CMM远比了解敏捷更容易获得满足感。
对于后者而言，个人的思考和创造性是不可缺少的。

实际的情况是至少在FDD的情况下结果更加简单和直接，并且数据是是否精确的（注意我不是在说准确，准确需要项目参与者的经验进行不间断的修正）。至少从我使用FDD的情况看，客户对于进度的变化非常清楚。而CMM恰恰无法提供这样实时性的数据。也许这种技术可以应用到CMM的框架下，但是必须满足Feature的设立者有充分的水平和经验，参与评审者也必须有能力掌握这些技术，并且水平必须满足。而在这样的情况下，这些有水平的人会不会选择在CMM下工作就成为一个大问题。实际上就如同我在回应庄的发言的时候谈到的，CMM的最大问题是人的问题。
当然满足感确实存在于CMM中，问题在于得到这些满足感的往往是那些经验和创造性有缺陷的人，而这样的人恰恰不是企业的核心人员。

没错，企业的核心业务人员往往更容易接受敏捷（即使他们不明白概念，但是他们知道怎么去运作），但问题出在主导IT项目建设的不一定是企业的核心业务人员。
这些人会受到来自开发商和企业内部业务人员的双重压力，而本身的能力又有一定的局限，这时类似于CMM的理论就很容易被他们所接受。
换句话说，他们接受CMM不是因为CMM可以搞好项目，而是CMM可以使得他们在搞不好项目的时候推卸责任。
即使在一些比较高层的领导身上也同样存在这种情况。
他们不希望看到真实情况，不希望看到复杂的变化，不希望在自己负责的时候项目产生问题，宁可捂着问题到自己离开以后再暴露……

个人认为这样比较CMM同敏捷方法不是很恰当。就类似于说接口没有提供相关解决方案一样。接口作为一种规范本来就不会提供这种东西，那是接口实现者才可能知道的。
我的感觉是内部具体开发的人都倾向于注重如何解决的方法，而外部人员都倾向于关注外在的度量和最终的结果(CMM)。这是两个不同的视角，其目的不完全一样，这也是导致很多矛盾的根本原因。

to partech
CMM关注的恰恰是过程而非结果，否则其也不是过程标准，而是一种产品质量标准了。其实恰恰就是因为CMM不能很好的提供外部人员所关系的种种数据，才造成了其尴尬的地位。
你说你提供给客户一个报告说，我们的软件有可能有多少个bug，各个级别的bug分可能是多少，这些bug可能在什么情况下出现的几率是多少。这样的数据对于那些不了解软件的客户有什么价值呢？
CMM的说白了还是一个开发导向的东西，而不是客户导向的东西。不解决这个问题，CMM将永远只是一种玩具化的标准。

to clamp
如果CMM成为一些人推卸责任的挡箭牌，那样的结果将是可悲的。当然现在确实是这样的情况，至少在我接触的人中经常提到他们和印度公司合作的时候，提出一些要求，最后印度方面会返回一堆文档，说明这样如何如何不行，从而推卸其对甲方负责的责任。
问题在于如果把CMM看作一种甲方对于乙方过程能力的判断标准，应该带来的结果是乙方更加能够满足甲方的要求，而不是乙方更加愿意按照自己的喜好满足甲方的要求。

完整和严谨是指其定义的精确性，灵活的实施是指其开放性。这就跟C++的定义和用C++来写程序一样没有任何冲突。至于由谁来掌握，你见过C++的开发者指望C++标准中告诉他如何开发一个程序么？


支持信仰的说法，而你说指的逻辑，恰恰是你们自己在发言时的一个问题。这一点，o6z在CSDN的时候就没少被人这样指责过，至于其它人嘛，对不起，你们的发言我看的不多。当然，作为我个人，只要你们说的有理有据，我完全包容你们犀利的文风。


真是欲加之罪何患无辞。我不是天才，我的知识不可避免地有所欠缺，这也是我在这里讨论的原因，但是我绝对不会想来教育你们谁。让青海渔风到这里看看，也只是想让他了解一下这里的各种看法并且分享他的经验。你绝对应该承认，他的经验比你丰富得多，但是我很奇怪，这个号称开放的论坛，却不能让他产生兴趣。你这种思路，我只能认为是“以小人之心度君子之腹”。


CMMI的一个出发点是整个企业的健康进步，如果你是老板你会希望低下有一个不可替代的下属么？至于是不是容易抵触，我想技术人员抵触发不出工资的情绪会更强一些。

我对你口中的专家没什么兴趣，这本来就是个大集市，所以你这种虚伪的客套就免了吧，还不如省点时间写出你的项目管理经验让大家来学习学习。

下面回答你的问题：
1. 不要误解了我说的比较，否则我前面那么多的话真是自说自话了。不要纠缠于同方法论的比较，是因为CMMI本身不是方法论，这是个公认的事实，比较起来没什么意思只会沦为口水战。你见过拿GMP和药品生产流水线比较的么？
2. 如何看清CMMI的优缺点，你忘了o6z的教导了：实践是检验真理的唯一标准。也许你确实经历和很多失败的实践，而比如GMP在执行过程中也会遇到诸多挫折，但是我确实可以告诉你很多正确的成功的实践。我几天前来到这里的时候就是为了找一些有兴趣的人来探讨实践，而且也预料到在这里说多了背离这个论坛主流的观点肯定会卷入离开主题的争论，但是也许是我太年轻沉不住气，最终还是被卷了进来。
3.关于CMMI的真正价值，我愿意向你重复一遍前几天写的那段小小的比喻（o6z的批评使我改进了一些说法以更精确地表达我的理解）：

先和o6z辩一下几个杂乱的问题

你没有理解青海渔风所说的质量成本所言何物，就搬出“Quality is free”这样的大标题出来，这就是为什么我觉得你这句话纯属教条主义。按克罗斯比的理论，不合格品预防措施的成本总是低于修复不合格品的成本，这就是为什么他可以认为质量免费。但是质量成本就可以不计了么？要想得到越高质量的产品，无论在何种工程实践中，缺陷预防的成本也会急剧攀升，比如更好的员工培训，更精确的公差标准，更自动化的工具等等都增加质量成本。这样的简单的概念是不应该被误读的，希望你能认真地理解我们想要表达的东西，而不是屡屡制造断章取义的嫌疑。

关于数据统计方法的问题。你所提到的XP的细小而精确的数据分析方法，的确有可能能保证一个小项目的顺利交付。但是忽略对企业整体横向和历史数据纵向的分析会带来很明显的问题，你无法知道一个项目组以外的世界。也许作为项目经理，你的视野是足够了，但是作为更高层的领导者，他什么都不能掌握，只能依赖于项目执行者的经验和良知。这对于商业社会里面的企业是不可想象的。纯粹的XP不会告诉你如何解决这些问题，因为它只是关注当前项目的交付。这就是为什么很多人质疑XP在大项目中的表现，为什么很多狂热的CTO或者PM们无法在组织内大规模推行XP的原因。而CMMI，除了关注一个项目的表现之外，提供了基于整个企业的视角。

而对于effort的统计，本身就是数据抽象的一种形式。诚然，在较短的迭代时间内你可以看到你做了什么，而且当你需要对一些事情做计划的时候，可以使用“细小而精确”的短期历史数据作为参考。但是，这里隐含了两个前提，其一就是迭代过程中组织及环境的相对稳定，第二是你的短期历史数据足够准确。前者可以说是梦幻团队加好运气的典型表现，后者正如你所说的“精确不等于准确”。XP强调应对需求的变化，这本身没错，但是在实际操作的过程中，需求的变化很多时候可以博得客户的理解，更为头疼的却是团队的不稳定，所以对于基于经验的计划带来了极大的难度。而在CMMI的统计学项目控制框架下，针对个人的effort统计数据可以评估个人效率，而且按照统计学原理对大量历史数据的综合分析可以得到相对合理的参考数据，这两个问题都可以迎刃而解。这也是统计学原理在工程项目中的价值所在。

而对于团队成长，你根本就是在回避问题。CMMI强调经验，任何工程过程都强调经验，XP甚至依赖经验。但是CMMI的另一个特征是关注如何把经验转化成知识，如何把知识高效的传播。至于具体如何做，我们公司有成型的流程和方法。至于证据，公司对于我这个没有什么经验的人也能委以这样的任务，而我做起来并不困难，这就说明了知识传播体系的成功。像我这样的经验的人，各位老大敢让我独立带XP的项目吗？DLEE说得很明白，这同时也说明问题所在。所以CMMI在促进团队成员个人成长方面，也具备很完善的指导意义。