但是开发人员会这样反问:“这样做对我有什么好处?”。开发人员学习使用新的软件,每天都要按时Check out,按时Check in,写烦人的comment,还要被该死的分支,归并,集成搞得头晕脑胀。开发人员付出了大量的劳动,而他们又得到了什么呢?几句空泛的口号?一年甚至几年之后通过CMM 2评估?还是五年之后达到千行代码0.2个错误?但是,这些都与开发人员本身的利益无关,而且又是如此的遥不可及,又怎么能够要求大家一如既然,始终如一的付出呢?即使是最勤奋,最有职业道德的开发人员,如果始终在做一件根本不会给自己带来任何利益的事情,他(她)也会慢慢的厌倦。在这样的情况下面,开发人员不写comment,很少做归并的行为也不是那么令人费解了,因为这是一种希望减轻工作负担的无奈。要知道,开发人员不是生产线上的机械手,设定好程序,就可以始终如一、机械的工作下去。如果忽略了人的主观能动性,要想顺利的执行配置管理过程几乎是不可能的。
那应该怎么做呢?一方面我们应该考虑配置系统能够给组织带来的各种好处,但是另外一个方面,我们绝不能单单只考虑组织的利益,而应该花大量的时间来声明配置管理系统给每一个开发人员带来的好处(自身素质的提高、技能的提高、收入的改善等等),并且真正的让开发人员在日常的工作中体会到配置管理系统带来的好处。只有这样,配置管理才能真正的融合进入每一个人日常的工作中,成为一种习惯。
我觉得还是我的方法好
“为什么你不在你的私有分支上工作啊?我们规定了要在自己的私有分支上工作,然后再归并到集成分支上的。”
“这个部分只有我一个人开发,没有必要再建私有分支了。比起你的方法,我觉得还是我的方法好。”
“但是你这样做是违反了我们的规定。”
“可是那样太麻烦了,直接在集成分支上改又方便又不怕归并的时候出错。我还是觉得我的方法好。”
“可是……”
习惯的力量是可怕的,尤其是旧的习惯被证实是有效的(但不一定是最有效的)。如果我们奢望让大家忘记旧的习惯,养成新的习惯,请不要寄希望于一次的培训,也不要指望项目经理发一封邮件就能够万事大吉了。因为在软件行业中,每一个人都受过良好的教育,拥有发达的头脑,而且对自己的判断坚信不疑!这个时候,我们需要的是说服,用好习惯带来的好处来说服大家改变,并且要让大家亲身体会到这些好处是如此的实在。而且令人沮丧的是,旧有的习惯还会死灰复燃,这给我们的工作带来了不少的麻烦,所以我们需要持续不断的进行监控,一旦发现旧习惯有再次抬头的倾向,必须要再次重申新习惯给我们带来的好处。