CMMI与敏捷开发
作者：张伟 &
&最近看了很多关于敏捷开发和CMMI比较的讨论，结合我实施CMMI的经验和对敏捷开发的研究，提出点薄见，还希望大家多多讨论！
&&&&首先我现在很多公司盲目跟随潮流使用敏捷开发过程，或CMMI标准过程，未完全确定自己公司的实际情况，保守的说一个企业开发过程未真正的达到CMMI3级的标准过程，那么它的敏捷开发过程很难实现，只能是徒具一个敏捷开发外壳。
&&&&二十世纪初，17&位该方法的倡导者建立了敏捷联盟（Agile&Alliance），并将该软件开发方法命名为敏捷软件开发过程。敏捷联盟成立之初总结了四条基本的价值原则：○人员交流重于过程与工具（Individuals&and&interactions&over&processes&and&tools）&○软件产品重于长篇大论（Working&software&over&comprehensive&documentation）&○客户协作重于合同谈判（Customer&collaboration&over&contract&negotiation）○随机应变重于循规蹈矩（Responding&to&change&over&following&a&plan）。
&&&如果想采用敏捷开发，针对这四条规则应思考并解决四块问题：○怎样控制人员交流的效果？○通过开发，测试组成团队技术能力能高效控制住软件产品的开发过程么？这样是否会增加风险？○怎样控制客户和项目***同协作的效率？是否会增加大量成本？○随机应变度如何把握？这样的过程对以后项目的开发过程可重复性和可以预测性有多大？
能力成熟度模型集成（CMMI）是一个过程改进方法，它通过过程域为组织提供了实现高效的过程所必需的基本元素。它将软件开发的过程分为许多的过程域，通过这些过程域来指导一个项目、一个部门甚至整个组织的过程改进。CMMI能帮助我们整合以往“各人自扫门前雪，休管他人瓦上霜”的组织功能，建立起过程改进的目标与优先级，指导我们进行过程和质量改进，通过实施过程中产生的众多文档提供了评价现有过程和做出改进的参照项。这就是大家一提到CMMI，大多第一反应就是实施后文档很多。所以在此我觉得有必要重申一个观点：是真正在我们实施的过程中加强对项目控制和改进才产生相关文档，而不是为了达到相关文档数量而实施CMMI。
&&&&在80年代早期，在SEI的资助下美国空军成立了一项研究来分析为什么许多软件合同都会超出工期和预算。他们的结论是：糟糕的过程，承包商认为无法按照预定的工期和预算完成合同的原因在于需求不断变更。这是许多企业急切想解决的问题。但我们如何解决呢？下面给出了点个人的国内软件情况分析和见解，希望对大家有所帮助。&&
&&&&很多人认为CMMI臃肿、枯燥，不够灵活，难以适应需求的快速变更，敏捷开发对流程控制不够，容易产生混乱。
&&&&中国现在的软件环境面临几个问题：
1.中小型企业很多，真正能达到CMMI2级以上标准的不多。很多公司现在是达到了CMMI3级文档的要求但实际项目开发过程没有产生CMMI3级所预期的效果。
2.软件项目开发中的测试环节，很多公司的高层对此重视还不够，中国现在达到敏捷开发所要求的测试技术素质还不足。不能够简单而高效得应对需求，开发的变化。
3.无论CMMI，还是敏捷开发都强调了团队的配合度，然而现实国内软件公司的软件开发与测试的配合度（重点是开发和测试）很难在实施后达到CMMI和敏捷测试的效果。
4.公司领导层的重视不够，很多领导层人员想实施但实施的决心和持久度还不够。对实施风险有较大的忧虑。
5.公司缺少这两个方面的专业人才。引进咨询公司会很大程度增大资金投入，并且咨询人员属于空降部队，说服力和职权都难以将过程实施下去。
6.很多公司过分注重个人能力，相信技术牛人，依靠这些技术牛人来保证软件开发的质量。这会产生很大风险，并且对于WEB项目来说风险将会更大，造成很多项目是失败的。然而很多公司有太注重流程，导致过程很复杂，效率低下也难以让项目产生高的效益。这两个方面的平衡点是公司实施思考的重点。
那我们软件如何实施呢？是实施敏捷开发还是实施CMMI？什么阶段实施是合理的？两者能够结合使用么？
针对这些问题我觉得应该明确一些问题和寻找一些切入点:
1.首先我们要明确软件整体发展方向和环境，已经迫使我们要适应当今软件发展而做出调整，软件开发已经不是几个人敲敲代码就能赚到钱的工作。面对日益激烈的软件市场竞争，我们应该从各个方面提高自己的竞争了，而一个符合公司的项目过程就是现在很多公司要考虑的点。
2.不同的公司应对公司不同的情况适当选取一个模型作为基准点，如果一个小的公司得开发过程还没有达到CMMI3级，甚至没达到CMMI2级那么不建议采用敏捷开发过程。如果对于一个项目过程达到CMMI3级要求的公司，可以考虑敏捷开发。对于达到CMMI3级要求的中型企业，并且开发测试人员配备完备，素质较高，那么建议使用敏捷开发模型吧，这会提高项目的效率。对于大型企业来说，最好轻易不要改变自己已有的软件项目过程模型，或采用CMMI5模型作为基石，选取部分项目灵活使用敏捷开发积累经验。
3.作为一些小型软件企业首先在保证自己企业能很好生存下去的前提下，可以现提高自己部分项目规范，如评审等，因为CMMI提出，在组织中必须建立开发过程，必须采用同行评审来提高质量，必须有版本控制系统。一个CMMI3级或更高的开发过程是一个很庞大的过程，企业不发展到一定地步很难适用，所以可选取其中部分开发过程适用。逐步规范自己的开发过程，然后不断调整个人技术能力和项目开发过程对项目的影响平衡点，不断提高自己项目效益。
4.当企业项目开发过程达到CMMI3级，实施敏捷可以获得敏捷带来的重要好处，还可以减少返工，并全面提高推行CMMI的积极性。如果实施的软件开发过程既能遵循CMMI规范，又能符合敏捷原则，我们就可以真正获得项目开发中的可重复性和成本、风险等可预测性的好处。但敏捷开发在不违反敏捷宣言所规定的主要目标的前提下，裁剪为遵循CMMI规范的软件开发过程是我们要主要研究的问题。
5.实施敏捷开发或CMMI过程切忌急功近利，要认识到这只是推动公司发展，提高项目效益的一中手段，而非点石成金的魔棒。
6.实施敏捷开发或CMMI过程，应在公司项目轻松的时间段进行。
&&&&&结论：
&&&&&企业项目开发过程采用什么模型应该根据自身情况决定，并且不应该硬搬模型，应根据自身情况对其进行裁剪使其适应公司使用。敏捷开发和CMMI在一定情况下可以结合使用，但暂时来看适应条件比较苛刻。具体如果想要结合无很多成功例子做参考，现仍处于讨论阶段。
&&&&&希望大家能够多多讨论，推动国内软件的发展！
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&张伟，&&我的QQ：（有兴趣的可以交流交流）
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。CMMI与敏捷开发模式 - 博客频道 - CSDN.NET
每天积累一点，一年后你会发现，自己变化很大
静下心来，一步一步，学习开源项目。
分类：process
1)&&CMMI&开发模式
优点是开发流程制度化和重视过程（设计，文档，编码，测试，原因分析），强调项目的可控性（&Risk&管理），缺点是开发周期长，灵活性差。
CMMI&体系适用范围的特征：产品&/&项目创新要求不高，设计和需求比较稳定，人员规模比较大。
Key word: RD/BD/FD/DD/CD/UT/FT/ST, test case, QA, DR, risk management, continuous improvement (CMMI5), PDCA (plan, do, check, act)
2)&&敏捷开发模式
优点是在不同开发环境下的高度灵活性和开发人员的自我管理，缺点是项目维护难度大（知识和经验分散在软件开发人员手中）。敏捷开发对设计文档没有硬性要求，倡导&Documented&式的代码风格和代码的重构。
Agile&体系适用范围的特征：产品&/&项目创新要求特别，设计和需求变化偏大，人员规模较小但素质较高，且团队稳定气氛良好。
排名：第619名
（57）（391）（71）（100）（63）（7）（194）（1）（38）（21）（105）（194）（58）（15）（57）（47）（1）（18）（9）（24）（42）（15）（12）（14）（45）（11）（1）（1）（11）（26）（27）（13）（8）（4）（3）（3）（31）（226）（79）（19）（24）（53）（25）（9）（37）（9）（126）（4）（3）（14）（8）（9）（10）（3）（2）（1）（20）（0）
http://www.vpser.net/一、敏捷开发定义
& & &敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
二、敏捷开发原则
& & 1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意
& & 2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
& & 3、经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
& & 4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
& &5、围绕被激励起来的人个来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
& &6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
& &7、工作的软件是首要进度度量标准。
& &8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
& &9、不断地关注优秀的技能和好的设计会增强敏捷能力。
& &10、简单----使未完成的工作最大化的艺术----是根本的。
& &11、最好的构架、需求和设计出自与自组织的团队。
& &12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭***发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：
组织文化必须支持谈判
人员彼此信任
人少但是精干
开发人员所作决定得到认可
环境设施满足成员间快速沟通之需要
最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。
另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是要有效的&负反馈&，否则错误会迅速膨胀，并在最终提交时造成极大返工。
阅读(...) 评论()