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