【IT168 信息化】　　IBM Innovate 2010(原IBM Rational软件开发高峰论坛)今日在北京国际饭店隆重拉开序幕。您将了解到 IBM Rational 平台是如何助您实现包括团队创新、工作创新、结果创新的“全程创新”，为您的开发找准创新着力点，全面提高产品市场竞争力。会上，东软电信事业部副总经理兼CTO王爱民先生做了精彩的主题演讲!

东软电信事业部副总经理兼CTO王爱民先生

　　大家好。非常高兴能够来到这里和大家一起参加这个会议，也非常感谢IBM给我们一个机会，和大家一起共享东软在软件工程领域的一些经验、心得和体会。

　　这是我演讲的主要内容，包括项目工程改进的背景，以及方法和实施的具体介绍。我仅仅以配置管理域做一个简单的介绍，最后做一下总结。在介绍之前我先介绍一下，我来自东软。东软集团是1991年成立，现在员工17000人。是当前中国最大的IP解决方案和服务提供商，涉及的领域包括电信、电力、金融、社保、金融和教育。我在的这个部门是东软的电信事业部，主要面向运营商为他们提供服务，面向服务于中国联通和中国电信。大家看到的这个图片是大连的软件园，也是我所工作的地点。

　　我在东软已经工作十多年了，也亲身经历了电信事业部这个部门从30人到300人，到500人，到现在1000人的规模也碰到了国内企业发展中遇到的各种各样的问题，如何提升你的管理，如何把这种作坊式的工作方式变成正规军，而不是一直以这种方式作战。如何把你的管理过程固化到企业里，如何使之持续执行，这些都是我们国内企业发展过程中必然碰到的问题。

　　我们敢用的最主要的目标就是为了企业持续发展。如果要做发展，首先你要的是，你的方法论是否正确。所以，第一件事就是引进科学的软件过程方法和知识指导企业的研发管理，并形成企业级的、组织级的、项目级的增加实验，贯穿于整个研发的实施。另外，你要有一个专业化的工程和管理的实施团队来保证科学的实施和持续的改进。这是我们的一个目标。

　　下面介绍我们具体的改进方法和措施。既然做软件工程，大家都是做软件的，肯定要有一套方法论，你怎么去实现?我们说CMI只是定义了你要达到这个标准，我们说我们过了三级、五级，你只是达到了标准，但是并没有告诉你怎么做，只是告诉你要达到哪些标准。你如何定义出一个符合一定成熟度等级的开发流程，这是CMI并没有告诉你怎么做的。但是IMP正好是普通类空白，定义了完善软件开发的流程，告诉你项目团队如果达到CMI的标准。既然对我们来讲，在2003年、2004年的时候我选择了Rational，选择了RUP必然要有IBM的Rational打交道。其实在2003年考察配置管理内容的时候，我并没有意识到方法论的重要。随着和Rational交流的深入，可以说逐渐认同Rational。我们说方法论和工具实际上是相辅相成缺一不可的，方法论是政治，只有方向正确才能出彩。你的工具实际上是你的手段，你的那些先进的理念、先进的想法、先进的方法论要靠工具落地和实施。

　　我们知道业界有很多软件工程的工具，有些工具可能各自有各自的优点，但是它后面是不是有一种完善的方法论体系呢?不一定。Rational既有它的方法论，我们知道著名的RUP，Rational领域的一系列工具。所以说只有方法论和工具相结合才是我们最想要的。所以，在2003、2004年的时候我选择了Rational。从这几年的发展过程中大家也可以看到，比较好的那些公司现在也基本上被Rational收购了。

　　从2003年到现在，七八年的时间，东软逐渐形成了自己的一套方法体系，我们叫之为NUP，是基于复合为导向，以风险控制为原则，总结自身经验的基础上构建了东软统一过程。NUP是一套通用的过程框架，通过一系列的工程文件，指南、规范和模板，为企业开发的过程提供过程和开发的指导。通过软件全生命周期的规范和定制，强化过程执行，固化非常好的实现。

　　我们中国人有一个习惯，学技术非常的虚心，但是一学管理，尤其是这种项目管理的时候，就说不行，这老外不懂我们的实际情况，不懂中国的情况，中国有中国的特色。这个不适合我，这样拿过来之后不行。那我们最著名的华为的老板在学习国外先进理念的时候，提出的是先僵化，再优化，再固化。先僵化就是要僵化的执行，消除势力，你的企业不适合IBM的思想怎么办?削一削，砍一砍，让那只脚能穿进那只鞋子里去。当两年的僵化的过程中，你才能慢慢理解它的内涵，当理解了内涵之后才能做一些优化和改进的工作。最后是固化，固化实际上是制度化、模板化、规范化和流程化的一个实施。所以，我们提倡的是“僵化式学习、优化式创新，固化式提升”，这也是我们几年来的一个很深切的感受。这是我们的工作体系和过程对应的一个关系图。在配置和变更，主要是CC、CQ。

　　我们学习Rational一些非常好的使劲分为以下几点：以配置管理和变更管理为基础，引进需求管理和项目管理，注重各种实践的自动化实现，将各个阶段的内容有效继承和引用起来，逐步引进、不断完善，一定是一个迭代的逐步完善的过程。

　　我们的实施路径，第一，以CC、CQ的实施为整体流行的基础。咨询图和工作实施相结合将非常好的时间规划到平台，开始的时候我们并没有懂，一定请IBM流程的咨询服务，注重企业自身的咨询人员实施人员。结合NUP的非常好的实践，从点到面逐步推广。只有这样才能保证你一步一步的执行，并且保证不断的结果。这是我们部门实施平台的情况。当前是以CC、CQ无为基础的研发平台，大家能看到我们有很多系统，你的IT系统有很多，比如有需求的管理系统，有缺陷的管理系统、任务管理系统，大家能够看到，所有这一切都是以CC和CQ为核心，所有工作最后都会落到配置库上。

　　我举一个例子给大家做一个简要的阐述。首先，我们要看一下大家都说配置管理，到底什么是软件配置管理?到底包括了哪些方面的内容?我们说软件配置管理是通过对产品生命周期不同时间点的产品配置项进行标识，第一个要有配置项并进行标识，之后对这些产品配置项的标识进行变更和控制，从而保证项目的完整性、一致性和可控制的过程。你要做配置的管理计划，要做版本控制、要做变更，对所有工作要做审计，而所有的工作一定要在配置控制上进行操作，所以包括以下五件内容，这五件事情做好了，配置工作自然而然就做好了。这是我们CC、CQ使用的一个过程。从2003年开始到现在有七八年的时间，我将这个阶段分成七个区段，第一是摸索区，工具的考察，考察了CC，我基本上把所有的配置工具全部考察了一遍。之后是导入期、成长期和成熟期。从2003年到2005年，我发布的第一个软件工程的全套的体系文档，到2002年的第二版、2007年第三版、到今年中期发布的2010年的版本，七八年的时间是一个曲线的增长过程，从这里面也验证了我刚才提到的“先僵化、再优化、再固化、持续改善”这样一个理念。所以，做项目管理、过程改善绝对不是一蹴而就的，是需要有一个过程，而且这个过程时间会很长，会很痛苦。要一点一点逐步的去实施。

　　这是我们配置的一个环境，这套配置环境可能是中国乃至世界很特例的一个，我采用的都是Linux系统，我没有运用到Windows的域管理。CC里面大量的是小碎文件，小小碎文件，这种是最优的。我唯一要强调一点，中国企业里面对配置库的安全性并没有引起足够的重视。一个软件企业最重要的资产实际上就是这些文档、软件、过程，如果你的服务器瘫痪了、硬盘坏了，你的企业损失肯定是巨大的。因此，我们一定要在安全再安全的存储库上进行标识和存储。我是为电信服务的，所以我的系统也是电信级的，7×24小时，有每日备份的计划等等一系列。还有，一个月我会把我们的一份大硬盘送到银行，即使将来发生什么意外的话，它也是存在的。

　　刚才说了配置管理里要分五项，首先看配置的管理计划，配置管理计划到底要干什么，它的主要内容是什么?大家都看到了，我就不一一念了。也就是说，你的配置管理计划要怎么做?你的基准是怎么建立的、产品发布的计划是什么样的、基准状态是怎么做记录的，这些东西是不是都做了记录，是不是一步一步的都在执行。当大变更的时候你是不是做审计了，是不是做记录了，这是配置管理计划里需要的内容，包括你配置库的权限。

　　我们再来看版本控制，版本控制和开发管理我们的基本策略。对我们来讲采用的是两流的架构，开发流和集成流，这样的话两个空间较为稳定。以控件为单位实施的版本控制，设立并管理基线，使用Activity来组织整合版本，即将对控件和构建的运营开发。

　　再看变更控制，变更控制的目的，配置管理里面最重要的是变更控制，变更控制的目的就是防止配置项被随意更改。你要做哪些工作?要做变更，做变更就需要填变更申请单，之后你要审批你的变更流程，并且你所有的这些工作要在配置库上执行，执行完了之后你要做审核、做评审，最重要的是，你还要做记录。而所有这一切一定要进配置库。一个软件企业对我们来讲有很多很多的系统，对我来讲有需求管理系统、有缺陷跟踪系统、有任务管理系统。所有这些系统一定要打通、打穿，这样才能避免信息孤岛的存在，才能使你的整个管理的漏洞最小，才能使你的开发人员和你的员工把精力关注到真正我们需要他关注的地方去。这是我们CQ扩展的事例，我们的需求来了之后，当你做完需求分析、设计，流程审核完了之后，会自动导到CQ中去。同时，你要做需求的矩阵。这是在CQ中处理的整个流程，可以看到需求的分析、开发，最后会导入到CQ，走一个流程回到管理系统。这是我们称之为闭环的。

　　对BUG的处理，我们东软有一个BUGBASE，确认是BUG之后也会自动的导到CQ里面。这是CQ中BUG处理流程，BUGBASE处理完导到CQ，CQ处理完之后会通知BUGBASE，然后会进行改变，之后进行提交。

　　基准管理。对我们来讲，我们采用的是复合基线的方式来管理组件，严格按照配置管理的规划建立基线，建立基线后选定配置项如果虚的，必须提出行变更申请，通过对基线进行修改之后需要对基准进行变更和审核。所有这一切都要在配置库下进行，都要严格地按照项目管理计划来实施和执行，只有这样你才能真正保证生产的一致性。对我来讲，我的生产系统是为运营商服务的、电信服务的、中国联通服务的，你要保障你生产的环境、测试环境和我的配置库环境的代码一致，一旦出了问题，影响轻则一千户的投诉，重则上万的用户投诉。这是我们做的最重要的电信的系统，我们称之为BASE，主要是CM，基非帐务系统。我们采用的是并行开发的形式做的，可以看到中间的是我们的主版本或者是我们核心版本库。每一个省上完之后，每个省有每个省的系统。对于全国性的需求，共性的东西我们要在核心版本上演变、升级，继续往下做。对于本地化的个性化的东西，我们会在本地化的版本负责实施，而这一切都是用UCM实现的，使用UCM就使得我们并行开发和维护变得简单、变得容易。所有这一切都要做配置审计，而你的配置审计需要你的QA和你的CM共同实施和保证。也就是说你要严格按照配置项的计划进行审计，跟踪不符合问题的处理，跟踪不符合问题的表，还要跟踪他是不是改了，你要填审计报告，要对这些审计报告做记录。

　　刚才我讲的这些基本上涵盖了业界公认的管理配置管理的一些非常好的实践。做一个简要的小结：第一，要在安全的存储库中进行公认的标识和存储。第二，控制并审计对工作的变更。第三，记录并跟踪变更请求。第四，维护稳定一致的工作空间。第五，以控件为单位实施成本控制。第六，支持对工件和构件的并行开发。第七，要设立并管理基线。第八，使用活动来组织和整合版本。第九，尽早集成、持续集成。第十，确保软件的构件更新性。

　　在2007年IBM大会上，配置管理分会场里我讲了一下配置管理的内容。2007年到2010年，三年的时间，对我们来说有什么变化，或者说有什么不一样的地方，或者在改进过程中有哪些体会呢?就两个字，坚持。坚持不懈的坚持你已经固化下来的非常好的实践，坚持不懈的改进。大家都知道，我们通过三四年的时间形成了你的一套方法论，形成了你自己的体系，但是千万不要把这些东西变成一纸空文，束之高阁，因此要一直坚持的去执行，坚持做持续改进的工作，它是一个长久的工作。要把你那些核心的理念、核心的想法灌输到每一位员工，植入他的骨髓，成为日常的习惯，这是我们长期做的，一直做的事情。但是人都是有惰性的，人都不喜欢受约束，尤其是中国人，不喜欢受约束，你怎么办?除了日常的审计工作之外，你必须定期的做组织级的配置审计和评估，你督促整个非常好的实践和流程能够稳定、持续执行。目的，评审配置管理在项目中的实施情况衡量配置业务部门配置过程中的成熟度水平，发现配置管理的改善机会，提出改善建议，为各部门进一步改进提升配置管理提供指导。

　　这是7月份我们对我们部门做的一个审计情况，一共是7个要点21个审计项，大家可以看到，配置管理的策划，建立和维护配置库，创建项目基准，控制项目基准变更，执行项目审计等等，后面是两个具体项目评审的情况。举个例子，对于极力和维护数据库，我们有七个审计项，是否是按照配置管理计划进行了配置库，是否按目录进行了配置，文档是否按项目计划纳入了配置管理，是否有活动的Activity，内容规格是否规范、代码是不是有乱码等等。

　　我们查完之后发现的问题有一堆，只是做了一些简要的，比如第一个，曲线的分配不一致，主要原因是项目人员变更没有未及时更新项目配置计划，多数是没有接触过系统的培训等。大家都知道实施了这么多年，你还有这么多问题，所以说它是一个长期坚持的一个工作。

　　改进建议：对刚才说的那个，各业务部门应有针对性的配置一些配置管理人员，分配到项目中担任CML，保证项目的正常执行。

　　东软的经验总结，一定是以方法论为先导，致力于企业文化的改进。第二，着眼于研发体系的创建，不断扩展改进的过程领域。从2003年到2010年，我们的软件周期降低了30%，而且还有持续改善的趋势。第三，方法论与工具一定要相结合，并奖非常好的实践固化下来，并且要坚持不懈的执行。我的演讲完了，谢谢大家!