薛勇中医 访谈:中国银行软件中心主任工程师 薛勇

       访谈:中国银行软件中心主任工程师 薛勇

软件研发成本度量标准在中国银行的应用取得了较显著效果,但仍有一些问题需要进一步的深入研究与解决。

    ——中国银行软件中心 主任工程师 薛勇

一、项目管理者联盟记者:薛总,您好。最近看到报道,得知软件研发成本度量标准在中国银行软件中心的应用取得了显著效果,上午我们和姚丹总监也了解了咱们这边引入标准的管理背景,也得知这个项目主要是您负责的,那么具体到这个标准应用的项目,您是怎么样推行的?

      薛勇:功能点度量是基于需求功能的软件规模度量方法,是度量生产效率的一个关键点。这项工作由中心EPG组织牵头作为过程改进专题工作,下面有两个主要的部门,一个是总体部,主要负责功能点规模估算;另一个是项目管理部,负责工时登记及生产效率,整体工作以跨部门工作组形式推进,工作组直接向我汇报。

二、项目管理者联盟记者:您怎么想到要做度量这件事呢?

薛勇:首先,大规模软件开发同样需要度量生产效率,那么如何操作呢,涉及到一个规范的问题,比如今年产出是多少,如果只有工作量,缺了规模,效率就没法衡量。第二个是从工作量估算的角度,必须先估算规模,然后参考历史的生产率数据建立基线,最后得出工作量及周期。如果没有数据基础,就没有历史数据供参考,只能拍脑门了。

三、项目管理者联盟记者:您是说度量首先要进行规模估算?那么规模估算咱们之前是采用什么方法呢?

薛勇:是的。规模估算有多种方法,我们原来采用代码行估算规模,但是发现有局限性,这个规模产生于设计或编码结束后,作为事后度量还可以,但在项目早期阶段仅凭一个需求时是不太容易估算出代码行的。所以要找到一个方法,能解决事前估算、事中监控、事后度量的问题。

2007年我们就开始接触功能点方法,但是当时更多地是根据书本上的理论,试图拿一把尺子量所有人,基于项目建立组织基线,最后发现挑战太大了,大家都在质疑估算结果的准确度,其原因有两个方面:

第一,原始模型的变动因素,比如说功能点里面的14个调节因子,看起来像是计算机处于七八十年代早期背景的非功能约束,其理论上最大值对于功能点规模有30%的影响。估算人员可以根据自己的解释,随时对这个刻度进行调整,这就失去了权威性。

第二,当时建组织基线是基于项目的,但从我们的人员、整个组织架构的形式都是基于产品的,项目是动态的,产品团队才是静态的。比如今天是ABC三个产品组合产生的生产效率,明天是DEF产生的生产效率,他们之间没有可比性。另外利用这些数据进行度量管理也存在问题,项目生产率出问题,如何知道是ABC谁的问题?

2010年我们重新引入了标准功能点的方法,这次重点解决了以上两个问题。首先根据各个产品系统情况分别自定义14个调节因子系数并相对固化,因为我们的项目大部分都是在已有的产品上做增强型改造。只有当非功能特性如系统架构发生了重大调整才允许变动,但是变动的数值及变动的频率要严格控制,这样就把30%的波动减少了。

其次,按照整体IT产品系统架构规范确定系统边界,按照产品系统分解功能点,按照产品及项目维度分别建立各自生产率基线,在估算时分别计算并累计总工作量,度量目前确定的方针是产品团队自己和自己比。

四、项目管理者联盟记者:那后来咱们标准功能点方法应用的情况怎么样呢?

薛勇:引入标准功能点方法后,我们也遇到了一些问题。如立项之前的快速估算问题,我们在立项之前会根据需求做概要功能分析,架构设计及概要产品设计形成技术方案,然后估算工作量及周期并计算项目成本供立项审批决策使用。但这个阶段时间比较短,不可能等所有需求分析完成才开始。需求分析是我们立项后的第一个实施阶段,标准功能点在需求分析后形成。

另外,对标准功能点的理解和掌握是否准确,估算及评审人员的相应技术资质如何解决,已有估算数据是否准确。还有一个问题是,即便是那14个标准的调整因子,我们都是坐在“井”里面自己琢磨,同业怎么搞,行业标准、国家标准到底是什么,我们能不能和行业标准对标,这也是我们重点要去解决的。

五、项目管理者联盟记者:那咱们参与行业标准《软件研发成本度量规范》的试点应用,采用这个标准推荐的快速功能点方法,效果如何?您觉得和之前的方法有什么大的区别呢?

薛勇:通过和协会的合作,我们请了协会的专家对中心现行标准进行了评估和改进,对历史评估数据进行了抽样检查,找出存在的问题,补充了适用于立项前的快速功能点估算方法,基于以前标准功能点累计的数据对快速功能点估算的加权因子进行了测定,对人员进行了培训及CCEP技术认证,基本解决了我们遇到的问题,目前正在按照完善后的标准执行。

快速功能点估算的方法在规模估算上分别针对新建和增强型产品作了适当简化,通过基于标准功能点建立的生产率历史数据的套算关系,解决了立项前时间短,需求尚未详细分析情况下的快速估算问题。

在立项后的需求分析阶段,我们仍然采用标准功能点进行估算规模,并以此作为度量的规模数据。每年会分析两者差异,套算简化系数及对应关系。

在生产率度量方面,重点根据同一产品并行任务的稳定性及沿时间轴的变化趋势找出生产工艺及过程改进的问题,提升生产效率。这是我们在大规模软件开发模式上扩展管理半径,进行精细化量化管理的基础。

六、项目管理者联盟记者:做到现在您觉得是您要的吗?

薛勇:现在初步目标是我们想要的,还有一些配套的工作需要进一步完善。例如工时数据的质量问题和分类标准完善问题,特别是分类标准要结合度量场景设置。另外,从管理模式来说,度量在中国的文化背景下去推广还是比较难的,举个例子,别人要来度量我,可能在中国的管理模式下会产生抵触,这就要防止另外一个倾向,大家为度量而度量。

七、项目管理者联盟记者:谈到这个问题,您有什么好的想法吗?怎么防止“为度量而度量”?

薛勇:我觉得有两点。第一,高层管理者特别是企业一把手强有力的支持和推动。第二,建立完善的度量体系,从多角度、多维度进行度量分析,弄虚作假的情况是能识别出来的。

八、项目管理者联盟记者:关于度量,现在您还有待解决的问题吗?或者说需要后边重点攻克的问题?

薛勇:还有两类非功能开发任务需要解决,一类是非功能优化,一类是投产维护中的产品缺陷修正,目前功能点方法尚不能覆盖。我们正着手研究是否可以通过逆向方法倒推功能点规模或采用其他方法,这两类任务总体占比20-30%,目前对于这两类任务单独实施,避免混合在功能项目中影响度量数据。