配置管理中人的因素【转】

luoyear

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

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

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

　　这么做对我有什么好处？

　　我觉得还是我的方法好。

　　我觉得挺悬。

　　这样做对我有什么好处？

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

　　建立并且管理统一的基线

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

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

　　……

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

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

　　我觉得还是我的方法好

　　“为什么你不在你的私有分支上工作啊？我们规定了要在自己的私有分支上工作，然后再归并到集成分支上的。”

　　“这个部分只有我一个人开发，没有必要再建私有分支了。比起你的方法，我觉得还是我的方法好。”

　　“但是你这样做是违反了我们的规定。”

　　“可是那样太麻烦了，直接在集成分支上改又方便又不怕归并的时候出错。我还是觉得我的方法好。”

　　“可是……”

　　习惯的力量是可怕的，尤其是旧的习惯被证实是有效的（但不一定是最有效的）。如果我们奢望让大家忘记旧的习惯，养成新的习惯，请不要寄希望于一次的培训，也不要指望项目经理发一封邮件就能够万事大吉了。因为在
软件行业中，每一个人都受过良好的教育，拥有发达的头脑，而且对自己的判断坚信不疑！这个时候，我们需要的是说服，用好习惯带来的好处来说服大家改变，并且要让大家亲身体会到这些好处是如此的实在。而且令人沮丧的
是，旧有的习惯还会死灰复燃，这给我们的工作带来了不少的麻烦，所以我们需要持续不断的进行监控，一旦发现旧习惯有再次抬头的倾向，必须要再次重申新习惯给我们带来的好处。

　　我觉得挺悬。

　　心理学家经过研究得出结论：当人们对于做一件事情的结果不抱希望或者结果不可能达到的时候，往往会选择敷衍、拖延，甚至逃避这件事情。

　　每当我们谈到SPI的时候，我们的目标往往是：“三年以后，我们对软件开发进度的预计将达到95％的正确性”，“五年以后，我们将要达到千行代码0.2个错误”。每每听到这样的宏伟目标，我觉得挺悬！一个需要
三年，五年才能达到的目标能让大家抱多大的希望呢？尤其是在IT这样一个流动频繁的行业中――等到目标达成的时候，我都不知身在何方了？

　　同样的情况也出现在配置管理的工作中，我们往往急于树立一个远大目标，比如“在软件的整个生命周期中，建立并且维护软件产品完整性”。这样的目标很宏伟，但即使是一个专业的软件工程人员也很难用一句话来把它解
释清楚，那它对于一个开发人员意味着什么呢？也许什么意义也没有，只是一个口号而已。我们有能力仅仅靠一个空泛的口号就能让大家奋力向前吗？不能！我们需要用无数个短期、可行的目标来构筑这个宏伟的远大目标。

　　“用半个月时间，培训所有的员工，让大家掌握配置软件的基本操作”。

　　“用一个星期时间，分配所有的角色，并且让大家明确每个角色的职责”。

　　“一个月后，所有的软件成果都应该纳入配置管理系统的管理中”。

　　“三个月后，CCB正式成立，所有对配置项的修改必需经过修改控制流程”。

　　……………………

　　……………………

　　正是这些短期，可达的目标让我们体会到了我们正在进步，我们的努力是有成效的，更加重要的是，开发人员的付出换回了成果，积极性得到了保护。激情的火焰能够烧掉征途上所有的荆棘！ 人不同于机器，因此在软件过
程改进的过程中，除了技术（Technology）、管理（Management），还有人（People）的因素。只有三者兼顾（P.M.T.），才能取得我们梦寐以求的美好结局。

luoyear

万事都以结果为导向
本文最后几点总结的很好
正是这些阶段的 看的见的目标
指引着我们的工作一步一步推向前进。

QA工作的意义也一样
我们每天都在检查
我们每天都在沟通协调纠偏
我们对项目产生了哪些实实在在的帮助呢？
产品的质量取得了怎么样的改善了呢？

ISO、CMM、TQM，诸多的体系
我们都有了
我们实现了跨越式的认证通过
我们经营业绩取得了怎么样的改善？
我们的商誉是否提高了？
我们是不是在成本、进度、质量三角环上达到了一个较为完美的进步？

luoyear

我们制度化的目的
1）人们按照规范做，比较容易达到好的效果
2）不按照规范做，大部分时间是比较糟糕的结果
3）提高其应付性对付规范的成本

luoyear

Originally posted by 海的女儿 at 2004-6-28 09:24 AM:
呵呵，没有规章制度就很难打破旧的局面。还好哦，我们公司已经决定要过CMMI了，有了它的约束，工作应该会好做许多哦，当然咯，也会很忙，很具挑战性

很好的学习机会

luoyear

请新建一个帖子!