翻译：敏捷与CMMI：双剑合璧，更具威力！

如果仅仅从方法论的角度和高度来说，我确实觉得可以踢开cmmi所要求的实践，将敏捷方法与cmmi的关注焦点结合起来。
但是这里还有一个问题，实际上是不同的场景下，如何评估中心关注点的优先级。这其实也是一个对自身进行评价的问题，也就是说cmmi由于没有提供一个可以对自身进行评价的系统，从而产生了一个巨大的逻辑线索漏洞。这其实是比阶段式方式更加应该改进的地方。

CMMI评估还是可以根据一些实际公司的情况，比如基于文档情况。但是对自身的评估体系怎么去评估呢？我们能不能往前走一走，帮SEI想一下，如何去进行这些评估。公司过程改进投入产出比吗? 提高质量带来的好处怎么进行量化呢？所以，我觉得对CMMI本身孤立的进行评估是不可能呢。他必须与外界相互作用才能产生效果。然后根据这些效果去评价。还有，如果说最后过程改进效果不理想，是实施的不够好，还是CMMI评估体系本身的问题，谁能说清楚呢？SEI的人肯定会说我们实施的问题，但能说这种评估体系本身没有缺陷吗？因为CMMI的实施对企业文化，流程，职责划分都产生了影响，这些影响是好的还是不好的，适应还是不适应，都很难定论。

我不觉得我们有帮SEI的责任，并且我对于SEI现在实施的cmmi评估的方法都存在根本上的反对。
比如他们信誓旦旦的承诺，cmmi这个评估可以对软件开发过程进行评审。那么我们看看这个评审是如何进行的。其实说起来很简单，就是先看看文档，然后找人谈话，前后时间是多少大家可以去自己查。我不认为这样的做法是一直负责的学术机构能够搞出来，并且在世界上推行的标准。对过程的评估一定要经过一个比较长的持续跟踪和多角度多侧面，并且还需要考虑成本和产出因素的综合评估系统。否则这个评估的结论，仅仅能够说是基于评估那个时刻很小的一个层面的一个状态的评估。
而另外一个问题是由于SEI不能做到上面一点引申出来的问题——SEI由于不能提供一种基于长期跟踪的评估方式，所以他们过于强调文档的作用，很多时候都是基于对文档和人员访问的间接的评估，而不是直接深入现场和过程的直接评估。

CMMI/PSP/TSP 是从 TQM 里借用的基本思路，这是本质的缺陷，试图用机械论来规范软件开发，从理论上看很科学很美好，但人的复杂性远远超过生产线的管理，所包含的随机性和心理性问题是 CMMI 体系里完全缺乏考虑的。更糟的是，为了影响力甚至商业利益， SEI 将 CMMI 的思想体系标准化，让 CMMI 从方法学变成了争取订单的工具。
我们的公司曾经成功使用 CMMI 体系争取到了订单，感谢。但 CMMI 承诺的质量水准、更高的总体效率、更高的客户满意度、更好的开发人员感受，对不起，全部欠奉。我们的客户，一家世界领先的电信设备制造商、CMMI 体系的坚决拥护者，从相关的几个项目中也只收获到挫折感，最后仍然要靠非流程化的个人英雄主义挽救项目。
比起 CMMI 理论上的完备性、严谨性，各种 Agile 过程看起来很原始，简直就没有体系。但它的程序员自管理的核心逻辑才是真正的“以人为本”，而不象 SEI 的理论大厦中充斥着对程序员的不信任（SEI 的关键字 Discipline)。它的实用主义的完成 Story 的思想实际上会比 SEI 的需求管理更受现实客户的欢迎（不管他们声称多么重视体系化）。
这两类思想，就如同计划经济和商品经济一样，是相信计划还是相信进化？必须做选择。结合？想象把两个世界的霸主：恐龙和人来结合吧。

使用CMMI进行过程改进的公司，不需要天才程序员，需要螺丝钉一定的平庸程序员。

可能这样比较好操作，你所说的那种长期跟踪不太好操作，也不太好赚钱。SEI不厚道是正常的。

CMMI是真正的方法论，如“ozzzzzz”所言，“仅仅给出一个指标系统来衡量过程的成熟度是否可行”，这是影响cmmi传播的重要因素，让cmmi变成文档的代名词。
既然是理论，避免不了抽象，空洞，如同孙子兵法，千人万象，要提出一个衡量指标很困难。它的重要性在于指导您如何思考问题，如何处理问题，如何避免问题，在于对资源的有效利用。在这里不得不提到我们的航天工程，这么大的项目，这么多人参与，难道还是个人英雄主义吗？独立开来看，我们的不少研究所都很官僚，效率低下，然而最终整体的结果，我们又花最少的钱在最短的时间内做事。所以工程学不能这么功利，成败就在您按下发射钮的那一刻。回过头再看，您的项目是不是很平滑，员工的工作量是不是很平均，交接的时间是不是刚刚好，是不是所有人都感觉充实而不忙碌，自信而不紧张。Agile还不太熟悉，理解上倾向于是技巧。

这里有一个问题，并非所有的软件项目都是航天工程，并且可以说是绝大多数的项目不是航天工程。另外在以cmmi这类重型方法为主导的那些时候，实际上航天项目在软件上的失败例子并不少，这一点可以看看NASA和欧洲的例子。实际上关注质量的做法，基本上早就有个结论性的东西——质量是生产出来的，而不是检验出来的，更加不是管理和控制出来的。这一点上可以说是cmmi理论基础上的一个弱的地方。
另外cmmi是标准，而由于是标准，就不能是方法论，因为标准是要中立，与实施方法无关。而由于过程成熟度这个东西，是否可能由一套语言体系将多种不同的方法过程纳入进来这是一个难题。而cmmi希望从整个流程上整体性的对过程进行判断，这显然会造成其内部头绪太多。实际上我们考察其他质量监控理论和生产理论，即便有所谓全程质量管理，全面质量管理，全程生产调控等等的说法，实际上也是在关键点进行监控和调节，并且尽量将监控和调节的点做到尽量少而绝对必要。
而工程学的一个特征就是功利，全面的功利，不折不扣的功利。如果不考虑投入产出比，不考虑效率，不考虑成本，不考虑这些实实在在的功利因素，就无所谓工程学了。而现在软件开发的现实，特别是国内的项目，有多少不是极限项目，能叫你四平八稳的去做呢？

风怒了，删除掉

CMMI框架和CMMI认证是两回事，CMMI认证和中国公司的CMMI认证又可能是两回事。

就像踢足球能感受到的快乐和看中国足球能感受到的快乐是两回事。如果你看中国足球一肚子气，千万不要误以为足球本身没有意思。踢足球，足球比赛，中国参与的足球比赛，这些都是有联系但又很不同的东西。

所以不要偏题－－题目应该是“踢足球”；对应我们的话题，即“参考CMMI框架进行流程改进”而非“通过CMMI五级认证”。

另外，很多在国内的公司（比如外企），即使没有意图去通过CMMI认证，实际上我知道也是参考CMMI和其它框架或实践进行流程管理或改进的。每个公司每个项目都有自己的需求和特点，管它是什么框架，有好东西都可以借鉴。每种框架又都有限制或适用场合。。。

帮派之争没太多意义