【转载】CMMI与敏捷开发模式比较

CMMI与敏捷开发模式比较

四月 9, 2012 07:07 by FlySky

我曾经参与了一个新产品项目两个版本的开发，分别采用了CMMI与项目级敏捷方式，总结一下两种模式。

CMMI采用的是传统的瀑布模式开发，开发流程是立项 －>需求分析－>概要设计->详细设计->编码->单元测试->集成测试->系统测试->对外测试/开局测试。在这个过程中，提交的文档相当多，在前期，估计代码规模，开发人员需要提交概要设计说明书、详细设计说明书、单元测试用例、集成测试用例、系统测试用例，QA需要根据这些数据统计用例覆盖率，单元测试和集成测试由开发人员完成，联调（开发人员最辛苦的时期，这种周期大约持续两个月）之后，便是由测试人员开展的几轮大规模系统测试，通过了TR5阶段，版本参与对外测试，直到后期商用。

CMMI开发基本上在前期就已经确定了大部分对外发布的需求， 但是如果后期客户要增加新的需求，根据需求实现的工作量、复杂程度以及对版本的冲击程度等等，决定该需求是在本版本交付，还是在其子版本或者下个版本实现。总的来说，对于大型的商用产品而言，基本上都采用这种方式，但是测试人员参与测试比较晚，bug集中爆发，另外后期增加需求对软件架构冲击比较大。根据项目情况可能会做出相应的过程裁剪，有的项目就不是实行完整的CMMI流程。

敏捷开发模式，采用了项目级的敏捷开发： 
总的开发团队：7个Scrum，每个Scrum平均10-12个开发人员，不包含测试团队；
每个Scrun小团队中大致人数13： 10个开发人员，3个测试人员，1个团队负责人

敏捷模式：迭代开发（3周一个迭代周期）、结对编程、Sprint计划会议：每次迭代前估计工作量，澄清需求，估计story的工作量（开发团队集体估计）、状态墙（可以加燃尽图，用以察觉团队是否按照预计的计划进行， 同时可以看到团队的生产率）、迭代验收测试（产品负责人、QA）、持续集成（每日构建版本通过冒烟测试）、迭代回顾会议、每日站立会议—15分钟。  
Jira--------跟踪bug        
Excel-----管理整个产品的backlog        
一个主线，多个分支：同步主线，Merge分支-------SVN（版本管理工具）

敏捷宣言：

Individuals and interactions over processes and tools 

Working software over comprehensive documentation 

Customer collaboration over contract negotiation 

Responding to change over following a plan 

      敏捷开发过程让测试提前参与到每一个迭代周期中，bug在前期解决了一部分，当然不排除后续迭代引入新的问题，开发人员的压力分解到各个迭代过程中，由于需求实现是不断增加到版本中的，不会出现在项目后期仍存在增加需求导致整个版本需要重新大规模测试的情况。    

      对于大型的复杂系统而言，在人力、时间有限的情况下，无论是采用CMMI还是敏捷，都难免成为死亡行军项目，开发模式没有最好，只有最适合项目的模式，这个需要不断地探索。

题外话：
我经常和别人一起讨论敏捷开发过程的知识，并且我们也会经常争论结合使用敏捷开发过程和CMMI高级别的话题。他们两个是否能够结合使用？或者他们两个只是向相反的方向发展？带着这个疑问，下面我们一起来探讨。
“这个问题可以说是老生常谈，但是我对第5级别中的那个基本差异有一个疑问，这个疑问会使人产生不安的情绪。CMMI1.2强调了想在组织中控制结果的变更，进而将其重心转移到了个人的身上。敏捷开发在意义上说不单单是为了让每个项目能在应对各种各样的环境中都拥有灵活的能力，并且可以让他们在这个环境中尽其所能表现的最好。我们并没有特别关注在所有项目中要规范行为以便可以预知结果是“可靠的”。
但是，我并不清楚我现在尽力想说明的这种区别，是否确实是敏捷开发和CMMI的基本概念中的一个基础的区别，还是只是组织如何解释和执行CMMI第5级别的一个结果。当然，敏捷开发团队在过程模型和过程实践资产中拥有的信任似乎要比CMMI团队中的要少――虽然在敏捷中没有方法可以规范这些事情即便他们是低成本的，但是没有假设说明这就是组织要走的路。事实上，敏捷开发支持者偏向于这样的想法，在任何形式的可遇见的过程模型中快速地建立起逐渐减少的成果。是否这就是等同说敏捷开发支持者相信特殊原因会影响执行效果是如此的普遍，以至在组织中试图建立预见性的模型是无用的？”

CMMI第4级别：
QPM（量化项目管理）：主要关注懂得过程行为变更的个别项目，他们认为这些变更影响着他们的成功和如何处理事情――或者至少影响着完成产品发展或者达成目标。组织单位（EPG）必须要监控成果。
OPP（组织过程实践）：主要关注集成模型，项目可以使用模型来规范他们想要达到成功的方面，比如说质量，进度表，预算，维护以及其他任何事情。诀窍就是项目在过程执行中以这些模型为基础，控制QPM中的行为。比较典型的是，这些模型可能是基于相似的项目中的重复的结果不断建立起来的，虽然可能并没有这样的需求。在个别项目级别中模型应该先被改进以便使用，所以在CMMI模型中使用基于一个项目的历史数据（比如说，增量）或者20个项目的历史数据是没有区别的，虽然这可能对使用者来说是有区别的。

CMMI第5级别：
CAR（原因分析与解决方法）：主要关注引起问题的主要原因，过失，管理问题或者其他一切需要解决的问题。项目，EPG或者其他任何人是否可以应用，是作为解决问题的方法。EPG在OPP中监控结果，或者得到别的经验。（敏捷开发是否在增量开始点或者结束点不建议进行类似的行为？我不清楚我所知道的术语是否正确）
OID（组织创新与推展）：完全非项目特点。关注基于个体，CAR，模型使用，外界因素等的组织改进。你是否会收集并且使用所有这些学到的经验？你进入企业后是否会寻求新的或者更好的做生意的方法（其中敏捷开发可能只是一个例子）？在组织中又该如何处理证明，分析（职业），和使用（结构请参照第4级别中的模型和过程控制）这些改进。

我个人认为CMMI高级别和敏捷开发应该结合起来工作。敏捷可以帮助CMMI高级别更容易实现短期的转变，并且它在处理事情的发展上起了很重要的作用。我的经验基本是从第5级别得来的，有部分来自第4级别。许多组织怀着“每个人都必须如此做”的想法而通过了第3级别，但是他们却反对在第4，5级别中有着同样的想法。就像我曾经提到的，敏捷开发是使用CMMI第4，5级别来改进如何发展产品的完美例子。

 

总结：

CMMI的特点：应用了CMMI的公司，有自己的过程标准和产品标准，有专门人员保证过程和产品的质量，而且可以自己改进公司过程以达到符合现实生产。CMMI就是工业化地生产软件，公司花费了时间精力人力物力来制定并完善标准，最后的结果是更加高效高质量地生产产品。一般大公司适合用CMMI的模式生产软件。

敏捷开发的特点：快速，缺少文档，做完就扔，做项目没有得到经验教训和度量数据，就拿一需求也敢做软件。一般小公司经常这么做，一是项目基本从官方拿，伺候好那几个人就成，对软件质量和效率要求不高。二是项目一交就拿钱，不管升级啥的。三是十来个人七八条枪，想用CMMI体系也力不从心，每个过程域分一个人都不够使。

http://flysky.fm1062.com/post/20120408-2.aspx