CSSPI2009上InfoQ的采访：CMMI在国内企业的实践以及敏捷评价

InfoQ在CSSPI2009上对我的采访：http://www.infoq.com/cn/interviews/yf-cmmi-agile

CSSPI的会我们是每年都会参加的，今年临时通知说有一个访谈，进门一看原来是老朋友泰稳:)，同样，备份在这里，是我这阶段对一些问题的看法。

btw，InfoQ越办越好了，上面有些不错的访谈，编排也很好 :)

题目：袁峰谈CMMI在国内企业的实践以及敏捷评价
受访者：袁峰
采访者：霍泰稳

摘要：国内CMMI领域专家袁峰在该访谈中，谈到CMMI在国内企业的应用现状，传统企业对软件的需求，并结合CMMI谈到敏捷开发方法的适用性，最后对软件团队应该采用何种开发方法给出自己的评价。

(00:00)M：好，我是InfoQ中文站的编辑霍泰稳，很高兴今天能在这采访中科方德的事业部总经理袁峰先生。先给我们介绍一下你自己和你工作的单位吧？

A：我叫袁峰，实际上我个人是比较这个产学研结合比较多结合的一个代表，过去因为我原先在软件所工作，包括我现在还在也承担一部分研究工作，比如一些国家研究课题，但。实际上更多的精力在做产品我们做课题。，这几年我们在走的一个路，就是研究跟实践比较结合的路一些，所以我有另外一个身份是中科方德公司软工事业部的总经理，这样我们自己在做一些产品，这个也是我现在特别想做，而且我觉得特别有意义的一个事情，能够把我们在理论研究上的一些东西和我们实践的东西相结合，并且把我们的一些想法体现出来，并且具体应用到企业那里去。

这跟我们光坐在科研机构是不一样的，和我们仅仅做一些这种实践（也是不一样的），有一些国内企业受实力的限制，一般企业很难有自己的研究院，但是对于方德来说，它本来就是软件所的一个投资公司，它背后天生就有这样的研究力量，我觉得这是一种很好的组合，很好的模式。，大概我的情况大概也就是这样。

(01:39)M：在你明天的演讲上会提到，CMMI工具和开发者的感悟，主要跟大家分享的是那些东西？

A：因为这几年我们一直在做CMMI工具这一块，其实我本来是不太想把我们的工具（我们的工具叫QONE）挂上CMMI这个帽子的，我们的工具叫QONE，把我们QONE工具灌上CMMI这个帽子。但是去年看了去年潘加宇给我介绍的了一本书叫《定位》，我相信你应该也看过，《定位》上提到说，你一下子给我们的这个对象，比方说客户或者说我们的听众一个概念印象，如果他从来没听说过，没有和他脑海里任何一个熟悉的词关联起来，是很难不会产生什么影响的。

而我们的这个工具的客户，事实上很一大部分客户就是CMMI的一些这种客户。，我们有个客户很有意思，他们在内部培训工具的时候，他培训（我们这个）工具的用法，又贴海报，又做培训班等，他自己给我们的工具起个名字，就把我们的工具叫成了CMMI集成平台。他没有称它为QONE，他说叫QONE，我们内部几百上千人不知道是啥东西，我说就叫作叫CMMI集成平台，所有人都知道我在干吗。他这个想法其实很好，所以我也不忌讳把我们东西叫CMMI集成平台。但事实上，刚才我们聊的时候也说到，这个CMMI它所关注的像项目管理、需求管理、缺陷管理、质量管理等等这些事情，你即使不做CMMI，你也需要关注，不论用什么方法论，你都也需要把你的整个团队管好，把你的项目计划做好，跟踪好，你都也需要知道团队的建设，项目的进度，成本控制怎么样，也需要知道这些事情，所以这些事情实际上是你的研发管理体系里面需要全盘考虑的全盘一个事情。

CMMI是一个很好的框架，他帮助你，就说去建立这样一个管理体系的一个框架，它提供了这样一个模型，包括他有一套问卷这样的指导体系，你即使不做CMMI，你的研发管理也是要做的得。，这个是QONE我们自己设想的一个长远目标，我们是要做研发管理工具，而不仅仅是CMMI工具，但是为了让我们的客户能够第一印象知道我们，我们有CMMI工具这样的一个定位，至少我们目前的市场定位是CMMI工具，而且我们也确实对这种CMMI客户他们的一些的特别要求做了一些很多的支持，这个不用讳言的。，这是我想跟大家交流的一些东西。

(04:20)M：那目前你们典型的客户是主要是哪些客户，就是哪一个领域的，他们在用你的产品时候，主要是做哪些东西？

A：像我们的客户就是从首先有一个规模特征上来讲，。比如就是一些做互联网的创业小团队，十几个人的小团队，很少有用我们的工具的。，为什么？因为一方面是资金的原因，很多小的团队，它都在生存期，很难说我拿出几十万去买哪那个工具；另外它自己本身的项目管理也有它的特点，比方说它的进度压力，比方它的生存压力导致了，比方我可能会快速的接项目，项目的重复性也会相对少一些，那么这个特点就导致了他们它不会选择我们的工具。

我们目前工具多数的用户（规模）在四五十人以上，多到几百人、上千人的，很多是一些行业客户，分布在不同的传统行业。的，比方说为传统行业提供这个IT项目支持的这样一些客户，分布在保险、金融、航空、航天，交通等等各个领域，包括你像一些军工的一些客户，刚才我也提到国防，他们会有他们的一些特别严格的要求，所以也是我们重要的一个客户来源。

(05：45)M：因为你经常和大家打交道，那么你总结一下，这些传统的企业他们有没有一个什么共同的特点，对软件需求方面这一块？

A：有的，其实也分为几种，你像我们接触的，因为确实我从研究所出来以后，这几年接触了很多的客户，也有很多感想。你就会发现客户各种各样，有的客户呢，它的软件工程的基础和规范性的这个水平相对薄弱，是你在研究所里想不到的，你比方说我们现在去有些客户那里，我们就从头帮他去建，建什么？建配置管理规范，就是你要把配置库用起来，有些东西比如你代码要用管起来，要不然你回头找不着了怎么办，你缺陷得有Bug管理工具，这个在我们看来是最基本的。项目管理你要有基本的项目管理，你要把这一套管理起来，这个是一种。这是基础比较差的，但是确实事实上有很多，我们必须面对这个事实，而且去帮助他们它改进。

另外还有很大一部分，实际上我们这几年随着我们干这个行业我们会发现，国内确实很多企业在发展，他们已经大量用在用大量一些涵盖各个领域的工具，比方说配置管理做的很好的配置管理工具，有一些特别的，他的需要变动特别多的，而且需求全生命周期需求变更维护的，有一些也用了这个变更管理工具，、需求管理工具；，包括用项目管理工具，也有一些用，包括你像这几年我们看到比较多的，像买一些国外大型的商用工具也有用多很多。

那么这些企业他们在管理之中，随着队伍两方面，一方面自身队伍的庞大，就会管理上有压力有需求，另外一方面开发的软件复杂性越来越大，体量越来越大，这样也会有很多的要求，这样导致他自身对软件开发管理，确实有发自自身的迫切的管理上的需求，我们现在是觉得这种客户是我们特别愿意面对的，我们称之为我们的优质客户，因为他是实实在在有规范化管理的需求，有可能根本不过CMMI，因为他是甲方，他不需要过CMMI，有的他已经过了CMMI，现在是要做实质的改进的客户，我觉得这个很重要，这个也是我们看到国内的这种客户越来越多，这是国内整个软件行业发展的一个表现。

(08:40)M：现在大家谈敏捷谈的比较多，感觉上大家对CMMI关注的好像稍微少了一点，据你了解现在谁还在用CMMI？

A：用CMMI其实也很多，你像从工艺功利这个角度出发，我要做外包，甲方对你资质有相关要求要做CMMI，像这些这种有很多。我当时也跟我们很多客户提到这样一个观点，我说CMMI不是坏事，你们做CMMI，比方说我是一个开发团队的这个负责人，我现在觉得我这个团队越来越大，项目越来越多了，我想好好的规范化整一整，梳理一下我的体系，把我的这个管理更加规范化起来。我去找老板要钱，老板说，你找我要50万干吗，我说我想梳理一下过程规划，老板很难答应。

但是呢，CMMI呢，它是一个契机，因为国家有相关的政策去支持，那么我说老板，我们现在要投标，我们这个要过一下CMMI，我们要过了政府还会有补贴，通常这个事情就很容易启动了，借助过CMMI这个契机（，CMMI本身也是一个很好的框架），我们按照这个框架去要求我们的整个管理体系，是能够把我们很多事情规范化的，又能借助外部的力量支持，也靠借助我们自己，其实更多的是自己。有自己的这个规范化管理的这种意愿和这种实际的需求，我们在这样一个契机下，借助CMMI这个契机，我们可以把自己的这种规范化管理做起来，这实际上是非常好的。

其实前几年，我自己曾经跟我们部门的人讨论，说CMMI未来客户有一个下降的趋势，但事实上好像，我记得上一次，应该是去年，我看到一个数字，CMMI实际上这个的客户数在是上升的，包括全国各地的一些补贴政策其实还有，只是说这几年讨论敏捷的公司企业团队确实越来越多，那么敏捷也有很多他很好的地方，就是我们底下聊天也会聊到很多，我是觉得不同的方法各有不同的好处，没必要一定要，一个方法论就能够涵盖所有的需求。，如果说一个方法论包打天下，从某种角度上说，我先不听这个方法论是什么内容，我先打个问号，你说一个方法论它一定有它的适用面，有他的适用对象，我觉得这是一个实事求是的一个态度，也是一个理性的分析问题的一个态度，不管什么样的项目，不管什么样的客户和任务，都是用敏捷，我是觉得怀疑，你说我所有的东西都是适用CMMI，我也表示怀疑，所以我觉得方法论戴哪盖一个帽子，占领一个阵营不重要，重要的是一定要适合本身实际的需求。

(11:55)M：刚才我们在聊天的时候，也谈到，在你工作当中，也用过敏捷，也试用过敏捷，对敏捷有没有什么评价？

A：我们现在团队里也有用敏捷的，我觉得敏捷有很多很好的地方，比如说敏捷的四个精神，沟通、勇气，简单，反馈，这些都是很好的精神，我觉得和CMMI也不违背。CMMI里面，实际刚才咱们聊到的CMMI是不是不重视人，其实我觉得只要是做软件开发的，只要是软件团队的，如果真正是一个软件团队的管理者，如果他不重视人，那么他就非常危险。因为软件团队主要靠人，我们的规范性是去帮助我们产品的质量，规范化管理，不是为了消减人的积极性的，所以我非常同意Kent Beck写的这个敏捷书上的有一句话，他是批判CMMI的，他说CMMI有一点是什么，强调文档，那么文档就成了不同的人之间，去推卸责任的一个壁垒避垒，比方说我这个东西我已经写文档了，我已经交给你了，就这个不是我的责任了，那你没弄好，我已经写文档了。，我是很同意他这句话的。

但是呢，我也我同意这句话的同时，我也不赞同，那我们就完全不写文档了，那就从一个极端走向另外一个极端，我觉得都不好，所以这是我的一些看法。我觉得我们内部也有用敏捷，那么我们实际上，我们自己内部定义一套我们自己的过程，而且随着我们的工具的升级来改进过程，因为我们自己也在用我们的自己的工具，这是学着Google，自己的狗食自己吃，比如那我们自己的工具像工具在4.0版本的时候，我们的这个过程就是根据基于我们自己的工具的过程，比方说我们每天要做哪些事情，要用那些规范，跟工具是怎么绑定的，这样大家都知道怎么做，你我们5.0版出来以后，我们工具提供了更多的支持，那么自然我的管理的一些规范也随之就变了。

所以我觉得这个是固定的，那你说我们这个规范一定是敏捷的吗，或者一定是CMMI的吗，我觉得都不重要，比方说他可能符合CMMI的，所有这些要求，那么我也希望，它能够带有敏捷的一些这种元素，不见得是所有，你比方说结对编程，我觉得不强求，现场客户，我想强求有时有些也强求不了，所以我觉得不拘泥，有用的就最好，每个企业每个团队根据自己的特色摸索出对找到自己的有用的过程。

(14:47)M：还是以实用为原则？

A：对。

(14:49)M：那根据你的理解，敏捷这个方法论主要适用于哪些方面？

A：敏捷你比方说像这个小团队，快速开发，项目开发，我觉得会比较更加适合一些。我们往往会看到有一些问题，就是网上有些言论，或者说大家说一些言论问，问说敏捷能不能做更大团队的开发，答案往往是也可以，比方说我分成不同的小团队什么什么的，我并不去置疑这个事情，但是我是觉得，你一个方法的传播，要考虑到他传播带来的一些衰减。那么比方说，敏捷方法在你的带领下，比方说你是一个非常好的一个敏捷这样一个的导师，在你的带领下，你可能100人的团队用的很好，但未必适合于我。

比方说我们这个，所以我是觉得呢，敏捷有它的适用面，同时对他的使用者也有一定的要求，也会有一些条件的要求，比方说要求我有很好的敏捷的Coach，要有很好这样一些配合，条件的配合，那么在没有这些条件配合的情况下话，也许发挥不到你想象的那个作用。你像我们这几年做产品，我有个很大的感觉，就说我就跟我们同事我都说，不要追求任何新潮的技术。我说一个新潮的技术，比方说一个新的框架，我用在一这个项目里面，可能会很好，能够支持快速的开发，但是用在产品里面，当你的产品里面有太多别人的东西你不能控制的新潮东西，可能引发的隐患和风险对我们来说是一个有很大的风险巨大的，尽量不要去做。

同样你比方说，敏捷这些东西，包括未来还会有，会不会有什么其他的方法论，大家一听起来很热血沸腾，很激昂的新的方法论，我觉得可以去学习，可以去了解，可以去尝试，但是不要为了尝试而尝试，更多的事情我们还应该关注在目标，目标我们实际上是为什么？是为了把我们的产品打造的更好，可以让我们的人开发的效率更高，让我们的产品质量更好，让我们的人干的更开心，这些我是认同的，但是具体的方法，可能还需要根据具体的情况去参考这些方法的精神，去制订你自己的过程，而不是照搬。

(17:25)M：因为你一直在一线和那些传统的企业，包括那些搞CMMI的这些企业打交道，我想了解一下这些企业他们对敏捷的出现有什么看法？

A：敏捷的出现呢，通常像搞技术的人，因为我自己是也是做技术的，以前做技术的，包括现在也没有脱离技术，那么做技术的人，通常他听了敏捷都会很高兴，因为技术人员对新鲜的技术、方法等这样的热情也是很重要的。如果哪那天我对这些新鲜技术没有热情了，这也很麻烦。我们面对的这些企业呢，有很多业企业也面临很多很多的问题，那么敏捷呢，比方说，大家都会遇到需求经常变更，那么敏捷说，我就是来解决需求经常变更的，所以很多企业听到这个的时候都会眼前一亮，但实际尝试的时候确实有做得好的，但是也确实有做得四不像的。

这就是我说敏捷有他的适用面，同时敏捷也会对做敏捷的这些人会有一些要求。比方说同样是敏捷一个敏捷的方法，你是专家，你做出来可能是一个样子，那我做出来是不是这个样子，不一定。所以我是觉得，我们看到的现实情况是，这个使用的水平参差不齐，所以我倒到觉得不强求那些概念，敏捷啊，Scrum啊，什么什么的概念我都不强求，更加的还是要注重实效。

(19:05)M：我们最后再沟通一个问题，给这些传统的软件团队，他们应该如何去应对新的开发模式的挑战？你的一些看法？比如说他从前是做CMMI的，现在要转向敏捷，面对敏捷的挑战，应该如何面对？

A：我的观点其实还是和前面都一致，我的意思就说如果我现在还回到这个，比方说我来做我这个团队的开发过程，如果我是一个开发团队的主管，我要来制订我整个的过程规范，首先我要对敏捷要有所了解，我了解敏捷哪些地方对我是有帮助的，我对CMMI等等也要了解，首先针对我要解决的问题，比方我现在这个团队，有一个比方说这种计划进度，很难把控这个问题，需求变更很难把控，需求各阶段产品之间的一致性，出现很大的问题导致我很多返工的问题。

那么针对我要解决的这些问题去参考那些模型、方法论、别人的经验、最佳实践，去参考这些东西，然后针对我企业的这种现状，我团队所处的环境，我这些人的水平，我要面对的开发的任务的情况，去制订我自己内部的开发过程，然后，最好不要想一步到位，这是我特别觉得很重要的一个建议，不要想着一下子做到100分，如果现在你是30分，你想做100分，往往一来做不到，二来打击到你做改进的积极性，先解决最重要的一个两个三个问题，然后再不断地往前改进，先做60分反而更现实，而且也更多的使你的团队收到改进的回报。总体来说我现在比较偏中庸，我觉得中国文化的中庸还是很重要的，不要偏向任何的一边，更多的注重实效，这是我的感受。

(21:25)M：感谢接受我们的采访，谢谢。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yuandafeng/archive/2010/07/14/5734747.aspx