技术开发 频道

SCM不仅仅是支持和管理

    事实如此,SCM仍然相当依赖于在职培训。没有哪所大学或学院提供4年的SCM专业课程。现在学术界已认识到这项工作所包含的复杂性。一些2年制的专科学院开始提供SCM的认证课程。1998年,我曾与3个在读博士生一起工作过,他们各自的论文都与SCM及其功能有关。

    如果这些都是真实的,则计划不能被简单的认为是“写一个SCM计划。”计划是一个非常好的开始,但我们需要的不只是一纸解释SCM所扮演的角色和责任的文章。SCM计划中需要包括:

    度量——多长时间,多少,什么时候和哪里?

    技术综合——需要控制什么,谁拥有它,谁能得到它?

    管理结构——谁在做什么,在哪里,什么时间,怎样做?

    可能性——如果发生了,会产生什么结果?

    工作量跟踪——需要人力及其素质,花费的人时

    转包商——责任和权利

    资源——预算,工具许可证,培训,管理开销

    矩阵式管理——分布的工作队伍

    管理转换——非正式到正式到分领域

    记录保存——保存什么,哪里保存,保存多长时间?

    管理——谁管理,管理什么,他们怎样进行管理?

    过程——可重复的标准化程序

    实案1  

    去年,东南部某大型宇航公司的一位SCM经理推荐购买一个自动化的SCM系统,这个系统可以满足SCM组列出的所有要求。管理部门暂时搁置了此推荐,希望其它工程部门给出这个工具的评审意见。最后此购买计划被取消了。工具的确给予了SCM部门支持,但它没有对工程师们列出的开发中需考虑的因素给予足够支持。不久后,他们买了另外一个工具,这个工具满足了SCM、软件工程师、软件质量保证、测试、集成以及管理层的所有主要需求。

    实案2:

    最近到一个位于新英格兰的私人企业访问(此企业不为政府所有),我发现工程师在使用SCM中最担心的是所谓限制。他们被错误的引导认为SCM意味着正式的管理,受限的访问,创造性的解决方案受到限制等等。当我解释资料能通过一系列的非正式管理步骤被转换为正式的管理基线,而且SCM并不等于完全禁闭或瓶颈,他们变得热切想加入到SCM的建设中来。一些会谈之后,一个逐步规范建立正式的SCM方法通过了,以取代非正式的管理和资料收集,这样可以产生基线项。每个人都对此而感到欣喜。工程师们很快意识到他们可以与SCM一起像一个团队一样工作来解决问题,而不是两个只关心自己和使用自己的方式解决问题的独立组织。更重要的是,SCM组懂得,当他们走出自己的办公室走到工程师中间时(即给予支持-面向服务),他们很快会变成开发过程以及开发团队的一个有机整体。

    结论

    在以上的两个案例中,SCM组和工程师们很快意识到他们可以象一个团队一样工作解决问题,而不是两个各不相干不相往来的独立体。一流的SCM运做只能通过对SCM的4个主要功能进行周到的计划才能实现。随着自动化的SCM工具和基线应用变得越来越复杂,SCM的基本原则已经开始有了新变化。SCM支持工程师,管理资料并提供维持基线完整性的服务。如果你所工作的地方,SCM不是这样工作的,那么现在该是时候问一声:为什么我们不是这样?

    关于作者

    Bruce Angstadt是纽约韦伯斯特的Xerox公司的软件过程改进经理。他为政府和产业公司做了35年工程支持方面的工作。他最感兴趣的领域是技术培训和软件配置管理。在为Xerox工作之前,他曾受雇Bell工作室的Navy和Harris公司。他同时还在加州的Systems Technology Institute of Malibu大学讲授一系列配置管理的课程。他毕业于佛罗里达州的奥兰多的Rollins College,是心理学和企业管理双学士。
 
 
    矩阵式管理——分布的工作队伍

    管理转换——非正式到正式到分领域

    记录保存——保存什么,哪里保存,保存多长时间?

    管理——谁管理,管理什么,他们怎样进行管理?

    过程——可重复的标准化程序

    实案1

    去年,东南部某大型宇航公司的一位SCM经理推荐购买一个自动化的SCM系统,这个系统可以满足SCM组列出的所有要求。管理部门暂时搁置了此推荐,希望其它工程部门给出这个工具的评审意见。最后此购买计划被取消了。工具的确给予了SCM部门支持,但它没有对工程师们列出的开发中需考虑的因素给予足够支持。不久后,他们买了另外一个工具,这个工具满足了SCM、软件工程师、软件质量保证、测试、集成以及管理层的所有主要需求。

    实案2:

    最近到一个位于新英格兰的私人企业访问(此企业不为政府所有),我发现工程师在使用SCM中最担心的是所谓限制。他们被错误的引导认为SCM意味着正式的管理,受限的访问,创造性的解决方案受到限制等等。当我解释资料能通过一系列的非正式管理步骤被转换为正式的管理基线,而且SCM并不等于完全禁闭或瓶颈,他们变得热切想加入到SCM的建设中来。一些会谈之后,一个逐步规范建立正式的SCM方法通过了,以取代非正式的管理和资料收集,这样可以产生基线项。每个人都对此而感到欣喜。工程师们很快意识到他们可以与SCM一起像一个团队一样工作来解决问题,而不是两个只关心自己和使用自己的方式解决问题的独立组织。更重要的是,SCM组懂得,当他们走出自己的办公室走到工程师中间时(即给予支持-面向服务),他们很快会变成开发过程以及开发团队的一个有机整体。

    结论

    在以上的两个案例中,SCM组和工程师们很快意识到他们可以象一个团队一样工作解决问题,而不是两个各不相干不相往来的独立体。一流的SCM运做只能通过对SCM的4个主要功能进行周到的计划才能实现。随着自动化的SCM工具和基线应用变得越来越复杂,SCM的基本原则已经开始有了新变化。SCM支持工程师,管理资料并提供维持基线完整性的服务。如果你所工作的地方,SCM不是这样工作的,那么现在该是时候问一声:为什么我们不是这样?

0
相关文章