project-management - 如何衡量软件开发绩效？

Question

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

score 64 · Accepted Answer

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

假设我们确实使用 hudson 构建来收集程序员输出的统计信息。您会寻找什么，一旦程序员了解它，测量会产生什么意想不到的副作用？

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

它还在继续。

关键是，无论您衡量什么，人类（不仅仅是程序员）都非常擅长优化以满足该目标。

那么你应该如何看待你的开发者的表现呢？嗯，这很难。它涉及人类经理，他们善于理解人（以及他们拉扯的 BS），并且可以在他们将要谁/在哪里/做什么的背景下主观地看待每个人，以确定他们是否做得好.

然而，一旦你弄清楚谁在表演/不表演，你会做什么是一个完全不同的问题。

（我不能把这种想法归功于它。它最初来自 Joel Spolsky。这里和这里）

score 46 · Accepted Answer

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

score 12 · Accepted Answer

不。

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

衡量开发人员绩效的方法是让优秀的经理做好他们的工作，制定准确反映需求的良好规范，并根据这些规范仔细跟踪每个人的进度。

很难做到正确。软件解决方案行不通。

score 10 · Accepted Answer

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

代码审查评论——每个项目，我们可以决定在给定时期内需要进行多少次代码审查。根据代码审查，个人获得有关其编码标准改进的评论。需要引起注意对同一个人的代码进行代码审查的反复出现的问题。您可以使用自动代码审查工具或手动代码审查。
测试覆盖率和测试完整性。– 覆盖百分比需要预先确定，如果某些开发人员未能经常尝试，则需要加以注意。
愿意签到复杂的任务并毫不费力地交付它们
实现用户故事中定义为“完成”的内容
每个技术领域的掌握水平。

在一些项目中采用敏捷方法，开发团队的测量和预期性能是根据版本决定的。在每个发布计划中，都会与团队成员就预期性能协商不同的“合同”。我发现这种方法更成功，因为没有理由在需要发布复杂算法的版本中遵守 UI 相关测量。

score 5 · Accepted Answer

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

score 4 · Accepted Answer

说到软件开发人员的 KPI。www.smartKPIs.com 对您来说可能是一个很好的资源。它包含一个用户友好的、记录良好的性能度量库。目前，它列出了 3300 多个 KPI 示例，分为 73 个功能领域以及 83 个行业和子类别。

此页面上提供了软件开发人员的 KPI 示例www.smartKPIs.com - 应用程序开发它们包括但不限于：

缺陷去除效率
数据冗余

除了绩效衡量示例之外，www.smartKPIs.com 还包含一个绩效报告目录，说明了 KPI 在实践中的使用。此类信息技术报告的示例可在以下网址获得： www.smartKPIs.com - 实践中的 KPI - 信息技术该网站每天都会更新新内容，因此请不时查看更多内容。

请注意，虽然绩效衡量的示例有助于为决策提供信息，但每个绩效衡量都需要根据每个组织的目标和优先事项进行选择和定制。

score 2 · Accepted Answer

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

score 2 · Accepted Answer

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

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

在审查开发人员时，您确实需要查看他们的工作有多好，并在公司需要什么以及公司将该个人置于何种情况/位置的背景下定义“好”。应该以同等的考虑和思考来评估进度.

score 1 · Accepted Answer

检查每个人写了多少行代码。

然后解雇底部的 70%.. 没有 90%！... 每天！

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

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

score 1 · Accepted Answer

许多企业在设置发布管理工具时常犯一个错误。Salesforce 发布管理工具包是当今市场上最好的工具包之一，但如果您不遵循设置它的重要步骤，您肯定会得到一些非常糟糕的结果。您将可以使用它，但不能充分利用它。建立与业务流程隔离的发布管理流程是最严重的错误之一。发布管理工具与企业战略、目标、治理、变更管理以及其他一些方面密切相关。发布管理流程需要以这样一种方式形成，即业务中的每个人都在同一页面上。

发布管理的目标发布管理 的主要目标是拥有一组一致的、可靠且可重复的、资源独立的流程。这可以实现最有利的商业价值，同时优化可用资源的利用。考虑到大多数组织都专注于运行短期、高收益的业务项目，因此优化应用程序的交付价值链以确保业务价值的交付没有阻碍是至关重要的。

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

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

在发布周期方面，还必须有一个集中式系统来跟踪不同用户集的所有需求。还必须集中该系统，以便软件开发团队深入了解业务要求的功能和更改。请求必须成为优先事项，以确保企业获得最大利益。拥有一个指导团队很重要，因为它涉及对业务需求的审查以及对业务需要进行的最合适的更改进行优先级排序。

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

score 1 · Accepted Answer

这是一个老问题，但您仍然可以从敏捷软件开发中借用Velocity，在其中为每个任务分配权重，然后计算在每个冲刺（或迭代或您使用的任何 DLC）中解决的“权重” ）。当然，这与以下事实有关，就像之前提到的评论者一样，您需要主动跟踪自己的开发人员是在工作还是在线聊天。

如果您知道您的开发人员正在响应式地工作，那么您可以依靠它velocity来估计团队可以做多少工作。如果在任何迭代中这个数字下降（相当大），那么要么估计不准确，要么团队工作量减少。

最终，将KPI与速度结合使用可以让您了解每个开发人员（或每个团队）的性能。

score 0 · Accepted Answer

通常，直接使用指标来衡量绩效被认为是一个坏主意，并且是让团队进入底层的简单方法之一。

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

这是一个例子：

60% 的关键任务错误是由 Joe 编写的。这是一个简单直接的指标。解雇乔，对吧？

但是等等，还有更多！

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

指标是对开发人员的不好衡量。

score 0 · Accepted Answer

我会分享我的经验，以及我是如何学习一个非常有价值的衡量团队绩效的过程。我必须承认，我之所以选择跟踪 KPI，仅仅是因为大多数部门都会这样做，但并不是真正出于洞察力，直到我有责任评估开发人员的绩效，经过大量阅读后，我采用了以下解决方案。

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

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

使用这种策略，我们可以确定每周的大致情况，了解我们已经完成了多少以及任务组有什么待处理的事情。我们还可以确定谁表现最好。

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

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

project-management - 如何衡量软件开发绩效？

15 回答 15

Related

Reference