实施软件配置管理的误区
软件配置管理是一种有效的管理手段。对于一个软件组织，软件配置管理做还是不做，做得好还是做得差，区别是很明显的。没有很好的实施配置管理的软件组织，经常会发生软件开发中的很多常见问题，比如修改好的BUG重新出现、更新的代码被他人覆盖甚至丢失、各人开发的程序难以集成等等。另一方面，软件配置管理是软件工程中发展得比较成熟的一个学科，有着理论和工具的有力支持，用户的选择也比较多。也许正因为软件配置管理易实施，见效快，因此，软件组织进行流程改进也好，加强管理也好，软件配置管理常常是第一个切入点。
然而，在实际的工作中，由于对软件配置管理的认识有偏差，或者应用时流于形式、不着重点，实施软件配置管理很容易走向误区。概括起来，主要有以下五点。
一、片面理解软件配置管理
常常有人把配置管理和版本管理等同起来，在这种理解的指导下实施的配置管理，就象缺少零部件的机器，很难如同期望的那样运转起来。
经常可以看到这样的情形：架设好某个版本控制的工具，比如CVS，然后让每个程序员把自己的代码导入到它的仓库里，然后规定以后做任何修改都要先检出，改好了再检入，然后就对外宣布，“我们实施软件配置管理了。”
这样的做法简直让人啼笑皆非。版本控制只是配置管理的一部分，如果没有其他配置管理活动的支持，比如变更管理和工作空间的管理，那版本控制的结果可能只是得到一堆没有实际意义的“版本”。即使仅仅是版本控制，如果没有对配置项进行很好的标识，如果没有建立正常的检入/检出（check in/out）机制，如果没有对基线进行统一的管理，那么这样得到的版本很可能连构建（build）都无法通过，要这样的版本又有何用呢？
二、追求大而全的软件配置管理
这是走向了另一个极端。很多负责配置管理实施的人员都是技术人员出身，出于对技术的热爱，他们希望把软件配置管理学习、理解得很透彻，然后同样出于对技术的热情，希望能把所有在技术上很“诱人”的东西都实践起来。这样的热情是好事，也是坏事。最直接的不良后果就是为技术而技术、为流程而流程，而忽略了真正要追求的“结果”。
导致“大而全”的另一个常见原因是简单拷贝标准或者他人的实施计划。互联网上有大量的软件配置管理的资料，不用花多少时间就可以搜索到一大堆的配置管理的标准和各种模版。如果不加思考，不根据自己的实际情况就照搬这些现成的东西，那恐怕很难取得实效。
软件配置管理是一项消耗资源的活动，实施者需要量力而行。
三、缺少配置管理员
很多开发团队都没有配置管理员这个角色。即使有，也往往是随便找一个别处无法安排的“闲人”来充当。这种做法是很有问题的。
配置管理员是一个很重要的角色，因为整个开发团队的工作成果都在他的掌管之下。如果他负责管理和维护的配置管理系统出现问题的话，轻则影响团队其他成员的工作效率，重则可能出现丢失工作成果、发布错误版本等严重的后果。
在小型的团队里，配置管理员可以由某人，比如项目经理兼任。但通常，还是需要专职的配置管理员。
四、过分依赖于工具的支持
工具在软件配置管理中起着不可替代的作用。没有工具的支持，实施软件配置管理是不现实的。也许也正因为工具的重要，造成了一些人对工具的迷信，以为只要购买和部署了配置管理工具，一些都可以自动的实现。
归根到底，工具也是需要人去使用的，驱动软件配置管理的是人，而非工具。就拿最简单的检入/检出来说，工具提供了这项功能，工具也可以要求程序员在检入/检出时必须书写备注；但如此就能保证实现良好的检入/检出了吗？ 程序员完全可以输入毫无意义的备注来逃避工具的检查。对于这种情况，更好的解决方法是和程序员进行充分的沟通，晓以利害，让他们认识到这样做对他们有什么好处。
工具只是提供了一种“可能”，要把这种“可能”转化为现实，就需要人的积极参与。
五、缺乏后继活动和持续改进
配置管理不是一次性的实施活动，需要经常性的检查实施的效果。如同其他的流程改进活动一样，配置管理在实施之后，也需要重新检视是否合乎新的情况，需要持续的改进。
另一个常见的问题是缺少对新成员的培训。软件开发的人员流动比较大，新成员的加入是经常性的。如果他们对团队的配置管理策略不熟悉，或者不会使用配置管理工具，这些都将影响他们的工作效率和情绪。
以上列举的是实施软件配置管理的一些常见误区。当然这些只是“冰山的一角”，在现实工作中，我们常常可以看到更多的各种各样的错误。事实上，即使你了解了这些错误，你仍可能重复这些错误。为什么会这样呢？一个很重要的原因就是“术业有专攻”。软件组织的专长是开发软件，而不是实施软件工程。一些软件项目的团队，或者因为经费问题，或者因为以为配置管理很容易，或者因为很自信，会选择自己研究自己实施。诚然，这种方式是一种选择，特别是在初期，作为一种尝试性的摸索和应用也是很合适的。但是，如果要系统化的实施配置管理，绝大多数项目组还是不具备足够的能力和经验。这时候，来自项目组外部的帮助就很必要。对于一个成熟的组织，项目组也许可以在组织内部寻求到帮助，如果没有，就需要考虑来自组织外部的帮助。