如何衡量软件开发绩效？ [关闭]

Posted 2023-02-15

【中文标题】如何衡量软件开发绩效？ [关闭]

【英文标题】：How to measure software development performance? [closed]

【发布时间】：2010-11-13 04:17:56

【问题描述】：

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

【问题讨论】：

对你的程序员正在做的事情保持积极的兴趣，不要依赖一些随机的软件工具来为你提供它本不该提供的信息。

相关：programmers.stackexchange.com/questions/26596/…

这个问题似乎离题了，因为它是关于“测量”in-duh-viduals 的表现。

【参考方案1】：

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

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

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

它还在继续。

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

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

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

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

【讨论】：

为您 +1，为乔尔 +1。 8-)

+1 以获得很好的答案。虽然我见过更糟糕的操作 - 例如，我看到人们在被固定数字激励时创建错误/问题。啊！！.....

【参考方案2】：

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

【参考方案3】：

没有。

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

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

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

【讨论】：

同意，这个人写的代码最少，实际上可以做的工作最多。

也同意——我做过的最有成效的事情之一就是删除了数百行代码

【参考方案4】：

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

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

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

【参考方案5】：

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

【参考方案6】：

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

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

缺陷去除效率 数据冗余

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

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

【参考方案7】：

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

【讨论】：

或者你需要努力提高估算人员的表现！

我们的团队自己进行估算，所以在这种情况下，它是一样的。

【参考方案8】：

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

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

在审查开发人员时，您确实需要了解他们的工作有多好，并根据公司的需求以及公司将该个人置于何种情况/位置来定义“好”。应该以平等的方式评估进度考虑和思考。

【参考方案9】：

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

【参考方案10】：

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

然后发射底部的 70%.. 没有 90%！... 每天！

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

【讨论】：

我不知道你是不是在开玩笑，但由于某些经理会因为你的回答而产生错误的想法，人们的工作可能会受到威胁，所以我投反对票。跨度>

趁有机会带上 Peer Pressure 徽章！ 8-)

话虽如此，如果您是在开玩笑，并且您编辑了答案以明确表示，我会很高兴地投票支持。

我建议在你还有一些名声的时候删除这个糟糕的笑话......

@unforgiven3：哎呀。你对经理的评价很低。

【参考方案11】：

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

【参考方案12】：

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

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

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

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

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

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

【参考方案13】：

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

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

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

【参考方案14】：

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

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

这是一个例子：

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

但等等，还有更多！

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

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

【参考方案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，而要为它的洞察力而跟踪它。