敏捷方法在现今相当流行，但我似乎找不到很多有关哪些指标最有用以及为什么的文档。我发现许多东西都说一些传统的指标如代码行数和测试覆盖率是不合适的，这就留下了两个主要问题：
- 为什么这些指标（和其他指标）是不合适的？
- 哪些指标最适合敏捷，以及为什么？
即使使用敏捷过程，你难道不想知道你的单元测试有多少代码覆盖率吗？还是说这些指标（和其他指标）只是不像圈复杂度和速度等其他指标那样有用呢？
6个回答
3
敏捷是一种以业务为导向的事物，它旨在通过将浪费降至最低，并提供最优回报来 最大化客户价值。这是应该被衡量的。为了做到这一点，我使用玛丽·波彭迪克推荐的系统。这个系统基于三个全面的度量，必须作为一个整体来考虑：
- 周期时间
- 从产品概念到第一个发布或
- 从功能请求到功能部署或
- 从漏洞检测到解决方案
- 业务案例实现（如果没有此项，其他所有内容都无关紧要）
- P&L 或
- 投资回报率或
- 投资目标
- 客户满意度
- 例如净推广得分
当然，在团队层面上，您可以跟踪测试覆盖率、圆形复杂度、符合编码标准等方面，但高质量本身并不是一个目标，它只是一种手段。不要误解我，我并不是在说高质量不重要，高质量对于实现可持续步伐是必要的（我们的“完成定义”中包括“没有增加技术债务”），但目标仍然是以快速和有利可图的方式向客户交付价值。
- Pascal Thivent
2
无论采用何种方法，都应该使用一些基本的度量标准。根据S. Kahn的说法，最重要的三个指标如下：
- 产品大小 - 在测试的最后阶段发现的缺陷数量 - 在实际使用中发现的缺陷数量
如果这些是你跟踪的所有内容，那么至少有五种方式可以使用它们：
- 计算产品缺陷率（A） - 计算测试缺陷率（B） - 确定A的理想目标并监测其性能 - 确定B的理想目标并监测其性能 - 评估A和B之间的相关性 - 如果发现相关性，则形成测试效果的度量标准（B/A * 100%）
虽然不一定有趣可读，但《软件质量工程的度量和模型》提供了极好的深入软件工程和度量概述。
- 产品大小 - 在测试的最后阶段发现的缺陷数量 - 在实际使用中发现的缺陷数量
如果这些是你跟踪的所有内容，那么至少有五种方式可以使用它们：
- 计算产品缺陷率（A） - 计算测试缺陷率（B） - 确定A的理想目标并监测其性能 - 确定B的理想目标并监测其性能 - 评估A和B之间的相关性 - 如果发现相关性，则形成测试效果的度量标准（B/A * 100%）
虽然不一定有趣可读，但《软件质量工程的度量和模型》提供了极好的深入软件工程和度量概述。
- JRL
1
1.1) LOC 很容易回答
它们真的取决于您使用的语言！例如，在JAVA或Ruby上编写相同的功能可能会有很大的差异。
一个编写不好的软件可能比一个好的软件有更多的代码行数！
1.2) 代码覆盖率
在我看来，你应该使用度量标准，虽然它并不完美，但它应该能够让你了解你的代码需要更多的测试的地方。
这里只有一个要注意的点是，它也取决于语言。有些情况下，您可能有一个您真的不需要测试的类或方法！例如，一个只有getter和setter的类。
2) 从（1）中，您刚提到了代码度量标准，但从您关于速度的问题来看，您对整个创建过程的度量标准感兴趣，因此我将列出一些：
速度：经典的方法，如果使用得当，可以很好地提高敏捷团队的绩效，因为您将知道团队在固定时间内真正能做到什么。
燃尽图和燃尽图表：它们可以让您对团队在交互（冲刺）期间的表现有一个良好的概念。
- Diego Dias
0
关于问题1，我不认为这些指标在敏捷过程中会有任何问题。
LOC为您提供相对大小的测量。虽然在项目之间比较数字可能并不总是有用的，但它可以为您提供项目内增长率。如果您能获得它，每个迭代中更改的行数也可能很有用，以跟踪重构速率。
代码覆盖率（代码行数）让您大致了解团队是否在项目中达到最低自动化测试要求。
至于问题2，保留上述内容，以下是一些其他建议：
LOC为您提供相对大小的测量。虽然在项目之间比较数字可能并不总是有用的，但它可以为您提供项目内增长率。如果您能获得它，每个迭代中更改的行数也可能很有用，以跟踪重构速率。
代码覆盖率（代码行数）让您大致了解团队是否在项目中达到最低自动化测试要求。
至于问题2，保留上述内容，以下是一些其他建议：
- 代码行数（LOC）与测试数的比较。 如果可以，请保持单元测试、集成测试和系统测试的不同比例。
- 每个故事的验收标准平均数量与测试场景（或测试）的比较。 这有助于更好地了解您是否正在根据故事的意图进行测试。
- 发现的缺陷数量
- 发现的工作量（这通常由敏捷跟踪软件捕获），这不是最初估计的部分。它将帮助您判断您是否做足了规划。
- 跟踪速度冲刺到冲刺的一致性或缺乏一致性
- 虽然可能不受欢迎且可能存在潜在危险，但跟踪每个开发人员完成的工作量的估算。 尽管团队应该是自组织和自我驱动的，但并非所有团队都能够处理人类问题。
- Jim Rush
0
只是要补充一下
为什么 LOC 和测试代码覆盖率不是理想的指标：
敏捷开发强调结果，而不是产出（请参见敏捷宣言）。这两个指标仅跟踪产出。此外，它们没有正确地衡量重构，这是敏捷过程的重要方面。
另一个要考虑的度量标准是运行测试功能。我无法更好地描述它：http://xprogramming.com/articles/jatrtsmetric/
- geowa4
0
我将回答这个非常古老的问题...
在我看来，LOC和测试覆盖率是很好的指标，但它们有一个大问题：如果你强制要求它们增长得快，结果会令人恐惧：大量无意义的代码，或者在测试覆盖率中，你可以在try-catch块中调用所有的代码而不编写任何assert...甚至更糟糕的是，只为“合规”原因编写一个，但没有任何面向业务或代码的含义...
因此，如果这些指标能够帮助团队诚实地评估他们的成果，那么这些指标就非常好，但如果它们成为某些“合规”规则的一部分，那么使用它们会造成更多的伤害（死代码、糟糕的测试！）比你最初想要达到的目标还要糟糕。
因此，对于每个指标，都要考虑如果你被迫达到某个特定值，你会如何欺骗它以及后果...这不是LOC或测试覆盖率的问题，许多其他指标也可能有类似的结果，甚至包括圈复杂度...如果你以错误的方式划分代码，你可以减少圈复杂度，但这并不意味着你会得到更好或更易读的代码！
因此，这些种类的指标非常好，可以看到团队内部发生了什么情况，但您采取的任何措施都应基于具体目标，而不是指标本身...例如：
测试覆盖率较低：您每月实施编码道场来帮助培训人员编写可测试代码，找出哪些代码覆盖率最差，并尝试实施更好/更可测试的架构，以帮助/激励开发人员编写测试等。
正如您所看到的，您从未告诉团队要达到某个特定的测试覆盖率值，您只是使用该指标来查看您可以改进的地方，然后寻找有利于您过程的措施，在一段时间后，您预计测试覆盖率会增加，但您并没有推动人们这样做！您正在评估变化以查看措施是否有所帮助。如果在一段时间后，您发现测试覆盖率没有随着您的措施而改变，那么就是时候寻找其他想法了，依此类推...
- Martin
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接