软件工程团队速度的 5 个有形指标
介绍
首先，既然我们要讨论度量的话题，那么无论如何，软件工程团队表现良好意味着什么？出于本文的目的，让我们将给定软件工程团队的以下指标作为基本指标：
开发速度（尽量最大化）
错误数量（尽量减少）
这个模型显然过于简化了，但是，为了保持这篇文章的简短，我们将在本文中使用它。此外，我们在这里专注于技术角度。业务和工程的一致性对于成功至关重要，但是，这是另一篇文章的主题。
既然我们已经定义了要优化的基本指标，那么我们如何实际衡量它们呢？
测量错误的数量相当容易。我们可以从字面上计算团队每单位时间产生的错误数量，例如每月的错误数量。然而，发展速度并非易事。
为什么 Scrum 故事点可能是一个糟糕的指标
可能会想到的第一件事是 Scrum 故事点。这里的问题是，如果有人想使用这个指标，你会假设 A) 故事的评估有点精确，B) 故事的评估不会随着时间的推移而改变（相似的故事得到相同的分数）。根据我的经验，这两个假设都是高度推测性的。故事点可以在某种程度上用作衡量标准，但它们还不够，也不能描绘出完整的画面。此外，一些团队无论如何都没有使用它们。
同时，你无法改进你没有衡量的东西。要知道您正朝着正确的方向前进，您需要一些具体的、希望易于理解的指标。
建议的指标
事不宜迟，这里有 5 个简单的指标，初创公司、规模扩大公司，甚至更大的公司都可以用来衡量其软件工程团队的开发速度：
代码审查保持开放的天数——代码是软件工程团队的主要输出，代码审查是代码编写方式的美丽日志。您可以查看代码审查的速度。
为新开发人员配置开发环境所需的天数——随着时间的推移，团队欢迎新成员，因此如果您想加快速度，您可以考虑您的开发环境。为新团队成员配置它有多容易？
构建代码和运行测试所需的时间——测试的速度会影响您试验和开发的速度。
开发人员每天不间断编码的小时数——上下文切换 是一个严重的效率杀手，这里的数字越低可能是开发速度较慢的原因。
过去 6 个月团队中开发人员的流动——正如我们已经提到的，让工程团队处于绩效状态需要一些时间。如果开发人员没有长时间专注于给定的项目，团队的开发速度很可能会很低，因为每个新工程师只有在了解代码库和业务领域后才能变得富有成效。
结论
诚然，仅靠这些指标是不够的，它们实际上是开发速度的代理指标。题目比较复杂，需要综合考虑多方面的因素，才能做出更精准的评价。此外，根据给定环境的上下文正确解释指标也非常重要。过度仅依赖某些指标实际上可能会适得其反，因此采用整体方法很重要。
尽管如此，这些易于衡量的指标可能会在某些方面对软件研发团队的当前状态有所了解。更有趣的是，一旦进行了测量，人们就可以想出如何改进它们并看看会产生什么效果。
