敏捷与CMMI

敏捷与CMMI，算起来，应该是流行了多年，并且至今仍在流行的词汇。但是，到底什么是敏捷，什么是CMMI，到底都是干什么的？相信很多人仍然弄不明白。本文将尽可能地用通俗易懂的方式，阐明这几个问题。

什么是敏捷？

在日常的工作中，经常会听到或者看到项目组的开发团队哭着喊着想用敏捷，而管理团队却有种种顾虑，比如：文档少了的话，后期维护怎么办？我的人员个个都是独一无二的，进行结对编程的话，效率降低了怎么办？代码任何人都可以修改的话，改乱了怎么办？等等各种问题。似乎敏捷更受开发团队的欢迎而不是管理团队。

那么，到底什么是敏捷？

从根源上来讲，敏捷是软件开发团队在历经各种各样的折磨、反思之后形成的软件开发方法，是乙方对怎样才能更好地向客户交付价值的反思，是对怎样才能更好地规避软件开发过程中的风险和消除软件开发过程中的浪费的反思。较少的文档、结对编程等等，只是反思之后采用的应对措施，是敏捷的表现而不是根本。

什么是CMMI？

对现在的软件企业来说，CMMI3级是进入行业的敲门砖，很多企业都会为了这个证书做很多的表面工作，而在更多的软件从业人员眼中，CMMI就是一堆的文档、一堆规范、一堆要求，没有任何的实用价值，甚至在部分人的眼里，CMMI还是会阻碍项目目标达成的障碍。

那么，到底什么是CMMI？

从根源上来讲，CMMI是甲方在受够了各种各样不同水平的乙方的折磨之后，为了选择合格的乙方而形成的模型，是对乙方能力和水平衡量的各种条条框框的集合。各种各样的文档、规范、要求，只是为了让甲方安心而出现的，是CMMI的表现。

什么样的情况下应该选择敏捷，什么样的情况下应该选择CMMI？

对甲方来讲，使用CMMI的甲方，可以选择一个可靠的第三方，通过各种各样的过程证据，证明乙方确实按照要求履行了合同；使用敏捷的甲方，需要自己对完成项目有强烈的愿望，愿意投入人力与乙方一起把项目做好。对乙方来讲，使用CMMI的乙方，精力不可避免地被各种文档的建立和维护、各种合规性的工作牵扯，需要在文档上投入较多的人力；使用敏捷的乙方，可以将主要精力集中在价值交付上，但文档及合规性等方面如果投入不够的话，对组织资产的积累会有一定的影响。

所以，如果你是甲方，并且有强烈的愿望想把项目做好，又能够投入足够人力的话，建议你用敏捷的方式，能够快速的得到可用的软件，并且可以逐步调整你的需求，做你真正想做的东西；如果你只是想完成上级领导的布置的任务，且自己不想担很大风险的话，建议你用CMMI的方式，请一个可靠的监理，做一个可以完成上级要求的东西。如果你是乙方，无论是在哪种甲方的情况下，都建议你尽可能的用敏捷的方式，争取客户参与，持续集成，经常把已经做出来的功能拿给客户看一看，用一用，会在很大程度上降低验收的风险。

总的来说，CMMI非常适合政府类经常听上级命令行事，且参与项目的个人不愿承担太多风险的项目，而敏捷则适合于银行、军队、自用软件等如果项目做不好，会有非常大损失的项目。