Project management 如何度量软件开发性能？

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

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

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

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

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

不

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

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

---

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

不要简单地使用构建工具来衡量每个程序员的性能。当然，您可以将团队作为一个整体来衡量，也可以肯定地衡量每个程序员的进度，但是您不能用这样的工具来衡量他们的绩效。有些模块比其他模块更复杂，有些程序员负责其他项目，等等。这不是一种推荐的方法，它会鼓励程序员编写草率的代码，这样看起来他们做了最多的工作。

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

您可能会更好地衡量团队跟踪进度的情况。如果团队成员（或整个团队）持续迟到，您需要与他们合作以提高性能。

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

产生的代码行-鼓励开发人员大量产生低效的垃圾 复杂性度量—鼓励过度分析和重构 产生的bug数量-鼓励人们寻找真正简单的任务，并憎恨您的测试人员 ... 这个名单还有很多

---

在审查一名开发人员时，你真的需要看看他们的工作有多好，并根据公司的需要以及公司在哪些情况下/立场来定义“好”。对进度的评估应该给予同等的考虑和思考。

通常，直接使用绩效衡量指标被认为是一个坏主意，也是让团队投入实际工作的简单方法之一

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

下面是一个例子：

60%的关键任务bug是由Joe编写的。这是一个简单明了的指标。解雇乔，对吗

但是等等，还有更多

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

---

度量是对开发人员的一种糟糕的度量。

像这样的性能度量的主要问题是，人类非常擅长与任何度量自身性能的系统进行博弈，以最大限度地提高准确的性能度量-通常是以牺牲其他有价值的东西为代价

假设我们确实使用hudson构建来收集程序员输出的统计数据。一旦程序员掌握了它，您可以寻找什么，以及测量它会产生什么意外的副作用

• （开发人员只是炮制出堆积如山的样板代码和其他不必要的过度工程，或者只是简单地内联所有该死的方法）
• 单元测试失败（不要编写任何单元测试，这样它们就不会失败）
• 单元测试覆盖率（编写测试代码的弱测试，但不真正正确地测试代码）
• 在他们的代码中发现的bug数量（不做任何编码，那么你就不会得到bug）
• 修复的bug数量（选择要处理的简单/琐碎bug）
• 根据他们自己的估计完成任务的实际时间（估计得越高，空间就越大）

事情还在继续

关键是，无论你衡量什么，人类（不仅仅是程序员）都非常擅长优化以满足这一要求

那么，您应该如何看待开发人员的性能呢？嗯，那很难。它涉及到人力资源管理者，他们善于理解人（以及他们所说的废话），并能在他们是谁/在哪里/在做什么的背景下主观地审视每个人，以判断他们是否做得很好

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

---

（我不能把这种想法归功于乔尔·斯波尔斯基。而且）

我们从团队每个人那里得到了360条反馈。如果您的团队成员都认为您是垃圾，那么您可能是垃圾。

说到软件开发人员的KPI。www.smartKPIs.com可能是一个很好的资源。它包含一个用户友好的性能度量标准库。此刻

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