UML软件工程组织

 

 

配置管理,我之所悟
 
作者:黄芸 来源:bokee.com
 

本文是我从事配置管理工作,从事SEPG工作的一点心得和体会,写出来仅与各位同仁进行交流。

所悟之一:配置管理工作关注的焦点是什么?

配置管理,从字面上来看,是由配置和管理两个动词所构成的,没有宾语。初识配置管理时,我感觉这个词太抽象了,为何?就是缺了个宾语,我无法将其与实际项目中任何事物联系起来,到底配置什么,管理什么。

其实,明确了这个宾语,也就回答了这个问题:配置管理关注的焦点就是配置项。

为何配置管理工作内容中首先提及的是"识别配置项"!这是我们工作的核心,管理的对象。在开始配置管理工作之时,在制定配置管理计划之时,我们首先要做的第一件事就是要明确项目中所有配置项。

我们可以细想一下,配置管理中的几项工作哪项与配置项无关?版本控制就是控制配置项的版本;变更控制就是控制配置项的变更;配置审计就是对配置项进行物理审计或功能审计;发布管理就是控制配置项的发布;配置状态发布实际上就是发布配置项目前的状态。

为何我们说:在制定配置管理计划,制定配置管理策略的时候要依据项目需求来定!项目的需求是什么,实际就是对配置项管理的要求!不同的项目配置项不同,不同的项目对配置项的管理级别以及管理方式的要求是不同的。明确了这些,我们才能够考虑项目的配置管理策略,制定项目的配置管理计划,才可以说项目的配置管理工作启动了。

总结:配置管理,我可以这样理解:配置统一工作环境用来支撑配置项管理工作。

所悟之二:配置管理工作中是过程重要还是工具重要?

我在做配置管理工作的时候,被问到的最多问题就是关于配置管理工具的:"为何这个工具老是报错?"很少有人向我提及:"你制定的配置管理策略在某某方面操作起来有问题!"

我们用的配置管理工具都是比较成熟的产品,为何我们操作起来经常会有异常的问题出现,大家有想过这个问题吗?我认为开发人员想这问题就太简单了。每个软件产品都有内在的业务处理逻辑,业务处理逻辑在配置管理中就是我们要谈及的过程,就是配置管理策略,那么配置管理工具也是软件产品,道理自然一样。一般配置管理工具,如Microsoft Visual SourceSafe,工具将过程已经固化;高级配置管理工具,如ClearCase,工具本身只是为我们提供了一个平台,我们在此基础上可以定制我们想要的过程。不管是工具本身已经固化过程还是我们自己在工具基础上定制过程,只要过程是明确的,我们对过程理解透彻,即使出现问题的时候,你也可以想出:为何会出现这个问题!就我总结,很多问题都是因为对过程的不熟悉,误操作而导致的。以不变的过程应对万变的问题,我认为大部分问题都是可以解决的。

同样,我想到我们在推行质量工程的时候,LSSP(Linkage Standard Software Process)发布之时,在项目组实施之时,大家都惊呼:"太多文档!"在预评估的时候,大家对SPI(Software Process Improvement)的期望都会提及:"我们需要工具支持!"一样的道理!

我在这里不是全盘否定工具的作用,但是我们可以完全依赖工具吗?试想一下:如果对工具本身的处理过程都不能理解很清楚的人,工具对他真的很有效吗?难道工具真的是我们需要的吗,真的可以帮助我们提高工作效率吗?质量工程中做任何一件事都要考虑投入与产出,工具给我们带来的产出你明确了吗?以上问题你都很肯定的时候,那就是可以使用工具的时候。

总结:我认为,配置管理工作中重要的是过程。过程是本,在大家都很明确过程的时候,工具对过程,对大家工作的支撑作用是会显著的。

所悟之三:基线和Label到底是什么关系?

LSSP发布以后,有太多人问我:"Label到底是什么?为何每次都是和基线同时出现?"

配置管理中抽象的概念比较多,基线就是其中之一。基线,顾名思义,是基准线,是项目组是下阶工作的起点。所以,对基线的确立将是非常慎重的一项工作,这将直接影响我们下阶段的工作。

一旦基线确立之后,那么Label就要隆重登场了。Label其实就是基线的实际体现形式。

总结:Label是基线在配置管理工具中的体现形式。通过Label,我们可以获取某一基线配置项的特定版本。

所悟之四:我们为什么要做内部发布?

系统版本发布,我们都很熟悉,不就是系统割接上线吗!配置管理中,我们把这种发布叫做"外部发布",那么就必然有与其相对的"内部发布"。他们之间到底有什么区别,我们为何又要多出一项工作:"内部发布"。

在产品投入正式生产之前,我们需要能够证明:我们的产品是可以顺利割接上线的;我们的产品是可以满足用户需求的。
这些信心从何而来?靠我们平时的演练,靠我们对产品的测试。

内部发布就是模拟系统割接上线,这种演习对于正式的割接是非常有好处的,其实我们的项目组是有在做的,只不过大家没有意识到这就是内部发布。例如:产品Alpha或Beta版本发布。

而且,这样我们可以随时访问产品:测试系统,熟悉系统,最终确认系统是否真正满足用户需求,是否真正好用。
内部发布,是给我们自己多几次机会,从而保证外部发布的成功。

一次总结,一次交流,彼此获益,何乐而不为!

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号