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

to 庄
此问题我已经思考了很久。同时我还在考虑究竟什么是软件开发组织的核心竞争能力的论题。如果我们的方法论只是研究基于一个项目的完成情况，不去研究一个企业生存的周期，那么其显然是有缺陷的。
而同时如果软件的质量只是以满足客户需求来衡量，不是以针对客户业务目标来衡量，那么显然也是有问题的。从这一点说，最终的软件是否可以运行，已经有多少bug，易用性如何，等等的话题都是越过我们的客户需求，而单纯的以我们自身的目标为目标的做法。
置于说QUALITY IS FREE是不是一个共识性的问题，如果你从经济学的角度看这个论断显然是占不住脚的。但是问题在于我们不是经济学家，我们研究的是工程。在工程领域质量方面的核心潮流TQC，恰恰就是以这个命题为核心。至少从我开始工作，到今天TQC在工程领域的地位依然没有动摇。它依然和并行工程以及敏捷制作一样是现代工业领域的核心学术派别，并且得到各个从官方到研究机构的广泛性支持。

我在回答问题之前，要首先明确的说一下，为什么我需要在理论上来对于CMM所得到存在的基础进行讨论。其实原因很简单，我不需要摆什么事实，实施就发生在我们周围，并且既便那些支持CMM的人也不能否认CMM不能解决我们目前面对的最迫切问题。而置于他们所摆出的实施，例如所谓的在CMM框架下的TDD和迭代增量，我不知道是不是应该给大家作常识性的解答，从而去证明你们对于TDD和迭代增量有根本性的理解错误。但是我至少希望你们知道所谓的测试可以和编程同时进行的，并且CMM完全不反对这样作的论断，根本就不和TDD有任何的联系。同时我觉得也不需要去给你们说明，所谓在需求阶段就存在几个迭代，所谓大迭代中有小迭代的论断，是一种概念性错误。因为这些你们完全可以去找资料自己对照解决。置于实践的例子，我也完全不需要给你们指出，因为在SCM领域的敏捷实践，在设计领域的敏捷实践，在部署领域的敏捷实践，在过程管理方面的敏捷实践，都是最好的例子。你们完全可以去研究这些最佳实践如何可以在CMM下无障碍的实施。而是不是去讨论什么一个月一次的审计如何如何的话题。其实这个事情的道理也异常的简单，那就是如果判断一个实践是有效的那么就应该做到极至。同时我们还需要考虑一个机制如果不能从根本上杜绝一些问题的发生是否应该去判断这个机制的有效性。落实到你们的例子，那就是如果你们的过程机制不能杜绝不每日提交代码的事情发生，那么你们的机制是不是可以被成为最佳实践。至少从XP的角度看，这个问题可以轻松的解决，而不需要依靠一月一次的审计来完成。

当然有其他方法，不过你首先要解决的是统计学究竟应该怎么应用到软件开发的过程中这个更重要的问上。同时你还需要考虑统计学是否需要考虑其统计的过程需要和所处的环境相互协调的问题。
首先你要考虑你究竟要统计什么，也就是那些数据是你需要收集的，那些数据是你可以忽略的。你的数据最终所反映的事实系统所显示的状况，究竟是否可以作为一个研究的基础。这个问题都不能解决，其他的任何方法都不需要你去理解。
比如判断一个软件的质量究竟应该应用什么模型，其判断的依据究竟应该是以满足客户需求为主，还是以满足开发者为主。同时究竟是以以前的历史数据为主，还是以最近数据为主。你所收集的数据究竟是客观的测量，还是依赖经验的判断。统计最后的归纳和计算，究竟是应该如何提纯，驱除脏数据。这些问题都是首先需要解决的。
而作为XP来说量化的指标是比较细小而精确的。其根本的方法再说使用最近实践的数据说明你最近工作的状态。例如使用点来计算需求所带来的开发工作量，并且不断在各次迭代中修正其数据的准确程度，不断比较，最终逼进一个客观的实际值。而不是依靠其前期的预测和其他项目的统计。

首先你究竟如何去判断effort，是依赖一些不被程序员理解的数据，还是依赖一些看的见的事实。是依赖客户的自身感受，还是依赖一些他们根本就不能理解其意义的数据。
当然作为我来说其实根本就不需要去计算这个数据，因为我使用小迭代的增量开发，每一个迭代的周期都足够的小，其完成的需求都足够的小，其反映的effort也足够的小。如此你就不需要去进行一个长期的统计用来说明你的工作究竟取得了什么成效，因为你今天作的事情，马上就会得到验证。你不需要等一年半载，你最多一个月就会看到你究竟作了什么。而往往你的工作会立刻反映，也就是你做完之后立刻得到反映。而判断的标准首先就是来自程序员自身的判断，他们会对比前期的工作结果，直接的告诉你他们最近的状态。而你不需要担心他们会不会提供虚假的数据，也不需要举行一个评审会。因为在我这里评审是随时随刻不断的进行的，审计也是随时进行的。我们在迭代交接的中间同客户共同研究我们的过程，从而不断的使我们的数据精化。
当然我觉得你需要仔细研究XP的实施过程，才能理解我究竟是在说什么。

什么是最佳，那就是你知道的最好的。其实这是一个社会学的问题，所以如果你偏偏希望得到一个量化的说明是不合适的。这就如同你无法用一个量化的指标去评价一件艺术品的价值，但是你确实可以用一个非量化的指标去评价它。精确和正确不是一个概念，我想你明白这个道理。
当然这样作就需要完全的依赖程序员们的主观判断，我并不觉得这有什么不好。因为工具是他们用的，鞋好不好只能用脚的感觉来判断。
同时我没有那么多最佳实践需要我们去选择，也就是说我们不需要去裁减。我们只是一个一个添加，稳定一个添加一个。因此判断一个实践究竟是不是最佳对于我们不是非常重要。
当然如果从方法论研究的角度去判断究竟那个实践是最佳则需要不同的方法。不过我想你也应该明白，很多问题不需要在你进行一次完整的统计之后才去判断。因为你的经验和事实会很明白的告诉你究竟发生了什么，也就是质的判断也比量的判断更加直接。
例如我想你明白SCM强调粒度的重要，如果你作的配置项粒度越大，其管理和使用的效果就越差。那么你完全就不需要去计算那个配置项究竟代表了多少数值，而只需求去判断究竟它们的大小顺序是如何。

问题是为什么是要我去判断团队是成长了，而不是依靠这个团队所有的人作出的判断。
团队究竟是不是在成长，效果是不是在提高，团队的成员最有发言权，他们的主观感受是最好的依据。因为你们每天做的事情，每日完成的工作他们自己最清楚。
我想你问的问题，这里论坛里的多数人已经知道，而不需要我去告诉他们。

to askycn
希望你能够知道风险控制的最佳实践是迭代增量开发，而不是评审和预测。这一点是目前已经明确得到广泛认同的。
而迭代不是说你搞一个项目分成两个周期，而是要以时间跨度为标准。迭代的周期如果越长，其效果就会越差。同时如果粒度过于小，则会带来管理和配套工作上的压力。作为主流开发方法的RUP推荐的是1周到4周，最佳应该是2周。xp一般和定在2周，其他多说迭代开发多数都在4周之内。如果一个迭代的周期跨度为8周以上，那么迭代所产生的风险控制能力就会大幅度的降低。
而实际上你对于CMM在风险控制上的理解是没有问题，在CMM分析风险，控制风险，主要是依靠评审和审计。CMM没有利用软件工程的在这个方面的研究成果，这一点让SEI感到很难过。因此很有可能在今后，CMM也同DOD一样会进行以迭代开发的改造。
而迭代开发由于其周期限制，和资源投入的紧凑，造成对于流程的要求更加严格。同时由于现代企业的扁平化趋势，也造成对于流程的需求已经同原来完全不同。现在的流程需要的更加简单和控制节点更少更集中，而不是更加复杂和控制节点更分散。在一个开发流程中出现的角色越多，实践上这个流程就越是有问题。而CMM恰恰是反其道而行，这一点是CMM的一个问题。
CMM的产生的背景是冷战时代。那个时候的项目主要是国家项目，其成本要求和质量要求都不象现在这样重要。一个项目的评价由于需要经过一个繁琐的行政流程和政治过程，因此需要一些量化的数据作为依据。而由于那个社会项目的周期都比较长，同时瀑布模型是置于核心地位，造成在项目中对于项目进展的评价非常困难。因此作为CMM这样的体系基础才会产生。
而当代社会发展迅速，更多的项目是周期更加短，预算更加压缩的项目。同时由于企业的人员的思维方式，他们看重的是你的项目究竟进展到了什么地方，而不是看你提供的一大堆报表。也就是他们更加希望你的项目进展可以可视化，而不是用一吨位的数据说明。而由于其需求更加需要满足变化的竞争环境，需求的可变更能力成为对软件开发组织的最迫切要求。在这样的现实环境中你的需求需要的的是可以在最后阶段也能进行变更，并且这些变更不能拖延，需要立刻进行。CMM究竟如何面对这样的现实挑战呢？CMM会使用什么思想来解决适应需求变更为一种开发常态的用户诉求呢？
同时你应该明白CMM不是方法论，所以既便是印度RUP依然占据主要的市场份额。但是由于CMM对于迭代支持的不友好（这一点不需要我们去证明了，你的同事对于迭代基础知识的缺乏就是最好的例证），造成RUP的动机不能得到满足。而迭代的重要性，我不需要给你作解释，我想任何一个当代方法学家都会对迭代的重要进行论述。

to 青海渔风：
其实我关注的就是那些敏捷开发方法最关注的问题，包括：
1、短周期的迭代。这个我以前说是敏捷开发方法的核心。今天 o6z 说其实就是当前主流软件工程实践的核心。
2、测试驱动开发。
3、重构。
4、持续集成。
5、提高开发过程的柔性，拥抱变化。
能否在 CMM 的框架下很容易的展开。如果你们能给我一个满意的答复，我是很有可能欣然接受 CMM 的。但是你们有点自说自话，谈了很多我并不是非常关心的话题（诸如评审，以及印度公司的成功实践等等）。

也许 askycn 留下来，我们能针对这个新的话题继续展开一些有益的讨论。虽然 o6z 的发言让我对其前景不是那么乐观，但是我还是想听听 askycn 针对这些问题的发言。

最后，非常感谢 o6z 对于 CMM 的来龙去脉和其内部存在的一些问题做出的深入剖析，使得这样复杂的问题最终能逐渐形成一个共识（如果在其它某个论坛，这样的话题几乎可以肯定会成为无休止无结果的口水战）。当然也要感谢青海渔风和 askycn 贡献出自己的宝贵经验。

最后这句话就是我们共同的期望。

谢谢你的讨论。不过我想你的结论只在代表你自己观点的结论，不能作为其它。个人来说我觉得看待CMM也好AGILE也好，眼光应该放宽一些，就像剑道中说的“守破离”的那样。
对CMM/CMMI的理解，不见得你的理解就很全面，有可能你高估了自己的能力，低估了网络的能量。同时鼓励整个行业把宝都押在CMM/CMMI上，这样风险太大了。

第一句很对，就像很多general原则一样正确。
第二句可能你带有臆测的成分，或者没有仔细看我们的帖子。因此再次重申一下我们讨论问题的范围和原则：
1. 只谈自己的理解，分享自己的经验，不试图证明自己的理解或经验高人一等。
2. 只谈CMMI的价值所在，及如何在工程实践中发挥这些价值。不鼓吹CMMI以及任何其他方法论。具体项目中工程方法的选择是脱离背景的空谈所不能决定的。

刚刚做完monthly audit，晚上我会写下我的一些心得，希望大家带着冷静的心态，基于我们的最终目标——成功的软件工程实践来讨论问题，不要纠缠与方法论之间的对比。我的意思是，没有对与错，只有适合与不适合。

o6z讲了很多，我基本上同意他的意见。
但是我在项目实施中，发现一个比较悲哀的问题，在我所接触到的客户中间，正有越来越多的客户试图套用传统行业的项目管理的方式来对项目进行控制。
而且还专门请拥有传统行业项目管理、质量控制经验的人来做这件事情。

因为从甲方的角度来看，短迭代意味着几乎要时刻监督项目的进展，几乎无休止的处理相关的问题，对甲方项目管理人员的要求相当高。
甲方往往派不出或者不愿意派出拥有丰富管理和协调经验的人来长期深入的跟进软件开发项目。
大企业的情况还好一点，中小企业的情况更糟。

甲方很迫切的需要一种方法，可以确切的控制软件项目的进度和成本，并且所需要的投入较少。
而CMM是比较迎合甲方的这一类要求的。
敏捷的理念则要求甲方必须负起应负的责任，更多的投入到项目中来。

所以从甲方的角度来看，还会在类似的道路上走的更远一些……

我想起了两个反模式：
1.Design by Committee
2.Golden Hammer

建议讨论问题的时候，先不要急着下结论。

对于CMM的背景知识我看来还需要介绍一些，加深一些大家对于CMMI的认识。
首先CMM包括CMMI的体系来自一种基于模型对过程进行不断的过程改进的思想。这个模型是SEI的研究结果，而过程改进是其实现其诉求的方式。
过程改进的思路是Deming、Grosby、Juran的质量管理工作的一个派生品，实际上我们经常见到的TQC就是这个理论体系下的最主要成功。我希望感兴趣的人能够仔细研究CMM的培训教程，不要再次在基本概念上犯错误。Grosby所首先提出的“QUALITY IS FREE！” 的思想，是实施CMM的一个潜在前提。就是因为这个论断，才可以在过程改进的能使得成本和质量达成统一，以满足开发组织和客户得共同要求。
CMM所使用得模型能力模型，SEI号称是对过程需求得公共集合，是行业中的最佳实践和实际知识得综合，并且是以一种可以用来指导过程改进得优先顺序得格式进行得表示。因此才产生所以得1－2－3－4－5的分级，也就是说那些KPA所属的级别代表了其应该在企业过程改进中的优先顺序。但是显然就如同前面CMM支持者们所表达的，他们根本就没有按照这个顺序进行过程改进，而是依照客观实际的情况有选择的针对性的开展了工作。虽然他们的做法是一种值得夸耀的行为，但是其确实是同CMM的体系相违背的。这样的违背经常性的发生在实施CMM的组织中。
如SEI所称，采用这个模型可以通过已经证明有效的最佳实践来改善或者创建自己的过程。问题在于这些最佳实践是否可以互相协调的进行，以及在不能协调的时候需要优先考虑实施那些最佳实践。这就是优先顺序所要解决的问题。也就是说这些KPA是由一些联系以优选顺序进行连接的一个系统整体，而不是一个离散的部分的组成的环境。这一点尤其的重要，这也是目前大多数实施了CMM和没有实施CMM的企业所没有关注的问题。就如同上面的讨论所展示的，既便是最坚定的CMM支持者，也要无意识之间拿个别的KPA去套其他方法，用意证明CMM的全能和兼容性。
同时CMM有一个基础性的隐喻，复杂性的软件和开发环境必须要复杂的过程来解决，而由此必然带来执行该过程的人数的增加。但是问题在于现代复杂系统研究的结果表明，复杂系统的解决最佳途径在于使用简单过程的组合，从而得到一个可控制的过程。而一个过程的复杂度和参与人数的多数必须保持在一个合理的范围内，脱离其管理能力的扩展是危险的行为。实际上这就带来了一个CMM实施的隐含前提，其实施组织必须要有强的管理能力。同时我们研究当代管理学发现，一个组织的管理能力的强弱与否，恰恰是其是否可以快速的修正流程，是否可以保持流程的最简单化和最直接化。或者说一个公司的管理能力的强弱不是在于看其究竟有多少人，而是在于其实现业务目标的流程是否做到最简单化和成本最低化。这其实就是现在所流行的BPR的思想，和Lean成为最热制造模式的内在理论根基。
同时CMM还有一个前提的假设，那就是规范化的过程有比较优势。显然这样的论断是有问题的，规范化适应的是人数众多的环境，从而可以驱除个体差异带来的行为不可预测性。而软件开发的价值恰恰在于利用个体的差异，促进行为的不可预测，从而达到一个更高目标。实际上也就是说软件开发根本上来说还是一种人类的智力活动，其个体的创造力是这项活动的核心。规范化恰恰是不能提供创造性所需要的自适应的管理方式。
同时CMM面对现今的管理学核心实践并行工程，希望提出自己的解决方式。但是其对于企业的理解依旧停留在以部门作为企业的组织形式，以阶段作为运行活动的流程模型。虽然CMM一再声称其反对阶段的流程方式，但是就如同我们经常见到的情况一样，CMM的企业的生产发生的阶段化是一种普遍的情况。
当然SEI已经看到了这种情况，因此他们提出了集成过程的概念，也就是这个CMMI。其最初的论断是，使用单一模型的集成虽然可以和可能对于一个并行环境进行个别部分的评价，但是个别流程的最佳并不等于整体的最佳。
同时CMMI的提出还要解决不同标准的兼容的问题。如大家所知CMM自身就有集中，比如SW－CMM，SA、SE、people，以及相关的EIA/IS 731，ISO，项目管理框架，等等。
CMMI希望自己可以提出一个公共的模型，以平息不同模型间的不兼容。同时一个统一的模型局势还可以协调不同流程间的不协调，从而解决部分最佳不等同整体最佳的矛盾。
SEI认为采用一个统一的模型可以改善成本效益。也就是说由于使用了一个统一的模型，则只需要以一个模型为依据进行公共的工作。因此就可以减少面向不同模型的培训，减少为执行不同模型而进行的评估，为了维护多余过程资产的费用，维护和采购多种模型的知识费用。但是我要说的是，统一的模型是否可以带来这些成本的减少，是需要进行计算的，这是一个逻辑的问题。
同许多CMM追随者所表现的不一样，CMM是非常强调人的经验的。当然这些强调往往是用来说明CMM自身是行业经验的总结，对其实施自然可以带来对前人知识的共享。可惜的是知识工程告诉我们首先应该作的是开始挖掘自己的经验，分享这个经验以使其转化为知识。只有从自身的经验开始，逐步的去学习他人的经验，才是更加有效和实用的做法。而在已经组织没有任何的自身经验的积累的时候，学习他人的经验不可避免的会带来严重的曲解问题。这样的情况实际上已经非常多的发生在我们的周围。

CMM的客户可见性并不好，其提供的只是一些死板的数据，而不是可以很快兑现的事实。
迭代可以给客户提供众多的直接了解项目进展的机会。关键在于你是否是从需求开始进行的迭代，而不是使用原来阶段化的思维，在阶段中进行的过程反复。实际上就如同上面CMM支持者所反映的所谓在CMM实施迭代的例子一样，多数的所谓迭代使用者依然在使用瀑布的模型，他们的做法不管采用了多少个反复，依然不是迭代的。
关于成本和进度的可见性，我推荐大家学习FDD。这种方法的可视性是最好的，既便没有受过培训的客户也可以直观的了解进度和成本的情况。并且其数据是量化的指标。