• 2010-01-30

    度量随想

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/57388446.html

    这是一个以代码行衡量工作量的团队,写得多就是干得好。老板们还时不时会蹦出来说,你看看人家团队写了XX万的代码,用了XX的资源,你们的效率还得提升啊!

    生长在这样的环境下,实现一个功能时,我们发现,这个功能只要从一个已有函数借鉴过来一些东西就能完成。我们会停下来先做个重构,把公共部分提取出来吗?别干傻事了,最后的结果肯定是有人过来批评我们,为啥写的代码比别人少。所以,为了不影响绩效,我们就把这段代码复制过来,然后,修改一两点,整个世界清净了。接下来的故事,每个熟悉软件开发的人都能够想象得到。

    一些软件开发团队,尤其是所谓大公司的团队,对度量情有独钟,更有甚者,成立了专门的团队,独立于项目专门做度量。于是,在我们每天为了交付忙碌的时候,总会有人时不时出现在我们面前,你看,你们团队的这个指标不合格,那个指标也危险了,对了,上次你提交的报告封面标题不符合规范,要改一下。已经被交付弄得焦头烂额的我们会怎么想?我们的开发都忙活不完,谁有心情理标题是不是符合规范呢?

    如同度量在其它领域一样,度量给了我们一条基线,防止我们在开发过程中由于疏忽造成的不良后果。不过,软件开发的许多度量指标并不是那么成熟。即便如大家广为接受的代码行,都会产生像前面那样的效果。

    之所以会起到这样副作用,很多团队把度量当作了目的,而把写好软件抛在了脑后。

    在很多公司里,度量总要和绩效挂钩,甚至要进行排名。在利益驱动下,团队被引导到以提升度量指标为目的,加之很多度量指标——如代码行——的错误引导,整个团队就像大踏步走向了一条错误的道路。

    还有些团队认为只要度量指标达标了,工作就做好了。所以,在一个以圈复杂度衡量代码好坏的团队,有成员会硬生生把一个函数拆成两个,从而通过圈复杂度的校验。他们根本不知道为什么要有这样的指标,对他们而言,要做的就是通过度量。

    关于度量,另外一个故事是,一个度量指标叫千行代码缺陷数,有一个转型中的团队,他们用了更少的代码完成功能,虽然缺陷也少了,但是,按照这个指标来说,他们却高于其它团队,因为他们的代码少了,这让他们在公司内部评比中成了落后分子。显然,虽然团队在进步,但度量却没有与时俱进。

    其实,度量本身没有错,它原本应该更好的鼓励团队工作,帮助团队发现问题。

    只是,很多情况下,我们用错了。

    分享到:

    历史上的今天:

    引用地址:

    评论

  • 想必你说的应该是国内某知名通信企业吧。
    我现在就在这样的一个团队里,口号是我们要敏捷,要时间培训,没有,聘请申请W的T敏捷咨询师,怕花钱,老大们永远是对他的老大负责,表面功夫很组。
    关注你的博客很久了,借此宝地发发牢骚
    回复Nicholas ren说:
    真正的改变不是那么容易,即便那些决定改变的企业,其中的很多人也没有意识到改变到底意味着什么。
    2010-07-12 10:53:51
  • 是啊,现实就是有人还固执的生活在远古时代,并且弄得现代人好像是异类。
  • 尤其是所谓大公司的团队,对度量情有独钟,更有甚者,成立了专门的团队,独立于项目专门做度量。-------- 不增值,就会瞎指挥。指点江山的感觉,估计很好。
  • 我觉得有的时候所谓的deadline也是一样的东西