科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道东软王爱民:僵化式学习 优化式创新 固化式提升

东软王爱民:僵化式学习 优化式创新 固化式提升

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

8月27日,IBM Rational软件创新论坛Innovate 2010在京举办,东软电信事业部副总经理兼CTO 王爱民和大家一起共享东软在软件工程领域的一些经验、心得和体会。

作者:崔兰 来源:ZDNet软件频道 2010年8月30日

关键字: 大会关注 Innovate 2010 Rational IBM

  • 评论
  • 分享微博
  • 分享邮件

ZDNet软件频道讯 8月27日,IBM Rational软件创新论坛Innovate 2010在京举办,东软电信事业部副总经理兼CTO 王爱民和大家一起共享东软在软件工程领域的一些经验、心得和体会,王爱民表示,随着企业规模的增大,国内企业发展中遇到的各种各样的问题,如何提升你的管理,如何把这种作坊式的工作方式变成正规军,而不是一直以这种方式作战。如何把你的管理过程固化到企业里,如何使之持续执行,这些都是我们国内企业发展过程中必然碰到的问题。王爱民先生在会上讲解了东软集团为解决这些问题所做的改进方法和措施。

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

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

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

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

配置管理

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

版本控制

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

变更控制

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

对BUG的处理

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

基准管理

对我们来讲,我们采用的是复合基线的方式来管理组件,严格按照配置管理的规划建立基线,建立基线后选定配置项如果虚的,必须提出行变更申请,通过对基线进行修改之后需要对基准进行变更和审核。所有这一切都要在配置库下进行,都要严格地按照项目管理计划来实施和执行,只有这样你才能真正保证生产的一致性。对我来讲,我的生产系统是为运营商服务的、电信服务的、中国联通服务的,你要保障你生产的环境、测试环境和我的配置库环境的代码一致,一旦出了问题,影响轻则一千户的投诉,重则上万的用户投诉。这是我们做的最重要的电信的系统,我们称之为BASE,主要是CM,基非帐务系统。

对于全国性的需求,共性的东西我们要在核心版本上演变、升级,继续往下做。对于本地化的个性化的东西,我们会在本地化的版本负责实施,而这一切都是用UCM实现的,使用UCM就使得我们并行开发和维护变得简单、变得容易。所有这一切都要做配置审计,而你的配置审计需要你的QA和你的CM共同实施和保证。也就是说你要严格按照配置项的计划进行审计,跟踪不符合问题的处理,跟踪不符合问题的表,还要跟踪他是不是改了,你要填审计报告,要对这些审计报告做记录。

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

 

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章