如何衡量软件开发绩效?

Mik*_*keG 28 project-management metrics

我正在寻找一些衡量软件开发团队绩效的方法.使用构建工具是个好主意吗?我们使用Hudson作为自动构建工具.我想知道我是否可以从Hudson报告中获取信息,并从中获取每个程序员的进度.

mad*_*lep 62

像这样的性能指标的主要问题是人类非常擅长游戏任何系统来衡量他们自己的性能以最大化那个确切的性能指标 - 通常以牺牲其他有价值的东西为代价.

让我们说我们使用hudson构建来收集程序员输出的统计数据.您能找到什么,以及一旦程序员了解它,测量的意外副作用会是什么?

  • 代码行(开发人员只是编写样板代码的山脉,以及其他不必要的过度工程,或者只是简单地内联每个该死的方法)
  • 单元测试失败(不写任何单元测试,然后它们不会失败)
  • 单元测试覆盖率(编写运行代码的弱测试,但没有真正测试它)
  • 在他们的代码中找到的错误数量(不做任何编码,然后你不会得到错误)
  • 修复的错误数量(选择容易/琐碎的bug来处理)
  • 根据自己的估计完成任务的实际时间(估计更高以提供更多空间)

它继续下去.

关键是,无论你衡量什么,人类(不仅仅是程序员)都非常善于优化以完全满足那个东西.

那么您应该如何看待开发人员的表现?嗯,这很难.它涉及人类管理者,他们善于理解人(以及他们所汲取的学士学位),并且可以在谁/哪里/什么是他们想要做出好的工作的情况下主观地看待每个人. .

一旦你弄清楚谁在/不在表演,你所做的就是一个完全不同的问题.

(我不能相信这一思路.它最初来自Joel Spolsky.这里这里)

  • +1给出了很好的答案.虽然我看到了更糟糕的操作 - 例如我看到人们*在他们被修复的数字激励时会产生*错误/问题.aaargh !! ..... (4认同)
  • 为你+1,为乔尔+1.8-) (2认同)

Alb*_*oPL 46

不要仅使用构建工具来衡量每个程序员的表现.您可以整体衡量团队,当然,或者您当然可以衡量每个程序员的进度,但是您无法使用这样的工具来衡量他们的表现.有些模块比其他模块更复杂,有些程序员负责其他项目等等.这不是推荐的方法,它会鼓励程序员编写草率代码,这样看起来他们做得最多.

  • 这是一个真实的故事. (3认同)

Ric*_*dle 12

没有.

像这样的度量标准注定要失败.不同的人在代码的不同部分,不同类别的问题上工作,绝对测量充其量是误导.

衡量开发人员绩效的方法是让优秀的管理人员能够很好地完成工作,拥有准确反映需求的良好规范,并根据这些规范仔细跟踪每个人的进度.

做得很难很难.软件解决方案无效.

  • 同意,这家伙写的最少量的代码实际上可以做最多的工作. (6认同)

小智 10

我认为在决定衡量开发人员绩效的方法时需要采取非常谨慎的方法,因为大多数传统方法(例如代码行,签入数量,修复的错误数量等)都被证明是当今软件工程概念的主观方法.我们需要重视团队绩效方法,而不是衡量项目中的个别KPI.然而,在商业开发环境中工作,重要的是要跟踪并密切关注各个开发人员的以下因素;

  1. 代码审查评论 - 每个项目,我们可以决定在给定时期内需要进行的代码审查的数量.根据代码审查,个人可以获得有关其编码标准改进的评论.需要引起同一个人代码的代码审查的重复问题.您可以使用自动代码审查工具或手动代码审查.
  2. 测试覆盖率和测试的完整性. - 需要先预先确定所覆盖的百分比,如果某个开发人员未能经常尝试,则需要注意.
  3. 愿意签署复杂的任务并毫不费力地交付它们
  4. 实现用户故事中定义为"完成"的内容
  5. 掌握每个技术领域的水平.

在某些项目中采用敏捷方法,开发团队的测量结果和预期性能将根据发布情况确定.在每个发布计划中,都会有与团队成员就预期绩效进行协商的不同"合同".我发现这种方法更成功,因为在发布复杂算法的版本中没有理由遵守UI相关的测量.


Pau*_*ier 5

我不建议使用构建工具信息来衡量软件开发人员的性能/进度.一些令人困惑的问题:可能一项任务比另一项任务要困难得多; 可能一项任务涉及"设计空间"而不是"实施空间"; 可能(可能)更有效的解决方案是更好的解决方案,但更好的解决方案贡献更少的代码行,而不是提供更多代码行的非常低效的代码; 等等