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

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