应该这样度量软件生产率

    提升软件开发人员的生产率似乎是每家软件组织必备目标,但如何度量开发人员的生产率呢? IEEE给出的标准定义是“the ratio of the output over the input effort that made it,”也就是产出和花在产出的投入之比(标准的废话)。直到今天,如何度量软件规模(也就是产出的量)业界也没有共识,所谓的生产率也自然是乱七八糟的各行其道。
    近年来,业界基本上使用两种度量方式:
1.      用产品规模或过程特性来评估生产率,如,每天完成的代码行或每月完成的功能点。许多人将这种方式称之为传统或“客观”软件生产率度量方式。国内软件组织基本都采用这种方式。
2.      第二种方式则是软件人员自评方式,这个方法国内用的比较少,美国不少软件组织使用这种方式。
    这两种方法各有利弊,都被广泛研究。
其他一些小众方法,如,同行评估,基本没人研究关注。
     第一种方法的好处是易度量,貌似“客观”,我之所以给客观加引号,是因为目前任何规模度量都带有主观性。盖茨对代码行的评价一针见血,“Measuring software productivity by lines of code is like measuring progress on anairplane by how much it weighs. 用代码行度量生产率就像用重量度量制造一架飞机进展情况一样”。所谓“标准功能点方法”也不那么标准,在计算功能点时,主观判断也不可避免。但如果能够和实际场景结合的好,平衡好可比性和复杂性的话,“标准度量”照样能发挥不少作用。

    为了克服第一种方法的问题,不少软件团队选择自我评价生产率,但其致命伤是其可比性极差,没有可比性的生产率,对许多老板说是不可接受的。
    最近读到一篇来自微软的关于软件生产率的度量报告,印象深刻,这份报告有效结合了上面提到的两种方法,通过有创意的数据收集、分析过程,揭示了一些影响软件开发人员效率的真正因子!
 
数据收集
 
    研究针对的对象是微软的81位三个级别的软件工程师(1级、2级、高级),他们平均开发经验8年,大部分时间都在微软。这项研究历时5周,每天下班时,软件工程师花几分钟时间通过邮件提交一份生产率的评价。
    数据收集的核心是下面这张表,左边是工程人员自我评估当天的效率,最低一颗星,最高五颗星。右边可选,工程人员可以说下当天和平时有什么不一样,这些选项非常有意思且接地气:
 工作时间比平时长
 工作时间比平时短
 昨晚睡得好
 昨晚睡的差
 今天出差
 在家工作
 参加了培训
 截止期快到了
 今天干扰比平时多
 今天干扰比平时少
 今天会议时间比平时长
 今天会议时间比平时短
 帮助别人的时间比平时多
 帮助别人的时间比平时少
 今天被指定解决一个问题
 每天都不一样
 上面选项都不适用
 其他
 
 工程人员每天花几分钟总结提交的度量表                          
 
    在分析这些数据时,研究团队从微软内部数据系统中提取出这些人员的一些相关工时数据,如,编程时间,修复缺陷时间,代码评审时间,测试时间,其他开发活动时间等,识别出影响软件工程人员工作效率的关键因子。


建立线性回归模型和结论


    参与过CMMI高成熟度的同学应该都了解一些过程性能模型的建立、维护方法,线性回归模型应该是最常用的方法之一。这里就不详细描述回归模型建立的步骤了,研究团队所建模型的
R
²47%,也就是说模型可以解释将近一半数据偏差的原因,所以是很有意义的。顺便说一嘴,在CMMI四级或五级评估时,凡是看到异常高的模型,一般我都会打个问号。如果仅有两三个因子的模型就能解释超过90%的偏差的话,你的软件项目也太简单了。

 

模型因子的系数表



    上面这张表是模型中因子的系数,不难看出,少干扰、休息好、少开会、加班、时间多花在编程和代码评审上会有助于提升软件开发人员的生产率。不算出差和被指定解决问题,休息差、工作时间短、会议多则是效率的杀手。
 
总结


    有效结合业界两种方法,微软生产率研究团队做了一件很有意义的事。后续调查显示绝大多数参与者都认为自己在这个过程中学习到了一些新东西,对梳理出有效工作模式很有帮助,大部分参与者的生产率都有所提升。
    这个研究对微软完善其开发过程也起到了很好的作用,模型揭示让开发人员把更多时间投入到编程活动会明显提升生产率,微软在多方面改进了环境、过程,支持开发人员可以多投入到编程活动中。
    
    我个人特别赞赏他们这种接地气的研究方式,这是我20年来看到的最低,但最有指导意义的生产率模型,这些日常、可控的因子可以正面影响真正需要的过程改进活动,项目过程活动,这才是CMMI中过程性能模型的价值和意图。他们的做法值得我们借鉴,希望以后能有机会,在CMMI改进中做些类似的工作。

应该这样度量软件生产率》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/133.html