CMMI与敏捷(推荐)

CMMI更注重流程管理，比如订立的里程碑，评审点等等，是一个很流程化的东西，需要项目计划，质量保证计划，按照软件瀑布式展开，也就是，需求，设计，研发，测试，上线的这种流程。每个流程都会产出文档，会有评审会。也就是说，是一步一步的走。实际中CMMI这种流程控制的，都是大项目，有明确的时间周期，而且周期较长，有明确的需求，分析的够透彻，需求不随意变更。也就是有

CMMI以完善流程为主要手段，敏捷完善个人，改善文化为主要手段 
-CMMI以管理，流程为本，敏捷以人为本 
-CMMI实施，执行及其不灵活，难度大；敏捷轻量级，灵活适应，需要有经验的辅导 
-CMMI被老板喜欢；敏捷被一线的工程技术人员喜欢

CMMI和敏捷是两种流派，CMMI注重过程和文档，敏捷注重代码本身、程序员的能力和团队沟通协作。

CMMI比较适合于软件外包，起源于美国国防部给软件公司下订单时，为了保证交付质量和进度，需要对软件公司进行一个摸底评估，因此卡梅隆大学就做了一个CMM用来评估软件公司的成熟度模型，后来演化为CMMI。在国内，因为软件外包的兴起，有些外包采购方也要求软件公司过CMMI，所以国内软件公司兴起了一股过CMMI的高潮。有些大型软件公司也通过CMMI来衡量自己的软件开发能力。

而敏捷起源于一些国外黑客和NB程序员群体，在2001年这些牛人们搞了一个聚会，发布了有名的四句敏捷宣言。除了敏捷宣言，还有11条敏捷实践原则。

CMMI的开发模型，一般以瀑布为主，也有螺旋和快速原型等经典的软件工程开发模式。敏捷开发模型基本都是迭代，迭代周期一般从1周到1个月。不是迭代，你都不好意思说你用的是敏捷开发。

工具方面，CMMI和敏捷的工具很多是共通的，不过敏捷相对更“极端”一点（参考极限编程，XP，这是敏捷主要的技术实践基础）。比如CMMI有同行评审，而敏捷提倡结对编程，实际上是时刻都在做同行评审。CMMI有版本配置管理，敏捷提倡持续集成，即每一次代码checkin都会引发一次构建、代码检查、自动测试、看板更新、邮件推送甚至是版本自动部署。CMMI有版本发布里程碑，而敏捷提倡持续交付，即每时每刻，在服务器上的版本都是可交付的。

从应用范围来说，CMMI适合于外包和大规模团队的分工协作，是一种重量级的过程，属于集团军作战；敏捷适合一个完整的小团队，属于特种部队作战。现在国内外互联网公司采用敏捷开发模式很多，因为用户需求变更频繁，版本更新换代快，必须快速响应。有很多大型软件公司也尝试使用敏捷开发方式，毕竟现在都在搞项目化运作，大公司小团队是趋势。

关于CMMI、RUP、Agile的区别，个人当前的浅见：
CMMI,Capability Maturity Model Integration，偏向于组织级协作的过程框架，强调组织内所有项目应该遵从的相关协定和标准。而底层工作人员很少感觉到CMMI的存在，是因为这些CMMI的规则与约定是驾凌于单个项目管理与实现之上的，在执行具体项目的时候容易（常）被模糊稀释化（这里不论效果好坏或是管理责任的问题）。
RUP，Ratianal Unified Process，统一软件开发过程，是面向对象分析设计的软件工程方法论，逻辑上可以理解为一个贯穿软件项目生命周期的过程框架。个人认为它相对与组织级别的CMMI，RUP更偏向于项目级。书上把CMMI和RUP做为并列关系看待的两种重型软件工程方法，但个人认为RUP更聚焦，聚焦于具体开发项目，例如执行哪种开发流程模型是RUP的讨论点，而CMMI则默认瀑布模型。
Agile，敏捷开发,其实是一个过程家族（方法集合），而FDD、XP、Scrum等等则是敏捷家族的具体方法论和过程子集。

所以说，CMMI和Agile不是一个层面的事物，拿CMMI和RUP会更有可比性。另外说明，它们拥有一点重要而相同的地方在于它们的核心思想都是演进evolution，即持续改进。

CMMI是得到明确定义的，最新版本是V1.3，包括了开发、服务和采购三大部分。
Agile并没有得到明确定义，可以从理念、思想层面来看待Agile，比如拥抱变化，注重沟通；也可以从具体实践来看待敏捷，比如计划扑克，迭代计划，持续集成；也可以从流派来看Agile，比如Scrum，XP，DSDM，FDD，ASD，Agile Crystal，还可以从团队管理角度来看Agile，还有其它方面。
Agile是丰富多彩的。
所以两者不能简单比较。需要明确在那个层面上来看待这些问题。

CMMI是一个最佳实践集，它提供一个框架。而敏捷可看做实践挂到CMMI框架中

Agile宣言:

1. 项目成员及交互胜过流程和工具。
2. 与客户的协作胜过协约谈判。
3. 交付的工作软件胜过文档。
4. 响应改变胜过按部就班。

建议把Scrum分成两部分，1是Scrum流程，比如计划会议、每日会议、燃尽图、回顾、用户故事、扑克估算等等，2是Scrum团队，三个典型的角色

我来分享点拙见。分别在通信行业和互联网行业实践过几年的Scrum，有一些体会。
首先，敏捷被很多人和团队视为对传统项目管理的否决，视为不要流程，不要规则的依据。项目管理本身是一门高深的，非常有价值的学问。不懂项目管理的人做敏捷常常做成野鸡流程。

Scrum的精华有两点，第一是短迭代，第二是自组织。
短迭代让团队可以形成节奏感，并在每个迭代后有机会进行回归，并在下一个迭代中提高。相比传统的瀑布流程，因为缺乏这样的反馈机制，团队的改进相对困难。
自组织的目的是让团队对目标进行自我承诺，激发团队最大的能量以达成目标。这是在公司这种权威组织中实行的小规模民主激励。对于自尊心较强的工程师团队，相当有效。不过也有缺点，那就是团队自我意识可能过强，导致跨团队合作出现问题。

但如果仅仅实现这两点，Scrum的结果可能是非常糟糕的。特别是短迭代造成两个负面后果：
第一，短迭代倾向于产生短期设计，在将来的迭代中需要经常重写。
第二，短迭代导致没有时间进行全面的回归测试，导致bug数量上升。

为了有效的解决这两个问题，Scrum必须伴随一些关键的工程实践。
第一，最重要的，是测试自动化。无论是单元测试还是功能测试，都是在短迭代下保证质量的重要，甚至是唯一手段。
第二，重构。有了自动化测试，敏捷团队应该勇敢的不断重构代码，消除技术债务
第三，持续集成。有了自动化测试，持续集成可以在最短的时间内报告问题，并要求团队将CI的错误作为最高优先级立即处理。

所以可以看出来，自动化测试是scrum最重要的实践之一。一个没有自动化测试的组织，采用scrum虽然也可以受益，但达不到“高绩效团队”的水准。