寻找软件开发中外部、内部和流程质量的适当指标

要点

质量有不同的领域，它们属于不同的利益相关者。外部质量由产品人员（例如产品负责人、测试人员）拥有，内部质量由开发人员拥有，过程质量由管理者拥有.
衡量质量可能会产生严重的副作用：当被欺骗时，或者当人们过度关注质量时，其他重要的事情可能会达不到要求。绩效衡量也会降低人们的创造力并阻碍协作.
找到副作用很小或没有副作用的指标是可取的，但并不总是可能的。有时添加一个指标可能会很有用，它可以抵消其他指标的副作用.
一个好的指标应该始终回答一个有助于实现明确目标的问题，以便在出现其他问题或目标发生变化时可以对其提出质疑和调整.
几个常用的质量指标并没有回答最相关的问题，还有许多鲜为人知的指标却更充分.

PO：“嘿伙计们，我们需要尽快添加这个新功能！它将带来我们需要的收入增长."
开发人员：“但是我们需要时间重构代码!"
测试人员：“并正确测试它!"
PO：“嗯……需要多少时间?"
开发人员：“嗯……三周?"
测试人员：“相反 4!"
"好的，我给你 2。到时候见."

听起来很熟悉?
在我的职业生涯中，我有过很多类似的讨论。我认为它们是更深层次问题的症状。功能的实现是可以衡量的：它就在那里。质量更难衡量。无论如何，我们需要多少质量？做什么的？哪些指标真正告诉我们质量?

为什么要衡量质量?

衡量质量的动机非常不同。人们通常会跳过指定测量目标的这一部分，因为他们认为自己已经知道了。我认为这是一个大问题，因为不同的目标可能会导致非常不同的问题，从而导致需要更多不同的指标.

衡量质量的风险

尝试衡量质量时存在两个相当严重的风险.

首先，有古德哈特定律, 这通常被引用为“当一项措施成为目标时，它就不再是一个好的措施”。在我的职业生涯中，我多次经历过这条法则。例如，当我的团队的表现是通过速度来判断时，我们的估计就会逐渐上升。我们甚至不想作弊，这只是因为我们下意识地不想向团队之外的任何人证明降低速度是合理的。还有一次，我们被要求将遗留代码库的代码覆盖率提高到 85%。结果，测试套件中添加了很多毫无价值的测试，使得代码更难维护。在这两个示例中，意图都是好的，但我们最终得到了毫无意义的估计和严格的测试套件，这使得更改变得不必要的困难.
在选择质量指标时，我们应该了解古德哈特定律。使用好的指标作为错误群体的目标很容易导致糟糕的结果.

第二个风险是测量对协作产生负面影响。质量指标可以很容易地理解或用作绩效指标。现在，当我的表现得到衡量时，我会更加谨慎地对待我的时间和资源。即使我的团队的整体表现得到衡量，我们也不太可能帮助其他团队。这肯定会损害整体性能.

出于同样的原因，创造力可能会受到影响。当我感到被监视和评判时，我会避免潜在的失败。但创造性的工作——比如软件开发——通常需要实验，而根据定义，实验可能会失败.

丹尼尔·平克 (Daniel Pink) 在《Drive》中描述，外在动机（如绩效衡量）实际上会对从事创造性工作的人产生负面影响.

因此，我们需要非常小心，不要选择被视为绩效指标的指标，以避免这些负面影响!

如何找到好的指标

要找到好的指标，有一种非常简单的目标导向方法，名为质量管理体系 (目标、问题、指标的缩写）。您可以在许多其他框架中找到这个基本思想.

基本思想是首先明确说明一个目标，例如。作为一个开发团队，我们想知道我们的代码质量是否足够好，以便我可以致力于新功能.

这个目标会带来很多问题，这些问题可能会导致指标提供（部分）答案.

这种方法的优点在于，我们可以安全地将一个指标替换为另一个能更好地回答问题的指标。或者当我们意识到某个问题与实现目标不再相关时删除指标。或者我们可以在目标需要调整后回顾我们的问题.

软件质量的领域

灵感来自 Dan Ashby 的“质量的 8 个视角”", 我提出了质量的三个基本领域:

外在品质: 优质用户和（作为代理）测试人员最关心.
这种品质对于整体成功显然非常重要。如果产品对用户没有吸引力，它可能根本不会成功.

内在品质: 这个质量领域不能被用户直接感知，但对于试图维护或改变产品的开发人员来说非常重要.
内在品质对于当前的成功来说并不是必要的。你可以创造出一款出色的产品，满足用户的所有愿望，但内在质量却很糟糕。然而，最终会出现新的要求、业务模式的转变，或者您想要应对的市场变化。内在素质差可能会让你做起来太慢.

工艺品质: 另一方面是创建、开发和维护产品过程的质量。流程质量对于管理者和利益相关者尤其重要.
影响流程质量的因素有很多：内在素质不好会对其产生巨大的影响，还会失去团队的重要成员，或者增加整体的工作量。组织重组的成功和失败应清楚地显示在流程质量指标中.

这三个域并没有明显的区别，但都有不同的所有者，主要负责和问责。例如，渴望取悦那些关心外部质量的高要求利益相关者的开发团队可能会破坏内部质量。最终，只有开发团队才能充分了解内在质量以及对产品可维护性的影响。另一方面，利益相关者可能知道内在质量最终很重要，但他们的首要任务是要求实施有吸引力的功能。因此，每当开发团队看到内在质量受到太大侵蚀时，他们就需要反对这些功能需求。利益相关者应该相信这种判断，因为最终外部质量会受到影响，当内部质量变得如此糟糕时，产品将变得无法维护.

外在品质

外部质量可能是最难衡量的方面。毕竟，这最终关系到人们如何看待产品，而人们的感知不仅仅受到产品本身的影响。为了回答这些问题，我尝试从测试人员的角度来判断产品是否应该投入生产，从用户的角度询问他们的意见，或者从产品经理的角度来决定进一步的开发.

产品的缺陷程度如何?

特别是对于测试人员而言，最常见的指标之一是 发现的缺陷数量. 这很有意义，因为有缺陷的产品可能不会被认为具有良好的质量.

然而，简单地取数成立测试期间的缺陷很容易被玩弄：不要测试。但即使你进行了测试，也很难判断你是否做得足够。即使您做了很多测试，您也可能花了很多时间来测试错误的东西.

我们可以通过将生产前发现的错误数量与生产中发现的缺陷数量进行比较来改进这一点。这奖励了彻底的测试，但很大程度上取决于生产中如何发现/报告缺陷.

我认为缺陷统计所回答的问题通常不是关于产品，而是关于测试过程。 “我的测试效果如何？” 是一个有效的问题，但它对外部质量有相当间接的影响.

检测缺陷的另一种方法是监控 服务水平目标（SLO) 如中所述站点/服务可靠性工程 (SRE). 基本思想是从用户/业务的角度回想软件组件。例如，我们可以简单地计算对用户的不良反应。 “坏”可能意味着显示错误消息，但也比要求的慢。我们可以简单地监控这些事情并发出警报。要么更接近用户，使测量反映实际的用户体验，要么更接近后端，以减少可能的根本原因并最大限度地减少实施工作。关于这项技术还有很多话要说，它当然不会取代测试，但我认为它是有关产品总体可靠性的非常客观和可持续的信息来源.

虽然 SLO 试图从用户的角度出发，但仍存在无法衡量正确事物或以错误方式衡量的风险。就像在测试中一样，我们可能有巨大的盲点.

将 SRE 视为产品中的产品，或者作为产品的附加固定要求。它需要不断的重新评估、调整和发展。许多组织可能会将这些努力视为开销，但由于它们使我们更接近于衡量产品当前的真实质量，我认为做出正确的决策是非常必要的。我认为几年后我们将很难记住没有 SRE 之类的东西我们是如何进行软件开发的.

用户喜欢这个产品吗?

外部质量的一个相当明显的标准是用户是否喜欢该产品.

如果您的产品有客户支持，您可以简单地计算 投诉数量 或联系人。此外，您可以对它们进行分类以获得更多信息。虽然这实际上需要付出很大的努力，而且远非微不足道，但它是一种非常直接的措施，可能会产生大量有价值的信息.

这里的一个问题是选择偏差. 我们只统计那些正在接触的人，忽略了那些还没有烦恼到打扰的人（但).

另一个类似的问题是生存偏差. 我们会忽略那些因错误而退出并且从不联系的用户.

这两种偏见都可能导致我们过度关注少数抱怨的问题，而我们应该进一步改进用户真正喜欢的产品.

除了这些问题之外，投诉率也可以被操纵：隐藏联系信息或增加队列等待时间，让联系客户支持变得非常困难.

为了获得更少偏见的反馈，我们还可以发送 反馈调查 给我们的用户。这种方法至少避免了对负面反馈的关注，但仍然存在一些选择偏差，因为并不是每个人都会花时间填写调查.

将反馈表扩展为烦人的工作，以令人困惑的方式提出问题，或将默认值设置为首选答案（请参阅默认效果) 这里也有很大的游戏潜力.

为了减少用户方面的工作量，我们可以依靠 平台评级 就像应用程序商店一样。这可能会降低选择偏差，但数字变得非常模糊，因为很难判断用户为什么留下一星或五星评级.

回答这个问题的另一个明显的方法是测量 新用户和/或回访用户的数量. 不过，这些数字可能具有欺骗性。营销活动通常会产生巨大的峰值，而实际的改进需要时间才能被用户注意到.

据我所知，没有任何衡量标准可以回答用户是否非常喜欢该产品的问题。尽管指出了它们的缺点，但上述可能是我们目前拥有的最佳选择.

但仅仅因为它很难，不应该成为我们根本不关心的借口。通过结合其中一些不完美的指标并牢记它们的缺点，我们仍然可以清楚地了解我们的用户是否喜欢我们的产品.

产品对用户来说效果如何?

因此，用户是否喜欢该产品的问题很难回答。可能更容易确定用户是否可以有效地使用它.

为了回答这个问题，我们可以促进 用户体验 (UX) 测试. 我们邀请实际用户使用该产品执行许多任务，同时我们仔细观察。这是回答这个问题的好方法！当然这里有一些游戏潜力。我们可以通过给出过于详细的指示、选择错误的任务、对参与者进行有偏见的选择或以某种方式影响用户以获得我们正在寻找的结果来破坏它。因此，成功地进行用户体验测试需要一些认真的专业知识、实践以及一些设置来保证适当的实验室条件.

根据我的经验，这些测试并不会经常发生，因为仅仅是为了促进它们而付出的努力。此外，它们产生了极其有价值的见解，但只有很少的可数指标.

更实用的方法可能是添加 用户跟踪/可观察性. 这通常是在靠近用户的地方完成的，例如通过复杂的跟踪库在前端完成。这些提供了非常有趣的见解，例如页面上点击/悬停次数最多的项目的热图。这很好，但没有必要。回答诸如“用户需要多少时间来执行 X？”、“有多少用户使用 X？”或“用户采取哪条路径来执行 X？”之类的问题。也可以通过简单的后端指标来回答.

用户跟踪/可观察系统可以通过不实施来简单地进行游戏。实现它、提供必要的基础设施或检查它的完整性并不是一件容易的事。然而，一旦到位，它可以用来获得非常紧急的不可预见问题的答案.

内在品质

对于内在质量，有大量的工具，它们充满了各种指标，但它们真的能回答我们最重要的问题吗？为了回答这些问题，我试图从开发人员的角度来考虑，他应该接管现有产品的进一步开发.

产品的可维护性如何?

在这种情况下，我想知道的第一件事就是它有多大？简单地看一下 代码行数 可能看起来有点愚蠢，但实际上这并不是最糟糕的主意。我可能需要了解每一行，因此它们的数量与我维护它的能力直接相关.

然而，代码行是一个危险的指标，特别是当开发人员积极优化代码并生成非常难以阅读的密集代码时.

更精致复杂指标如圈复杂度仍然很容易测量并很好地揭示压缩的复杂代码.

当我们向产品添加更多功能时，复杂性自然会增加，但我们应该不断检查增加的复杂性是否足以满足添加的功能.

产品可维护性的另一个重要驱动因素是其符合标准和良好实践。衡量这一点的一种流行方法是静态代码分析. 通过分析代码，我们可以很容易地识别出很多不好的模式，称为代码异味. 例如，不适合开发人员头脑的长方法和庞大类很快就会成为问题。强耦合使得不可能在不对其他地方进行相应更改的情况下更改部分代码，情况可能会更糟.

这些气味还有很多。一般来说，有臭味的代码更难处理。因此，它是内在品质的一个非常重要的方面。有很多工具可以自动测量气味，为我们提供不良代码的良好指示，但它们忽略了一些非常重要的方面，例如误导性或不一致的命名。因此，请记住，发现 0 次代码异味并不意味着该代码是完美的.

它对意外更改的防护效果如何?

更改代码是危险的。通过添加新功能，我们可以轻松破坏现有功能。单元测试是防止这种情况发生的一个非常好的做法，与此密切相关的指标是 代码覆盖率. 它只是单元测试期间执行的代码行数除以代码行总数.

然而，在测试期间执行一行的事实并不意味着检查了其效果。如果您采用代码覆盖率为 82% 的测试套件并从中删除所有断言，则覆盖率仍然完全相同!

最有价值的问题代码覆盖率答案是有多少行代码根本没有被检查?

回答我们实际问题的一个更好的工具是 突变测试. 它会改变程序的代码，例如，它将用“-”替换“+”，或者将某些整数变量设置为 0 或将某个对象设置为 null。然后它执行所有执行变异行的测试。如果这些测试中的任何一个失败，则该突变被视为被杀死。如果尽管发生突变，所有测试均成功，则视为存活。幸存突变的数量是一个比单独的代码覆盖率更好地回答我们最初问题的指标.

突变测试的缺点是它需要执行许多额外的测试，因此会导致反馈周期更长。因此，我建议仅在夜间构建中运行突变测试，并且如果可能的话，仅针对自上次运行以来实际更改的部分代码运行突变测试.

团队对产品的信心如何?

关于代码的一个被忽视的事实是，对于好的代码是什么样子，几乎没有一个全面的标准。您可以遵循的风格、模式和概念如此之多，但几乎没有两个开发人员对所有这些都达成一致。组织代码存储库的方法也有很多：如何以及记录什么内容，在哪里以及以什么方式记录.

一个团队最伟大的项目对于下一个团队来说可能会很糟糕，因为他们习惯了完全不同的风格.

这就是为什么从一支球队到另一支球队的交接从来没有想象中那么顺利的原因之一。通常代码是正式移交的，但是一旦要求新所有者自己进行简单的更改，就会出现很多悬而未决的问题，并且开发速度并不像以前的团队那么快.

我们可以通过以下方式缓解问题 (代码）样式检查器 和严格的指导方针，但根据我的经验，这些不能防止问题的发生，同时可能会严重阻碍流畅的开发.

简单地询问开发人员对项目的意见可能会非常有效，而不是非常不完美的自动化指标。简单的 团队调查 诸如“您使用代码的效率如何？”之类的问题（1 = 根本无效 - 4 = 非常有效），或者“您需要多少时间将一个简单的更改部署到生产中？” 可以给我们一个非常明确的答案，说明团队对产品的信心如何.

结合诸如“您需要什么来改进上述答案？”这样的问题，我们可以同时产生改善这种情况的想法.

我发现这个调查方法非常适合这个问题，因为团队对代码不自信的原因有很多：过去的开发压力、移交的代码、重大需求变更、失去重要的团队成员等等。 ..它总是会在调查中揭晓.

工艺品质

当一群经理找到我（质量人员）并要求验证他们想要为每个开发团队研究的指标列表时，其中大多数是内部质量指标。这让我有一种不好的预感。我非常确定这种监控会使指标成为目标，因此根据古德哈特的说法，这种监控将会被毁掉。幸好他们都在读书加速 (InfoQ 评论), 那本书中描述的基本指标（也称为 DORA 指标）似乎是解决他们问题的一个非常好的方法。他们希望防止因开发压力过大、团队人员不足或其他最终对流程有害的宏观管理决策而陷入问题。外部和内部质量的指标也可以用作过程质量的指标，但它们通常过于详细，我们可能无法看到更大的图景.

从书中的指标回溯，我们需要回答三个问题：“流程有多快？”、“流程的生产力如何？”和“流程的安全性如何？” 关于开发成本或效率的问题可能也很有趣，但通常与这两个问题直接相关.

过程有多快?

我在敏捷软件开发早期偶然发现的一个指标是速度. 它衡量团队在每个冲刺或时间范围内完成的故事点数量。故事点是团队对每个用户故事或功能进行估计的结果。因此，团队通过估计过程获得了指标的直接影响。由于估计完全是任意的，因此这是一个高度可玩的指标。即使团队并不是真的想作弊，一旦你开始通过速度来衡量团队的表现，估计值总是会上升。这种现象被称为故事点膨胀.

速度并不能真正回答这个过程有多快的问题。它回答了团队预测自身绩效的能力如何的问题。这并非完全没有价值，但如果用作性能指标则根本不起作用.

另一个非常相似的指标源自精益理论: 交货时间. 它通常测量流程启动和完成之间的时间。出于实际原因，我们可以定义该流程在开发团队完成第一次提交时开始，并在代码部署到生产时结束。所以基本上我们最终得到的是速度减去故事点.

更快的工作速度不仅会缩短/改善我们的交货时间，还会减少我们的交付成果的大小。然而，较小的可交付成果可以给我们更早的反馈，让我们的工作更加专注。这些都是很好的副作用！但我们也可以减少测试工作，这可能会导致生产质量下降。最终，这种糟糕的质量将导致事件和错误报告，这将再次破坏我们的交货时间，但显然交货时间不能成为我们的唯一目标.

该流程的生产力如何?

衡量生产力的一个流行指标是产能利用率. 它基本上是实际产出与潜在产出的比率。有几个类似的指标.
这在监控工厂中的机器时非常有意义。机器的容量是相当固定的。甚至维修停机时间通常也可以考虑在内。然而，当我们审视软件开发过程的生产力时，很多事情都不同了。最明显的是，计划外/计划外的工作更有可能发生，投资于工程师的知识和技能可能会在短时间内降低利用率，但可能会在以后带来生产力的大幅提升，而人根本不是机器。利用率下降很简单意味着一个好的产品团队只是等待最后一次更改的结果，并且有一些时间来整理和提高内部质量.

根据我个人的经验，当 100% 利用率是（隐含的）目标时，你实际得到的结果与生产力相反：要么人们假装 100% 做着无意义的忙碌工作，要么由于倦怠而导致产能大幅下降。也许两者可能同时发生.

我们可以关注而不是利用 批量大小, 这基本上是尚未交付给客户的正在进行中的事情的数量。在软件开发中，这些基本上是未部署到生产中的任何更改。因此，我们可以使用稍微容易测量的代理: 部署频率. 每当我们开始同时处理几件事时，结果就是在更长的时间内我们无法部署到生产中。要么我们只能在一切完成后进行部署，要么我们仍然有开放的分支需要最终合并.

在测量批量大小或部署频率时，部署到生产中的内容并不重要。它可以是一次大的重构，使下一个功能的开发更快，它可以是诊断功能的实施，使产品更容易观察并导致更好的决策，或者它可以是一个新功能.

玩弄这个指标的最简单方法是部署许多没有多大意义的微小变化。将实际工作切割成更小但有意义的部分并简单地减少正在进行的工作是更可能的副作用，这将大大提高性能和生产力.

该过程的安全性如何?

因此，为了使该过程更快，我们可以牺牲某些检查。也许我们应该这样做，但可能到了某个时候，我们会很快地交付缺陷而不是可用的软件。因此，我们还需要关心过程的安全性。衡量这一点的一种非常简单的方法是计算失败更改的数量并将其与更改总数进行比较： 变更失败率.

改善这个数字的最明显方法是在实际应用更改之前添加大量检查。这是完全有效的，但可能会增加批量大小和交货时间。如果检查是自动化的，仅在确实必要时才应用，并且保持简短但富有成效，那么变更失败率将会很低，而不会损害我们的性能指标.

试图防止失败当然是一件好事，但最后的一些风险往往相当持久。预防这些事件可能需要付出很大的努力，甚至可能（在经济上）是不可能的。因此，与其不惜一切代价防止这些故障，我们有时还可以投资于真正善于发现和修复它们。这 平均恢复时间 是衡量这一点的好方法。我们只是在出现问题时启动时钟，并在一切恢复正常后停止时钟.

这奖励了对监控、现代部署技术、（再次）小=低风险批量大小以及其他理想事物的投资。最糟糕的游戏是隐藏失败，但根据我的经验，这最终会以非常可靠的指标（例如收入）显示出来.

结论

根据我的经验，这三种品质都很重要.

外部质量可能是最明显的。但这很难衡量。我们倾向于衡量我们能做什么，而不是我们应该做什么。我们应该非常清楚我们的质量指标与实际有趣的问题有多远，并且理想情况下提出至少更接近的新指标.

为了回答产品对用户的效果如何，我们应该实施一些用户跟踪，最好以用户体验测试的结果为指导。为了发现缺陷并密切关注它们，我们还应该采用 SRE 并拥有一套像样的持续监控的 SLO，但也要密切关注用户的投诉，因为我们的监控可能存在一些漏洞。至于我们的用户是否喜欢该产品的问题，可能没有简单的衡量标准，我们应该意识到这一差距.

内在质量确实不缺乏衡量标准。静态代码分析让我们走得很远，但很容易迷失在所有这些数字中。但我们不应该声称这些数字中的任何一个代表了整体的内在品质。它们过于详细和固执己见，完全忽视了开发团队的能力。根据我的经验，衡量内在质量需要不断地审查测量结果，而这只能由开发团队自己完成。作为基线，代码复杂性和代码气味让我们很好地了解代码库的可维护性。突变测试让我们很好地了解代码功能的保护程度，并且通过添加偶尔的团队调查，我们还可以跟踪团队的整体信心.

但团队的工作绝不能用内部质量指标来评判，因为古德哈特定律不可避免地会导致不良的副作用.

流程的质量应该是管理者应该监控的。理想情况下，问题和指标不应要求开发团队以某种方式工作，因为这种方式很可能并不适合所有团队或产品。 DORA 指标非常适合此目的.

保持团队的灵活性并相信他们的判断可能是真正伟大的软件开发公司最重要的因素之一.

在任何测量中，我认为我们需要意识到我们想要回答的问题与指标实际回答的问题之间的差异。这些知识使我们最终能够找到更好的指标，或者找到额外的指标来抵消或至少减轻我们现有指标的负面影响.