如何衡量软件开发绩效？

Question

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

Answer 1

像这样的性能指标的主要问题是人类非常擅长游戏任何衡量自身性能的系统，以最大限度地提高性能指标 - 通常以牺牲其他有价值的东西为代价。

让我们说我们确实使用hudson构建来收集程序员输出的统计数据。你能找到什么，以及一旦程序员被搞砸到它上面会产生什么样的意外副作用呢？

• Lines of code（开发人员只需编写大量的样板代码，以及其他不必要的过度工程，或者只是简单地内联每个方法）
• 单元测试失败（不写任何单元测试，然后它们不会失败）
• 单元测试覆盖（编写运行代码的弱测试，但没有真正测试它）
• 代码中发现的错误数量（不做任何编码，然后就不会出错）
• 修复的错误数量（选择容易/琐碎的错误）
• 根据自己的估计完成任务的实际时间（估计更高以提供更多空间）

它继续。

关键是，无论你测量的是什么，人类（不仅仅是程序员）都非常善于优化以完全满足这一点。

那么您应该如何看待开发人员的表现？嗯，这很难。它涉及人类管理者，他们善于理解人（以及他们所汲取的学士学位），并且可以在谁/哪里/什么是他们要弄清楚的情况下，主观地看待每个人 是不是做得好。

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

（我不能相信这一思路。它最初来自Joel Spolsky。Here和here）

Answer 2

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

Answer 3

没有

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

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

很难做得对。软件解决方案不起作用。

Answer 4

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

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

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

Answer 5

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

Answer 6

说到软件开发人员的KPI。 www.smartKPIs.com可能是您的好资源。它包含一个用户友好的库，其中包含详细记录的性能指标。目前，它列出了3300多个KPI示例，分为73个功能区域，以及83个行业和子类别。

此页面上提供了软件开发人员的KPI示例www.smartKPIs.com - application development其中包括但不限于：

• 缺陷去除效率
• 数据冗余

除了绩效衡量标准的示例外，www.smartKPIs.com还包含一份绩效报告目录，用于说明在实践中使用KPI。 有关信息技术的此类报告的示例，请访问：www.smartKPIs.com - 实践中的关键绩效指标 - 信息技术 该网站每天都会更新新内容，因此请不时查看其他内容。

请注意，虽然绩效衡量指标的示例对决策提供信息非常有用，但每个绩效指标都需要根据每个组织的目标和优先级进行选择和定制。

Answer 7

您可能会更好地衡量您的团队跟踪计划的效果。如果团队成员（或整个团队）一直迟到，您将需要与他们合作以提高绩效。

Answer 8

不要简短或寻找快速简便的方法来衡量开发人员的表现/进度。有许多因素会影响开发人员的输出。我见过很多人尝试各种指标......

生成的代码行 - 鼓励开发人员生成低效的垃圾 复杂性措施 - 鼓励过度分析和重构 产生的错误数量 - 鼓励人们寻找真正简单的任务并讨厌你的测试人员 ......列表继续。

在审核开发人员时，您确实需要了解他们的工作有多好，并在公司需要什么以及公司将这种差异放在哪些情况/位置的背景下定义“好”。应该平等地评估进度考虑和思考。

Answer 9

检查每个代码的编写行数。

然后开始70％的底部..没有90％！......每一天！

（对于那些不确定的人，是的，我在开玩笑。认真回答here）

Answer 10

有很多不同的方法可以做到这一点。关于这个主题的整本书。您可以使用Hudson的报告，但我认为这会导致错误信息并提供原始结果。真的，你需要有任务跟踪方法。

Answer 11

我们从团队中的每个人那里得到360反馈。如果你所有的团队成员都认为你是垃圾，那么你可能就是这样。

Answer 12

许多企业在设置发布管理工具时都会犯一个常见的错误。 Salesforce版本管理工具包是当今市场上最好的版本之一，但是如果你不遵循设置它的关键步骤，你肯定会有一些非常糟糕的结果。您将使用它，但不是它的全部容量。独立于业务流程建立发布管理流程是最糟糕的错误之一。发布管理工具与企业战略，目标，治理，变更管理以及其他一些方面密切相关。发布管理的过程需要以业务中的每个人都在同一页面上的方式形成。

发布管理目标 发布管理的主要目标是拥有一组与资源无关的可靠且可重复的流程。这使得能够实现最有利的商业价值，同时优化可用资源的利用。考虑到大多数组织专注于运行简短，高收益的业务项目，因此优化应用程序的交付价值链以确保在交付业务价值时不会受到任何限制。

以force.com迁移工具包为例，因为该工具已被证明在治理方面非常出色。发布管理工具应该允许在治理中实现最佳可见性和问责制。

流程和发布周期 发布管理流程必须与整个业务保持一致。有必要在各种工具用户之间建立简化和标准化的流程。这是因为他们将使用相同的平台和资源来高效完成任务。为您的业务的不同部门制定不同的流程可能会导致工具管理方面的严重失败。不同的用户组需要了解其他用户正在做什么。如前所述，可见性在任何业务流程中都非常重要。

在发布周期中，还必须有一个集中式系统来跟踪不同用户组的所有要求。此系统也必须集中化，以便软件开发团队深入了解业务所需的功能和变更。请求必须成为优先事项，以确保业务获得最大的利益。拥有一个指导团队非常重要，因为它参与了业务需求的审核，并且还优先考虑了业务需要做出的最合适的更改。

Salesforce系统应该发生的变化可能非常棘手，因此在业务和IT之间定期会面是很好的。这将有助于确定对系统有利的最佳更改，从而使业务受益。通过考虑实现功能的成本和价值，指导委员会的任务是决定要做出的最重要的功能变化。  这里还有很好的研究http://intersog.com/blog/tech-tips/how-to-manage-millennials-on-software-development-teams

Answer 13

这是一个老问题，但你仍然可以从Agile软件开发中借用Velocity，在那里你为每个任务分配一个权重，然后你计算你在每个sprint中解决了多少“权重”（或迭代或你使用的任何DLC）。当然，这就像以前提到的评论者一样，你需要积极地跟踪自己的开发人员是在网上工作还是在线聊天。

如果您知道您的开发人员正在响应，那么您可以依靠velocity来估算团队可以完成的工作量。如果在任何一次迭代中，这个数字都会下降（相当大），那么要么估计得很少，要么团队工作量就会减少。

最终，将KPIs与速度结合使用可以为每个开发人员（或每个团队）提供有关绩效的见解。

Answer 14

通常情况下，直接使用绩效衡量指标被认为是一个坏主意，也是让团队进入实地的简单方法之一。

现在，您可以使用按时完成的项目百分比，代码完成时的流失率等等指标......这是一个广泛的领域。

以下是一个例子：

60％的任务关键错误都是由乔写的。这是一个简单，直接的指标。消防乔，对吗？

但等等，还有更多！

Joe是高级开发人员。每次他都是唯一值得信赖编写超可靠代码的人。他写了大约80％的任务关键型软件，因为他是最好的。

度量标准衡量开发人员。

Answer 15

我会分享我的经验，以及我如何学习衡量团队绩效的非常有价值的流程。我必须承认，我已经专注于跟踪KPI，因为大多数部门会做同样的事情，但不是真正的洞察力，直到我有责任评估开发人员的表现，经过多次阅读后，我用以下解决方案进行了演变。

每个项目都有一个，我会让团队参与讨论项目要求并让他们参与其中，这样每个人都知道要做什么。在通过协作进行的同一讨论中，我们会将项目分解为任务并对这些任务进行加权。现在我们以前估计项目完成率为100％，其中每个任务都有百分比贡献。这确实有效，但不是最好的解决方案。现在我们将基于重量或点的任务精确地基于并使用相对测量来比较任务并区分权重，例如。需要开发Web表单来收集用户数据。 任务就像

 1. User Interface - 2 Points
 2. Database CRUD  - 5 Points
 3. Validation     - 4 Points
 4. Design (css)   - 3 Points

通过这种策略，我们可以确定每周大致已完成的数量以及工作组尚未完成的内容。我们也可以确定谁表现最佳。

我必须承认，我仍然面临着这个策略的一些挑战，例如并非每个开发人员都对每项技术都感到满意。不知何故，有些人兴奋地学习技术只是因为他们发现2015年高分的分数会落在那一部分，有些人会尽其所能。

请记住，不要为了自己的目的跟踪KPI，要跟踪它的洞察力。