CMMI与敏捷开发模式比较
版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://lilyraven.blogbus.com/logs/83244942.html
?
我曾经参与了一个新产品项目两个版本的开发，分别采用了CMMI与项目级敏捷方式，总结一下两种模式。
CMMI采用的是传统的瀑布模式开发，开发流程是立项－>需求分析－>概要设计->详细设计->编码->单元测试->集成测试->系统测试->对外测试/开局测试。在这个过程中，提交的文档相当多，在前期，估计代码规模，开发人员需要提交概要设计说明书、详细设计说明书、单元测试用例、集成测试用例、系统测试用例，QA需要根据这些数据统计用例覆盖率，单元测试和集成测试由开发人员完成，联调（开发人员最辛苦的时期，这种周期大约持续两个月）之后，便是由测试人员开展的几轮大规模系统测试，通过了TR5阶段，版本参与对外测试，直到后期商用。
CMMI开发基本上在前期就已经确定了大部分对外发布的需求，但是如果后期客户要增加新的需求，根据需求实现的工作量、复杂程度以及对版本的冲击程度等等，决定该需求是在本版本交付，还是在其子版本或者下个版本实现。总的来说，对于大型的商用产品而言，基本上都采用这种方式，但是测试人员参与测试比较晚，bug集中爆发，另外后期增加需求对软件架构冲击比较大。根据项目情况可能会做出相应的过程裁剪，有的项目就不是实行完整的CMM流程。
敏捷开发，采用了项目级的敏捷开发：
?? ? ? ?总的开发团队：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还是敏捷，都难免成为死亡行军项目，开发模式没有最好，只有最适合项目的模式，这个需要不断地探索
