最近看了许多针对敏捷开发和CMMI的讨论，现结合自己曾经实施的一点经验，谈谈自己的一点看法。希望能引发大家一点思考。
首先我现在很多公司盲目跟随潮流使用敏捷开发过程，或CMMI标准过程，未完全确定自己公司的实际情况，保守的说一个企业开发过程未真正的达到CMMI3级的标准过程，那么它的敏捷开发过程很难实现，只能是徒具一个敏捷开发外壳。
二十世纪初，17 位该方法的倡导者建立了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。敏捷联盟成立之初总结了四条基本的价值原则：1人员交流重于过程与工具（Individuals and interactions over processes and tools）2软件产品重于长篇大论（Working software over comprehensive documentation）3客户协作重于合同谈判（Customer collaboration over contract negotiation）4随机应变重于循规蹈矩（Responding to change over following a plan）。
如果想采用敏捷开发，针对这四条规则应思考并解决四块问题：1怎样控制人员交流的效果？2通过开发，测试组成团队技术能力能高效控制住软件产品的开发过程么？这样是否会增加风险？3怎样控制客户和项目中共同协作的效率？是否会增加大量成本？3随机应变度如何把握？这样的过程对以后项目的开发过程可重复性和可以预测性有多大？
能力成熟度模型集成（CMMI）是一个过程改进方法，它通过过程域为组织提供了实现高效的过程所必需的基本元素。它将软件开发的过程分为许多的过程域，通过这些过程域来指导一个项目、一个部门甚至整个组织的过程改进。CMMI能帮助我们整合以往“各人自扫门前雪，休管他人瓦上霜”的组织功能，建立起过程改进的目标与优先级，指导我们进行过程和质量改进，通过实施过程中产生的众多文档提供了评价现有过程和做出改进的参照项。这就是大家一提到CMMI，大多第一反应就是实施后文档很多。所以在此我觉得有必要重申一个观点：是真正在我们实施的过程中加强对项目控制和改进才产生相关文档，而不是为了达到相关文档数量而实施CMMI。但不可否认敏捷开发在应对当今客户方快速的需求变更，以及开发成本方面的确有独特的优势。即使SEI即将于2010年11月发布的CMMIV1.3，加大了对需求变更方面的控制。这样CMMI在成本，灵活性方面优势还是敏捷开发明显。
在80年代早期，在SEI的资助下美国空军成立了一项研究来分析为什么许多软件合同都会超出工期和预算。他们的结论是：糟糕的过程。承包商认为无法按照预定的工期和预算完成合同的原因在于需求不断变更。这也是软件公司面对共同问题，对此如何解决呢？我针对国内情况给出点自己的看法。
中国现在的软件环境面临几个问题：
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臃肿、枯燥，不够灵活，难以适应需求的快速变更，敏捷开发对流程控制不够，容易产生混乱。CMMI3级已经经过很多成功项目的检验，是一套成熟的模型，并且对企业项目开发实际切合度要求没有CMMI4、5级那样高。这样适当裁剪部分文档结合敏捷开发一起使用就成为一种可能，就可能增加软件项目的规范控制和高效开发，但在现在没有成功项目做为其理论支撑，风险很大。企业项目开发过程采用什么模型应该根据自身情况决定，并且不应该硬搬模型，应根据自身情况对其进行裁剪使其适应公司使用。敏捷开发和CMMI在一定情况下可以结合使用，但暂时来看适用条件比较苛刻。具体如果想要结合，暂时来看无很多成功例子做参考，现仍处于讨论阶段。
如果公司考虑规范化自己流程，首先要考虑公司组织架构的规范化问题和权责分配问题，这是规范流程的基础，流程是个抽象的词汇，并且对于软件开发来说的流程对人的依赖性太大，无论敏捷开发还是CMMI其实质的目的是相同的，就是如何保证高效的交流，CMMI理想化就是软件开发中的交流尽可能的都通过文档来进行，把文档作为一种传输介质。而敏捷开发同样目是为了保证高效的交流，而加入各种控制交流手段。还有一个目的就是所有工作量化的问题，量化问题涉及面太广，想所有东西都通过数据来证明，太难了，但这就是共产主义的精神，要实现理想中的共产主义，我们就需要不断的考虑如果能尽可能的将软件开发的过程变成数据。这样达不到共产主义我们也能达到小康。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |