我正在寻找一些衡量软件开发团队绩效的方法。使用构建工具是个好主意吗？我们使用 Hudson 作为自动构建工具。我想知道我是否可以从 Hudson 报告中获取信息，并从中获得每个程序员的进度。
【问题讨论】：
标签： project-management metrics
此类性能指标的主要问题在于，人类非常擅长玩任何系统来衡量自己的性能以最大限度地提高准确的性能指标 - 通常以牺牲其他有价值的东西为代价。
假设我们确实使用 hudson 构建来收集程序员输出的统计信息。您会寻找什么？一旦程序员了解它，测量会产生什么意想不到的副作用？
它还在继续。
重点是，无论您衡量什么，人类（不仅仅是程序员）都非常擅长优化以满足该目标。
那么，您应该如何看待开发人员的表现？嗯，这很难。它涉及人类经理，他们善于理解人（以及他们拉扯的 BS），并且可以主观地在他们是谁/在哪里/做什么的背景下观察每个人，以弄清楚他们是否做得好与否。
但是，一旦你弄清楚谁在表演/不表演，你会做什么是一个完全不同的问题。
【讨论】：
不要仅仅使用构建工具来衡量每个程序员的表现。当然，您可以衡量整个团队，或者您当然可以衡量每个程序员的进度，但您无法使用这样的工具衡量他们的表现。一些模块比其他模块更复杂，一些程序员负责其他项目等。这不是推荐的方式，它会鼓励程序员编写草率的代码，这样看起来他们做了最多的工作。
【讨论】：
没有。
这样的指标注定要失败。不同的人处理代码的不同部分，处理不同类别的问题，绝对测量最多是误导。
衡量开发人员绩效的方法是让优秀的经理做好自己的工作，制定准确反映需求的良好规范，并根据这些规范仔细跟踪每个人的进度。
很难做到正确。软件解决方案行不通。
【讨论】：
我认为在决定衡量开发人员绩效的方法时需要一种非常谨慎的方法，因为大多数传统方法，如代码行、签入次数、修复的错误数量等，在当今的软件工程中被证明是主观的概念。我们需要重视团队绩效方法，而不是衡量项目中的单个 KPI。然而，在商业开发环境中工作，重要的是要跟踪并密切关注各个开发人员的以下因素；
在某些项目中采用敏捷方法，开发团队的衡量标准和预期性能是根据版本决定的。在每个发布计划中，都会与团队成员协商不同的“合同”以获得预期的性能。我发现这种方法更成功，因为没有理由在要发布复杂算法的版本中坚持与 UI 相关的测量。
【讨论】：
我不建议使用构建工具信息来衡量软件开发人员的绩效/进度。一些令人困惑的问题：可能一项任务比另一项任务困难得多；一项任务可能比“实施空间”更多地涉及“设计空间”；可能（可能）更有效的解决方案是更好的解决方案，但是与提供更多代码行的非常低效的解决方案相比，更好的解决方案贡献的代码行数更少；等等
【讨论】：
谈到软件开发人员的 KPI。 www.smartKPIs.com 对您来说可能是一个很好的资源。它包含一个用户友好的、记录良好的性能度量库。目前，它列出了 3300 多个 KPI 示例，分为 73 个功能领域以及 83 个行业和子类别。
此页面上提供了软件开发人员的 KPI 示例www.smartKPIs.com - application development 它们包括但不限于：
除了绩效衡量的示例之外，www.smartKPIs.com 还包含一个绩效报告目录，这些报告说明了 KPI 在实践中的使用。 此类信息技术报告的示例可在以下网址获得：www.smartKPIs.com - 实践中的 KPI - 信息技术 该网站每天都会更新新内容，因此请不时查看更多内容。
请注意，虽然绩效指标示例有助于为决策提供信息，但每个绩效指标都需要根据每个组织的目标和优先事项进行选择和定制。
【讨论】：
您可能会更好地衡量您的团队对时间表的跟踪情况。如果团队成员（或整个团队）一直迟到，您将需要与他们合作以提高绩效。 p>
【讨论】：
不要走捷径或寻找快速简便的方法来衡量开发人员的绩效/进度。影响开发人员输出的因素有很多。我见过很多人尝试各种指标...
产生的代码行数 - 鼓励开发人员产生低效的垃圾 复杂性度量 - 鼓励过度分析和重构 产生的错误数量 - 鼓励人们寻找真正简单的任务并讨厌你的测试人员 ...列表还在继续。
在审查开发人员时，您确实需要了解他们的工作有多好，并根据公司的需求以及公司将该个人置于何种情况/位置来定义“好”。应该以平等的方式评估进度考虑和思考。
【讨论】：
有很多不同的方法可以做到这一点。关于这个主题的整本书。您可以使用 Hudson 的报告，但我认为这会导致错误信息并提供粗略的结果。你真的需要有任务跟踪方法。
【讨论】：
【讨论】：
我们从团队中的每个人那里获得 360 度反馈。如果您的所有团队成员都认为您很垃圾，那么您可能就是。
【讨论】：
许多企业在设置发布管理工具时常犯一个错误。 Salesforce 发布管理工具包是当今市场上最好的工具包之一，但如果你不遵循设置它的重要步骤，你肯定会得到一些非常糟糕的结果。您将可以使用它，但不能充分利用它。建立与业务流程隔离的发布管理流程是最严重的错误之一。发布管理工具与企业战略、目标、治理、变更管理以及其他一些方面密切相关。发布管理的流程需要以这样一种方式形成，即业务中的每个人都在同一个页面上。
发布管理的目标 发布管理的主要目标是拥有一组一致的、可靠且可重复的、资源独立的流程。这可以实现最有利的商业价值，同时优化可用资源的利用。考虑到大多数组织都专注于运行短期、高收益的业务项目，因此优化应用程序的交付价值链以确保业务价值的交付没有阻碍是至关重要的。
以 force.com 迁移工具包为例，因为该工具已被证明在治理方面非常出色。发布管理工具应允许在治理中实现最佳可见性和问责制。
流程和发布周期 整个业务的发布管理流程必须是一致的。有必要在各种工具用户之间建立简化和标准化的流程。这是因为他们将使用能够有效完成任务的相同平台和资源。为不同的业务部门制定不同的流程可能会导致工具管理的严重失败。不同的用户组需要了解其他用户在做什么。如前所述，可见性在任何业务流程中都非常重要。
在发布周期方面，还必须有一个集中式系统来跟踪不同用户集的所有需求。还必须集中该系统，以便软件开发团队深入了解业务要求的功能和更改。请求必须成为优先事项，以确保企业获得最大利益。拥有一个指导团队很重要，因为它涉及审查业务需求以及确定业务需要进行的最适当更改的优先级。
应该对 Salesforce 系统进行的更改可能非常棘手，因此业务部门和 IT 部门之间定期会面是件好事。这将有助于确定对系统进行的有益于业务的最佳更改。通过考虑实现功能的成本和价值，指导委员会的任务是决定要进行的最重要的功能更改。 这里也好好研究一下http://intersog.com/blog/tech-tips/how-to-manage-millennials-on-software-development-teams
【讨论】：
通常情况下，直接使用指标来衡量绩效被认为是一个坏主意，并且是让团队踏实的简单方法之一。
现在，您可以使用诸如按时完成的项目百分比、代码完成时的流失百分比等指标...这是一个广泛的领域。
这是一个例子：
60% 的关键任务错误是由 Joe 编写的。这是一个简单直接的指标。解雇乔，对吧？
但等等，还有更多！
Joe 是高级开发人员。他是唯一一个每次都被信任编写超可靠代码的人。他编写了大约 80% 的任务关键型软件，因为他是最好的。
指标是对开发人员的不好衡量。
【讨论】：
我会分享我的经验，以及我是如何学习一个非常有价值的衡量团队绩效的过程的。我必须承认，我之所以选择跟踪 KPI，仅仅是因为大多数部门都会这样做，但并不是真正出于洞察力，直到我有责任评估开发人员的绩效，经过大量阅读后，我采用了以下解决方案。
每个项目一个，我会在讨论项目要求时招待团队并让他们参与进来，这样每个人都知道要做什么。在通过协作进行的同一讨论中，我们会将项目分解为任务并权衡这些任务。现在，以前我们将项目完成率估计为 100%，其中每个任务都有百分比贡献。好吧，这确实工作了一段时间，但不是最好的解决方案。现在，我们将基于重量或精确点的任务，并使用相对测量来比较任务并区分权重。需要开发一个 Web 表单来收集用户数据。 任务会像
1. User Interface - 2 Points
2. Database CRUD - 5 Points
3. Validation - 4 Points
4. Design (css) - 3 Points
通过这种策略，我们可以确定每周大概完成的工作量以及任务组的待处理工作量。我们还可以确定谁表现最好。
我必须承认，我在此策略上仍然面临一些挑战，例如并非每个开发人员都对每项技术都感到满意。不知何故，有些人对学习技术感到兴奋，仅仅是因为他们发现 2015 年的高 % 分数落在该部分，有些人会尽其所能。
请记住，不要为了自己的利益而跟踪 KPI，而要为它的洞察力而跟踪它。
【讨论】：