在我帮助一些软件团队实施软件配置管理的时候，我发觉很多朋友都喜欢这样问我：“你手头有没有别人写好的软件配置管理计划，能不能借我看一看”。后来我发现在网上一些软件工程方面的论坛上，类似“谁有软件配置管理计划的模板”这样的帖子也很多。

    “预则立，不预则废”，软件配置管理计划对于配置管理实施的重要性毋庸多言。大家想看看别人做的配置管理计划或者模板，无非是想学学别人的成功经验，避免自己走一些弯路。

    但是我想，在这方面，更应该学习的应该是计划软件配置管理实施的思路，毕竟，各个开发团队不同的地方太多了。下面是我观察和思考的一些成果，和大家分享。

像你的老板一样思考
    作为一个配置管理实施的执行人员，你怎么样才能够保证这项活动的成功呢？

    说起来很简单、但是也是重要的第一步，是定义“成功”。

    很多负责配置管理实施的人员都是技术人员出身，我经常能在他们身上观察到的一种现象是：出于对技术的热爱，他们希望把软件配置管理学习、理解得很透彻，然后同样出于对技术的热情，希望能把所有在技术上很“诱人”的东西都实践起来。

    我没有贬低这种热情的意思（事实上，我自己也经常被这种热情所导引）；但是，我们一定要小心地提防这种热情把我们引离了通向成功的方向。

    为什么要实施软件配置管理？因为有效的配置管理可以帮助我们提高软件产品质量、提高开发团队工作效率。

    什么是“成功”的配置管理实施？很简单，只要比较配置管理实施活动前后，软件产品的质量是不是得到了提高、开发团队是不是能够工作在一个有助于提高整体工作效率的配置管理平台上。

    软件配置管理活动在整个开发活动中是一项支持性、保障性的工作，它本身并不直接为企业产出可以直接赢利的工作成果；而配置管理每一项活动都需要消耗企业的人力资源，有些还需要购置专门的工具来支持活动的进行，这些都会导致企业生产成本的增加。

    所以，在我们计划实施配置管理时要做哪些事情的时候，要小心地界定每一项活动，取舍的标准是：从事这项活动是不是真正有助于我们实施活动的成功？它对于提高我们产品的质量有多大的帮助？能否帮助开发团队更高效率地工作？

    大多数情况下，你的老板花钱让你来做配置管理，并不是来让你学习配置管理或者研究配置管理，而是希望你的工作能帮助他改变些什么；他的投资成功与否，是用投资回报率（ROI，return-on-investment）来衡量，而不是你对于配置管理技术研究的程度。

评估开发团队当前配置管理现状
    计划配置管理实施的基础，是搞清楚开发团队当前配置管理的现状。知道自己现在站在哪里，才明白自己下一步要往哪里走。 对于配置管理现状的评估，可以自己进行，也可以引入外部专业咨询人员来完成评估活动。

    自己进行评估的话，可以参照SW-CMM中关于软件配置管理这个关键过程域的资料；也可以利用PMT编写的《软件组织配置管理能力自我评估问题集》，来完成自我评估的工作。

    引入外部专业咨询人员进行评估有两个好处，一是通常这样的咨询人员有比较丰富的配置管理实施经验，评估工作可以进行得更加细致，而且通常咨询人员会在评估结果的基础上提出实施的建议；二是引入外部人员，通常评估结果会比内部自我评估更客观。坏处是要花钱，而且如果该咨询人员与具体的配置管理工具厂商有利益关系的时候，也可能会出现评估过程受到这种利益关系影响的情形。

    不管以何种方式进行，评估这个步骤的工作是一定要仔细进行的。有了评估的结果，才谈得上改进。做好这个工作，比到处去找一份配置管理计划的模板更有意义。

定义实施的范围
    对于没有正式实施过软件配置管理的开发团队来说，在配置管理方面存在的问题可能会比较多；经过评估，会找出来很多需要改进的点，那么，怎么样来计划改进的工作步骤呢？

    曾经有一位朋友向我展示他撰写的软件配置管理计划，从基本的版本控制、基线管理、变更管理，到软件构建的管理（Build Management）、配置审核（Auditing）、配置状态的报告，洋洋洒洒，什么都做在计划里了。他的团队以前没有太多配置管理的概念，因而也出现了很多一直困扰他的问题，在我向他介绍配置管理可以帮助他改善或解决这些问题以后他变成了一个配置管理技术的爱好者。我想他一定仔细研读了RUP配置管理工作流、IEEE软件配置管理标准之类的资料然后写出了这份计划。我对他的计划提了一个问题：“你觉得按照日程安排我们做得完这么多事情吗？”

    这是前边说过的，热爱技术的朋友容易出现的情况，为技术而技术、为流程而流程；我记得一位朋友跟我说过一句非常有意义的话：流程改进应该是以结果为导向的（Result Oriented）。配置管理的实施也是如此，应当在当前评估的基础上，抓住团队头疼的几个问题，努力想办法解决这些问题。

    大家都知道管理学里有一个黄金法则：80/20法则。在这里我们也可以套用一下，想一想：我如何才能找出20％的问题，在当前这个阶段，这20％的问题给我的团队带来80％的困扰和痛苦，然后，我们集中80％的精力来解决这些问题。

    一句话，不要企图一口吃个胖子。流程改进是一个持续的历程，一个阶段会有一个阶段改进的重点，抓住重点、做出成绩，才是有效的改进之道。 计划资源要素
俗话说，兵马未动，粮草先行。配置管理的实施需要消耗一定的资源，在这个方面一定要预先规划。

    具体来说，配置管理实施主要需要两方面的资源要素：一是人力资源，二是工具。下面分别论述。

    人力方面，因为配置管理是一个贯穿整个软件生命周期的基础支持性活动，所以配置管理会涉及到团队中比较多的人员角色。比如，项目经理、配置管理员、开发人员、测试人员、集成人员、维护人员等。但是，工作在一个良好的配置管理平台上并不需要开发人员、测试人员等角色了解太多的配置管理知识，所以，配置管理实施的主要人力资源会是集中在配置管理员上。 配置管理员是一个比较奇妙的角色，对于一个实施了配置管理、建立了配置管理工作平台的团队来说，他是非常重要的，整个开发团队的工作成果都在他的掌管之下，他负责管理和维护的配置管理系统如果出现问题的话，轻则影响团队其他成员的工作效率，重则可能出现丢失工作成果、发布错误版本等严重的后果。然而，由于传统不了解配置管理重要性的原因，在国内的开发团队中，通常大家都不愿意去做配置管理员。我遇到很多情况，都是项目经理找来找去，选出来一个不喜欢做开发工作的女孩，来担任配置管理员。 在国外一些比较成熟的开发组织中，配置管理员被称为CMO（Configuration Management Officer），或者是配置经理；他们被称为是项目经理的左手。从这两个称谓我们可以看出他们对于配置管理员的重视。在选拔配置管理员的时候，也有相当高的要求，比如，有一定的开发经验，对于系统（操作系统、网络、数据库等方面）比较熟悉，掌握一定的解决问题（trouble shooting）的技巧，在个人性格上，要求比较稳重、细心。

    在配置管理员这个资源配置方面，要注意后备资源（Backup）的培养。在大家越来越重视配置管理的大环境下，经验丰富的配置管理员会成为抢手的人才；而配置管理员的离开可能会给团队的工作进度带来一定的影响，所以聪明的管理者会为自己留好备份。


    选择什么样的配置管理工具，一直是大家关注的热点问题。确实，与其他的一些软件工程活动不一样，配置管理工作更强调工具的支持；缺乏良好的配置管理工具的话，要做好配置管理的实施会非常困难。

    具体来说，我想在配置管理工具的选型上，可以综合考虑下边的一些因素。

    首先是经费。市场上现有的商业配置管理工具，大多价格不菲。到底是选用开放源代码的自由软件、还是采购商业软件，如果采购商业软件的话，选择哪个档次的软件，这些问题的答案，取决于你能从老板那儿拿到多少钱。

    一般来说，如果经费充裕的话，采购商业的配置管理工具会让实施过程更顺利一些，商业工具的操作界面通常更方便一些，与流行的集成开发环境（IDE）通常也会有比较好的集成，实施过程中出现与工具相关的问题也可以找厂商解决。

    如果经费有限的话呢，不妨采用自由软件，如CVS之类的工具。其实无论在稳定性还是在功能方面，CVS的口碑都非常好，我看到过很多组织成功地在CVS上完成配置管理的工作。如果你（或者你的配置管理员）不是一个依赖性很强的人，喜欢自己钻研、自己去寻找资料解决问题，CVS会是一个不错的选择。


    如果准备选择商业配置管理工具，应当重点考虑下面几个因素。

一、工具的市场占有率。大家都选择的东西通常会是比较好的东西。而且市场占有率高也通常表明该企业经营状况会好一些，被人收购或者倒闭的可能性小一点。

二、工具本身的特性，如稳定性、易用性、安全性、扩展能力等。你应当在投资以前仔细地对工具进行试用和评估。这儿比较容易忽略的是工具的扩展能力（Scalability），你现在可能只是在几个人、十几个人的团队中部署这个工具，但是以后可能会有几十个、几百个人要在依赖这个工具建立的平台上工作，到时候这个工具能不能提供这样的支持能力？如果到时候要换一个工具的话，你一定会后悔的选择。

三、厂商支持能力。工具使用过程中一定会出现这样那样的问题，有些是因为你使用不当引起的，有些则是工具本身的毛病。这样的问题会影响到开发团队的工作进度，你一定希望能随时找到厂商的专业技术人员帮助你解决这些问题。

    配置管理工具不是用一次两次的工具，因此，选择配置管理工具其实是选择和哪个厂商来建立一种长期的关系；如果你不信任或者干脆是不喜欢这个厂商的技术代表，那么，不管他把他的东西吹得怎么个天花乱坠，还是赶紧让他走吧。