前几天参加了微论坛配置管理的话题,我深感到虽然大家对配置管理理论基本都有共识,但在具体实施上面很难操作。这可能因为各个公司的情况不一样,具体实施并不是想象的那样容易。我们公司配置管理过程域是规范修订和实施最艰难的一个过程域,期间进行了3次大的改动,最后才确定下来,现在与大家分享一下。不是觉得我们公司配置管理做得好,因为好的公司我们也知道我们跟他们差距很大,目前我们还要持续改进,我们已有的经验只是希望给大家提供一个操作借鉴,让与我们类似的公司少走弯路。毕竟我们能够在满足
CMMI3级的要求下真的做了这个过程域。
配置管理在我们公司最早的时候几乎没有的,是项目经理自己控制的。各个负责人特点不同管理就不同,也经常出现发出去的版本不知道是不是正确的情况。EPG在讨论这个过程域建立的时候,基本无法达成一致,每个人的观点太不相同。epg后来决定让一个epg专职成员先写一个规范出来看看再说。那个成员下来查了些资料,根据配置管理的标准要求做了一个规范,当时大家看了,因为写的比较规范,所以文档找不出问题来,但是负责人那边就是不愿意执行,说没有办法执行,因为成本花费太大,做好了是不错,但是没有时间做。后面老板觉得这个流程就是照抄搬一个标准模式,根本没有考虑公司内部的情况。因为当时我们的项目经理都是有部分核心研发工作的,项目组成员工作基本都是满负荷,无法找专人承担满足配置管理的要求。根据我们当时改进的要求,项目上第一是要管理好生产质量,然后是进度和范围。所以配置管理规范建立的前提就是不能增加项目上过多的成本。鉴于当时我们epg会一次能从下午2、3点开到晚上9、10点,所以对以上认识有异议的同业希望不要提醒我了,因为肯定会有不同意见,我们epg组织就是这么过来的。我认为实施一个重要特点是,不是规范有没有道理,而是在现场能不能行得通,不管是真行不通,还是故意有人跟规范行不通。不是让所有人都赞同,而是让所有实施的负责人都没有话说,能照着做。
这样配置管理过程域我们就划为了2部分,就是组织部分和项目部分。项目部分就是日常的构建,一般性的迁入迁出要求和版本管理要求,与当时项目的做法差异不大。组织部分就是组织基线库,我们的规范主要就是组织基线库这部分,基线库里面只存放独立项目的产品(基线和固化版本),即建立公司的产品成果库。当时
咨询老师还是对我们的策略非常赞同,虽然很简化,但是过程域基本都能要求都满足,主要是方便操作。我们就找了一个公司的老开发人员又不是核心主力的,平时工作比较清闲 一点的,兼职组织配置管理员。后面在实施过程中发现很多问题,主要是流程的细节设计,比如表单样式和记录方式等非常不方便,项目和配置管理员都觉得不是很方便,实施半年后又进行了一次大的调整,主要是调整模板和表单以及一些小的沟通环节流程定义。这样又运行了近一年。
随着我们的需求过程域和发布结项过程域的实施和逐步改进,配置过程域原来在变更追溯上的设计不能满足整条范围控制线的要求,我们又对其进行了一次大的调整,基本是把规范重新写了一遍,不过主要的思路还是第二次的思路,把受控项的变更控制得更好。要求所有的变更从发起到估算计划到文档变化到代码实现到发布包都要能够追溯,也包括在组织基线库里的追溯。然后由QA兼职CM,这样对入基线条件能够更好把关,虽然这个项目上也是实施人员有人抵触,觉得填入库单太麻烦,但因为这时我们过程组的威信已经比较大了,而且项目经理也支持这样做--配置审计他们要参与,因为所以反对无效。
另,自动化入基线是非常好的,可以节省很多成本,虽然几年前我们就想做,但因为种种原因还是没有做。领导不愿意强制安排有一个原因就是当初被安排的人没有做出来后面都离职了,虽然离职都不是因为自动化入基线。有点迷信的。