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

资讯频道 → 研发管理

4顶
0踩

2013-09-09 14:01 by 副主编 WnouM 评论(6) 有7415人浏览

编程生产效率工作

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 / 译文：伯乐在线

来自: 伯乐在线

分享到：

4
顶

0
踩

评论共 6 条请登录后发表评论

6 楼 lixin3811 2013-09-16 11:17

@dohkoos，完全同意“前提条件很重要”--这个太重要

5 楼 dohkoos 2013-09-14 11:31

@lixin3811 做对比的是否都有能力实现同样的功能？做对比的是团队还是个人？如果是个人的话（我想应该是个人，因为这里没有说团队的效率），实现同样功能的代码量很难会达到数量级的差距。

最好能提供原始的调查报告。因为这类调查报告通常是采用抽样对比统计方法得出的，某些前提条件就很重要。

4 楼 lixin3811 2013-09-12 15:49

to dohkoos：程序员的生产效率差距可以达到100倍，是通过实现相同的功能研究的；比值中有知识积累的效能；所以这里的生产效率是狭义的。
to edhn：我感觉Martin之所以列出商业盈利或者商业价值作为衡量指标，是受到了精益开发(Lean)的影响，把生产效率的考量定位到团队的基于精益思想进行的项目，通过最终结果来衡量广义的生产效率或者生产力。这种方法跟管理者们所需的(衡量工期的)指标相去甚远。个人认为：能够细化到工作量评估在2-3人天以内的FP粒度是可以作为工期衡量指标的。
to crazyafei：目的不同，标准不同。Martin是衡量价值，而领导是衡量工期。

3 楼 crazyafei 2013-09-10 09:21

唉，就如同测量距离没有“米”这个单位一样，没有一个统一的、获得大家认可的衡量标准，是软件开发生产效率管理永远之疼。

2 楼 edhn 2013-09-09 21:30

代码行数衡量生产率确实很恶心，你写少而优的代码却可能被认为生产率低下。
FP也不够好，但胜于代码量。

不过文中后来把商业盈利扯上了，这相关的因素就太多了，产品定位，产品规划，细节体验，销售推广，运营维护等等，这包含开发周期以外的事情

1 楼 dohkoos 2013-09-09 18:59

不是早就有调查表明程序员的生产效率差距可以达到10-100倍吗！这里又说没法衡量生产效率。发现软件行业里到处都充满着类似的矛盾言论。

发表评论

您还没有登录,请您登录后再发表评论

4顶0踩