关于敏捷开发开发和CMMI对中国企业的适用性研究
本帖最后由 zhangwei_wuyan 于 2010-04-30 13:06:13 编辑 最近看了很多关于敏捷开发和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在一定情况下可以结合使用，但暂时来看适应条件比较苛刻。具体如果想要结合无很多成功例子做参考，现仍处于讨论阶段。
希望大家能够多多讨论，推动国内软件的发展！
张伟，2010.4.28 我的QQ：582357212（有兴趣的可以交流交流）
[最优解释]
很难看到这么好的文章，我比较赞成作者的观点，对于国内的很多企业，即使通过了CMMI3的认证，真正能领悟CMMI开发的并不多，能把自己企业的实际情况何CMMI相结合的就更少，有的甚至在为做文档而做文档，根本没有发挥出过程开发的优势，对于敏捷开发，又开始盲目推崇……
我觉得使用哪种开发方法首先必须要知道开发方法的真正价值，自己企业的自身特点，这两个是最基本的要求，否则盲目的使用所谓的“先进的”开发方法可能会适得其反。
[其他解释]
恩，赞同楼主的观点。
个人感觉，大企业待过，中小企业了解过，对于中小企业来说，能走到CMMI2,真的不容易。希望能够有发展，但是，CMMI的流程，如果要达到标准，出了技术，还要看人力和资源。没有人，什么也不用希望了。但是，当这些企业有了人以后呢，又会认为，我们现在有了这些人，一定要创造更多的价值。于是呢，在资源的分配上，为了满足当前的现状，又会出现分配资源不合理的情况。最终出现一种什么样的结果呢，我感觉想是一种畸形发展的过程。可能这也许就是畸形裁减出来的模型吧。
[其他解释]
