有九大指标可以对软件开发团队带来巨大改变

Steven A. Lowe is a Product Technology Manager at Google. He is a software developer, architect, entrepreneur, public speaker, musician, and author of "Head- First Domain-Driven Design (O'Reilly, 2018).

Prior to working at Google he was a Principal Developer and Consultant at ThoughtWorks. All opinions expressed are Steven's alone.

（查看英文链接：https://techbeacon.com/app-dev-testing/9-metrics-can-make-difference-todays-software-development-teams）

“选择指标需要相当多的思考和关注，以便能够支持企业真正需要回答的具体问题”。关键点在于：度量应被设计为回答业务问题的方法。而这些问题永远不会是“我们现在有多少KLOC？”

本文首先讨论的问题是：每个团队都应该开始使用（或者至少计划尽快使用）具体指标，这是显著提高绩效的方法。虽然本文的标题声称“有9个指标可以带来改变......” ，但真正想要发挥作用，还是需要这些指标实际用于提高业务价值的方式。是否能够提高，这取决于你。其次，本文将解释如何组合这些指标，来创造有价值，且可以衡量和测试商业价值假设。

以下是您应该持续监控的九个客观指标，从而对你的流程和生产环境进行渐进式改进。数字上的改进并不能保证您的客户满意度水平会突飞猛进， 但至少这些是正确的衡量标准。在本文的后面部分，你会明白为什么。

敏捷过程度量

对于敏捷和精益流程，基本指标包括前置时间（lead time）、周期时间（cycle time）、团队速度（team velocity）和缺陷开/闭率。这些指标有助于规划及为有关流程改进的决策提供信息。虽然它们不能衡量成功或价值的增值，而且它们也与软件的客观质量无关，但无论如何都应该测量它们。我将在下面解释原因。

• 需求交付时间（Lead time)——从创意到交付软件需要多长时间。如果您希望对客户做出更快的响应，可以通过简化决策制定和缩短等待时间来缩短交付周期。需求交付时间包含周期时间。

• 周期时间（cycle time）——您对软件系统进行更改并将该更改投入生产环境需要多长时间。使用“持续交付模型”的团队，可以在几分钟甚至几秒内（而不是几个月）就可以得到周期时间这个数据。

• 团队速率（team velocity）——团队通常在一个迭代（或叫做Sprint）中，完成多少个“单位”数量的软件。此数字仅应用于计划迭代。团队间的速度对比通常是无稽之谈，因为该度量基于非客观估计。将速率视为“是否成功”的衡量标准是不合适的，并且将特定的速度转化为目标会扭曲其估值和计划的价值。

• 缺陷开/闭率（Open/Close ）——在特定时间段内，报告和关闭的生产问题数量。总体趋势比具体数字更重要。

当任何指标超出预期范围或在警报方向趋势时，都不应该猜测它产生的原因。请与团队交谈，了解整个故事过程，并且，应该让团队来决定“他们是否有理由担心它”。如果团队真的担心它，再讨论如何解决。

你无法从数字中了解或假设它产生的根本原因，但这些指标可让您深入了解基本流程需要注意的地方。例如，在几次迭代中，缺陷单高创建率和低关闭率可能意味着生产问题目前的优先级低于新功能，或者可能是团队专注于减少技术债务以解决这类问题， 或者唯一知道如何解决这些问题的人辞职了，或休假了。你是无法从数字中知道或假设它产生的根本原因。

生产分析

• Mean time between failures (MTBF)

• Mean time to recover/repair (MTTR)

这两个指标用于衡量你所开发的软件在当前生产环境上的表现。

• 应用的崩溃率（application crash rate）——应用程序崩溃的次数除以使用次数。该指标与MTBF和MTTR相关。

请注意，上面三个指标都不会告诉你，有关受影响的个别功能或用户的信息。尽管如此，这三个数字越小越好。现代的操作监控软件可以非常轻松地收集各个程序和事务的详细指标，但是需要花费时间并仔细考虑为警报和/或触发器设置适当的范围以进行扩展或缩小（对于基于云的系统）。

我们希望我们的软件永远不会失败，但这基本上是不可能的。当我们的软件失败时，我们希望它永远不会丢失任何关键数据并立即恢复，但这可能很难实现。然而，假如这个软件是你的收入来源，那么这种工作负担是值得的。

除了MTBF和MTTR之外，更细粒度的测量基于单个事务或应用程序等。它们反映了交付的业务价值，和修复故障的成本。对于有事务处理的应用程序来说，如果在一百次中崩溃一次，但在一两秒内就恢复，而且没有丢失任何关键信息，那么1％的崩溃率可能已经足够好了。但是，如果是一个每天运行100,000笔交易的应用程序，每次崩溃都会损失100美元的销售额，并且在后面需要花费50美元进行修复，那么1％的崩溃率可能会成为高优先级的事情。修复它会显著影响收入底线。

安全指标

安全性是软件质量的一个方面，往往被忽视，直到后期也关注（有时甚至为时已晚）。除了更专业的评估和压力测试之外，还可以在构建过程中使用安全性分析工具。安全要求通常很简单，且常识性很强，但软件开发团队需要注意它们以及从中获取的指标。

全面的安全实践和相关指标超出了本文的范围，但与敏捷流程指标和生产指标一样，有一些特定指标可能对客户的整体满意度有很大帮助。

• 端点事件（Endpoint incidents）——有多少端点（移动设备、工作站等）在指定时间段（周期）经历过病毒感染？

• MTTR (mean time to repair)——在安全指标中，这是发现安全漏洞和部署的工作补救措施之间的时间。与上面提到的生产MTTR度量一样，应该在特定时间间隔内跟踪安全MTTR。如果MTTR值随着时间的推移变小，那么开发人员就会越来越有效地理解安全问题，例如错误以及如何修复它们。

对于这两个指标，随着时间的推移，较小的数字意味着您正朝着正确的方向前进。较少的端点事件不言而喻。随着MTTR值越来越小，开发人员越来越有效地理解安全问题，以及如何修复它们。

您可以在《敏捷项目的应用程序安全性》和《安全威胁模型：敏捷简介》一文中找到更多将安全度量标准应用于软件开发的方法。

关于源代码度量的说明

今天，很容易将源代码扫描器放入部署流水线，并生成大量客观指标。关于这些指标的相对重要性，有经验平均值和建议的范围和逻辑论证。实际上，这些工具在执行编码样式，标记某些反模式以及识别异常值和趋势方面最有帮助。

没有必要在数字上过于纠结。以下是一个例子，作为解释。

假设您在一个类中找到了一个方法，这个方法的NPATH复杂度为5200万。这意味着需要5200万个测试用例才能完全运用代码中的每条路径。也就是说，你可以将代码重构为更简单的结构，但在此之前，请考虑业务影响，这个老且丑陋的代码运行得很好（尽管其测试覆盖率可能不足）。通过它向团队强调这是一种反模式，以便他们可以避免重复这种错误，是一种有价值的学习，但修复它可能不会影响任何相关的商业指标。

最好是团队能在其代码所遵循的合规级别和规则方面达成共识。但要注意检查异常值和关注趋势分析，否则，也可能会浪费大量时间。

放在一起就是：成功才是最终的目标

使用自动化工具跟踪和衡量质量指标和用户分析的乐趣在于，它可以腾出时间专注于真正重要的指标：成功指标。

企业有自己的目标。目标也暗含着问题，例如“成功是什么样的？”或“这将如何影响客户行为？”恰当量化的问题就意味着指标。

换句话说，指标应仅用于回答问题，以检验支持特定业务目标的假设。只要问题和答案有助于推动积极变化，就应该这样做。

现在，难道不是所有项目都有一些不变的目标、问题和假设，因此才制定一些指标的吗？

是的，但仅限于业务的角度。用户参与度、收盘率、创收等业务层面的衡量指标可以提供有关业务在现实世界中的表现的反馈。对影响业务的软件的更改也会影响这些类型的指标。

在更精细的分辨率下，每个特征和用户故事可以具有其自己的成功度量 —— 最好只有一个，而且它与递送给客户的价值度量直接相关。对于从未提供过的功能，在一个迭代中，完成了十分之九的故事，但却无法交付的特性，是一种浪费，而不是成功。提供客户不想要或无法使用的故事是浪费，而不是成功。提升用户幸福度的一些故事是成功的。提供一个明显无法提高用户参与度的故事也是成功的，因为您将学到一些不起作用的东西，使业务假设无效，并释放资源以寻求其他途径。

价值假设是关于您认为由于特定功能的交付而将会发生什么的声明。软件，期望结果和度量之间的关系形成了特征（或系统，故事或升级等）的价值假设。该假设应该表达预期的目标指标如何变化，在什么时间范围内，以及多少被认为有效。您必须至少与团队和产品所有者交谈，以确定此功能或故事旨在为业务创建或改进的具体内容，以便制定其价值假设。你可能不得不问几次“为什么”（比如三岁）来剥离未说明的假设；耐心点。当您了解业务价值应该是什么时，您就可以开始询问能够引导您回答问题的指标的问题。

例如，为了提高电子商务结账流程的速度，一个“用户”故事可能包含以下假设：更快的结账流程会带来更多的销售。但为什么我们会这么想呢？是很多人在结账过程中放弃了购物车吗？如果这是共识（因为该共识得到了基线数据的支持），那么价值假设可能是“我们认为更快的结账流程将导致购物车放弃率下降，从而带来更高的销售额和改善的用户体验。”

你可以假设用户喜欢更快速的结账流程，但继续追问他们一下“是否注意到结账速度提升了”，也没有什么坏处。在新流程到位之前和之后，可以在一段时间内记录购物车页的弃单率和销售额。如果购物车弃单率下降且销售额增加（超出统计波动），则说明我们刚刚的这个需求证实了我们前面的假设，你可以考虑是否有必要进一步提高速度。如果不是这样的话，就将结账流程的速度这一指标先放一放，将注意力转向下一个假设。如果购物车弃单率降低但销售额不变，则可以观察更长的时间段，或重新考虑购物车放弃与销售之间的假设关系。换句话说，使用指标来学习，只要它们证明对推动改进有用。

在某些情况下，有些假设可能显然是错误的。因此，我们会在几天后删除指标（并回退对软件的改动！）。如果假设是正确的，我们就可以继续推动指标的改善。

我们已经看到主观的软件指标对于商业成功的重要性远远超过了传统的客观质量指标。获得见解和学习机会的工作量超过了发现和衡量功能相关业务指标所需的工作量。商业环境和机会不断快速变化。因此，与其总结一个非常不靠谱的公式，不如通过下面六个经验法则或启发式方法来帮助保持专注和灵活性。愿它们帮助您指导您获得高质量的软件和商业成功之旅！

• 指标不能告诉你整个故事；只有团队可以。

• “雪花的比较”是一种浪费。

• 你可以度量几乎任何事，但你无法关注每一件事。

• 只有业务成功的指标才能驱动软件改进，没有其它方法。

• 每个特性都有价值；要么度量它，要么就别做。

• 只衡量对现在来说重要的事情。

乔梁老师开课啦~视频课程《持续部署实战解析（Golang版）》， 限时特价！

（扫码订阅）

​