【理想流】CMMI批判（二）

CMMI批判之一

CMMI实施中的偶然和必然

从方法论的来源来看，必然是先有实践，而后对实践进行抽象，基于其相同部分，进行进一步的分析和归纳，最终形成方法论。所以方法论本身必然即是有限正确的又是不完备的。 因为CMMI要想成为一种标准，那他就必须忽略具体项目的个性，而基于共性。而又因为他是基于共性，那他也就不可能直接指导实践。

这世上从来也没有，也不会有一种方法论，是放之四海而皆准的。而象CMMI这种大型方法论，尤其需要不停在实践中调整，才可能对现实起正作用。这样决定最终成败的关键因素就变为这种调整究竟应该如何发生？调整的结果又到底怎样？

调整只能在应用的过程中发生，而不管应用CMMI或者其他方法论的，其根本目的是促成公司或项目组发生一些变换，进而在QCD（Quality, Cost, Delivery）上取得一定收益。

关于如何促成一个公司发生改变，《从优秀到卓越》这本书里有一些很有趣的观点可供参照。

比如：

你不可能使一个拥有50000名多员工的公司去拥护一个全新的激进策略。

实现从优秀到卓越这种跨越的公司，往往开始的时候并不公开宣布他们的伟大目标。......逐渐领悟到他们采取的行动的伟大意义... ...。

无论最终结果多么富有戏剧性，从优秀公司向卓越公司的转变从来不会突然降临。这里没有雄伟的规划，没有一了百了的创新，没有一个幸运的突变，更没有奇迹的瞬间。

可坚持到底的转变总是遵循一个能够预测的模式---从积累到突破。

而谈到无法实现这种跨越的公司时，作者又说：

他们不仅不通过飞轮逐圈旋转来积累动量，反而设法略过积累阶段直接跳跃到突破阶段。然后当他们面对令人失望的结果时，他们又摇摆不定翻来覆去地改变飞轮转动的方向。

作者想表现的观点可以说的更直白一些：成功的变革通常是一个由内向外的渐变的过程。而试图由外向内，进行突变，则大多失败。

这个观点符合辩证法的量变到质变规律，可以说是客观真理。

与此相对应，似乎实施CMMI就应该循着下面的过程来逐渐调整，逐步推进：

发现自己的问题，流程改善 - > 确认是否获得收益 - > 如果每次总能有所收益，那么证明路线是对的，可以进一步实施。

这样实施起来，由于已经取得收益，强行推行流程所带来的抵触情绪自然也就不存在。

但现实情形似乎正与此相反，而更像《从优秀到卓越》中描述的无法实现跨越的公司。

先确定什么时候通过，接下来咨询公司介入，管理层强行从上向下，由外向里推进... ...。

CMMI过程域中有一项叫做风险管理，但当企业把CMMI本身作为一个项目进行推进时，往往它却总被无视。做新项目的时候，我们知道短时间内应用太多新技术会导致风险上升。而做一次CMMI，我们究竟需要导入多少新东西？很多时候CMMI并不仅仅是流程改善，为做需求管理可能要导入COCOMO,FP法乃至其他，为做度量分析，机构过程性能等可能又要导入某某模型... ...。

倒不是说这些东西不好，只是如果仓促导入，那结局就必然吉凶未卜。

对此，我个人毫无根据的猜测是：逐步调整并应用CMMI这样的大型方法论是需要时间和金钱的。而这点似乎与中国软件行业所处的位置形成矛盾。即使明知道用五年时间，经由实践--理论-再实践-再理论的不停反复，最终可以取得成绩。真的有企业会这么做么？

按合理的方法耗时太久，即使达到2级或三级可能也需要三年或五年的时间。而这对许多怀着“一万年太久，只争朝夕”这样一种心情的人来讲，是不可接受的。

国内相当一部分企业实施CMMI，但无法取得收益，貌似是由一系列偶然因素所导致，比如：人员，比如资源，但实则不是。就好比两人对弈，每次落子，似乎结局都将因此而改变，但实际上最终结局通常早已经由棋手的棋力所决定，最终胜负不过是一系列偶然后的必然。

可以说，很多时候，当企业把目光转向那一张证书的时候，其实已经在深层次里埋下了形式化的种子，后续的不过是等着它什么时候发芽而已。

人件的作者曾经一针见血的指出：CMM的自相矛盾之处是：过程改进是好的，但是过程改进程序不是，或者说至少它们不经常是好的。诚哉斯言！

CMMI的副作用

也许我们可以这样来概括软件开发过程。先是用需求开发构造软件的概念，接下来把这一概念映射到程序模型并实现它。

而又由于软件的概念边界很多时候与人类社会宽泛接触，所以导致人类社会这一世上最复杂的系统中的种种不确定因素会很容易干扰到软件的概念，这种干扰再进一步传播，必然增加实现的复杂度。所以很多时候，构造数学库的程序，反倒比构造信息管理系统更为简单。

也正基于此，Brook在《人月神话》中指出：

所有软件活动包括根本任务----打造构成抽象软件实体的复杂概念结构，次要任务----使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。

这是极端深刻的。

掉过头来讲如果软件的复杂度确实由此而起，那么流程就远不是一个较佳的应对方案。

与此相对应，反倒是《人件》中的观点更有创见。

毛主席曾经讲：决定战争胜利的是人，而不是物。同理推导，决定项目成败的是人而不是流程。

Bill Gates曾戏称：“如果有一天早晨醒来，微软被大火烧个精光，给我20名最优秀的员工，一切马上就可以重新开始。” 如果中国企业真的只把这看为一句玩笑，而不去领悟其中的道理，那恐怕外包以及系统集成真就是一种宿命了。

而CMMI极为不好的一个副作用就是他使人们不愿去正视上面所说的这类真实存在的问题，而更愿意等待流程来解决问题，等待问题自动消失。

虽然这并非CMMI本身的罪过，但现实中CMMI却真实的发挥着这样的作用。我不杀伯仁，伯仁却因我而死，所以这个黑锅CMMI是必须背一背的。

CMMI来头过大，许多人对其仰视的同时迷失自我。最终在其东风之下，在项目运作中流程至上也就大行其道。隐约间，凡是项目的问题都可以用流程来解决，凡事流程没解决的问题都是流程还不够好。

且举一例：

某软件项目组，发现Peer review的效果不好，进一步分析后，发现其主要原因是一众参加者事前不学习材料，Review时三缄其口所致。考虑解决方案时，首先想到的是改善Review的流程。即先把Review拆分为两个阶段：Pre-review和正式Review。在这两个阶段都详细定义参与者的各种角色，同时要求参会者必须把自己Pre-review的结果登入数据库。

该项目组实行CMMI已有数年，迅速想到用流程来解决问题未尝不是CMMI泽惠。

诸如此类，凡是涉及到产生错误的地方，都试图定义一组流程来规定详细的步骤，进而约束项目组员的行为，恐怕不是只在某一家公司里存在。

这很可怕。

最终的结局，必然是所有的人都仿佛陷在茧里，毫无生气，做事形式化，生产效率低下。 当本质问题不解决的时候，就会有各种表象，针对每种表象定义规范，只会使规范成为一种负担。额外的负担越重的时候，也就越发无法专注于本应专注的实务，最终导致更多的问题产生。这简直就是一个恶性循环。

就上面的例子而言，本质上应该是管理问题，是人的问题，而非流程问题。打一个简单的比方，如果一个人在一小时内只能从井里打5桶水，在士气或技能没有提高的情形下，你即使多给他一个桶，那其实并不能让他变成每小时打6桶水。

Review这种事也是一个道理，如果一个人在当前的状态每次review能发现5个错误，在他的生产能力没有提高的情形下，无论你制定怎么样的流程，分成两次也罢，记录结果也罢，最终每次review他所能发现的错误仍然只能是5。（如果逼急了，也许数目上会从5变成10，但很可能其中5个没有任何意义。）

流程虽好，也能解决许多问题，但现实世界中并非所有问题都是流程问题。只可惜CMMI树大招风，宛如点石成金之术，也就只能被人四处滥用了。

结束语

记得许多年前，ISO刚兴起的时候，很多公司也是一窝蜂的去上ISO，可以想见，CMMI实施若干年后，如果中国的软件公司仍然无法取得突破，那么一旦有一个新的方法论出来，那么很多人的兴致十有八九会由CMMI转为其他。这来来去去的折腾起来，对咨询业到未必是什么坏事，对企业恐怕却会损伤根本，甚至坐失良机。

有句话毛主席曾经非常欣赏，碰巧对这里论述的问题也有些借鉴意义，稍做调整后，把它录在这里：

横尽虚空，山河大地无一可恃，而可恃唯我。

竖尽来劫，前古后今无一可据，可据者唯有当前。

1000个成功的企业中，隐藏于成功背后的东西可能各不相同，但他们却都成功了。模仿，学习不是不好，但如果忘记了“唯我”与“当前”四字，画虎不成反类犬就几乎就是种必然。

------------------------------------------------------------------------------------------------------------------------------------

理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质，追求真理。