第一部分 · 问题思考

敏捷开发方法和CMMI的最佳实践通常被认为是一对矛盾。如果这些看法或其原因没有得到解决，当我们采取某一个方法论的时候，很可能会看到更多的混乱和冲突。另外，一些方法论里的好的软件开发原则往往被忽视，但是其他方法论又需要这些好的原则，于是相互融合对于项目的成功尤为重要。从长远来看，这种不和谐的情况，不利于软件工程行业的健康发展。

为什么敏捷和CMMI两大阵营之间会存在纷争呢？这篇报告的目的就是为了阐明为何这种纷争不需要存在，当恰当地一起使用CMMI和敏捷，它们可以显著地提高绩效。

我们认为Agile敏捷和CMMI阵营存在分析的主要原因有两个：

1、早期同时采用敏捷和CMMI的人在他们的软件开发范例中，表现了几段的案例。早期使用CMMI的人是这样一些研发人员：处于大规模项目中、反对风险、关键人物系统，并经常伴随高级别的管理监控和分级管理制度。而早期的敏捷方法采用者通常聚焦小的和单个的团队研发项目，伴随易变的需求，在一个仅有软件的环境中。所以，这两个极端的情况，决定了所有的基调。

2、关于CMMI和敏捷的不准确的信息和对两个结果的错误使用，使得双方阵营错误的看待对方。这些负面的认知，把CMMI和敏捷放到了对立面，主要源自一下因素：

a)错误使用——在二十年的经验中，包括先前的CMM以及现在的CMMI模型，模型里面的实践有时候会被错误使用或者在应用到开发活动中时，已经被开发团队认为不需要那些实践开发也会做得很好；

b)缺乏准确的信息——在敏捷阵营中，缺乏对于CMMI的准确信息；在CMMI阵营中，也相对缺乏关于敏捷的准确信息；

c)有难度的专有术语——在CMMI中有很多专有术语的使用，例如：原则、质量保证和可预测性等等；在敏捷中也有很多术语，例如：持续集成、测试驱动开发、集体代码所有权等等。而这些术语都有具体的语境和内涵，因此容易应发误解和滥用；

d)“自下而上”和“自上而下”改进方法论的对抗——我们在推行一个方法论的时候，往往喜欢支持的声音胜过其他声音，这时候却忽略了另一个重要的声音，就是如何有效的运行业务。

在这篇报告中，我们识别和讨论那些最具破坏性的误解，从而形成对两个范例的正确理解，并给我们的建议方法，从而可以让大家提高对这两个强大方法论的理解，可以更有效的开展软件研发。在此之后，我们承认在CMMI的研发和介绍上的方式可能会导致一些用户误解了CMMI的真实信息和本质，这些误解可能会导致对CMMI理解的不一致和使用CMMI的无效性。

之后，我们识别在敏捷阵营中对于CMMI的普遍误解，以及在CMMI阵营中对于敏捷的普遍误解。在许多方面，这些误解和对CMMI以及敏捷的错误使用有关系，但是，也可以归因于缺乏准确信息，以及对于以往经验的过分依赖。所以，是由多方面原因造成的，而不仅仅是某一反面。

重要的是，当执行者命名他们的活动的时候，CMMI和敏捷这样的标签经常会被过于自由的使用，而不是合适的遵循两个方法论的要求。这些情况会给两个方法论带来负面的看法。

【相关文章】

《CMMI还是Agile：为何不拥抱彼此！》第一部分 · 问题思考

《CMMI还是Agile：为何不拥抱彼此！》第二部分 · 两个方法论的起源

《CMMI还是Agile：为何不拥抱彼此！》第三部分 · 影响对CMMI和敏捷观念的因素

《CMMI还是Agile：为何不拥抱彼此！》第四部分 · CMMI的真相

《CMMI还是Agile：为何不拥抱彼此！》第五部分 · Agile的真相