先简介一下背景情况，我在一个外资通信企业A 工作了7年，后来到另一个外企E呆了三年，算算共呆了十年，最近到了一个民营企业B。

A在2006年推广过了CMM3,E在公司2008年推广了Scrum ,B最近准备过CMMI3，新近又参加了CMMI的培训，颇多感悟拿出来与同学们讨论讨论。

不像很多人的误解，CMMI其实和Scrum并不矛盾，应当说瀑布模型与Scrum矛盾，或者说瀑布模型是由一系列的Scrum项目迭代而组成，更加适合大项目。

为什么这么说呢，传统的瀑布模型定义一个需求，然后进行分解，评审，开发测试，现场验收。

表面上看很合理，但是它忽视了一个问题，人不大可能对未知的东西能做出正确的判断，哪怕你的需求再完美，如果没有一系列的设计代码测试环节的跟上，还是会陷入失败的泥沼。

The only not changed thing is changing.大项目本身在规划两年，三年的交付时，就已经面临着很高概率的失败风险了。市场环境在变，用户需求在变，开发环境在变，部署环境在变，开发人员和开发工具在变。按照统计学正向分布的理论，实际上一个大和模糊的任务，发生大的概率是非常高的，项目的总偏差=每个子任务偏差平方的累加。

一个新项目本身不确定的因子太多，所以全新项目的失败率几乎高达40%，如何避免或减小公司的损失呢，办法只有一个，抓住关键点，定义清晰的目标，尽可能早的交付和客户讨论演示，取得反馈不断修改和提高。（正是Scrum的精华之处）

先举一个CMMI之前的开发案例吧。

当年从事一个现场升级项目，开发只花了两个月，（每天从8点15到晚上9点半，周六上班），然后一个月就通过验收测试，并且上了线，但是后来BUG直到一年后才完全稳定下来。还发现容量不够，高峰时总是Down机，最后只能修改合同，赔了用户款项了事。

原因：

1、需求过于简单，当时拿着一份老系统的测试规范就开始编程，测试规范只有20条。结果后来发现有好多细致的用户需求没有被记录在文档里，如用户的号码如果没有区号时系统要给号码自动加上0+区号的前缀。后来使用时被投诉才发现，又不得不修改。

2、没有安排真实环境集成测试，当时测一下就交付了，后来发现和本公司的交换机正常工作，和其他厂商的交换机无法工作。检查后发现是我们对异常参数的处理能力不够，规范上是某个号码是4-12位，我们少支持了一位，并且不支持#值。

我们的交换机不发#，他们的发#，结果我们的系统down机了。

3、没有性能测试的目标，当时含含糊糊的说要达到老系统的性能，并没有开发实际的性能测试工具，没有定义系统的工作方式，也不知道老系统的真实负载和实际处理能力。后来发现系统一到周一和周五早上就Down机（其系统负荷是平时的2-3倍），搞得用户每到这时候就特别紧张。

（PS,这个问题一直没有解决，最后是3年后上了新系统才完全解决了这个问题。）

-- 现在看，CMMI的对功能和非功能的需求开发和验证能比较好的解决这种需求不清的问题。

后来到另一个公司，很让我吃惊的是，这个公司的产品质量并不象名声那么好。领导层决定引入Scrum流程提高交付的质量和缩短交付周期及降低开发成本。

凭心而论，Standup Meeting,Demo to Customer,结对编程，固定发布周期，自动编译和自动测试等都是非常好的实践。

但是其忽略了一些问题，

1、其对Product Owner过于强调，实际发现产品的需求一开始很难被正确的定义优先级，所以会导前面的白费，但管理层显然不喜欢这个后果，对ProductOwner很不满意导致其受到责备。

2、开发和测试都敏捷了，可是项目和需求并没有敏捷。项目经理在Scrum里是个可有可无的角色。那团队里有了矛盾怎么办，进度延误了谁负责？谁对支付钱买产品的人做出承诺？这些问题Scrum并没有回答，需求的改变本来是Scrum最欢迎的，项目经理却对其大加斥责，（因为其导致了项目的额外付出和延误），实际最后项目几乎所有的人都不满意。

究其原因项目经理做的事情在很多公司里还是需要的，而Scrum虽然想以TeamLeader,ScrumMaster,Product Owner来分解项目经理的任务，但是并没有给出比较好的解决问题的办法。

谁给予Product Owner与客户洽谈的职责，谁给予TeamLeader以考评组员的能力，客户和外部的高层领导都不希望看到自己的意见有很多个不同的解决方案，而Team内部成员却争论不休的现象。

这些问题都是需要每个实行Scrum的公司考虑的。

3、对团队的要求过高，希望成员能够干好每一件事。我认为这是一个非常错误和不可能达到的伪假设。包括Product Owner,没有人能够做好每件事，IT的技术千变万化，市场的环境不断改变。一个人总有不知道的领域。一个人和一个团队很少能够做两个重复的项目，而现实情况时当你说不时就有人说你能力不够。

而Scrum这个假定并没有规定如何度量一个人的成就，最后导致从事困难的项目人员就被考评得比较差，并且团队士气低落，对上隐瞒自己的困难，项目经理不断增加Buffer，团队和管理层互不信任.

一个人做好一件事都很难，如何让他在短期内一会做好这件，一会做好那件呢？　

这一点上我认为CMMI及我后来呆这个公司比较有些解决方法，首先每个项目让项目经理制定培训计划，然后采用Delphi法（很多个专家一起拍脑袋定技术难点和项目的Effort)，每周对困难状态跟踪和不断的发现和解决新的困难。一句话，去拥抱困难，积极的解决，消除它而不是抱怨它，躲避它。

实际上E公司有一点是非常不好的，其不鼓励事前项目成员和不同部门的互相讨论，喜欢搞某个专家的独立决策，并且喜欢事后对各种决策做事后的所谓RouteCause分析和总结。弄得不好就演化为批判会，而不是项目前期的多方准备和风险决策的寻找和解决，接受过程。

我认为对于一些技术的关键点应当事前广泛听取群众的抱怨和意见，少部分人参与讨论和选择，独立的作出判断和决策才是一个好的决策者的工作方式，不过这种方式在E公司是不受肯定的。

4、到底是不是需要强调文档。

CMMI中非常重视文档和过程的定义，而Scrum里面强调代码为王，鼓励少写和不写文档。

我个人的感觉是各有利弊，过分强调文档会增加公司的生产和维护成本。用户需求，产品需求，概要设计，详细设计，测试方案，测试用例加其他很多文档，可能要比真正的交付产品的Effort多得多，在有的客户小项目中可能真的没有必要。

而Scrum又走向另一个极端，多模块和复杂的项目光看代码是很难让人知道它的设计思想和难以维护的，所以对于平台级的构件和关键的一些项目还是需要概要设计等任务的安排的，而标准也是需要每个决策者考虑的。

5、如何判断项目和需求的关键点

这个我感悟是最深的，CMMI和Scrum对这个都作了定义，就是Priority最高的需求或CMM　里面的关键路径的任务（到项目后就变为某项任务或活动了）。

回顾我做过的项目，成功的占了5／4，大部分都是二次开发和规模较小的项目或者大项目被分解成小的项目。不成功的几乎都是错误的定义或判断了关键点，总结下来有几点原因：

1）、项目的外部接口文档或资料没有得到就开始开发任务。

有一个项目，功能需求和非功能需求（性能，可用性等），项目交付，集成测试计划及人员安排都定义得相当完美。但是忽略了一点，当时说某个关键接口源程序拿来直接测就可以了，后来发现其实源程序只实现了其接口的一部分，而这个接口是对方不同意公布给外部厂商的，为了做完这个项目，派了人员到现场去开发，但最后还是没有得到领导的认可。

2）、内存泄漏的问题。

我们原来公司都是C++或JAVA语言开发的，几乎所有的项目最后都是内存泄漏而延误了进度。而不是功能需求的未完成耽误进度。这个问题是任何流程无法直接解决的。

实际上，每个程序员都应当培养代码评审的习惯，还应当从开发模块级别发布一些内存跟踪工具，模拟在实际用户应用的内存变化情况。另外公司建立一个Bug知识库也是一种好的方法。

3）、交流不充分或没有建立良好的沟通渠道。

我经历过的一个项目其实非常复杂，里面有三个不同领域的专家，彼此对自己的领域都很精通，但都不了解对方的知识，定义规范和任务时，靠邮件和电话会议沟通了很久也没有找到解决方案，我向领导提出当面开会，却没有得到明确的答复。在没有相应的外部资源支持（要投入交流和培训的成本）和对外部的推动力不够得情况下基于自己的假设完成了开发，做出来后一集成测试发现很多需求理解得并不充分，都站在自己的层面去实现，没有考虑整个方案的目标和制定相应的接口。后来由各方高层出面，在新项目中安排了培训和开会讨论等任务，基本解决了前个项目中的遗留问题。
CMMI中提出了一种方法，是项目经理根据需求把任务本身进行分解。先找到关键任务和其风险的解决方案。
CMMI中列出了一份项目失败的原因列表，我觉得非常好，它不是为了给谁抓小辫子，而是给了大家一个经验库让大家少犯类似的错误和更早的对问题提出多的解决方案。　

最后总结一句，尽管好像有点废话，任何一种流程都不是放之四海皆准的，需要根据每个公司，每个项目，每个团队，每个客户而去甄别，去调试，出了问题不要埋怨流程有问题，而是要想想自己如何去理解和应用这个流程的和如何去改进它。