| 2022-09-01
这是马丁•福勒在 2003年写的一篇文章。而且，于 2013 年还发布了推文，很多人参与讨论。
但 《Business Process Improvement: The Breakthrough Strategy for Total Quality, Productivity, and Competitiveness》 的作者 H. James Harrington 博士说：
你不能衡量，就不能理解。不能理解，就不能控制。不能控制就不能改进。
其实，Martin Folwer 把很多个不同「生产力」的概念混淆在了一起，得出了一个「结论」。所以，他说的看似正确，但实际上混淆了一些东西。一会说效率，一会说效能。这两个概念并不能与其文中例子的两个人（ Martin 和 Joe）简单地直接关联在一起。
Martin Folwer 的正文如下：
我们已经看到过很多有关软件生产过程，设计实践等方面相关讨论。由于软件行业缺乏衡量软件开发有效性的一些基本要素，因此许多论点无法解释。尤其是，我们无法合理地衡量生产力。
生产力通常是根据活动的输入及输出来确定的。因此，要衡量软件生产力，就必须衡量软件开发的产出 —— 我们无法衡量软件开发生产力的原因是：我们无法衡量产出。
这并不意味着人们没有尝试过。
我最大的困扰之一是基于代码行的生产力研究。
首先，由于语言之间的差异，不同的计数样式以及由于格式约定，就会引起一定的差异性。
其次，即使您对使用相同语言的程序，使用一致的计数标准，所有程序都会自动格式化为单一样式——代码行仍无法正确衡量输出。
任何优秀的开发人员都知道，他们可以编写相同的东西，但代码行数可能千差万别。另外，通过精心设计和分解，其代码可能会更短，因为它消除了重复。
“复制和粘贴”会导致 LOC 高和设计不佳，因为它会滋生重复代码。
如果您使用支持内联方法的重构工具来编写程序，就可以自己证明这一点。只需在常规例程上使用它，就可以使LOC计数轻松增加一倍。
您可能以为，代码行统计已经死了，但是似乎每个月我都会看到基于代码行的生产力研究 —— 即使是在知名的期刊如IEEE Software中，应该对此有所了解。
当然，这并不意味着 LOC 完全没有用，它可以很好地说明了软件系统的规模。我非常有信心地说：“100 KLOC系统比10KLOC系统更大”。但是，如果我一年内编写了 100KLOC 的系统，而 Joe 在同样时间用10KLOC编写了相同的系统，那并不会认为我的工作效率更高。
的确，我可以得出结论，我们的生产率大致相同，但是我的系统设计较差。
功能点是经常谈论的另一种度量产出的方法。我对它们有更多的同情，但仍不确信。我听说过有关单个系统从使用同一系统的不同功能点计数器获得的计数相差三倍的报道，这并没有得到帮助。
即使我们确实找到了功能点确定功能的准确方法，但我仍然认为我们缺少生产力点数。
我认为，功能点数是软件开发直接产出的一种方法，但是真正的产出则是另外一回事。
假设有一个准确的功能点计数系统，当我花了一年时间交付 100 FP 的系统，而 Joe 花了同样的时间交付了一个 50 FP 的系统，是否可以假设：我的生产力更高？
我认为：不能这样说。可能是我的 100 FP 中，只有 30 个实际上对客户有用的功能，但是 Joe 的全部 FP 都是有用的。因此，我会说，虽然我的直接生产率高，但 Joe 的真实生产率高。
Jeff Grigg 提醒我，有一些内部因素会影响交付功能点。 比如，我的 100 个功能点都是非常相似的功能，花了我一年的时间，因为我没能对这些功能进行恰当的复用，而Joe 的 50 个功能各自都大不相同，几乎没有重用的可能。但是，尽管如此，Joe 也不得不开发 50 个非常不同的功能点，而且几乎不可能使用「复用」这一杠杆。Joe 是一个能力很强的人，他在一年内就做到了。”
但是，所有这些都忽略了一点，即：有用的功能也不是真正的衡量标准。当我的能力提升了以后，我可能生产 30 个有用的功能点，而 Joe 仅生产15个。但是，有人发现，Joe的 15个 能为我们的客户带来 1000 万美元的额外利润，而我的工作仅能带来 500 万美元。
这时，我可能会认为，乔的真实生产力更高，因为他交付了更多的商业价值。
我断言，对软件开发生产力的任何真实衡量，都必须基于交付的商业价值。
这种想法也有助于成功率。关于软件成功的常见说法是虚假的，因为人们可能无法定义「什么是失败」。我会说，一个成功的项目所带来的商业价值要高于该项目的成本。因此，如果 Joe 和我分别开发五个项目，而我又成功完成了四个项目，Joe 只完成了一个项目。那么，我会比 Joe 做得更好吗？不一定。
如果我的四次成功都能获得 100 万美元的利润，但是 Joe 的一次成功所产生的收益比他所有项目的总成本高出 1000 万美元-那么他就是应该得到晋升的人。
有人说「如果无法衡量，就无法管理」。企业所管理的东西是无法始终衡量其价值的事物。你如何衡量公司律师，市场部，教育机构的生产力？你不能，但是你仍然需要管理它们。
如果很难确定团队的生产力，那么衡量个人对该团队的贡献就更难了。
**通过查看每个迭代提供多少功能点，你可以大致了解团队的输出。**这只是一种粗略的感觉，但是，你可以了解一个团队的开发速度，还是一个团队比另一个团队生产力更高的粗略感觉。然而，个人贡献很难评估。虽然有些人可能负责实现功能，但其他人可能扮演辅助角色——帮助其他人实现其功能。他们的贡献是他们正在提高整个团队的生产力 —— 但是除非你是该团队的开发人员，否则很难了解他们的个人产出。
如果这还不够复杂，《经济学人》（2003年9月13日至19日）发表了一篇有关生产力趋势的文章。似乎由于九十年代的计算机投资，经济学家现在看到企业的生产力提高了。关键在于，这些改进落后于投资：「投资计算机并不能自动提高生产力；公司还需要重新组织其业务实践」。电力发明也出现了同样的滞后。
因此，不仅难以衡量业务价值，而且还存在时间滞后。因此，也许直到团队发布所构建的软件几年后，才能衡量这个团队的生产力。
我明白为什么衡量生产力如此诱人。
如果我们能够做到，那么我们可以比现在更轻松，更客观地评估软件。但是错误的措施只会使情况变得更糟。
我认为这是我们必须承认自己无知的地方。