背景介绍

在软件行业中，优化软件交付组织并不是一个简单的标准化过程。因为可度量的指标太多，将产生大量的度量数据。要让组织分析这些数据并基于其采取行动是一项困难的任务，而这却是整个优化过程最重要的一步。如果组织中的人不基于度量数据采取行动，那么基于数据驱动的组织优化也就不会发生。

为了进一步推动这一领域的发展，2020 年以来的“数据驱动的决策制定”系列文章提供了一个框架，指明如何通过数据驱动决策制定来支持软件交付中的三个主要活动——产品管理、开发和运营。从那时起，有很多团队在使用这个框架来实现组织优化方面获得了数年的经验。在本文中，我们将介绍一个优化软件交付组织的社会技术框架是如何被建立起来以及如何进行常规应用的。

选择度量维度

在软件交付组织中，有太多可度量的东西，可以是容易计数的纯数学度量，例如一段时间内的缺陷数量，也可以是难以量化的社会技术过程度量，例如中断持续时间（发生中断的开始和停止时间）。

无论度量的是什么，只有当人们基于它们采取行动时，它们才是有效的。如果不定期采取措施来分析度量数据，并根据分析结果在组织中做出改变，那么度量过程就成了可避免的浪费。

在一个给定的组织中，人们可能很难就优化软件交付的度量维度达成一致。一个可能的指导原则是只度量组织可能愿意基于其采取行动的东西。可采取的行动包括确定优先级、过程变更、组织变更、工具变更和资本投入。

近年来，一些度量方法变得流行起来。例如，使用指标来度量软件交付过程的稳定性和速度，因为它是以对软件交付性能驱动因素的多年科学研究为基础，因此很受欢迎。

另一个例子是度量可靠性。在这方面，越来越多运行大规模服务的组织在采用，它基于 SLI、SLO 和相应的错误预算消耗跟踪来度量可靠性。

在度量价值方面，软件行业中已经出现了一些可为团队提供行动见解的指标。这与收益价值流里的价值指标不同。一些组织为此使用了假设驱动开发或（北极星）框架。到目前为止，还没有出现能够在这一领域占据主导地位的框架。

正如 2020 年的文章“数据驱动的决策制定——优化产品交付组织”所描述的，我们决定对价值、速度、稳定性和可靠性进行度量。到了 2022 年，我们增加了另一个衡量维度：云成本。为什么我们决定测量这些维度，而不是其他维度？答案如下表所示。

基于度量数据采取行动的意愿
我们向医疗保健领域的数字服务提供商提供订阅服务。这是一个新的市场。这可以度量订阅服务给客户带来的价值（而不仅仅是成本），让我们能够使用新的价值趋势反馈循环来引导产品开发。	产品所有者有为订阅客户提供更多价值的意愿，从而减少订阅流失和增加新的订阅。
我们的成本取决于使用Microsoft Azure所产生的经常性成本。了解团队、产品、产品线、业务单元和成本中心的云成本，为各个利益相关者提供云成本的透明度，从而做出明智的决策。	预算负责人和财务部门可以将云成本合理地分配给相关产品线和成本中心。此外，在没有事先达成协议的情况下，愿意保持在分配的预算范围内，不让云计算成本膨胀。
产品所有者和开发团队能够每2到4周发布一次特性。
在提升特性交付的速度时，部署稳定性就变得非常重要。更高的特性交付频率需要更高的部署稳定性（而不是反过来），因为需要部署的特性变得越来减小。	开发团队非常愿意使用零停机时间部署等技术，用客户注意不到的方式来部署特性。
为用户提供可靠的数字服务对于留住长期的订阅用户来说至关重要。可靠性度量为生产环境中的整体服务可靠性提供了透明度。	开发和运营团队提高可靠性的高度意愿。

到目前为止，我们没有打算度量其他维度，这有几个方面的原因。

总而言之，虽然我们也可以引入其他度量维度，但当前的这些度量维度似乎足以用来驱动一个合理的整体持续改进。

建立度量系统

我们建立的度量系统涉及数据驱动决策的三个主要层次：团队、中层管理和高层管理。

对于上述的每一个度量维度，我们设置了三个指标粒度：团队级指标、产品级指标和产品线级指标，如下图所示。

每一个度量维度生成的数据可以被视为一种三轴立方体。

这使得整个产品交付组织能够按照适合手头需要解决的问题的粒度来处理数据。数据集的示意图如下所示。

例如，分析交付速度的产品经理（上图中的蓝色立方体）可以基于产品级指标来查看所有相关产品的交付速度数据。他们也可以更进一步，基于产品线级指标来查看总体的速度数据。如果产品经理有技术背景，他们还可以基于团队级指标来更详细地查看速度数据。分析的结果可能会导致技术特性的优先发生变化，从而加快产品的交付，而更快的交付速度意味着可以找到更适合产品市场的产品。

同样，分析可靠性的团队架构师（上图中的红色立方体）可以基于团队级可靠性指标来查看其团队所拥有的所有服务的可靠性。然后，他们也可以查看他们所依赖的其他团队的服务的可靠性（也是基于团队级可靠性指标）。在考虑使用新产品时，他们可以先查看过去汇总的产品级可靠性数据（产品级可靠性指标）。如果产品级可靠性是合理的，他们就可以深入了解组成产品的单个服务的可靠性（团队级可靠性指标）。根据分析结果，可能需要与产品所有者进行数据驱动的对话，调整可靠性特性和面向客户的特性之间的优先级。

同样，由产品主管、开发主管和运营主管组成的领导团队可能会分析云成本数据。他们可以从查看产品线的成本数据开始，分析成本趋势，并将它们与相应的价值趋势联系起来。对于成本趋势与价值趋势反向相关的产品线，领导团队可以深入了解产品级成本和价值数据。根据分析结果，可能需要与各自的产品经理就新产品的预计盈亏平衡点和成熟产品的收入趋势进行对话。

建立行动过程

要基于上述跨组织孤岛和级别的度量数据采取行动，需要建立专门的过程。对于团队、中层管理人员（产品经理、开发经理、运营经理）和高层管理人员（“负责人”角色）来说，这个过程是不一样的。我们发现下面的这些方法在我们的组织中很有用。

通常是3个月，有时更频繁	一个专门的一小时会议，团队查看所有可用的度量维度（例如可靠性、速度、稳定性、云成本和价值），一起执行数据分析并制定行动项。
在scrum或类似的讨论中分析速度和稳定性数据，讨论相关的流程变更，并准备与其他角色进行改进对话。
基本上是每月，与SRE误差预算周期对齐	在运维评审或类似的讨论中分析可靠性数据，找出相关SLI（可用性、延迟、新鲜度等）始终较低的服务，并准备与服务所有者团队进行改进对话。
在管理会议和讨论中使用相关数据点进行组合对话。

关于团队级数据分析周期的说明：尽管许多团队选择每 3 个月查看一次指标数据，但有些团队更频繁地查看某些指标。具体来说，有时每天都要查看云成本数据，特别是当团队在通过优化架构或设计来降低云成本时。此外，当团队在大型重构后进行稳定性工作时，有时候每周都会查看构建和部署稳定性数据。

优化组织

在本小节中，我们将提供一个示例来说明我们如何利用在不同组织级别发生的数据驱动决策来优化组织的交付速度。

交付速度是一个非常重要的度量维度，因为每个人都希望能够更快地交付特性。在开始时，我们所有的团队都非常渴望加快交付速度。在某个时刻，我们引入了速度指标并趋于成熟，这在整个组织层面形成了如下所述的数据驱动工作流：

管道环境之间的交付时间变得更加透明。例如，在由以下环境组成的管道中

构建代理 -> Accept1 -> Accept2 -> 沙箱 -> 生产环境

这5种环境之间的4个平均交付时间一目了然：

构建代理 -> 时间 -> Accept1 -> 时间 -> Accept2 -> 时间 -> 沙箱 -> 时间 -> 生产环境

这为拥有管道的团队提供了一个新的视觉反馈循环，让他们可以知道代码在环境之间移动的速度。团队可以通过减少测试套件的运行时间来优化速度。

产品和开发经理可以从分析中得出以下结论：

合规性所需的文档基本上是手工完成的，而实现半自动化是可能的，这促使整个组织决定在这方面进行投入。

几年后，生成合规性框架所需的发布文档的手动工作量大大降低了，这为加快整个组织的交付速度铺平了道路。

总结

从整体上优化软件交付组织是一项复杂的工作，可以通过三种粒度的度量指标——团队级、产品级和产品线级指标来为其提供很好的支持。这为团队、组织的中层管理人员和高层管理人员提供了数据驱动的决策制定。建立专门的流程来分析数据，并在这三个层面采取行动，有助于组织进行整体的持续改进。

作者简介：

Vladyslav Ukis 博士毕业于德国埃尔兰根-纽伦堡大学（计算机科学专业）和英国曼彻斯特大学。毕业后，他加入 Siemens Healthineers，从事软件架构、企业架构、创新管理、私有云和公有云计算、团队管理、工程管理、投资组合管理、合作伙伴管理和数字化转型等方面的工作。他目前担任 Siemens Healthineers 团队数字健康平台的研发主管。他在 2022 年出版的“Establishing SRE Foundations”（Addison Wesley 出版社）一书中分享了他的 DevOps 知识：原文链接：