无法衡量的软件开发生产效率

标签: 衡量 软件开发 生产 | 发表时间:2013-09-09 14:01 | 作者:
出处:http://www.iteye.com
2003年8月29日,软件行业大牛Martin Fowler写过 《无法衡量生产效率》。10年后,Martin 在其网站首页以《十年后仍无法衡量生产效率》标题再次推荐了这篇文章,并附言:

引用
软件行业的巨大挫败之一,是我们没有合理建立研究,去思考诸如面向对象编程和测试驱动开发之类的开发工具和技术、还有其他更高级的语言是否对我们有益。我们经常看到不当的研究,并且常常很糟糕,是因为它们是基于一个错误的衡量方法(比如员工每天所编写代码的行数)。十年前的今天,我的挫败感促使我写了《无法衡量生产效率》一文。我认为该文在今天看起来,和十年前没什么不同。


原文内容如下:

我们见到过太多关于软件开发过程、设计实践以及类似内容充满激情的讨论。它们当中有很多是无法验证的,因为软件行业没有能去衡量代表开发效率的一些基本元素。特别是我们无法合理地衡量生产效率。

当然,生产效率可以通过观察生产过程的输入与产出来衡量。所以,要衡量软件开发的生产效率,你就必须去衡量软件开发的产出。我们无法衡量生产效率的根源就在于我们无法衡量产出。

并不是说人们没有尝试过。最令我气愤的就是那些用代码行数来衡量生产效率的研究。首先,总是存在不同的语言、不同的计数方式、不同的格式化风格造成的问题。即使采用一致的计数标准,衡量相同语言代码,且代码被自动格式化为统一的风格,代码行数仍然无法正确反映产出。

任何优秀的开发者都知道,让他们去实现一个特定功能所需的代码行数可能相差巨大。除此之外,精心设计以及重构过的代码都会更短小,因为它消除了冗余。复制粘贴风格的程序会有更多的行数以及更差的设计,因为它充满冗余。这很好证明,只要你使用一个支持inline method的重构工具去修改一个程序。只需用这个工具去重构那些普通函数,你就可以轻易让代码行数翻倍。

你可能觉得已经没人再用代码行数了,实际上每个月我都能看到基于代码行数的生产效率研究论文,甚至是在类似IEEE Software这样令人尊敬的期刊上。

也不是说代码行数是个完全没用的衡量,它能很好代表系统规模。我可以很确定一个100 KLOC(KLOC=千代码行)的系统比一个10KLOC的系统要大。但是如果我用了一年时间写了那个100KLOC的系统,而Joe在一年内用10KLOC实现了同样的系统,这无法说明我更高产。实际上我得到的结论是:我们的生产效率差不多,但我的系统设计得更差。

另一个经常被用来衡量产出的方法是使用功能点(Function Points)。虽然我更同情这种做法,但它并不能令我信服。我听过很多这样的故事:同一个系统,不同人统计的功能点数目相差有3倍之多。

即使我们能够找到一种方式用功能点精确衡量功能,我认为这仍然无助于解决生产效率的衡量问题。可以这么说,衡量功能点是观察软件开发直接产出的方式,但真实产出确是另一回事。假设有一个精确的功能点计算系统,如果我花一年发布了一个有100个FP(功能点)的系统,同时Joe也用一年发布了一个50FP的系统,是不是就能说我更高产?我觉得不是。很可能我做的100FP中只有30个对我的客户来说是真正有用的功能,而Joe开发的功能则全部都是有用的。我会这么说:虽然我的直接生产效率更高,但Joe的真实生产效率更高。

Jeff Grigg向我指出,还存在影响功能点交付的内因。我的100个功能点可能提供的都是很相似的功能,我之所以花了一年时间,是因为我没有很好的重用代码。Joe的50个功能都是差别相当大的(对他来说可不是个好消息),所以几乎没有重用的可能。尽管需要实现50个相当不同的功能,并且几乎无法重用代码,但Joe真的很棒,他在一年之内就全部完成了。

但这些都忽视了一点:即使是有用的功能也无法真正用来做衡量。假设我有了进步,完成了30个有用的功能点,同时Joe只完成了15个。但有人会发现Joe的15个功能点为我们的客户增加了1千万的盈利,但我的工作成果带来的盈利只有500万。我仍然认为Joe的真实生产效率要比我高,因为他产出了更多的商业价值。并且我坚信任何真正的软件生产效率衡量必须基于其所带来的商业价值。

这种思想也适用于成功率。通常关于软件项目成功的判断都是虚假的,因为人们并不理解什么是失败。我可以说一个成功的项目就是产生的商业价值大于研发成本的项目。假如Joe和我各参与了5个项目,我的4个项目是成功的,而Joe只有一个项目成功。这是不是就意味着我干的比Joe好呢?这可不一定。如果我的4个项目每个盈利1百万,而Joe那个成功项目的收入比他所有的5个项目成本的总和还要多出1千万,那么他才是那个应当获得提拔的人。

有些人会说“如果无法衡量,就无法管理”,这是站不住脚的。商业领域中,人们一直在管理着那些他们无法衡量价值的东西。你如何衡量一个公司里律师的生产效率?如何衡量市场部门、教育机构?你无法衡量,但你任然需要去管理它们(更多信息参考Robert Austin)。

如果团队的生产效率都很难衡量,那么个人对团队的贡献就更难衡量了。通过观察每个迭代产出特性的多少,你可以对团队的产出有个大致的概念。这是个很粗糙的感受,但是你可以感觉出团队的速率是否有所提高,或者大致感觉出两个团队的生产效率哪个更高一些。但是个人的贡献值就很难计算了。可能有的成员职责是实现特性,而有些成员的角色可能是协助者——他们负责帮助他人实现特性。他们的作用是提升整个团队的生产效率——除非你是这个团队中的一个开发者,你将很难搞清楚这些人的产出到底是什么。

如果你觉得这些情况还不够复杂,在《经济学人》(sep 13-19,2003)上有一篇关于生产效率趋势的文章。经济学家们似乎发现,由于90年代中对计算机产业的投资导致了如今商业领域中生产效率的提升。

这其中的重点是——增长是落后于投资的:“对计算机方面的投资并不会自动地推动生产效率提升,公司同时也需要重组他们的商业实践”。同样的滞后效应也出现在电力发明之后。

所以商业价值不仅难于衡量,还存在时延。很可能直到团队构建的软件发布多年之后,你才能够衡量团队的生产效率。

我可以理解为什么衡量生产效率如此具有诱惑性。如果可以做到,我们就可以更容易、更客观地评估软件。然而错误的衡量方式只会使问题恶化。我觉得必须承认:在这一领域,我们任然很无知。

英文原文: Martin Fowler  / 译文: 伯乐在线

感谢 WnouM 投递这篇资讯

资讯来源: 伯乐在线

已有 1 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [衡量 软件开发 生产] 推荐:

无法衡量的软件开发生产效率

- - ITeye资讯频道
2003年8月29日,软件行业大牛Martin Fowler写过 《无法衡量生产效率》. 10年后,Martin 在其网站首页以《十年后仍无法衡量生产效率》标题再次推荐了这篇文章,并附言:. 软件行业的巨大挫败之一,是我们没有合理建立研究,去思考诸如面向对象编程和测试驱动开发之类的开发工具和技术、还有其他更高级的语言是否对我们有益.

程序员的工作不能用“生产效率”这个词来衡量

- - 外刊IT评论
通过反复的交谈, Bill Caputo最终说服了我,让我相信了一些不可思议的事情. 这些事情改变了我整个看问题的方式,也让我重新思考如何更好的工作. 几乎正如10年前 Martin Fowler 发现的,用生产效率来衡量软件开发工作没有任何意义. 原因就在于,它们不属于同一范畴. 换句话说,生产效率不具有作为衡量软件开发工作的适用性.

软件开发的核心

- - 博客园_知识库
  「我们一直这样做开发,时间做久了,便忘了当初的本意.   有关软件系统开发,我们谈些什么.   我们谈过程,编码规范、开发流程、同行评审、结对编程、持续集成,从瀑布到敏捷再到极限编程.   我们谈架构,企业级、J2EE、容器化、SOA(面向服务架构)、Microservices(微服务化).   我们谈规模,大容量、高并发、大数据.

软件开发的“三重门”

- - 酷壳 - CoolShell.cn
自从上次写了“ 程序员技术练级攻略” 以来,就觉得似乎还有很多东西没有谈到,但当时没有继续思考了. 而春节前有人问我,是做底层技术,还是做业务. 这问题让我思考了很多,不由自主地回顾了一 下我这十多年的软件开发经历,并顺着整理分类了一下自己解决过的若干问题,还发散想了很多,经过了一个春节假期的发酵,产生了下面这篇文章.

软件开发的人文关怀

- - 博客园_知识库
  几年前,我从温伯格的《技术领导之路》中学到一点:技术人员往往更喜欢和机器打交道,因为他们“认为”自己更适合和机器打交道;但是,优秀的技术人员必须(也必然)具备好的沟通能力. 所以,温伯格鼓励各位技术人员多加练习和其他人打交道的能力. 温伯格的这个观点我是非常赞成的,好的技术人员一定需要“勇敢”面对他人,不能被“自实现的预言”局限在机器的世界里.

软件吞噬软件开发

- - PingWest中文网
软件蚕食世界,自互联网特别是移动互联网连接线上线下服务后,已成为不可逆的趋势. 每一项实用的服务可以由小团队来完成. 以WhatsApp为例,这款被高调收购的IM应用,拥有4.5亿月活跃用户,70%的日活跃率,至今还保持每天新增用户1000万的速度. 但这些服务居然由32名工程师支撑下来了,所以有了业界八卦“每位员工价值20亿”的说法.

软件开发中的两种态度

- - 外刊IT评论网
一种态度认为,应该对程序员在软件开发中的行为进行约束( DirectingAttitude). 持这种态度的人认为大部分的程序员水平都不高(谣传说有50%的人低于平均水平),所以应该对他们所做的事情进行管教约束. 要防止他们做一些可能会给他们正在开发的系统带来危害的事情. 通常,这种态度体现在一些系统设计和工具中时,你会发现它们会试图阻止程序员去做某些事情,限制程序员的一些做法,以此避免他们陷入过于复杂的境况.

软件开发的人文关怀

- - 极客公园-GeekPark
我是极客公园黑板报认证值日生. [核心提示]软件可以没有活力,而软件开发却不能没有活力;程序可以像机器一样,程序员却不能像机器一样. 要改变这种状态,就应当增添更多的人文关怀,把开发人员当成活生生的人,而不是视为程序或者工具. 编辑注记:本文来自余晟的博客 乱象,印记. 作者从自己的经验出发,提出了一些给软件开发人员提供人文关怀的可行措施.

软件开发模型综述

- - CSDN博客推荐文章
                     软件开发模型概述. 最早出现的软件开发模型是1970年W·Royce提出的瀑布模型. 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架. 软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段.

防火长城内的软件开发

- - Solidot
对于软件开发者来说,防火长城不只是屏蔽网站过滤流量这么简单——它是痛苦之源,尤其是如果你想开发针对中国市场之外的软件或想利用广泛使用的服务和软件库的话. 上海聊天机器人创业公司Rikai Labs的创始人DC Collier认为,中国的软件开发者写代码的时候一只手是绑在背后的. 防火长城的屏蔽范围日益扩大,这意味着越来越多的服务被永久性或不定期的屏蔽.