度量体系,帮助团队_一些对我的团队有帮助的质量指标

度量体系,帮助团队

有人问我“提高软件质量的最佳指标是什么？” （或类似的）一百万次，此博客文章是一个自私的省时工具，您可能正在阅读本文，因为您问了我一个类似的问题，然后将您发送到这里。

首先，我不喜欢指标，我认为推荐的软件质量指标中有99％是纯垃圾。 话虽如此，但有一些指标可以帮助与我合作的团队，这些是我将分享的指标。

其次，应该使用指标来推动变化。 我认为，跟踪的指标与跟踪指标的原因明确相关是至关重要的，这样人们就不会只关注数字，而是会关注观察数字将带来的好处。

良好的指标＃1：为了能够进行重构，而不必担心破坏我们已经建造的产品，我们决定将单元测试的覆盖率提高到> 95％并对其进行测量。 如果不遵守该指标，构建将失败。

良好的指标＃2：为了降低代码复杂性，提高可读性并简化更改，我们设置了一个限制并测量了每种方法的最大大小（15行）和循环复杂性（不记得数字了，但我认为是是<10）。 如果不遵守该指标，构建将失败。

良好的指标＃3：为了持续交付低复杂性，易于测试的工作单元并帮助实现可预测性，我们开始测量用户故事从创建到生产的整个周期时间，目标是保持3到5天。 当我们获得了超过5天的用户故事时，我们回顾并检查了原因。

在上述3种情况下，重点是目标，数字是我们认为将推动变化并且可以随时更改的数字。

如果人们不理解为什么要编写单元测试，那么他们将在不保证重构能力的情况下实现单元测试覆盖，例如通过编写没有断言的假测试。 我们永远不要将度量标准与我们测量某物的原因脱钩。

对我来说，这些是不错的指标。 如果您想看到一些不好的东西，请看我前一段时间写的这篇关于对抗性指标和交付团队的文章，这些文章并没有对他们的客户造成任何伤害。

http://mysoftwarequality.wordpress.com/2012/12/27/the-wrath-of-the-mighty-metric/

翻译自: https://www.javacodegeeks.com/2014/09/some-quality-metrics-that-helped-my-teams.html

度量体系,帮助团队