我想跟踪可用于改进我团队的软件开发过程、改进时间估计和检测在项目执行期间需要解决的特殊情况变化的指标。
请将每个答案限制为一个指标，描述如何使用它，并对好的答案进行投票。
kchad
问问题
22509 次
26 回答
51
（来源：osnews.com）
于 2009-03-20T08:04:55.337 回答
13
投资回报率。
软件带来的总收入减去生产软件的总成本。按总成本的百分比细分成本，并根据投资回报率隔离表现最差和最昂贵的领域。如果可能，改进、自动化或消除该问题区域。相反，找到您的最高投资回报领域，并找到进一步扩大其影响的方法。如果 80% 的 ROI 来自 20% 的成本或努力，那么扩大该特定区域并通过比较将其余部分最小化。
成本将包括工资、许可证、法律费用、硬件、办公设备、营销、生产、分销和支持。这可以在整个公司的宏观层面上完成，也可以在团队或个人的微观层面上完成。除了收入之外，它还可以应用于时间、任务和方法。
这并不意味着忽略所有细节，而是找到一种方法来量化一切，然后专注于产生最佳（客观）结果的领域。
于 2009-03-19T22:51:21.967 回答
12
逆代码覆盖率
获取测试期间未执行的代码百分比。这与沙法所说的类似，但用法不同。如果在测试期间运行了一行代码，那么我们知道它可能会被测试。但是如果一行代码没有运行，那么我们肯定知道它没有经过测试。针对这些领域进行单元测试将提高质量，并且比审核已涵盖的代码花费更少的时间。理想情况下，你可以两者都做，但这永远不会发生。
于 2008-10-09T22:19:29.040 回答
11
“改进我团队的软件开发过程”：缺陷查找和修复率
这与针对已提交或验证的修复数量而引发的缺陷或错误的数量有关。
我不得不说这是非常重要的指标之一，因为它为您提供了两件事：
低修复率表明团队正忙于其他事情（也许是功能）。如果错误数量很高，您可能需要让开发人员解决一些缺陷。
低找到率表明您的解决方案非常出色且几乎没有错误，或者 QA 团队已被阻止或有其他关注点。
于 2008-10-10T14:34:26.567 回答
7
跟踪完成一项有估计的任务需要多长时间。如果他们的情况很好，请问为什么。如果他们已经结束了，问为什么。
不要让它成为一件消极的事情，如果任务爆发或被低估了也没关系。您的目标是不断改进您的估算过程。
于 2008-10-09T22:13:30.287 回答
7
速度：每给定单位时间的特征数量。
由您决定如何定义特征，但它们应该大致相同数量级，否则速度不太有用。例如，您可以按故事或用例对功能进行分类。这些应该被分解，以便它们的大小大致相同。每次迭代，弄清楚有多少故事（用例）被实现（完成）。特征/迭代的平均数量就是你的速度。一旦您根据您的功能单元了解您的速度，您就可以使用它来帮助估计基于其功能完成新项目需要多长时间。
[编辑] 或者，您可以为每个故事分配一个权重，如功能点或故事点，作为复杂性的衡量标准，然后将每个已完成功能的点相加并以点/迭代计算速度。
于 2008-10-09T22:13:36.837 回答
7
跟踪您发现的错误的来源和类型。
错误源代表引入错误的开发阶段。（例如规范、设计、实施等）
错误类型是错误的广义样式。例如。内存分配，不正确的条件。
这应该允许您更改在该开发阶段遵循的程序并调整您的编码风格指南以尝试消除过度表示的错误类型。
于 2008-10-10T01:15:09.187 回答
4
跟踪源代码中的克隆数量（类似的代码片段）。
一旦发现克隆，就通过重构代码来摆脱克隆。
于 2009-03-20T07:55:11.053 回答
3
平均函数长度，或者可能是函数长度的直方图，以获得更好的感觉。
函数越长，其正确性越不明显。如果代码包含许多长函数，那么可以肯定的是其中隐藏了一些错误。
于 2008-10-09T22:17:44.787 回答
2
如果您使用的是 Scrum，则为积压。每次冲刺后有多大？它是否以一致的速度收缩？或者是因为（a）一开始没有想到的东西（“我们需要另一个没有人想到的审计报告用例，我将它添加到积压中。 ”）或（b）没有完成工作并将其推入积压工作以满足日期而不是承诺的功能。
于 2008-10-10T10:21:55.853 回答
2
Fan in and Fan out are my favorites.
Fan in: How many other modules/classes use/know this module
Fan out: How many other modules does this module use/know
于 2008-10-10T10:37:37.397 回答
2
类之间的相互依赖。您的代码耦合的紧密程度。
于 2008-10-09T23:36:03.880 回答
2
每次提交失败的测试或损坏的构建数。
于 2008-10-09T22:15:32.263 回答
2
跟踪一个来源是否经过审查，如果是，是什么类型。然后，跟踪在已审核与未审核代码中发现的错误数量。
这将允许您确定您的代码审查过程在发现错误方面的运行效率。
于 2008-10-10T01:18:46.217 回答
2
改进时间估计
虽然 Joel Spolsky 的 Evidence-based Scheduling 本身并不是一个度量标准，但听起来正是您想要的。见http://www.joelonsoftware.com/items/2007/10/26.html
于 2009-03-19T22:20:23.463 回答
1
改进我团队的软件开发流程
重要的是要了解指标对改进团队的软件开发过程没有任何作用。它们只能用于衡量您在改进您正在使用的特定指标方面的开发过程的进展情况。也许我在争论语义，但你表达它的方式是大多数开发人员讨厌它的原因。听起来您正在尝试使用指标来驱动结果，而不是使用指标来衡量结果。
换句话说，你宁愿拥有 100% 的代码覆盖率和糟糕的单元测试还是出色的单元测试和 < 80% 的覆盖率？
你的答案应该是后者。你甚至可以想要一个完美的世界并拥有两者，但你最好先专注于单元测试，然后让覆盖率到达那里。
于 2008-10-10T14:25:05.617 回答
1
相似行数。（复制/粘贴代码）
于 2008-10-09T22:14:09.083 回答
1
上述大多数指标都很有趣，但不会帮助您提高团队绩效。问题是您在开发论坛中提出管理问题。
以下是一些指标：项目进度级别和个人级别的估计值/vs/实际值（请参阅 Joel 的基于证据的方法的先前链接），发布时删除的缺陷百分比（请参阅我的博客：http://redrockresearch.org/? p=58 )、范围蔓延/月和总体生产力评级（普特南生产力指数）。此外，开发人员的带宽很好衡量。
于 2009-06-28T06:52:31.677 回答
1
很长一段时间以来，在 QA 中跟踪指标一直是一项基本活动。但通常，开发团队并没有充分考虑这些指标与业务各个方面的相关性。例如，缺陷率、有效性、测试效率、代码覆盖率等典型的跟踪指标通常根据软件的功能方面进行评估，但很少有人关注它们对软件业务方面的重要性。
还有其他指标可以为软件的业务方面增加很多价值，这在查看软件的整体质量视图时非常重要。这些可以大致分为：
- 业务分析师、营销和销售人员捕获的测试版用户的需求
- 产品管理团队定义的最终用户要求
- 确保软件在峰值负载下的可用性以及软件与企业 IT 系统集成的能力
- 支持大批量交易
- 安全方面取决于软件服务的行业
- 与竞争对手相比，必备功能和必备功能的可用性
- 还有一些……
于 2011-09-19T12:02:51.643 回答
1
每次 QA 团队报告错误时 - 分析为什么该缺陷逃脱了开发人员的单元测试。
将此视为一种永久的自我改进练习。
于 2009-06-28T13:19:21.130 回答
1
我喜欢缺陷解决效率指标。DRE 是在软件发布之前解决的缺陷与发现的所有缺陷的比率。我建议将您的软件的每个版本都跟踪到生产中。
于 2010-06-13T15:38:37.673 回答
0
如果您使用 Scrum，您想知道每天的 Scrum 进展如何。人们是否完成了他们说他们会完成的事情？
就个人而言，我不擅长。我经常在我的日报上跑来跑去。
于 2008-10-10T10:18:45.313 回答
0
也许你可以测试CodeHealer
CodeHealer 对源代码进行深入分析，寻找以下方面的问题：
- 审核 质量控制规则，例如未使用或无法访问的代码、使用指令名称和关键字作为标识符、在更高范围内隐藏其他同名的标识符等等。
- 检查 潜在错误，例如未初始化或未引用的标识符、危险的类型转换、自动类型转换、未定义的函数返回值、未使用的分配值等。
- Metrics 量化代码属性，例如圈复杂度、对象之间的耦合（数据抽象耦合）、注释比率、类数、代码行数等。
于 2010-01-06T20:36:30.950 回答
0
代码覆盖率
于 2008-10-09T22:12:32.440 回答
-1
源代码控制提交的大小和频率。
于 2008-10-10T14:36:28.263 回答