另一个关于测量开发人员表现

我知道有关测量开发人员表现的问题已经被要求死亡,但请耐心等待.我知道关于你如何无法衡量开发人员绩效的古老争论,但实际情况是,在我们公司,有一种"需要"以这种或那种方式做到这一点.

我在一家规模相对较小的公司工作(在开发人员方面很小),管理层认为有必要根据"在第一次迭代时通过测试(QA)的功能来衡量开发人员的绩效".

我们以某种方式设法说服他们出于各种原因这是一个坏主意,而是通过将代码放入测试所有单元测试通过来测量开发人员.由于在我们的团队之前没有"要求"本身开发单元测试,我们认为这是一个正式开发单元测试需求的机会 - 即激励开发人员编写单元测试.

我的问题是:因为可以说我们不会向没有通过所有单元测试的QA发布代码,如何根据单元测试来合理地衡量开发人员的性能？基于单元测试,什么使优秀的开发人员脱颖而出？

单元测试通过但失败的功能？

根本没有为给定的功能编写单元测试,或者没有编写足够的单元测试？

单元测试的质量写的？

编写的单元测试数量？

任何建议将不胜感激.或者我在这种性能测量方面完全不合适？

也许我在这种性能测量方面完全不合适？

问题不在于"我们测量什么？"

问题是"什么坏了？"

接下来是"我们如何衡量破损？"

接着是"我们如何衡量改进？"

直到你有一些你想要修复的东西,这就是发生的事情.

你选择要衡量的东西.

人们根据该指标做出"看起来"最佳的回应.

你意识到你在测量错误的东西.

特别.

"在第一次迭代时通过测试(QA)的功能"这意味着什么？保存代码,直到它可以工作.后来看起来更好.所以,延迟到你在第一次迭代时通过QA.

"虽然单元测试通过但功能失败了吗？" 这似乎是"不完整的单元测试".所以你超越了一切.花点时间编写所有可能的测试.减慢交付速度,这样您就不会因此而受到惩罚.

"根本没有为给定的功能编写单元测试,或者没有编写足够的单元测试？" 不知道你如何测量它,但它听起来与前一个相同..

"编写单元测试的质量？" 主观测量.总是一个好的计划.定义您将如何衡量质量,并获得最大化特定测量的东西.想要更多评论？数数.还有什么空白？算一下.

"写的单元测试数量？" 没有什么能激励我编写冗余测试,比如计算测试次数.如果根据此指标让我看起来很好,我可以轻松复制和粘贴几乎相同的代码.

你得到你衡量的东西.无论您采用何种指标,您都会发现所测量的具体内容将颠覆大多数其他质量问题.无论您测量什么,但绝对确定您希望人们在减少其他测量的同时最大化测量.

编辑

我不是说"不要测量".我说"你得到的是你所测量的".选择您希望以其他方式为代价最大化的指标.选择一个指标并不难.只要知道告诉管理层测量什么的后果.