讨论：衡量程序员的工作效率

与其他领域一样，在软件开发领域中，管理者需要评估程序员的绩效和项目的进度。然而，如何定义恰如其分的评价体系，很令人挠头。

计算代码行数（source lines of code, SLOC）是最常用的方式之一。不过，最近 Shahar Yair 和 Steve McConnell 指出了该方法的一系列重要缺陷。首先，使用代码行数之和无法有效评估一个项目的实际进度，因为它更注重行为而不是结果。最终产品在多大程度上依赖于代码的性能和质量，这也是代码行数无法说明的。因此，聚焦于此实际上是非常有限的工作效率测量方式。

SLOC 无法表明要解决的问题的复杂性，也不能以可维护性、灵活性、扩展性等等因素来说明最终产品的质量。说到质量，它反而可能起到负面作用。通过重构、使用设计模式会减少代码行数，同时提升代码质量。代码量大，可能意味着有更多不必要的代码、更高不必要的复杂性、更加僵化难懂。

更危险的是，要用这样一种不完整的视角来评价开发人员的绩效，会起到错误的激励作用。开发人员会因此更注重代码的数量，而不顾其对产品质量的损害，也不会从最终产品的角度考虑去优化他们的工作，他们甚至可能有意编写更多冗长无益的代码。“测量什么，就得到什么”，Steve McConnel 回忆。

他指出，有些问题可以通过测量度量功能点数解决掉。那么决定程序大小的因素就变成了输入、输出、查询和文件的数目。不过这种方式也有其缺陷。McConnell 提出一些操作性上的问题，比如必须要有一个大家认可的功能点测量机制，而且要想把每个功能点映射到程序员身上也不容易。Daniel Yokomizo 是一位经过认证的功能点专家，他在评论中明确指出了这种方式的其他问题：缺少测量功能点复杂度的工具；还需要考虑诸如代码共享、框架、程序库之类的事情。这些都会影响到完成一个功能的时间。

有很多人参与了对于测量方式的讨论，他们都同意这些做法有其局限，不过他们都觉得衡量开发人员的绩效还是有必要的。实际上，不少人认为 SLOC 可以作为基础，在其之上通过考虑多种不同因素来进行更复杂的分析。McConnell 提出了四条分析开发人员工作效率的必备指导原则，他们也都同意。这四条原则如下：

1. 不要指望单一维度的工作效率测量方式能告诉你每个人的真实情况。
2. 不要指望任何测量方式可以在很小的粒度上区分出每个人的工作效率差异。这些方式可以为你提出问题，却不会告诉你答案。
3. 牢记：趋势总是比单独一点的测量来得重要。
4. 问问你自己：为什么要测量个人的工作效率？

测量开发人员的工作效率在什么样的上下文中才是有意义的？有哪些条件？这些条件该如何组合？许多问题仍没有答案。如果你有过类似经验可以分享，请不要犹豫。

查看英文原文： Opinions: Measuring Programmers’Productivity

在 InfoQ 英文站新闻的后面，大家就测量开发人员工作效率的话题展开热烈的讨论。Bruce Rennie 指出： > 我为什么要关注开发人员的工作效率？……这种测量开发人员工作效率的想法是从哪里冒出来的？……如果从团队的角度来看，就让人更迷糊了。在一个团队中，从个人层面进行测量和优化，这感觉好像没有考虑约束理论的因素。应该测量和优化整体的有效产出。最后一个问题：测量一个失败项目的工作效率有任何意义吗？

John Reynolds 指出： > 测量一个团队的下列指标更有意义：实际开发时间和预估时间，返工以及修复 bug 的时间与实际开发时间，客户满意度与反馈调查。

Mark Levison 明确说明： 危险，这会毁掉团队！> 如果测量个人的绩效，这就等于是在摧毁团队。如果我知道人家在测量我的代码开发速度，下面这些事情我就永远不会做了： - 参加规划和回顾会议

• 指导初级团队成员
• 结对编程
• 代码复查
• 简化代码、去除荣誉，任何可能减少我的功能点数的行为
• 除创建功能点之外的其他任何事情

而且，我会搞清楚功能点到底是什么，然后学着编写可以将功能点数最大化的代码。 随便找一种测量方式，我都可以告诉你它是如何毁掉团队的。我推荐将注意力放在产出上。

对于 Mark Levison 的说法，John Jimenez 提出： > 我相信你身处一个能力很强、产出很高的团队中。但是，如果你的团队不能按时完成任务或者表现不佳呢？我想你需要历史数据（或者类似的东西）来发现哪些成员表现不好。要是不这么做，就会有人怪罪管理层对有些比较偏心，甚至可能会有更坏的情况。在理想的企业文化中，人们希望可以在同事之间互相公平竞争、彼此评价，。然而，如果现状并非如此，管理层就应该努力制造类似的氛围，而对工作效率的测量就变得至关重要了。

Mark Levison 给出了自己的回答： > 问题在于这种“工作效率低下”确实是问题么？还是意味着别的什么？要是衡量我在团队的工作效率，那一定不高。因为我充当了 mentor 的角色，我帮助审查了很多代码，而且总是在重构，并试图改进团队的运作机制。我所在的团队中，代码质量在不断上升。那你说我的效率高不高？这种测量有意义么？ 最重要的，是团队的产出，而且他们可以一起快乐工作。如果团队在产生高质量、通过测试、而且简单的代码，那他们的工作效率又有什么关系？如果他们很高兴，就算有人只是充当胶水的角色，又待如何？

当我充当教练角色的时候，我鼓励管理层为团队设定目标，再看他们能否达成这些目标。任何个人层面上的测量都会破坏团队层面来之不易的成果。

Zachary Shaw 指出： > 我同意考核绩效会造成负面影响，但如果测量大家关心的指标，比如代码覆盖率、测试编写数目、移除警告数目、成功构建次数等这些数据，这样的测量就会有正面效应。……让团队同意对他们的某些工作进行测量，这也是很重要的。如果团队买你的账，那就能带来健康的竞争。

Zachary Shaw 还建议大家去尝试 Hudson 游戏： > 我们已经开始玩“Hudson 持续集成游戏了。……基本的要点在于，你会根据自己签入的代码得到或丢失分数。签入次数越多，测试编写越多，去掉的 TODO 和警告越多，你就能得到越高的分数。“测量什么，就得到什么”，确实是这样，自打我们玩了这个游戏之后，警告不见了，测试更多了，人们签入代码也更加频繁了。……

Mark Levison 又说： > 我真正担心的，是把工资、奖金之类跟个人的测量结果挂钩。可以去 http://gojko.net/2008/08/07/paying-programmers-are-bonuses-bad-and-what-to-do-about-it/ 看看这两者之间的关系。 我很熟悉 Hudson，而且觉得它也是提升质量一种很好的方式，只要信息能够限制在团队内部就可以。如果团队对其过于认真，或是有管理层介入，那我就会开始担心了。

最后，Robert Merrill 指出：要知道测量的原因，而且不要造成混乱。他说： > 我在一个小型（15-20 个人）项目工作室中进行测量活动已经 5 年多了。我们的测量只有一个原因：在给客户的提案中给出项目估算。我们通过两种方式估算，一种是敏捷式的规划游戏，另一种使用功能点数分析（我在 2002-2005 年期间是认证功能点专家［CFPS］）。我计算每个项目，并根据时间记录算出每个功能点所耗小时数。

要估算的时候，我会根据需求和项目的历史来预测每个功能点所耗小时数。这样一个独立的估算方式很有帮助。在面临客户压力时，这比完全主观的方式要更有效。（用功能点分析也可以发现需求缺口。）

为了不造成混乱（即使组织中互相的信任程度已经相当高了），我是唯一可以读取项目历史的人。除了总结报告之外，管理层看不到详细的数据。

测量机制是放大器。它会使得内部信程度高的组织更有成效，而信任程度低的组织则会变得更加孱弱不堪。