敏捷方法论中的软件度量

Question

敏捷方法现在相当普遍，但我似乎找不到关于哪些指标最有用以及原因的文档。我发现更多的事情说，一些传统的指标，如LOC和测试的代码覆盖率不合适，留下两个主要问题：

1. 为什么这两个（和其他）指标不合适？
2. 哪些指标最适合敏捷以及为什么？

即使使用敏捷流程，您不想知道您的单元测试有多少代码覆盖率吗？或者仅仅是这个指标（和其他指标）不像那样像其他指标一样有用，比如圈复杂度和速度？

Answer 1

敏捷是一种面向业务的事物，敏捷是最大化客户价值，同时最大限度地减少浪费以提供最佳的投资回报率。这是应该测量的。为此，我使用了Mary Poppendieck recommends的系统。该系统基于三个整体测量，必须作为一个包：

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

当然，在团队层面，您可以跟踪诸如测试覆盖率，圈复杂度，符合编码标准等内容，但高质量本身并不是目的，它只是一种手段。不要误解我，我不是说高质量不重要，高质量是实现可持续发展的必要条件（我们在“完成定义”中包括“不增加技术债务”）但目标仍然是以快速且有利可图的方式为客户创造价值。

Answer 2

无论采用何种方法，都可以并且应该使用一些基本指标 根据{{​​3}}，最重要的是以下三个：

• 产品尺寸
• 在测试的最后阶段发现的缺陷数
• 和现场发现的缺陷数量。

如果你跟踪的是这些，至少有五种方法可供使用：

• 计算产品缺陷率（A）
• 计算测试缺陷率（B）
• 确定A的理想目标并监控效果
• 确定B的理想目标并监控效果
• 评估A和B之间的相关性
• 如果找到相关性，则形成测试有效性的度量（B / A * 100％）

尽管阅读不一定有趣，但S. Kahn提供了出色的深入软件工程和指标概述。

Answer 3

1.1）LOC很容易回答

• 他们真的依赖于您使用的语言！在JAVA或Ruby上编写时，相同的功能可能会有很大的不同，例如

• 一个编写得不好的软件可能比一个好的软件更多！

1.2）代码覆盖率

• 恕我直言，您应该使用指标，虽然它不完美，但它应该让您对代码需要更多测试的位置有一个很好的理解。

• 这里你应该注意的一点是它也依赖于语言。在某些情况下，你有一个你真的不需要测试的类或方法！例如，只有getter和setter的类。

2）从（1）您刚刚提到代码指标，但从您关于速度的问题判断，您对所有创建过程的指标感兴趣，所以我会列出一些：

• Velocity：经典之作，如果使用得当，它可以很好地提升敏捷团队的表现，因为你会知道你的团队在固定时间内可以做些什么。

• 烧毁并烧毁图表：他们可以很好地了解团队在互动过程中的表现（冲刺）

InfoQ上有一些关于此的文章。 Here和here。

Answer 4

至于问题1，我认为这些指标在敏捷过程中没有任何原因。

LOC为您提供相对尺寸测量。虽然比较项目之间的数字可能并不总是有用，但它可以为您提供项目内的增长率。如果你能得到它，那么在sprint中改变的行数也可以用来跟踪速率或重构。

代码覆盖率（代码行）使您可以了解您的团队是否在项目中满足最低限度的自动化测试条件。

关于问题2，请保留上面的项目，这里还有一些：

• LOC与测试计数。如果可以，请为单元，集成和系统测试维护单独的比率。
• 每个故事的平均接受标准数与测试方案（或测试）。它可以帮助您更好地了解您是否根据故事的意图进行测试。
• 发现的缺陷数
• 发现的工作量（这通常由敏捷跟踪软件捕获）不是原始估算的一部分。它将帮助您判断您是否正在进行“足够”的计划。
• 追踪速度冲刺与冲刺的一致性或缺乏一致性
• 虽然可能不受欢迎且可能存在潜在危险，但跟踪估算工作已为每位开发人员完成。虽然团队应该是自我组织和驱动的，但并非所有团队都能够处理人类问题。

Answer 5

只是添加

为什么测试的LOC和代码覆盖率不太理想：

敏捷强调结果，而不是输出（参见敏捷宣言）。这两个只是跟踪输出。此外，他们没有正确地衡量重构，这是敏捷过程的一个重要方面。

要考虑的另一个指标是运行经过测试的功能。我无法描述这个：http://xprogramming.com/articles/jatrtsmetric/

Answer 6

我将回答这个非常古老的问题......

在我看来，LOC和测试覆盖率是很好的指标，但它们有一个很大的问题：如果你推动它们，你可以让它们快速增长，但结果将是严重的：大量无意义的代码，或者在测试覆盖率，您可以在try-catch块中调用所有代码，而不是编写单个断言...或者更糟糕的是，只需编写一个用于＆＃34;合规性＆＃34;原因，但没有任何面向业务或代码面临的意义......

所以，如果这些指标能够帮助团队诚实地评估他们的结果，那么这些指标非常好，但如果他们构成了某些合规性的一部分，那么它们就是一个邪恶的工具。规则，因为以这种方式使用它们会导致更多的伤害（死代码，错误的测试！），而不是你原本想要实现的目标。

因此，对于每个指标，如果您被迫达到某个值，请考虑如何欺骗它，并考虑后果......这不是LOC或测试覆盖的问题，许多其他指标可能有类似的结果，甚至是圈复杂度...如果你以错误的方式划分你的代码，你可以减少圈复杂度，但这并不意味着你会得到更好或更易读的代码！

因此，这些指标非常适合查看团队内部发生的情况，但您采取的任何措施都应基于具体目标，而不是指标本身...例如：

测试覆盖率很低：您每月执行一次编码dojos以帮助培训人员编写可测试的代码，您会发现哪些代码的测试覆盖率最差，并尝试实现更好/更可测试的架构，以帮助/激励开发人员写测试等。

正如您所看到的，您永远不会告诉团队达到一定的测试覆盖率，您只需使用指标来查看可以改进的地方，然后在您期望测试一段时间后查找有利于您的流程的措施报道增加，但你不是在推动人们这样做！您正在评估更改，以查看这些措施是否有帮助。如果经过一段时间后您发现测试覆盖率没有随着您的措施而改变，那么现在是时候寻找其他想法了，等等...