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

青海渔风
========
CMM不能打破这个循环。或者说CMM不是用来打破这个循环的工具。我想在这点上我们又达成共识了。

那么，CMM在这样的循环是扮演了什么样的角色呢？
首先，它在中国的不适应，进一步凸现了这个恶性循环的存在。
第二，在将来这个恶性循环被打破之后，我们的大部分的行业参与者能够接受“质量成本”计算在价格之内的这个观念之后，CMM能够帮助我们量化质量目标、并控制好“质量成本”。并且能够使得企业能够持续改进。

打破这个恶性循环，这不是CMM的责任。

至于怎么打破这个循环，坦白说，目前还没有找到被普遍接受的解决方案。不过，根据这些年的观察，我在前面的帖子中也总结了一些看来似乎有些希望的方案，就是：将“质量成本”计算成企业发展所必须的投入，而不将其计算入项目的成本中去。这样，打开恶性循环的缺口。

在这方面的例证就是：国内实施CMM出了成绩的几家单位，在实施之初，都是有利润压力的。最后，这个压力由公司高层出面来解决。即从资金与人力上，确保推动。从而使得企业度过了实施CMM最初的一段时间的痛苦。慢慢走上良性循环的道理。

我早就在讨论cmmi究竟适应什么范围的问题，而恰恰是你们在一再声名cmm如何正确，这一点恰恰是我要告诉你们的。cmmi是有价值的，但是其价值往往被其的水平的支持者的言论所淹没。或者说我们从这些人的言论中的得到的结果只能是cmmi毫无价值。这是一种悲哀，反对CMMI的人在不断的寻找其价值，支持CMMI的人在不断诋毁CMMI的名声。
同时建议你们系统的需要软件工程学的知识，不要在基本概念不清楚的情况下去研究cmm，这样的做法只能是去曲解cmm的内在本质。例如你们可去看看究竟什么是迭代，否则我们的讨论就非常难于进行。
本着善意的态度我在这里解释一下迭代的基础概念，希望你们仔细学习。
迭代的定义：迭代开发是构建软件（或者其他东西）的方式，整个生命周期依次由几个迭代组成。每一个迭代都是一个自包含的袖珍项目，他们由活动组成，例如需求分析、设计、编码、测试。每一次迭代都将产生一个迭代版本，这是一个部分完成的项目，但是它是稳定的、完整的、可测试的并被测试过的。更进一步说全部团队的所有软件都是由这些迭代版本组成。
同时我们也要注意到从理论上来说迭代开发只能是简化过程和优化性能，并不能带来对风险的规避和项目的完整，因此迭代往往是和增量开发结合使用的。因此我们平时说迭代开发的时候往往是说迭代和增量开发。
其实所谓的敏捷方法其实就是现代迭代开发的一个代表，我们真正应该研究的是迭代和增量。这个体系中的方法包括你最经常见到的一些，up、msf和敏捷的所有方法。
关于迭代的基本知识我建议大家阅读Craig Larman的《敏捷迭代开发－管理者指南》。大家可以在comp.object找到作者。这里我要说明的是名字中的敏捷在我看来说多余的，似乎是作者为了销量而添加的。书中阐述的迭代的理论内容，介绍了SCRUM、XP、RUP、Evo四种方法。而在我看来介绍Evo的比重最大，大概的原因是Evo这种方法足够的老。
下面介绍一些TDD的问题，TDD原先叫做TEST FRIST，后来进一步的进化为有测试驱动的开发。其核心的关注点是由测试案例去驱动开发，而不是由设计去驱动开发，或者说人们由原来为满足某种设计要求而编码，改变为为通过某个测试案例而编码。TDD和重构一样是xp用来强化设计的有利武器，他们的出现屏弃了原来的所谓概要设计到详细设计到编码实现的可控制性低，质量不稳定，维护和修改成本高的问题。TDD的一个要求是从需求开始而不是从结构开始建立你的测试，这样作可以直接针对具体化的需求进行编程，而不是对一个经过多次折射的映象进行编程。同时由于你如果进行了详细设计，那么由于TDD会自然性的伴随重构，对于维护一个设计的稳定和涉及到的编制者之间的协调将十分困难。而TDD的小不前进的策略往往还会对于SCM造成一定程度的压力，对于那些不能灵活使用SCM并且具有一定能力的组织，推行TDD和重构是危险的。当然这样的组织环境下推行任何方法都是危险的。

to:青海渔风

认识到自己目前处于“社会主义初级阶段”，是非常重要的收获。

在这样的前提下，我们才能够来考虑：“如何在现在这样的恶劣环境下，提高我们的开发管理水平。”

软件开发过程中的成本管理，或者说得更广泛一些：“量化管理”，是非常有必要的，哪怕是一家3个人的小公司，也必须考虑成本，否则他就无法生存。

如你所说，现在CMM不能帮助我们（注意，是现在的我们），而只能等恶性循环被打破之后，才能作为天使下到凡间。那么，在现在这个阶段，我们该如何控制成本，做到心里有数呢？

很多推行软件工程，CMM之类的人，都认为这件事情关键在于老板要下决心，但是问题在于，如果这个老板自己还在生存线上挣扎，你如何说服他去花那些“闲钱”？

这样的发言让我想起了上ERP是找死，不上是等死这句话。
质量成本是不是需要被负担，同时需要被什么人负担都是问题。我们现在与其等待甲方改变，不如努力的适应市场。
说一千道一万，其实最后在一点上我们双方已经达成共识。也就是在目前国内的商业环境性cmm不能接触根本问题，如果在此基础上进行讨论，我觉得意义已经不大了。cmmi再好，如果不能解决我们简单的问题，它的价值是不是要受到削弱呢，其所谓的指南性和指导性又如何体现呢？
同时我们还需要看到我们国家的软件行业的最重要认为还是满足自身市场的需要。国内的中小性的企业有大量的信息化的需求，但是他们的负担也很中，能够投入的资源也有限。在这样的情况下，要他们负担所谓的质量成本是不合适的。当然又开发方来负担这个成本一样不合适。
总之我们所处的环境同印度软件起飞的时候有完全的不同，他们又同美国有完全的不同。不看到这些不同，单纯的以别人的经验为我们模仿的目标是不合适的。
当然我们必须看到目前的竞争已经或者将要进入一个国际市场国内化，国内市场国家化的年代，单纯的以一种方式进行操作的行业是危险和无前途的。

这里我需要补充一下以免你误解，检查，或者用术语说是审查，的确是由质量部门一个月做一次的。而开发过程中，把代码不断提交到或者更新自版本管理系统，这是团队的基础素质，需要审查才能做得到么？审查的目的是找出由于疏忽造成的问题，而由于基本要求都不清楚而造成的问题，建议由培训来解决。

青海渔风
========

凡事都有一个渐进的过程。在你的发言中，有两点：
1. 是否要等恶性循环打破之后，才能作为天使下到凡间。现阶段我们能够做些什么？
当我们在问这个问题的时候，其实就是在心里觉得等不是一个积极的态度。总会有一些其它办法的。
单位质量所投入的成本有一个递增的过程。也就是说，在质量越高的情况下，想再前进一步，需要投入的成本越大。那么，换句话说，如果我们起点很低，那么，做一些质量的工作，投入就未必有想像中的那么大的。关键是要选好切入点。

根据我这些年的观察与总结。在CMM上，好的切入点有以下几个：
a) 配置管理
b) 需求管理
配置管理是一个相对低投入高产出的CMM活动，而且，这也是为什么一个企业在实施CMM的时候，相关人员马上大叫着配置管理原因。公司在做配置管理的投入，最简单的情况下是一个文件服务器，以及一个版本控制工具。当然，还要有一套制度与一个推行的人。
在推行配置管理的时候，项目中的人可以兼职的。他需要做的就是制定配置管理计划，标识出配置管理项，然后，每个月做一次审计。然后，及时更新配置项的状态等。看起来似乎工作很多，但是，实际上，并非如此复杂。比较配置管理计划与配置项，一次做出来之后，其它项目都可以拿过去修改一下就可以用的。而每月的审计大约是二个小时的会议就可以。至于配置项的状态更新，是一个日常工作，但是，对于一个小型的项目而言，其量也不是很大。因为需要配置管理的项不是很多的情况下，每天更新的内容不是很多。坚持每天做的话，其实很容易做完。

至于需求管理，是在CMM中经常较早实施的活动之一。为什么呢？它与配置管理不同，它并不会让你看到立竿见影的效果，而且会给实施之前人员的工作方式带来很大的干扰。
但是为什么我们还要推需求管理呢？因为它的推行，对于项目的质量控制有很重要的意义。CMM的效果必须通过质量来体现的，而需求管理活动，很大程度上帮助实现这了目标。
这里不能够展开需求管理具体包括哪些内容，因为内容很多。不过，粗略地讲，就是跟踪每一项需求及其变化，以及这些需求在各个阶段的制成品中的体现。这里的跟踪，在技术上，可以简单地表现为一个TraceabilityMatrix，它可以是一个Excel表，也可以是定制的一个需求管理软件。

综合来看，这两项是相对成本较低的切入点。坦白说，这两项的引入，不仅仅是质量的事，而且还是可以提高项目的工作效率，从而通过节约项目的其它投入来抵消部分“质量成本”的。
比如配置管理，如果没有它的话，文档不一致的问题，会使得大家工作协调中，不可避免地出现了一些冲突，解决这些冲突是需要时间的。而配置管理没有这个问题。当然还有很多其它好处，这不是本帖的重点，也就不展开了。有兴趣的朋友，可以继续交流。


2. 是否要等到老板下决心才可以？我们可以把所有的责任都推给老板？
如果只是等肯定不行。老板往往不是技术专家。他关心的是投入产出。所以，不见以好处的事，他不会做，也不应该做。
当然，老板不下决心，可以么？也不行。
那究竟是怎么回事呢？
事实上，这同样是一个互动的过程。
首先，必须老板接触到CMM这样的一个概念。不管他从某种渠道得到CMM相关的情况，他必须感兴趣，然后，愿意从某个项目开始进行尝试。在这个时候，你别指望他能够全情投入支持。
这时候，推行CMM的人员，就要注意了。打起精神，从最简单，最有成效的部分做起。在试点过程中，去体现出CMM的好处。
当然，在试点结束之前，老板不能中途失去信心。如果那样，这就没有办法做了。但是，如果项目执行结束之后，推行人员必须给老板相关的结果，来验证在什么样的投入情况下，得到了什么样的效果。即要有总结。
总结之后，让老板有了更多的信心，才会有下一次投入的机会。

当然，这样的循环过程，在实际执行中，涉及到很多因素。包括技术的，与商业的。所以，这个过程中，CMM推行人员就非常重要。

还有一点：在目前我们的客户还不能够接受“质量成本”的情况下，一定要将这些钱认同为：为了公司的进一步发展而做的投资。将它从项目的成本中剥离出来，不跟着项目计利润。只有这样，才更容易些。

呵呵，我不怀疑你对于IBM的历史研究分析。
即使在我所举的个案中，IBM同样成功交付了软件（但是该成功交付的软件完全无法投入使用，因此被迫继续改造，只不过按照IBM的说法是客户的需求未明确或者需求变更）。
但是有一点是确切的，IBM将很难再在这家客户寻找到新的应用开发类的项目机会了（当然他仍然可以继续卖硬件、系统软件和服务）

事实上，在“客户需求明确且没有大幅度变更”的前提下，你说的方法可能是有优势的。但是在目前国内的软件环境下，这个前提几乎是不成立的。

关于第二点，你说的没错，满足业务要求的软件本身肯定是有一定质量水平的。
但是，质量不错的软件完全可能不满足业务要求。
我已经看过（包括自己也做过）不止一个bug很少，符合功能需求确认书的但是最后没有投入应用的系统了。

我特别想知道推行人员怎样“给出相关的结果，验证这些活动的效果"是怎样操作的？通过数据度量还是其它手段？
一般来讲，如果推行人员对业务过程不熟悉，往往事倍工半，这对过程改进的人员要求比较高，往往有很丰富的一线管理，技术开发经验和过程改进的概念，最好两者兼备（这种人自己都可以做老板了）。一个业务骨干，老板会让他去做这些比较“虚”的事情吗？如果愿意，说明老板眼光比较长远，这样就算不推CMM,也会对过程改进比较重视，效果肯定也不错，因为老板自己就在做这个事情。
我觉得问题在于组织内部往往有很多鸿沟，很多政治，如果打出口号是CMM什么什么的，往往已经开始变味了。一个追求卓越的组织，管他什么CMM什么AGILE，符合自己业务情况的改进都应该加以考虑。
CMM在操作上有些悖论，我们还是谈过程改进比较实际些。少谈些主义，多解决些问题。
BTW:
Borland acquires TeraQuest ,是要干什么？
http://www.borland.com/news/press_releases/2005/01_18_05_borland_aquires_teraquest.html

to:青海渔风

现在就需要打破循环的手段，不用CMM行不行？

在量化管理的问题上，还存在一个悖论：
精确的计算出成本，这个活动本身也是需要花成本的。
如果精度的提升所需花费的代价，大于可能得到的收益，量化工作就该停止。

似乎现在大家都认为CMM从1到5，越高级就越好，我看也是个误区。

至于配置管理，这也不是在CMM的范围内才能进行的工作。比如CVS，比如Bug跟踪，早就该正规的用起来，不管是多小的一个开发团队。

至于需求管理，问题就更复杂一些，因为如何才算把需求管好，评价的标准都无法统一。

假设：“我能把所有客户提出的变更需求全部挡回去！”你认为我的需求管理工作做得如何？

说实话，我认为需求管理的成败，更多的取决于“领域经验”，而非“管理水平”。也不是CMM改进能够帮我提高的。

同意楼上的观点。我们也在实施CMMI，个人感觉就是空对空的东西太多了。
我们的实施过程大致如下。咨询公司的一群专家“审问”了我们不同角色的人员，像我就是作为BM“受审”的。专家说我们的流程有xxxx不符合，于是就给了一套规则，给了一套体系结构。然后技术质量部就拿着这个东西制定规范。当然，规则是可以裁剪的——然后技术质量部就说这个是可以裁剪的——问题是裁剪是交给我们来完成的，然后有些是技术质量部认为不能裁剪的，然后我们突然发现有些“不能裁剪”的东西在实际中只是浪费时间，没有任何意义。而问题是，无论专家还是我们的技术质量部，他们根本就不知道我们到底在开发的时候需要一个什么样的东西，他们只是知道CMMI的教材里面说了什么。
说道这里我倒是想起了两个不相关的东西——一个是我对我们的scm管理的看法（请看http://zoff.blogdriver.com/zoff/643601.html，我的blog，呵呵），而另一个就是电子政务中遇到的一个有趣的问题。xxx总局下过一个文件，要求统计xxx率之类。然后下面的局就要统计，需要软件增加这个功能，然后问题来了，这个xxx率要求的数据在以前根本就没有存，也就是说以前的xxx率都算不出来，但是总局要，于是只好提供了瞎编功能。我说这两个例子，就是想说，一个文件也好，一个规矩也好，总要和实际挂起钩来。现在的情况是CMMI和实际之间，总是隔着一条河。kpa说要干什么，就要干什么，这样专家的工作就结束了——而软件公司真正需要的是这个要求到底如何和现有的流程作一个妥协或者改革，这个专家是不管的，然后问题在于，像我们的技术质量部一样，似乎软件公司负责实施CMMI的人也不知道真正他们需要的是“在CMMI的理论指引下，高举提高利润的大旗，降低成本、提高质量，为把公司建设成为赚钱机器而奋斗”，而是为了CMMI而CMMI。而这样，我始终认为，一把锋利的斧子，带来的危害比起一把铅笔刀更大。