一天过去了，两天过去了，一周过去了，一个月过去了。怎么回事？配置管理系统好像不是很对劲啊――配置项明显偏少，有些配置项Check out的时间竟然超过两个星期，而有的配置项一天竟然被修改了三十多次，而且经常发生旧版本覆盖新版本的情况。不会吧？不可能吧？这些问题不应该出现的，我们的配置管理模型是很完善的啊？流程也都考虑了所有的分支情况，角色也都分配了啊，而且也进行了所有人员的培训，不应该出现这些问题啊。太奇怪了。SPI人员觉得有点不能理解，到底发生了什么事情了？
私人交谈，会议，邮件，电话，终于，SPI人员听到了开发人员心里最真实的声音：
l 这么做对我有什么好处？
l 我觉得还是我的方法好。
l 我觉得挺悬。
这样做对我有什么好处？
每当提到配置管理系统的好处的时候，下面的句子总会被不厌其烦的用到：
建立并且管理统一的基线
避免因为版本不一致带来的混乱
更好的保存团队的工作成果
……
但是开发人员会这样反问：“这样做对我有什么好处？”。开发人员学习使用新的软件，每天都要按时Check out，按时Check in，写烦人的comment，还要被该死的分支，归并，集成搞得头晕脑胀。开发人员付出了大量的劳动，而他们又得到了什么呢？几句空泛的口号？一年甚至几年之后通过CMM 2评估？还是五年之后达到千行代码0.2个错误？但是，这些都与开发人员本身的利益无关，而且又是如此的遥不可及，又怎么能够要求大家一如既然，始终如一的付出呢？即使是最勤奋，最有职业道德的开发人员，如果始终在做一件根本不会给自己带来任何利益的事情，他（她）也会慢慢的厌倦。在这样的情况下面，开发人员不写comment，很少做归并的行为也不是那么令人费解了，因为这是一种希望减轻工作负担的无奈。要知道，开发人员不是生产线上的机械手，设定好程序，就可以始终如一、机械的工作下去。如果忽略了人的主观能动性，要想顺利的执行配置管理过程几乎是不可能的。
文章来源于领测软件测试网 https://www.ltesting.net/