我知道关于衡量开发人员绩效的问题已经被问死了，但请多多包涵。我知道关于如何无法衡量开发人员绩效的古老争论，但现实是，在我们公司，“需要”以一种或另一种方式做到这一点。
我在一家相对较小的公司工作（就开发人员而言很小），管理层认为有必要根据“在第一次迭代时通过测试 (QA) 的功能”来衡量开发人员的绩效。
我们以某种方式设法让他们相信，由于各种原因，这是一个坏主意，而是通过将代码置于所有单元测试都通过的测试中来衡量开发人员。由于在我们的团队中，以前没有“要求”本身开发单元测试，我们认为这是一个正式确定开发单元测试需求的机会——即激励开发人员编写单元测试。
我的问题是：既然可以说我们不会向 QA 发布未通过所有单元测试的代码，那么如何根据单元测试合理地衡量开发人员的性能呢？基于单元测试，是什么让优秀的开发人员脱颖而出？
任何建议将不胜感激。还是我在这种绩效衡量中完全偏离了标准？
也许我在这种性能测量中完全偏离了标准？
问题不是“我们测量什么？”
问题是“什么坏了？”
其次是“我们如何测量破损？”
其次是“我们如何衡量改进？”
直到你有你想要修复的东西，这就是发生的事情。
你选择要测量的东西。
人们通过根据该指标做“看起来”最好的事情来做出回应。
你意识到你在测量错误的东西。
具体来说。
“在第一次迭代时通过测试 (QA) 的功能”是什么意思？保存代码，直到它必须工作。后来看起来好多了。因此，延迟到您在第一次迭代中通过 QA。
“虽然单元测试通过但功能失败？” 这似乎是“不完整的单元测试”。所以你过度测试了一切。花大量时间编写所有可能的测试。放慢交付速度，以免您受到此测量的惩罚。
“根本没有为给定的功能编写单元测试，或者没有编写足够的单元测试？” 不知道你是如何衡量这个的，但听起来和上一个一样。.
“编写的单元测试的质量？” 主观测量。总是一个好计划。定义你将如何衡量质量，你会得到最大化特定衡量的东西。想要更多评论？数那些。还有什么空格？数一下。
“编写的单元测试数量？” 没有什么比计算测试的数量更能激励我编写冗余测试了。如果根据这个指标让我看起来不错，我可以轻松地复制和粘贴几乎相同的代码。
你得到你所测量的。无论您采用什么指标，您都会发现所测量的具体事物将颠覆大多数其他质量问题。无论您测量什么，但绝对确定您希望人们最大化该测量，同时减少其他测量。
编辑
我不是说“不要测量”。我是说“你得到你所测量的”。选择一个您希望以牺牲其他人为代价最大化的指标。选择一个指标并不难。只知道告诉管理层要衡量什么的后果。
我认为单元测试是一种质量工具，而不是生产力工具。如果你既想鼓励单元测试又想给管理层一个生产力指标，强制单元测试将代码投入生产，并根据在给定时间范围内投入生产的代码/功能报告生产力（每周，双每周一次，无论如何）。如果我们认为人们会玩任何系统，那么设计游戏以满足您的目标。
当 Joel说这种测量方法将被你的开发人员玩弄时，我认为它是正确的。它不会达到它所设定的目标，并且您最终可能会遭受质量损失（来自使用该系统的每个人的看法），而您对质量的测量都表明事情从未如此好过！
编辑. 你说管理层要求这个。你是一家小公司；你的管理层不能让每个人都举起棍子离开。告诉他们这是垃圾，你不会参与其中。
如果整个想法是让他们可以对人员进行排名以使他们变得多余（听起来可能是在这个时候），只需询问他们有多少人必须去，然后选择那些你认为最差的开发人员，使用你的智力和判断力，而不是一些愚蠢的经验法则
出于某种原因，我想到了缺陷黑市……尽管这有点相反。
对于开发人员而言，任何基于度量的系统都无法正常工作，因为它不是您可以使用传统方法衡量的东西。无论您尝试针对此类事情采取什么措施，都会被玩弄（因为解决问题是我们整天都在做的事情，而这只是另一个要解决的问题），并且会损害您的代码（例如我写的前几天一个简单的拼写校正器，大约有 5 个单元测试足以检查它是否有效，但如果我在单元测试中被衡量，我可以再花一天时间再写 100 个，这将全部通过但不会增加任何价值）。
你需要弄清楚管理层为什么要建立这个系统。如果是为了给予奖励，那么你应该看看Joel Spolsky 的关于激励薪酬的文章，这与我所看到的相差不远（想想奖金日，看看有多少人真的很开心——没有人因为他们只是得到了他们认为应得的东西——有多少人真的很生气——任何得到的比他们认为应得的少）。
引用史蒂夫·耶格的话：
不应该有一条规则，不允许公司做在呆伯特漫画中被正式嘲笑的事情吗？
我在挪威家里的报纸上读到了一些研究。简而言之，它说办公室类型的工作通常不会从绩效工资中受益。原因是在大多数办公室类型的工作中衡量绩效几乎是不可能的。
然而，像草莓采摘这样简单的工作可以从绩效工资中受益，因为绩效考核真的很容易。没有人会因为表现出色的人得到更高的薪水而感到难过，因为每个人都可以清楚地看到他或她采摘了更多的浆果。
在办公室里，并不总是很清楚另一个人做得更好。所以很多人会失去动力。他们对教师的绩效工资进行了测试，发现它给出了负面结果。薪水高的人通常不明白为什么他们比其他人做得更好，而薪水低的人通常不明白为什么他们的薪水低。
但他们确实发现，非货币奖励通常会有所帮助。从老板那里得到鼓励的话，说做得好，等等。
阅读 iCon，了解史蒂夫乔布斯如何设法让人们发挥作用。基本上，他让人们相信他们是某件大事的一部分，并将改变世界。这就是使人们付出努力和表现的原因。我认为开发人员不会为了钱而付出很多努力。它必须是他们真正相信和/或认为有趣或令人愉快的东西。
如果你打算将人们的薪酬与他们的单元测试表现联系起来，那么结果将不会是好的。
人们会尝试玩弄这个系统。
我认为你追求的是：
您的系统两者都不会完成。
通过将人们的工资与他们的测试是否失败挂钩，你正在抑制编写测试的动力。为什么有人会编写这样的代码，至少不会产生任何好处，最坏的情况会限制他们的薪水？总体动机将是保持测试台的大小最小化，以便将可能的故障罩降到最低。
这意味着你会得到更多的错误，除非它们是你不知道的错误。
这也意味着您将奖励引入错误的人，而不是那些阻止错误的人。
基本上你会得到与你的目标相反的结果。
这些是我对您的四个具体问题的初步想法：
棘手的这个。乍一看它看起来不错，但如果代码通过了单元测试，除非开发人员作弊（见下文）或测试本身是错误的，否则很难看出你将如何证明这一点。
这似乎是最好的方法。所有功能都应该进行单元测试，并且对代码的检查应该能够揭示哪些存在，哪些不存在。然而，一个缺点可能是开发人员编写了一个空测试（即只返回“通过”而没有实际测试任何内容的测试）。您可能需要花费大量精力进行代码审查才能发现这一点。
你将如何评估质量？谁来评估质量？这假设您的 QA 团队可以接触到高技能的独立开发人员——这可能是真的，但似乎不太可能。
计算任何东西的数量（代码行、编写的单元测试）是不可能的。开发人员将简单地编写大量无用的测试。
我同意 oxbow_lakes，事实上，自从我开始写这篇文章以来就出现了其他答案——大多数形式的测量都会被开发人员玩弄或更糟。
我相信时间是衡量开发人员绩效的唯一方法，尽管是主观的。
在任何一家公司只要有足够的时间，优秀的开发人员就会脱颖而出。项目负责人将知道谁是他们最好的资产。只要有足够的时间，不良的开发人员就会暴露出来。不幸的是，最终的问题是足够的时间。
基本心理学 - 人们为激励而工作。如果我获得奖金/保住工作的机会/无论是基于我编写的测试数量，我都会编写大量毫无意义的测试——可能会以牺牲我真正的工作为代价，也就是将产品推出市场门。
您可以提出的任何其他基本指标都会遇到同样的问题并且同样毫无意义。
如果您坚持“评级”开发人员，您可以使用更横向的东西。可能是其中一项 MS 认证测试的分数（这具有让人们接受培训的副作用）。至少这是客观的并且由中立的第三方独立验证，所以你不能“玩弄”它。当然，这个分数也与这个人在你的团队中的效率没有任何相似之处，但它比任意的内部测量要好。
您还可以考虑通过某种复杂性测量工具（更简单==更好）运行代码并根据结果对人们进行评分。同样，它具有帮助人们成为更好的编码员的效果，这是您真正想要实现的。
可怜的阿什...
使用管理上的无知来推动完全不相关的事情的荣誉，但现在你必须想出一个可行的措施。
我想不出任何不荒谬或容易被欺骗的绩效衡量标准。单元测试不能改变它。由于 Kopecks 和 Black Market 在几分钟内就建立了联系，我宁愿给你弹药，因为它不需要单独的性能测量：
首先，软件是相互冲突的目标之间的优化。评估其中的一个或几个——比如在 QA 期间进行了多少测试——将导致其他领域的严重权衡，从而损害最终产品。
其次，团队合作不仅仅是几个人粘在一起的产物。协同效应不能追溯到单个人的努力或技能——在团队中开发软件时，它们会产生巨大的影响。
第三，软件的总成本仅在时间之后才会显现。维护、可扩展性、与新平台的兼容性、与未来产品的交互都会带来巨大的长期成本。衡量短期成本（同比，或投入生产）根本不包括长期成本，一旦知道长期成本，将其追溯到发起人是没有意义的。
为什么不让每个开发者都为他们的同事“投票”：去年谁帮助我们实现了我们的目标？为什么不相信你（显然是他们的经理或领导）来判断他们的表现？
单元测试应该有几个因素的组合，对于开发组以外的人来说，在测量以下方面应该很容易获得记分卡：
1) 单元测试对代码和可能为 UI 元素输入的任何常见输入数据的覆盖程度如何？这似乎是一个基本的事情，但它是一个很好的起点，并且我认为可以使用 nCover 等工具轻松量化。
2) 是否经常测试边界条件，例如参数或字母的空值而不是数字和其他基本验证测试？这也可以通过查看各种方法的参数以及有编码标准来防止绕过这里的东西来轻松量化，例如，除了构造函数之外的所有对象方法都采用 0 参数，因此没有边界测试。
3) 单元测试的粒度。测试是否检查一个特定的案例，而不是尝试在一个测试中做很多不同的案例？测试类是否包含数千行代码？
4) 根据可读性和可维护性对代码和测试进行评分。新人是否必须花费数天时间弄清楚发生了什么，或者代码是否有点自我记录？示例将包括有意义的方法名称和类名称以及是否存在文档？
最后三件事是我怀疑经理、团队负责人或其他开发人员之外的其他人可以排名和处理的。可能有一些游戏可以利用这些东西，但问题是你想要得到什么最终结果？我在想有据可查、高质量、易于理解的代码 = 好代码。
查看戴明和全面质量管理，了解他对为什么根本不应该对任何工作进行绩效评估的想法。
相反，假设所有员工都是可接受的员工，除非证明不同。
如果有人做了一些不可接受的事情或没有达到您需要的水平，请将其写为性能问题。在您将他们赶出公司之前，确定他们获得了多少书面记录。
如果有人做得好，就把他们写下来，因为他们做得很好。如果您想提供奖金，请在表现良好时提供。更好的是确保你宣布人们何时得到一个attaboy。人们将努力获得它们。当然，您将拥有试图与系统博弈并根据其他成就被记录下来的政策类型，但无论如何您在任何系统中都会得到。通过在表现良好时宣布谁得到了他们，你已经消除了让办公室政治参与者发挥最佳作用的保密性。如果每个人都知道乔做了一件伟大的事，而你奖励玛丽，人们就会开始谈论它。至少，乔和玛丽可能都会得到一个好孩子。
每年，给每个人同样比例的加薪，因为你只保留了表现可以接受的员工，并且你在一年中只要他们做了好事就奖励了优秀的员工。
如果您坚持测量，那么请测量您为表现不佳而写下某人的次数以及为表现良好而写下某人的次数。然后，您必须小心谨慎地对此保持合理的客观性，甚至写出那些做好事时不是你朋友的人，以及当他们做坏事时是你朋友的人。但是面对现实，无论您如何坚持客观标准，经理都会在此过程中变得主观，因为现实世界中没有客观标准。
明确地，遵循公认的答案单元测试并不是衡量开发性能的好方法。事实上，它们可能是一项几乎没有回报的投资。
… 自动化测试本身不会提高我们的代码质量，但确实需要代码输出
– 从衡量开发人员的影响
根据代码/功能报告生产力，使其在给定的时间范围内投入生产并强制进行单元测试实际上是一个很好的系统。问题是您从中得到的反馈很少，并且可能有太多的借口来实现目标。此外，功能/重构/增强可能具有非常不同的大小和性质，因此在大多数情况下比较与组织相关是不公平的。
使用版本控制系统，如 git，我们可以将有价值工作的最小单元原子化为提交 / PR。可视化（如上面链接的引用）对于管理层来说是一个更好、更崇高的目标，而不是有一个扁平的阶梯或度量标准来比较他们的开发人员。
不要试图测量原始输出。尝试了解开发人员的工作，将其可视化。