敏捷方法中的软件度量

敏捷是面向业务的,敏捷是关于 客户价值最大化 同时尽量减少浪费 提供最佳的投资回报率 . 这是应该衡量的。为了做到这一点,我使用了Mary Poppendieck的系统 recommends . 该系统基于三个整体测量,必须作为一个整体:

1. 循环时间
   • 从产品概念到首次发布
   • 从功能请求到功能部署或
   • 从缺陷检测到解决
2. 业务案例实现(没有这个,其他一切都无关紧要)
   • 保洁公司或
   • 投资回报率或
   • 投资目标
3. 顾客满意度
   • 例如 Net Promoter Score

当然,在团队级别,您可以跟踪测试覆盖率、圈复杂度、与编码标准的一致性等,但高质量本身并不是目的,它只是一种手段。别误解我,我不是说高质量无关紧要,高质量是实现可持续发展的必由之路(我们在“完成”的定义中包括“不增加技术债务”),但目标仍然是以快速和盈利的方式为客户提供价值。

不管方法论如何,都有一些基本的度量标准可以也应该使用。
根据 S. Kahn ,最重要的是以下三点:

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

如果这些都是你跟踪的,至少有五种方法可以使用:

• 计算产品缺陷率(A)
• 计算测试缺陷率(b)
• 确定A的理想目标并监控性能
• 确定B的理想目标并监控性能
• 评估A和B之间的相关性
• 如果发现相关性,形成测试有效性度量(B/A*100%)

虽然读书不一定有趣, Metrics and Models of Software Quality Engineering 提供了一个优秀的深入的软件工程和度量概述。

1.1)位置容易回答

• 他们真的依赖于你使用的语言!例如,在Java或Ruby上编写时,同一个特性可能会有很大差异。

• 一个写得不好的软件可能比一个好的软件有更多的行!

1.2)代码覆盖范围

• 我想您应该使用metric,尽管它并不完美,但它应该让您很好地理解代码需要更多测试的地方。

• 这里你要注意的一点是它也依赖于语言。可能有些情况下,您有一个类或方法,您真的不需要测试!例如,只有getter和setter的类。

2)从(1)您刚才提到的代码度量,但是从您关于速度的问题来看,您对所有创建过程的度量都很感兴趣,因此我将列出一些:

• 速度:经典的速度,如果使用得好,它可以很好地提高敏捷团队的性能,因为您将知道您的团队在固定时间内真正能够做什么。

• 燃尽和燃尽图表:它们可以让您很好地了解团队在交互过程中的表现(sprint)

infoq上有一些关于这个的文章。 Here 和 here .

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

loc为您提供了一个相对大小的度量。虽然在项目之间比较数字并不总是有用的,但它可以为您提供项目内的增长率。如果您可以得到它,那么在sprint中更改的行数对于跟踪速率或重构也很有用。

代码覆盖率(代码行数)让您大致了解您的团队是否满足项目中自动化测试的最低标准。

关于问题2,保留上面的项目,这里还有一些:

• loc与测试计数。如果可以,为单元测试、集成测试和系统测试保持单独的比率。
• 每个故事的验收标准与测试场景(或测试)的平均数量。它可以帮助你更好地判断你是否违背了故事的意图。
• 发现缺陷数
• 发现的工作量(这通常由敏捷跟踪软件捕获)不是最初估计的一部分。它将帮助你判断你是否做了“足够”的计划。
• 追踪速度冲刺到冲刺的一致性或缺乏一致性
• 虽然可能不流行,也可能有潜在的危险,但跟踪每个开发人员完成的工作估计数。虽然团队应该是自我组织和驱动的,但并不是所有的团队都能够处理人的问题。

只是为了增加

为什么测试的loc和代码覆盖率不理想:

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

另一个需要考虑的指标是运行经过测试的特性。我无法形容比这更好的: http://xprogramming.com/articles/jatrtsmetric/

我要回答这个老问题…

在我看来,loc和test coverage是很好的度量标准,但它们有一个大问题:如果你推动它们,你可以使它们快速增长,但结果会很可怕:大量的无意义代码,或者在测试覆盖率中,你可以将所有代码都包含在try-catch块中,而不是只编写一个asse。RT…或者更糟的是,只需要写一个“遵从”的理由,但没有任何面向业务或代码的含义…

因此,如果这些指标能够帮助团队诚实地评估其结果,那么它们是非常好的,但是如果它们构成了一些“遵从性”规则的一部分,那么它们就是一个邪恶的工具,因为以这种方式使用它们会造成更多的伤害(死代码,糟糕的测试!)比你最初想要的要多。

所以,对于每一个指标,想想如果你被迫实现某个值,你会如何欺骗它,然后想想结果……这不是loc或测试覆盖率的问题,许多其他度量可以有类似的结果,甚至圈复杂度…如果以错误的方式划分代码,可以降低圈复杂度,但这并不意味着可以获得更好或更可读的代码!

所以,这些指标很好地反映了团队内部的情况,但是你采取的任何措施都应该基于具体的目标,而不是指标本身……例如:

测试覆盖率很低:每月实现一次dojo编码,以帮助培训人们编写可测试代码,找出测试覆盖率最差的代码,并尝试实现更好/更可测试的体系结构,以帮助/激励开发人员编写测试,等等。

正如您所看到的,您从来没有告诉团队实现某个测试覆盖率值,您只是使用度量来查看您可以改进的地方,然后寻找有利于您的过程的度量,在一段时间后,您会期望测试覆盖率增加,但您并没有强迫人们这样做!您正在评估更改,以查看这些措施是否有帮助。如果一段时间后你发现测试覆盖率并没有随着你的度量而改变,那么是时候寻找其他的想法了,等等……