SCM 不仅仅是支持和管理

软件配置管理（简称SCM）给使用者支持，管理资料库，并维持基线的完整性。先进的自动化工具，基线的生成，维护和产品的交付都要求细致和细节化的规划。为了工作更有效率，SCM必须辅以每日的强化，更新和维护。

不管你走到哪，面对什么人，只要你问起“SCM是一个支持组织还是管理组织？”即使你问的是两个在同一项目中工作的同事，你也很有可能得到两个不同的答案。那些疑心这是个坑人的问题或想显得懂得挺多的人可能会回答：“当然两者皆是。”但一旦要继续问“两者皆是”是什么意思？他们通常都会有更重要的事要先处理。

真正的答案是SCM是一个集支持与管理为一体的组织，但当它被正确的运用后，人们不得不开始考虑第三个要素，服务。

如果你跟软件工程师谈起这个问题，他们可能会告诉你，他们的确需要支持和一定量的管理，但不要太多。管理人员则一般会说管理是一个相对更重要的问题，如果这些管理不太耗资金和时间。一个有10年甚至更丰富经验的老SCM人，譬如一位一线主管或经理会同意这位管理人员的意见，也会坚持认为有些时候这些资金和时间是不可避免的需要投入的。一个SCM新人则很有可能会同意那些软件工程师的意见，并力图尽其可能的帮助他把工作完成。

这个问题变成了“SCM怎样才能在项目工作量增加的情况下，既能很好地完成支持、管理工作，又为项目提供服务？”

支持：SCM是一个提供支持的组织。它能给予项目工程师，项目本身，公司本身提供支持，甚至在很多情况下它也能对公司客户提供支持。

管理：SCM也是一个管理组织。它能对各种规格说明，文档，图表，需求，工具，软件及其它可交付物进行管理。

服务：SCM同时还是一个服务提供者。它提供各种支持并管理产出。这个看似简单的词却是一个成功的SCM系统中最重要的关键词。

SCM工作人员通常应具备两项能力：一是对公司工作提供支持，另一个则是管理产出。但当这两种工作被混淆，亦即SCM人员尝试管理开发人员工作的时候，麻烦和瓶颈就出现了。一般在这个时候，真正的SCM就会被绕过，人们通常用的籍口是“算了，以后再修改。”

这样一来，SCM经理的责任就包括：

l         确保SCM工程师都经过专业正式的培训，并且有一定量的资源（包括预算和工具）来有效的完成工作。

l         确保每一个项目支持方案既能够量身定做，又能平衡支持与管理。

l         确保SCM的功能非常灵活，能够适应工程师、客户、项目或公司本身不断变化的需求。

前景预测：

SCM的任务在过去的20-30年中并没有太大改变。然而，SCM工作的环境却有了相当大的变动；而且这种变动很有可能继续下去。软件的应用语言变了：从Basic, COBOL和FORTRAN，到Ada和Pascal，再到C++，Java等等。但这并未能真正给SCM冲击，毕竟代码换了个名字还是代码。

真正的给SCM带来影响力的冲动，来自于自动化工具和配置库系统的使用。

工具从版本控制和半自动化构造，发展到能建立和监视整个软件开发和产品环境。工具已变得更复杂精密，供应商也越来越多。不久前，对于SCM来说选择工作中需要的最佳操作工具还只是小菜一碟，但在如今的市场，在做出决定之前新的论点得先被提出来。对于各个工程部的代表们来说，在着手工作之前先根据他们自己的要求，考虑、评估和衡量各种可使用的工具和这些工具的工作能力，变得越来越重要。

今天SCM可使用的自动化工具，及其应用于制图方面的工具，都比以前的类似功能的工具要先进强大许多。但被问及“难道没有一个工具是可以做所有这些工作的吗？”时，答案仍然是否定的。主要原因在于，SCM的操作环境仍在不断发展着。

在近几年里，SCM 一直在处理代码和一些文件，这些东西通常都被塞在基线里，因为这样一来，它们能相当方便地被管理。但随着基于WEB的配置库的引入，不断发展的商业离岸销 售和子合同分包应用，基线，正如当初所定义的，迅速的变成了一个很自然的概念。想想你最后一次看到一个功能基线，分配基线或产品基线是什么时候的事了？可 能是某次你处理硬拷贝文件或打印的程序表的时候？而在一个电子化的办公室里，你再找不到这些东西了。现在的趋势是以查阅现有的受控版本（如代码，文档和需 求等等.）取代查阅基线版本；较早前则是这些受控的版本做为被归档的基线版本查阅。

在过去，大部分的程序同时有三种基线操作：功能线，分配线和产品线（或需求线，设计线和产品线，或其它类似配套的描述性标签）。美国航空航天局（NASA） 曾经尝试建立了一个有9条基线的系统，不过这个系统持续时间并不长。NASA，还有其它许多开发人员，认为了解受控项在哪条基线上非常重要，并且一直往这 个方向努力。这关系到受控项已被基线化，这样它就不能在没有经过正式的处理流程前被改变，并且还需要给这个受控项的电子部分取个名字。

是什么把他们的注意力终于从之前的3条基线上挪开呢？是SCM和其它开发工程师不断提出一问题，譬如“这个在不同文件中使用的JPG文件放在哪里呢？”“构造脚本和make 文件也应该受控吗？”和“我们可以在哪里管理公司的重用资产或重构？”

于是问题变成“控制委员会是管理文件还是文件包含的信息？”和“控制委员会管理的是软件代码还是别的？如果是，它是怎么工作的？又是怎么生成的？”在过去，SCM管理代码，有时候也包括文件。在我们正在开始处理应用的环境中，什么能被基线化呢？更简单的问题是“什么东西是不能被基线化的？”

答案：SCM能基线化所有针对某项目需要的东西，或使之可用。

答案：SCM能管理所有格式的资料，所以它能给人们支持并为项目提供一套完整的服务。

经验教训：

如果你不指望太多，看看SCM的标准，手册，指南，说明书等等，会发现SCM有4个主要功能：

1.       标识

2.       变更管理

3.       状态报告

4.       审计和验证

在几乎所有的教训中，计划都被忽略了。然而SCM 还在使用更复杂的设备以建立和维护复杂的环境，比如在多重平台上建立多重基线，多重环境等等。象所有人一样，SCM不得不把项目做得更快，用更少的资金， 更聪明的方式并且要比以往都好。计划则变得比以往任何时候都重要。在过去的10年里，人们一直相信这样的话：“让他们去做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不是这样工作的，那么现在该是时候问一声：为什么我们不是这样？

关于作者