什么是最有用的软件开发指标？

Question

我希望跟踪可用于改进我的团队软件开发过程，改进时间估算以及检测项目执行期间需要解决的特殊情况变体的指标。

请将每个答案限制为一个指标，描述如何使用它，并投票给好的答案。

Answer 1

_{（来源：osnews.com）}

Answer 2

投资回报率。

软件带来的总收入减去生产软件的总成本。按总成本的百分比细分成本，并在投资回报方面隔离最差的表现和最昂贵的区域。如果可能，改进，自动化或消除该问题区域。相反，找到您最高的投资回报率区域，并找到进一步扩大其影响的方法。如果您的投资回报率的80％来自您的成本或工作量的20％，请扩展该特定区域并通过比较最小化其余部分。

成本将包括工资单，许可证，律师费，硬件，办公设备，营销，生产，分销和支持。这可以在整个公司的宏观层面上完成，也可以在团队或个人的微观层面上完成。除收入外，它还可以应用于时间，任务和方法。

这并不意味着忽略所有细节，而是找到一种方法来量化所有内容，然后专注于产生最佳（客观）结果的区域。

Answer 3

反向代码覆盖

获取测试期间未执行的代码百分比。这与Shafa提到的相似，但用法不同。如果在测试期间运行了一行代码，那么我们就知道它可能会被测试。但是如果没有运行一行代码，那么我们肯定知道它还没有经过测试。针对这些区域进行单元测试将提高质量，并且比审核已覆盖的代码花费的时间更少。理想情况下，你可以做到这两点，但永远不会发生接触。

Answer 4

“改进我的团队的软件开发过程”：缺陷查找和修复费率

这与已经提交或验证的修复数量相关的缺陷或错误数量有关。

我不得不说这是一个非常重要的指标，因为它给你两件事：

1。代码流失。每天/每周更改多少代码（当您尝试稳定版本时这很重要），并且，

2。显示缺陷是否在修复之前，反之亦然。这将向您展示开发团队对质量保证/测试人员提出的缺陷的响应情况。

低修复率表示团队正在忙于处理其他事情（可能是功能）。如果错误计数很高，您可能需要让开发人员解决一些缺陷。
较低的查找率表明您的解决方案非常出色，几乎没有错误，或者质量保证团队已被阻止或重点关注。

Answer 5

跟踪执行具有估计值的任务所需的时间。如果他们很好，请问为什么。如果他们结束了，请问为什么。

不要把它变成消极的东西，如果任务爆炸或估计不足，那就没问题了。您的目标是不断改进您的估算流程。

Answer 6

跟踪您找到的错误的来源和类型。

错误源代表了引入错误的开发阶段。 （例如规范，设计，实施等）

错误类型是广泛的错误风格。例如。内存分配，条件不正确。

这应该允许您更改在该开发阶段中遵循的过程，并调整编码样式指南以尝试消除过度表示的错误类型。

Answer 7

速度：每单位时间内的特征数量。

由您决定如何定义要素，但它们应该大致相同的数量级，否则速度不太有用。例如，您可以按故事或用例对功能进行分类。应该对它们进行细分，使它们的大小大致相同。每次迭代，确定实现（完成）了多少故事（用例）。特征/迭代的平均数量是您的速度。根据功能单元了解速度后，您可以使用它来帮助估算根据功能完成新项目所需的时间。

[编辑]或者，您可以为每个故事指定一个功能点或故事点等权重作为复杂度的度量，然后将每个已完成要素的点数相加，并以点/迭代计算速度。

Answer 8

跟踪源代码中的克隆数量（类似的代码片段）。

在发现克隆后立即通过重构代码来摆脱克隆。

Answer 9

平均函数长度，或者可能是函数长度的直方图，以获得更好的感觉。

函数越长，其正确性就越不明显。如果代码包含许多长函数，那么可能是一个安全的赌注，那里隐藏着一些bug。

Answer 10

类之间的相互依赖性。代码的耦合程度。

Answer 11

每次提交失败的测试数或破坏的版本数。

Answer 12

跟踪某个来源是否已经过审核，如果是，那么是什么类型。然后，跟踪已审核代码与未审核代码中发现的错误数量。

这将允许您根据发现的错误确定代码审核流程的运行效率。

Answer 13

我特别喜欢并使用Mary Poppendieck recommends的系统。该系统基于三个整体测量，必须作为一个包（所以不，我不会提供3个答案）：

1. 周期时间
   • 从产品概念到首次发布或
   • 从功能请求到功能部署或
   • 从错误检测到解决方案
2. 商业案例实现（没有这个，其他一切都无关紧要）
   • P＆amp; L或
   • 投资回报率或
   • 投资目标
3. 客户满意度
   • e.g。 Net Promoter Score

我不需要更多知道我们是否与最终目标同步：为用户提供价值，并且快速。

Answer 14

如果你正在使用Scrum，那么积压。每次冲刺后有多大？它是否以一致的速度萎缩？或者由于（a）未被考虑开始的东西（“我们需要另一个没有人想到的审计报告的用例，我只是将其添加到待办事项中”而被推入积压的东西。 “）或（b）没有完成任务并将其推入积压工作以满足日期而不是承诺的功能。

Answer 15

http://cccc.sourceforge.net/

Fan in and Fan out是我的最爱。

扇入： 有多少其他模块/类使用/了解此模块

扇出： 该模块使用/知道多少个其他模块

Answer 16

  

改善时间估算

虽然Joel Spolsky的基于证据的计划本身并不是指标，但它听起来就像你想要的那样。见http://www.joelonsoftware.com/items/2007/10/26.html

Answer 17

每当QA团队报告错误时 - 分析开发人员为什么缺少单元测试。

将此视为永久性的自我改进练习。

Answer 18

我喜欢缺陷解决方案效率指标。 DRE是软件发布前解决的缺陷与发现的所有缺陷的比率。我建议将每个版本的软件的这些指标跟踪到生产中。

Answer 19

上述大多数指标都很有趣，但无法帮助您提高团队绩效。问题是您在开发论坛中询问管理问题。

以下是一些指标：项目进度级别和个人级别的估算/ vs /实际值（参见Joel基于证据的方法的上一个链接），发布时删除了％缺陷（请参阅我的博客：http://redrockresearch.org/?p=58） ，范围蔓延/月和整体生产力评级（普特南的生产力指数）。此外，开发人员的带宽也很适合衡量。

Answer 20

质量保证中的跟踪指标在很长一段时间内一直是一项基本活动。但是，开发团队通常不会完全了解这些指标与业务的所有方面的相关性。例如，典型的跟踪指标（如缺陷率，有效性，测试效率，代码覆盖率等）通常根据软件的功能方面进行评估，但很少关注它们对软件业务方面的重要性。 / p>

还有其他指标可以为软件的业务方面增加很多价值，这在查看软件的整体质量视图时非常重要。这些可大致分为：

1. 业务分析师，营销和销售人员捕获的测试版用户的需求
2. 产品管理团队定义的最终用户要求
3. 确保软件在峰值负载下的可用性以及软件与企业IT系统集成的能力
4. 支持大量交易
5. 安全方面取决于软件所服务的行业
6. 与竞争对手相比，必备且易于使用的功能的可用性
7. 还有一些......

Answer 21

改善我团队的软件开发过程

重要的是要了解指标无法改善团队的软件开发过程。它们可用于衡量您在改进开发过程方面的进展情况，以衡量您使用的特定指标。也许我正在讨论语义，但你表达它的方式是大多数开发人员讨厌它的原因。听起来您正在尝试使用指标来推动结果，而不是使用指标来衡量结果。

换句话说，您是否愿意拥有100％的代码覆盖率和糟糕的单元测试或出色的单元测试和＆lt; 80％的报道？

你的答案应该是后者。你甚至可以想要完美的世界并拥有两者，但你最好先关注单元测试，然后让覆盖范围到达那里。

Answer 22

类似的行数。 （复制/粘贴代码）

Answer 23

也许您可以测试CodeHealer

CodeHealer对源代码进行深入分析，寻找以下方面的问题：

• 审核质量控制规则，例如未使用或无法访问的代码， 使用指令名称和 关键字作为标识符，标识符 隐藏其他同名的人 更高的范围等等。
• 检查潜在错误，例如未初始化或未展示 标识符，危险类型铸件， 自动类型转换，未定义 函数返回值，未使用 分配的值等等。
• 指标量化代码属性，例如圈数 复杂性，对象之间的耦合 （数据抽象耦合），评论 比率，班级数，线数 代码等等。

Answer 24

如果你正在使用Scrum，你想知道每天Scrum的用途。人们是否完成了他们所说的完成工作？

就个人而言，我很擅长。我长期在我的日报上跑过来。

Answer 25

代码覆盖百分比

Answer 26

源代码控制的大小和频率提交。