中小软件公司中，配置管理员的发展之路

谨以此文献给在中小规模的软件公司中，希望向配置管理方向发展的朋友。

用几个小故事，展现配置管理在软件公司中的发展过程，同时，也是配置管理员在公司中的发展之路。为了展现主线，故事都比较概括，且本文侧重于配置管理的发展，所以很多与配置管理相关的具体工作都被省略掉了。

故事一：配置管理出现

H公司是一家成立不久的小公司，主要业务是开发客户定制的软件。项目A是该公司承接的第一个规模超过10个人的项目。项目进行到测试阶段时，项目经理发现项目组中经常出现已修改的bug重现，应该提交的代码没有提交，或者提交的版本有误等问题，白白耽误了很多时间，项目经理为此非常苦恼，在经过多方求医之后，最终认定是配置管理方面的问题。

项目经理再经过与高层领导商讨之后，为项目组增加了一名配置管理员。配置管理员到项目组之后，规范了配置管理工具的使用、工作成果的提交及发布机制，虽然增加了部分工作量，但有效解决了项目组的问题，且解决问题之后节省的时间大大超过了增加的工作量。

故事二：配置管理发展

鉴于项目A在没有配置管理员之前出现的种种问题及有了配置管理员之后的效果，在接下来的项目B中，项目经理从项目开始时就争取到了配置管理员的名额，并希望可以从根源上解决项目A中出现的问题。配置管理员到位之后，与项目组成员一起，优化了在项目A中使用过的流程，使之更贴合项目B的实际情况，并制定了需求、设计等工作产品的配置管理规范。有效防止了项目A中出现的问题的重现。

故事三：异地开发的配置管理

项目B结束之后没多久，项目C就开始了，因为客户要求驻场开发，但是又没有足够的空间容纳所有的项目组成员，所以与客户商定之后，决定一部分功能在公司开发。因此，配置管理员与项目组一起制定了配置库交互方法：每天通过邮件互相发送配置库的新增内容。过程中也有人提议用VPN的方式，但是因为公司中使用VPN访问配置库的速度太慢，所以不得不放弃。过程中采用的配置管理规范与项目B类似，唯一不同的就是每天两边配置库的合并。

故事四：多分支项目配置管理

随着公司业务的开展，公司做了越来越多的类似的项目，这时，公司领导发现，如果能把这些项目中共通的东西拿出来做成平台，那效率一定会提高很多，所以成立了平台项目组。现在公司的所有项目都有配置管理员，很自然地，平台项目也拥有了自己的配置管理员。鉴于平台组要为很多项目提供开发平台，且采用迭代方式开发，功能在不断完善，且每个迭代都会有新的版本发布，所以配置管理员重点进行了分支和发布方面的管理。

故事五：组织级配置管理

虽然绝大多数的可以重用的技术都纳入到平台中，但是项目的一些文档性的东西以及项目组特有的没办法纳入平台组的技术还是时有流失，为了保住这部分资产，公司决定建立组织级配置库，并期望该配置库解决上面所说的问题。但是组织级配置库中的内容量多，而且很杂，完全脱离了配置管理的范畴，进入了档案管理的范畴，所以公司现有的配置管理员都一筹莫展，希望公司可以招聘精于档案管理的人员进行管理。

故事发展到这里，在中小软件公司中，配置管理的发展基本上就到顶了，剩下的工作是怎样优化各类项目中的配置管理及组织级配置管理，以充分发挥配置管理的作用。