听程序员谈配置管理中人的因素(1)

经过需求分析、环境评估、定制、安装后，配置管理系统终于完成实施工作了。一个多月的辛苦总算没有白费，在开发人员的培训会上，气氛活跃、反映热烈，大家都认为配置管理系统会对今后软件开发提供巨大的帮助，彻底的解决由软件版本不匹配带来的问题。培训会议上，大家达成一致意见，今后所有的文档，代码，数据都要使用配置管理软件进行管理。SPI（软件流程改进）人员们也觉得很满足，这一次的工作竟然是出乎意料的顺利，也许要把SPI工作的进度稍微加快一些才好。

一天过去了，两天过去了，一周过去了，一个月过去了。怎么回事？配置管理系统好像不是很对劲啊――配置项明显偏少，有些配置项Check out的时间竟然超过两个星期，而有的配置项一天竟然被修改了三十多次，而且经常发生旧版本覆盖新版本的情况。不会吧？不可能吧？这些问题不应该出现的，我们的配置管理模型是很完善的啊？流程也都考虑了所有的分支情况，角色也都分配了啊，而且也进行了所有人员的培训，不应该出现这些问题啊。太奇怪了。SPI人员觉得有点不能理解，到底发生了什么事情了？

私人交谈，会议，邮件，电话，终于，SPI人员听到了开发人员心里最真实的声音：
这么做对我有什么好处？
我觉得还是我的方法好。
我觉得挺悬。
这样做对我有什么好处？
每当提到配置管理系统的好处的时候，下面的句子总会被不厌其烦的用到：
建立并且管理统一的基线
避免因为版本不一致带来的混乱
更好的保存团队的工作成果
……

但是开发人员会这样反问：“这样做对我有什么好处？”。开发人员学习使用新的软件，每天都要按时Check out，按时Check in，写烦人的comment，还要被该死的分支，归并，集成搞得头晕脑胀。开发人员付出了大量的劳动，而他们又得到了什么呢？几句空泛的口号？一年甚至几年之后通过CMM 2评估？还是五年之后达到千行代码0.2个错误？但是，这些都与开发人员本身的利益无关，而且又是如此的遥不可及，又怎么能够要求大家一如既然，始终如一的付出呢？即使是最勤奋，最有职业道德的开发人员，如果始终在做一件根本不会给自己带来任何利益的事情，他（她）也会慢慢的厌倦。在这样的情况下面，开发人员不写comment，很少做归并的行为也不是那么令人费解了，因为这是一种希望减轻工作负担的无奈。要知道，开发人员不是生产线上的机械手，设定好程序，就可以始终如一、机械的工作下去。如果忽略了人的主观能动性，要想顺利的执行配置管理过程几乎是不可能的。

那应该怎么做呢？一方面我们应该考虑配置系统能够给组织带来的各种好处，但是另外一个方面，我们绝不能单单只考虑组织的利益，而应该花大量的时间来声明配置管理系统给每一个开发人员带来的好处（自身素质的提高、技能的提高、收入的改善等等），并且真正的让开发人员在日常的工作中体会到配置管理系统带来的好处。只有这样，配置管理才能真正的融合进入每一个人日常的工作中，成为一种习惯。