无法衡量生产力

我们看到关于软件流程、设计实践等的许多情绪化讨论。许多争论无法解决，因为软件行业缺乏衡量软件开发有效性的基本要素的能力。特别是，我们没有办法合理地衡量生产力。

当然，生产力是通过查看活动的投入和产出来确定的。因此，要衡量软件生产力，您必须衡量软件开发的产出——我们无法衡量生产力的原因是我们无法衡量产出。

这并不意味着人们没有尝试。我最讨厌的事情之一是基于代码行进行的生产力研究。首先，所有关于语言差异、不同计数风格以及由于格式约定造成的差异。但即使您在相同语言的程序上使用一致的计数标准，所有程序都自动格式化为单一风格——代码行仍然无法正确衡量输出。

任何优秀的开发人员都知道，他们可以用代码行数量的巨大差异来编写相同的代码，此外，设计良好且经过分解的代码将更短，因为它消除了重复。复制粘贴编程会导致高 LOC 计数和糟糕的设计，因为它会滋生重复。如果您使用支持内联方法的重构工具来处理程序，您就可以证明这一点。只需对常用例程使用它，您就可以轻松地将 LOC 计数翻倍。

您可能会认为代码行已经死了，但似乎每个月我都会看到基于代码行的生产力研究——即使是在像 IEEE Software 这样应该更了解的知名期刊上。

现在，这并不意味着 LOC 是一个完全无用的度量，它在暗示系统的大小方面相当不错。我可以相当肯定地说，一个 100 KLOC 的系统比一个 10KLOC 的系统更大。但是，如果我在一年内编写了 100KLOC 的系统，而 Joe 在同一时间内用 10KLOC 编写了相同的系统，这并不意味着我更有效率。实际上，我会得出结论，我们的生产力大致相同，但我的系统设计得更糟糕。

另一种经常被谈论的用于衡量产出的方法是功能点。我对它们更有好感，但仍然不相信。我听到的一些关于单个系统从使用相同系统的不同功能点计数器获得的计数差异三倍的故事并没有帮助。

即使我们找到了一个准确的方法让功能点来确定功能，我认为我们仍然错过了生产力的重点。我可能会说，衡量功能是一种查看软件开发直接产出的方法，但真正的产出是其他东西。假设一个准确的 FP 计数系统，如果我花一年时间交付一个 100FP 的系统，而 Joe 花同样的一年时间交付一个 50FP 的系统，我们可以假设我更有效率吗？我认为不是。可能是我的 100FP 中只有 30 实际上对我的客户有用的功能，而 Joe 的所有功能都有用。因此，我认为，虽然我的直接生产力更高，但 Joe 的真实生产力更高。

Jeff Grigg 指出，有一些内部因素会影响功能点的交付。“我的 100 个功能点是极其相似的功能，我花了一年时间才完成它们，因为我没有充分利用重用。Joe 的 50 个功能（对他来说是坏消息）都是极其不同的。几乎不可能重用。但尽管必须实现 50 个极其不同的功能点，几乎不可能利用重用，Joe 还是一个了不起的人，所以他只用了一年时间就完成了所有工作。”

但所有这些都忽略了这样一个事实，即使有用的功能也不是真正的衡量标准。随着我的进步，我产生了 30 个有用的 FP 功能，而 Joe 只做了 15 个。但有人发现 Joe 的 15 个功能为我们的客户带来了 1000 万美元的额外利润，而我的工作只带来了 500 万美元的利润。我再次认为 Joe 的真实生产力更高，因为他带来了更多的商业价值——我断言，任何真正的软件开发生产力衡量标准都必须基于交付的商业价值。

这种想法也反映在成功率上。关于软件成功的常见说法是错误的，因为人们不理解什么是失败。我可能会争辩说，一个成功的项目是一个比项目成本带来更多商业价值的项目。因此，如果 Joe 和我分别运行五个项目，我成功了四个，Joe 成功了一个——我最终做得比 Joe 好吗？不一定。如果我的四个成功项目每个都产生了 100 万美元的利润，但 Joe 的一个成功项目比他所有项目的总成本高出 1000 万美元——那么他才是应该得到晋升的人。

有些人说“如果你不能衡量它，你就不能管理它”。这是一个借口。企业一直在管理那些无法真正衡量价值的东西。您如何衡量公司律师、营销部门、教育机构的生产力？你不能——但你仍然需要管理它们（参见罗伯特·奥斯汀了解更多）。

如果团队生产力很难弄清楚，那么衡量团队中个人的贡献就更难了。您可以通过查看团队每次迭代交付的功能数量来大致了解团队的产出。这是一个粗略的判断，但您可以了解团队是否正在加速，或者大致了解一个团队是否比另一个团队更有效率。但个人的贡献更难评估。虽然有些人可能负责实现功能，但其他人可能扮演支持角色——帮助其他人实现他们的功能。他们的贡献在于他们提高了整个团队的生产力——但除非您是该团队的开发人员，否则很难了解他们的个人产出。

如果所有这些还不够复杂，经济学人（2003 年 9 月 13 日至 19 日）发表了一篇关于生产力趋势的文章。似乎经济学家现在正在看到由于 90 年代的计算机投资，企业生产力正在提高。关键是改进滞后于投资：“投资计算机不会自动提高生产力增长；企业也需要重组其业务实践”。电力发明时也出现了同样的滞后现象。

因此，不仅商业价值难以衡量，而且还存在时间滞后。因此，您可能要等到他们构建的软件发布几年后才能衡量团队的生产力。

我理解为什么衡量生产力如此诱人。如果我们能做到这一点，我们就能比现在更容易、更客观地评估软件。但错误的衡量标准只会让事情变得更糟。我认为这是我们必须承认自己无知的地方。