"伤得起"的云计算应用——对云端应用之架构的思考
2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障，导致许多商业网站的服务中断，影响非常严重。作为云计算用户，我们需要思考的是，如何保证即便在云服务不可用的情况，我们的应用架构仍然能够屹立不倒？本文正是站在云计算用户的角度试图探讨这一问题。
技术访谈
该内容已经被标记书签！
标记书签错误，请重试！
录制于：
袁峰谈CMMI在国内企业的实践以及敏捷评价
受访人 袁峰 采访人 霍泰稳 发布于 2010年6月29日 长度 00:21:28 下载 MP3
概要
国内CMMI领域专家袁峰在该访谈中，谈到CMMI在国内企业的应用现状，传统企业对软件的需求，并结合CMMI谈到敏捷开发方法的适用性，最后对软件团队应该采用何种开发方法给出自己的评价。
个人简介
袁峰，中国科学院软件研究所，计算机软件与理论专业，博士，副研究员，研究领域包括UML、MDA、软件过程、工作流以及SaaS等。坚持科研与产业相结合，在参与众多863国家课题研究的同时，也广泛参与产业界的各种实践活动，是UMLChina成员以及CSDN软件工程领域专家，在CSDN上开通专家博客，并在《程序员》、《软件世界》等杂志上发表相关技术文章。
关于会议
中国系统与软件过程改进年会，是由中国软件行业协会主办、中国软件行业协会系统与软件过程改进分会承办的在中国软件过程改进领域最有影响力的、规模最庞大的国际盛会，以专业、领先和规模庞大著称。
国内CMMI领域专家袁峰在该访谈中，谈到CMMI在国内企业的应用现状，传统企业对软件的需求，并结合CMMI谈到敏捷开发方法的适用性，最后对软件团队应该采用何种开发方法给出自己的评价。
个人简介
袁峰，中国科学院软件研究所，计算机软件与理论专业，博士，副研究员，研究领域包括UML、MDA、软件过程、工作流以及SaaS等。坚持科研与产业相结合，在参与众多863国家课题研究的同时，也广泛参与产业界的各种实践活动，是UMLChina成员以及CSDN软件工程领域专家，在CSDN上开通专家博客，并在《程序员》、《软件世界》等杂志上发表相关技术文章。
关于会议
中国系统与软件过程改进年会，是由中国软件行业协会主办、中国软件行业协会系统与软件过程改进分会承办的在中国软件过程改进领域最有影响力的、规模最庞大的国际盛会，以专业、领先和规模庞大著称。
我叫袁峰，我个人是产学研结合比较多的一个代表，过去我在软件所工作，包括现在还在承担一部分研究工作，比如一些国家研究课题，但实际上更多的精力在做产品。这几年我们走的研究跟实践结合的路，我另外一个身份是中科方德公司软工事业部的总经理，我们自己在做一些产品，这也是我现在特别想做，而且觉得有意义的事情，能够把我们在理论研究上的一些东西和实践相结合，并且把一些想法体现出来，具体应用到企业那里去。
这跟我们光坐在科研机构是不一样的，和我们仅仅做一些这种实践（也是不一样的），国内企业受实力的限制，一般企业很难有自己的研究院，但是对于方德来说，它本来就是软件所的一个投资公司，它背后天生就有这样的研究力量，我觉得这是一种很好的组合，很好的模式。我的情况大概就是这样。
这跟我们光坐在科研机构是不一样的，和我们仅仅做一些这种实践（也是不一样的），国内企业受实力的限制，一般企业很难有自己的研究院，但是对于方德来说，它本来就是软件所的一个投资公司，它背后天生就有这样的研究力量，我觉得这是一种很好的组合，很好的模式。我的情况大概就是这样。
因为这几年我们一直在做CMMI工具这一块，其实我本来是不太想把我们的工具（我们的工具叫QONE）挂上CMMI这个帽子的。去年看了潘加宇给我介绍的一本书叫《定位》，我相信你应该也看过，《定位》上提到，一下子给客户或者说我们的听众一个概念，如果他从来没听说过，没有和他脑海里任何一个熟悉的词关联起来，是很难产生什么影响的。
而我们的工具客户，事实上很大部分客户就是CMMI的客户。我们有个客户很有意思，他们在内部培训工具的时候，就把我们的工具叫成了CMMI集成平台。他没有称它为QONE，他说叫QONE，我们内部几百上千人不知道是啥东西，叫作CMMI集成平台，所有人都知道我在干吗。他这个想法其实很好，所以我也不忌讳把我们东西叫CMMI集成平台。但事实上，刚才我们聊的时候也说到，CMMI所关注的像项目管理、需求管理、缺陷管理、质量管理等等这些事情，你即使不做CMMI，也需要关注，不论用什么方法论，你都需要把你的整个团队管好，把你的项目计划做好，跟踪好，你都需要知道团队的建设，项目的进度，成本控制怎么样，这些事情实际上是你的研发管理体系里面需要全盘考虑的一个事情。
CMMI是一个很好的框架，他帮助你去建立这样一个管理体系的框架，它提供了这样一个模型，包括他有一套问卷这样的指导体系，你即使不做CMMI，你的研发管理也是要做的。QONE我们自己设想的长远目标，是要做研发管理工具，而不仅仅是CMMI工具，但是为了让我们的客户能够第一印象知道我们，我们有CMMI工具这样一个定位，至少我们目前的市场定位是CMMI工具，而且我们也确实对这种CMMI客户的特别要求做了很多的支持，这个不用讳言。
而我们的工具客户，事实上很大部分客户就是CMMI的客户。我们有个客户很有意思，他们在内部培训工具的时候，就把我们的工具叫成了CMMI集成平台。他没有称它为QONE，他说叫QONE，我们内部几百上千人不知道是啥东西，叫作CMMI集成平台，所有人都知道我在干吗。他这个想法其实很好，所以我也不忌讳把我们东西叫CMMI集成平台。但事实上，刚才我们聊的时候也说到，CMMI所关注的像项目管理、需求管理、缺陷管理、质量管理等等这些事情，你即使不做CMMI，也需要关注，不论用什么方法论，你都需要把你的整个团队管好，把你的项目计划做好，跟踪好，你都需要知道团队的建设，项目的进度，成本控制怎么样，这些事情实际上是你的研发管理体系里面需要全盘考虑的一个事情。
CMMI是一个很好的框架，他帮助你去建立这样一个管理体系的框架，它提供了这样一个模型，包括他有一套问卷这样的指导体系，你即使不做CMMI，你的研发管理也是要做的。QONE我们自己设想的长远目标，是要做研发管理工具，而不仅仅是CMMI工具，但是为了让我们的客户能够第一印象知道我们，我们有CMMI工具这样一个定位，至少我们目前的市场定位是CMMI工具，而且我们也确实对这种CMMI客户的特别要求做了很多的支持，这个不用讳言。
我们的客户首先有一个规模特征。比如一些做互联网的创业小团队，十几个人的小团队，很少有用我们的工具的。为什么？一方面是资金的原因，很多小的团队，它都在生存期，很难说我拿出几十万去买哪个工具；另外它自己本身的项目管理也有特点，比方说它的进度压力，比方它的生存压力导致了，可能会快速的接项目，项目的重复性也会相对少一些，这个特点就导致了他们不会选择我们的工具。
我们目前工具多数的用户（规模）在四五十人以上，多到几百人、上千人的，很多是一些行业客户，分布在不同的传统行业。比方说为传统行业提供这个IT项目支持的这样一些客户，分布在保险、金融、航空、航天，交通等等各个领域，包括一些军工的客户，刚才我也提到国防，他们会有一些特别严格的要求，也是我们重要的一个客户来源。
我们目前工具多数的用户（规模）在四五十人以上，多到几百人、上千人的，很多是一些行业客户，分布在不同的传统行业。比方说为传统行业提供这个IT项目支持的这样一些客户，分布在保险、金融、航空、航天，交通等等各个领域，包括一些军工的客户，刚才我也提到国防，他们会有一些特别严格的要求，也是我们重要的一个客户来源。
有的，其实也分为几种，你像我们接触的，我从研究所出来以后，这几年接触了很多的客户，也有很多感想。你就会发现客户各种各样，有的客户呢，它的软件工程的基础和规范性的这个水平相对薄弱，是你在研究所里想不到的，你比方说我们现在去有些客户那里，我们就从头帮他去建，建什么？建配置管理规范，就是你要把配置库用起来，有些东西比如代码要管起来，要不然你回头找不着了怎么办，你缺陷得有Bug管理工具，这个在我们看来是最基本的。要有基本的项目管理，你要把这一套管理起来，这个是一种。这是基础比较差的，但是确实事实上有很多，我们必须面对这个事实，而且去帮助他们改进。
另外还有很大一部分，实际上这几年随着我们干这个行业我们会发现，国内确实很多企业在发展，他们已经大量在用一些涵盖各个领域的工具，比方说做的很好的配置管理工具，有一些特别的，他的需要变动特别多的，而且需求全生命周期需求变更维护的，有一些也用变更管理工具、需求管理工具；包括用项目管理工具，也有一些用，你像这几年我们看到比较多的，买一些国外大型的商用工具也有很多。
这些企业在管理之中，随着两方面，一方面自身队伍的庞大，管理上有压力有需求，另外一方面开发的软件复杂性越来越大，体量越来越大，也会有很多的要求，这样导致他自身对软件开发管理，确实有发自自身的迫切的管理需求，我们现在觉得这种客户是我们特别愿意面对的，我们称之为我们的优质客户，因为他是实实在在有规范化管理的需求，有可能根本不过CMMI，因为他是甲方，他不需要过CMMI，有的他已经过了CMMI，现在是要做实质的改进的客户，我觉得这个很重要，我们看到国内的这种客户越来越多，这是国内整个软件行业发展的一个表现。
另外还有很大一部分，实际上这几年随着我们干这个行业我们会发现，国内确实很多企业在发展，他们已经大量在用一些涵盖各个领域的工具，比方说做的很好的配置管理工具，有一些特别的，他的需要变动特别多的，而且需求全生命周期需求变更维护的，有一些也用变更管理工具、需求管理工具；包括用项目管理工具，也有一些用，你像这几年我们看到比较多的，买一些国外大型的商用工具也有很多。
这些企业在管理之中，随着两方面，一方面自身队伍的庞大，管理上有压力有需求，另外一方面开发的软件复杂性越来越大，体量越来越大，也会有很多的要求，这样导致他自身对软件开发管理，确实有发自自身的迫切的管理需求，我们现在觉得这种客户是我们特别愿意面对的，我们称之为我们的优质客户，因为他是实实在在有规范化管理的需求，有可能根本不过CMMI，因为他是甲方，他不需要过CMMI，有的他已经过了CMMI，现在是要做实质的改进的客户，我觉得这个很重要，我们看到国内的这种客户越来越多，这是国内整个软件行业发展的一个表现。
用CMMI其实也很多，从功利这个角度出发，我要做外包，甲方对你资质有相关要求要做CMMI，这种有很多。我当时也跟我们很多客户提到这样一个观点，我说CMMI不是坏事，你们做CMMI，比方说我是一个开发团队的这个负责人，我现在觉得我这个团队越来越大，项目越来越多了，我想好好的规范化整一整，梳理一下我的体系，把我的这个管理更加规范化起来。我去找老板要钱，老板说，你找我要50万干吗，我说我想梳理一下过程规划，老板很难答应。
但是CMMI呢，它是一个契机，因为国家有相关的政策去支持，那么我说老板，我们现在要投标，我们要过一下CMMI，我们过了政府还会有补贴，通常这个事情就容易启动了，借助过CMMI这个契机（CMMI本身也是一个很好的框架），我们按照这个框架去要求我们的整个管理体系，是能够把我们很多事情规范化的，又能借助外部的力量支持，也靠我们自己，其实更多的是自己。有自己的这个规范化管理的意愿和实际需求，我们在这样一个契机下，借助CMMI这个契机，可以把自己的这种规范化管理做起来，这实际上是非常好的。
其实前几年，我自己曾经跟我们部门的人讨论，说CMMI未来客户有一个下降的趋势，但事实上好像，我记得上一次，应该是去年，我看到一个数字，CMMI的客户数在是上升的，包括全国各地的一些补贴政策其实还有，只是说这几年讨论敏捷的公司企业团队确实越来越多，敏捷也有很多很好的地方，就是我们底下聊天也会聊到很多，我是觉得不同的方法各有不同的好处，没必要一定要一个方法论就能够涵盖所有的需求。如果说一个方法论包打天下，从某种角度上说，我先不听这个方法论是什么内容，我先打个问号，一个方法论它一定有它的适用面，有他的适用对象，我觉得这是一个实事求是的态度，也是一个理性分析问题的态度，不管什么样的项目，不管什么样的客户和任务，都用敏捷，我是觉得怀疑，你说我所有的东西都是适用CMMI，我也表示怀疑，所以我觉得方法论戴哪一个帽子，占领一个阵营不重要，重要的是一定要适合本身实际的需求。
但是CMMI呢，它是一个契机，因为国家有相关的政策去支持，那么我说老板，我们现在要投标，我们要过一下CMMI，我们过了政府还会有补贴，通常这个事情就容易启动了，借助过CMMI这个契机（CMMI本身也是一个很好的框架），我们按照这个框架去要求我们的整个管理体系，是能够把我们很多事情规范化的，又能借助外部的力量支持，也靠我们自己，其实更多的是自己。有自己的这个规范化管理的意愿和实际需求，我们在这样一个契机下，借助CMMI这个契机，可以把自己的这种规范化管理做起来，这实际上是非常好的。
其实前几年，我自己曾经跟我们部门的人讨论，说CMMI未来客户有一个下降的趋势，但事实上好像，我记得上一次，应该是去年，我看到一个数字，CMMI的客户数在是上升的，包括全国各地的一些补贴政策其实还有，只是说这几年讨论敏捷的公司企业团队确实越来越多，敏捷也有很多很好的地方，就是我们底下聊天也会聊到很多，我是觉得不同的方法各有不同的好处，没必要一定要一个方法论就能够涵盖所有的需求。如果说一个方法论包打天下，从某种角度上说，我先不听这个方法论是什么内容，我先打个问号，一个方法论它一定有它的适用面，有他的适用对象，我觉得这是一个实事求是的态度，也是一个理性分析问题的态度，不管什么样的项目，不管什么样的客户和任务，都用敏捷，我是觉得怀疑，你说我所有的东西都是适用CMMI，我也表示怀疑，所以我觉得方法论戴哪一个帽子，占领一个阵营不重要，重要的是一定要适合本身实际的需求。
我们现在团队里也有用敏捷的，我觉得敏捷有很多很好的地方，比如说敏捷的四个精神，沟通、勇气，简单，反馈，这些都是很好的精神，我觉得和CMMI也不违背。CMMI里面，实际刚才咱们聊到CMMI是不是不重视人，其实我觉得只要是做软件开发的，如果真正是一个软件团队的管理者，如果他不重视人，那么他就非常危险。因为软件团队主要靠人，我们的规范性是去帮助我们产品的质量，规范化管理，不是为了消减人的积极性的，所以我非常同意Kent Beck写的敏捷书上的一句话，他是批判CMMI的，他说CMMI有一点是什么，强调文档，文档成了不同的人之间，去推卸责任的一个壁垒，比方说我这个东西我已经写文档了，我已经交给你了，就不是我的责任了，那你没弄好，我已经写文档了。我是很同意他这句话的。
但是呢，我同意这句话的同时，我也不赞同我们就完全不写文档了，那就从一个极端走向另外一个极端，我觉得都不好，这是我的一些看法。我觉得我们内部也有用敏捷，实际上，我们自己内部定义一套我们自己的过程，而且随着我们的工具的升级来改进过程，因为我们自己也在用我们的自己的工具，这是学Google，自己的狗食自己吃，比如工具在4.0版本的时候，我们的过程就是根据基于我们自己的工具的过程，比方说我们每天要做哪些事情，要用那些规范，跟工具是怎么绑定的，这样大家都知道怎么做，我们5.0版出来以后，工具提供了更多的支持，那么自然我的管理的一些规范也随之就变了。
你说我们这个规范一定是敏捷的吗，或者一定是CMMI的吗，我觉得都不重要，比方说他可能符合CMMI的所有要求，我也希望它能够带有敏捷的一些元素，不见得是所有，你比方说结对编程，我觉得不强求，现场客户，我想强求有时也强求不了，所以我觉得不拘泥，有用的就最好，每个企业每个团队根据自己的特色摸索出对自己有用的过程。
但是呢，我同意这句话的同时，我也不赞同我们就完全不写文档了，那就从一个极端走向另外一个极端，我觉得都不好，这是我的一些看法。我觉得我们内部也有用敏捷，实际上，我们自己内部定义一套我们自己的过程，而且随着我们的工具的升级来改进过程，因为我们自己也在用我们的自己的工具，这是学Google，自己的狗食自己吃，比如工具在4.0版本的时候，我们的过程就是根据基于我们自己的工具的过程，比方说我们每天要做哪些事情，要用那些规范，跟工具是怎么绑定的，这样大家都知道怎么做，我们5.0版出来以后，工具提供了更多的支持，那么自然我的管理的一些规范也随之就变了。
你说我们这个规范一定是敏捷的吗，或者一定是CMMI的吗，我觉得都不重要，比方说他可能符合CMMI的所有要求，我也希望它能够带有敏捷的一些元素，不见得是所有，你比方说结对编程，我觉得不强求，现场客户，我想强求有时也强求不了，所以我觉得不拘泥，有用的就最好，每个企业每个团队根据自己的特色摸索出对自己有用的过程。
你比方说像小团队，快速开发，项目开发，我觉得会更加适合一些。我们往往会看到有一些问题，就是网上有些言论，或者说大家问，问敏捷能不能做更大团队的开发，答案往往是也可以，比方说我分成不同的小团队什么什么的，我并不去置疑这个事情，但是我是觉得，一个方法的传播，要考虑到他传播带来的一些衰减。那么比方说，敏捷方法在你的带领下，比方说你是一个非常好的一个敏捷的导师，在你的带领下，你可能100人的团队用的很好，但未必适合于我。
所以我是觉得呢，敏捷有它的适用面，同时对他的使用者也有一定的要求，也会有一些条件的要求，比方说要求我有很好的敏捷的Coach，要有很好这样一些配合，条件的配合，那么在没有这些条件配合的情况下，也许发挥不到你想象的那个作用。你像我们这几年做产品，我有个很大的感觉，我就跟我们同事我都说，不要追求任何新潮的技术。我说一个新潮的技术，比方说一个新的框架，我用在一个项目里面，可能会很好，能够支持快速的开发，但是用在产品里面，当你的产品里面有太多别人的你不能控制的新潮东西，可能引发的隐患和风险对我们来说是巨大的，尽量不要去做。
同样你比方说敏捷，包括未来还会有什么其他的方法论，大家一听起来很热血沸腾，很激昂的新的方法论，我觉得可以去学习，可以去了解，可以去尝试，但是不要为了尝试而尝试，更多的事情我们还应该关注在目标，目标我们实际上是为什么？是为了把我们的产品打造的更好，可以让我们的人开发的效率更高，让我们的产品质量更好，让我们的人干的更开心，这些我是认同的，但是具体的方法，可能还需要根据具体的情况去参考这些方法的精神，去制订你自己的过程，而不是照搬。
所以我是觉得呢，敏捷有它的适用面，同时对他的使用者也有一定的要求，也会有一些条件的要求，比方说要求我有很好的敏捷的Coach，要有很好这样一些配合，条件的配合，那么在没有这些条件配合的情况下，也许发挥不到你想象的那个作用。你像我们这几年做产品，我有个很大的感觉，我就跟我们同事我都说，不要追求任何新潮的技术。我说一个新潮的技术，比方说一个新的框架，我用在一个项目里面，可能会很好，能够支持快速的开发，但是用在产品里面，当你的产品里面有太多别人的你不能控制的新潮东西，可能引发的隐患和风险对我们来说是巨大的，尽量不要去做。
同样你比方说敏捷，包括未来还会有什么其他的方法论，大家一听起来很热血沸腾，很激昂的新的方法论，我觉得可以去学习，可以去了解，可以去尝试，但是不要为了尝试而尝试，更多的事情我们还应该关注在目标，目标我们实际上是为什么？是为了把我们的产品打造的更好，可以让我们的人开发的效率更高，让我们的产品质量更好，让我们的人干的更开心，这些我是认同的，但是具体的方法，可能还需要根据具体的情况去参考这些方法的精神，去制订你自己的过程，而不是照搬。
敏捷的出现呢，通常像搞技术的人，因为我自己是也是做技术的，以前做技术的，包括现在也没有脱离技术，做技术的人通常听了敏捷都会很高兴，因为技术人员对新鲜的技术、方法等的热情也是很重要的。如果哪天我对这些新鲜技术没有热情了，这也很麻烦。我们面对的这些企业呢，有很多企业面临很多很多的问题，比方说，大家会遇到需求经常变更，那么敏捷说，我就是来解决需求经常变更的，所以很多企业听到这个的时候都会眼前一亮，但实际尝试的时候确实有做得好的，也确实有做得四不像的。
这就是我说敏捷有他的适用面，同时敏捷也会对做敏捷的这些人有一些要求。比方说同样是一个敏捷的方法，你是专家，你做出来可能是一个样子，那我做出来是不是这个样子，不一定。我们看到的现实情况是使用的水平参差不齐，所以我倒觉得不强求那些概念，敏捷啊，Scrum啊，什么什么的概念我都不强求，更加的还是要注重实效。
这就是我说敏捷有他的适用面，同时敏捷也会对做敏捷的这些人有一些要求。比方说同样是一个敏捷的方法，你是专家，你做出来可能是一个样子，那我做出来是不是这个样子，不一定。我们看到的现实情况是使用的水平参差不齐，所以我倒觉得不强求那些概念，敏捷啊，Scrum啊，什么什么的概念我都不强求，更加的还是要注重实效。
我的观点其实还是和前面一致，比方说我来做我这个团队的开发过程，如果我是一个开发团队的主管，我要来制订我整个的过程规范，首先我要对敏捷要有所了解，我了解敏捷哪些地方对我是有帮助的，我对CMMI等等也要了解，首先针对我要解决的问题，比方我现在这个团队，比方说计划进度很难把控这个问题，需求变更很难把控，需求各阶段产品之间的一致性，出现很大的问题导致我很多返工的问题。针对我要解决的这些问题去参考那些模型、方法论、别人的经验、最佳实践，去参考这些东西，然后针对我企业的这种现状，我团队所处的环境，我这些人的水平，我要面对的开发任务的情况，去制订我自己内部的开发过程，然后，最好不要想一步到位，这是我特别觉得很重要的一个建议，不要想着一下子做到100分，如果现在你是30分，你想做100分，往往一来做不到，二来打击到你做改进的积极性，先解决最重要的一个两个三个问题，然后再不断地往前改进，先做60分反而更现实，而且也更多的使你的团队收到改进的回报。总体来说我现在比较偏中庸，我觉得中国文化的中庸还是很重要的，不要偏向任何的一边，更多的注重实效，这是我的感受。
采访人 霍泰稳 是InfoQ中文站的联合创始人兼总编辑，有多年的软件开发经验和媒体从业经历。
好东西
发表人
李 引
发表于
safa被抢了
发表人
Hua Xiao
发表于
顶，实用主义。
发表人
jiang chenxin
发表于
顶
发表人
nfs chiefleo
发表于
敏捷和CMMI并不冲突
发表人
李 中华
发表于
CMMI和敏捷可以结合
发表人
Gao Fei
发表于
6 条回复
关注此讨论 回复