配置管理中人的因素

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

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

  私人交谈，会议，邮件，电话，终于，SPI人员听到了开发人员心里最真实的声音：

  l 这么做对我有什么好处？

  l 我觉得还是我的方法好。

  l 我觉得挺悬。

  这样做对我有什么好处？

  每当提到配置管理系统的好处的时候，下面的句子总会被不厌其烦的用到：

  建立并且管理统一的基线

  避免因为版本不一致带来的混乱

  更好的保存团队的工作成果

  ……

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

 

原文转自：http://www.ltesting.net