写点什么

软件交付优化:数据洞察下的智慧决策

作者:Vladyslav Ukis

  • 2023-08-04
    北京
  • 本文字数:3335 字

    阅读完需:约 11 分钟

软件交付优化:数据洞察下的智慧决策

数据驱动的决策制定”系列文章概述了数据驱动的决策制定是如何为软件交付中的三个主要活动——产品管理、开发和运营提供支持的。

 

背景介绍

 

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

 

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

 

选择度量维度

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

度量维度

选择这个维度的理由

基于度量数据采取行动的意愿

度量框架

价值

我们向医疗保健领域的数字服务提供商提供订阅服务。这是一个新的市场。这可以度量订阅服务给客户带来的价值(而不仅仅是成本),让我们能够使用新的价值趋势反馈循环来引导产品开发。

产品所有者有为订阅客户提供更多价值的意愿,从而减少订阅流失和增加新的订阅。

北极星框架

云成本

我们的成本取决于使用Microsoft Azure所产生的经常性成本。了解团队、产品、产品线、业务单元和成本中心的云成本,为各个利益相关者提供云成本的透明度,从而做出明智的决策。

预算负责人和财务部门可以将云成本合理地分配给相关产品线和成本中心。此外,在没有事先达成协议的情况下,愿意保持在分配的预算范围内,不让云计算成本膨胀。

FinOps

速度

更快的特性交付可以减少库存成本,缩短发布时间,降低测试自动化债务和缩小部署自动化差异。

产品所有者和开发团队能够每2到4周发布一次特性。

DORA

稳定性

在提升特性交付的速度时,部署稳定性就变得非常重要。更高的特性交付频率需要更高的部署稳定性(而不是反过来),因为需要部署的特性变得越来减小。

开发团队非常愿意使用零停机时间部署等技术,用客户注意不到的方式来部署特性。

DORA

可靠性

为用户提供可靠的数字服务对于留住长期的订阅用户来说至关重要。可靠性度量为生产环境中的整体服务可靠性提供了透明度。

开发和运营团队提高可靠性的高度意愿。

SRE

 

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

 

  1. 我们已经可以使用当前的五个度量维度来优化组织,并给客户和业务带来积极的影响:优化订阅价值,让订阅给客户带来更多价值。特性的优先级更多的是由价值进行驱动的。优化云成本让我们的业务案例变得更加强大。团队在设计软件架构时将云成本考虑在内。优化部署速度有助于快速找到适合市场的特性。团队可以适当地进行特性分解、设计松散耦合的架构、进行测试自动化、部署自动化等。优化部署稳定性有助于在频繁更新的同时提供良好的用户体验。团队努力实现零停机部署、API 向后兼容性等。优化可靠性有助于在整个订阅期间始终保持良好的用户体验。团队努力实现有效的监控和事故处理。

  2. 我们已经看到,优化当前的这些度量维度隐式地推动了组织其他方面的改进,例如:团队努力实现松散耦合、测试自动化和部署自动化。更重要的是,他们不断寻找方法来优化这些领域的部署管道,这在软件交付组织中有组织提供了一系列用于自动化创建合规性文档的工具,提升持续合规性遵循能力。这些工具会在每次部署管道运行时自动运行。助于形成一种非常健康的工程文化。团队定期更新第三方框架和库依赖项。除了需要更频繁地进行安全渗透测试,我们还没有看到这些度量对安全和数据隐私实践造成什么影响。

 

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

 

建立度量系统

 

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

 

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

 


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

 

  • X 轴:指标粒度团队级指标;产品级指标;产品线级指标。

  • Y 轴:度量维度价值;云成本;稳定性;速度;可靠性。

  • Z 轴:组织级别团队;中层管理(产品经理、开发经理、运营经理);高层管理(“主管”角色)。

 

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

 


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

 

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

 

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

 

建立行动过程

 

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

 

组织级别

数据分析周期

过程描述

所使用的指标粒度

团队

通常是3个月,有时更频繁

一个专门的一小时会议,团队查看所有可用的度量维度(例如可靠性、速度、稳定性、云成本和价值),一起执行数据分析并制定行动项。

团队和产品级指标

产品管理

基本上是3个月

同上。

产品级指标

开发管理

基本上是两个月

在scrum或类似的讨论中分析速度和稳定性数据,讨论相关的流程变更,并准备与其他角色进行改进对话。

产品级指标

运营管理

基本上是每月,与SRE误差预算周期对齐

在运维评审或类似的讨论中分析可靠性数据,找出相关SLI(可用性、延迟、新鲜度等)始终较低的服务,并准备与服务所有者团队进行改进对话。

产品和团队级指标

高层管理

通常是4到6个月

在管理会议和讨论中使用相关数据点进行组合对话。

产品线和产品级指标

 

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

 

优化组织

 

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

 

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

 

团队级别

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

 

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

 

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

 

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

 

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

中层管理级别

产品发布时间变得更加透明。以产品X为例:

 

2021年:Release1 -> 时间 -> Release2 -> 时间 -> Release3

2021年:Release1 -> 时间 -> Release2 -> 时间 -> Release3

2022年:Release1 -> 时间 -> Release2 -> 时间 -> Release3 -> 时间 -> Release4

 

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

  • 产品X没有进行更频繁发布的管理层原因是什么?例如,到目前为止,功能分解还没有达到团队能够逐步实现和发布一小部分功能所需的粒度。功能太大了,需要更大的版本和更低的发布频率。
  • 产品X没有进行更频繁发布的技术原因是什么?例如,紧密耦合的架构和手动测试套件。
  • 产品X没有进行更频繁发布的项目原因是什么?例如,项目管理与组织设定的发布节奏根本没有预见到一年内会有更多的发布。

高层管理级别

产品线和产品发布时间变得更加透明。产品主管和开发主管看到了发布节奏和每个发布所带来的管理负担之间的联系。他们在产品线和监管部门之间发起项目来重新评估组织的监管框架。

 

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

 

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

 

总结

 

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

 

作者简介:

Vladyslav Ukis 博士毕业于德国埃尔兰根-纽伦堡大学(计算机科学专业)和英国曼彻斯特大学。毕业后,他加入 Siemens Healthineers,从事软件架构、企业架构、创新管理、私有云和公有云计算、团队管理、工程管理、投资组合管理、合作伙伴管理和数字化转型等方面的工作。他目前担任 Siemens Healthineers 团队数字健康平台的研发主管。他在 2022 年出版的“Establishing SRE Foundations”(Addison Wesley 出版社)一书中分享了他的 DevOps 知识:https://www.informit.com/store/establishing-sre-foundations-a-step-by-step-guide-to-9780137424658

 

原文链接

https://www.infoq.com/articles/software-delivery-performance-indicators/


相关阅读:

范珂:数字化时代下,数据驱动决策组织文化的打造

首席数据官:数据驱动时代的大势所趋


2023-08-04 10:242389

评论

发布
暂无评论
发现更多内容

2021 InfoQ 写作平台年度优质企业号评选名单公布!

InfoQ写作社区官方

2021年度评选 热门活动

k8s daemonset controller源码分析

良凯尔

源码 Kubernetes 源码分析 源码解析 #Kubernetes#

synchronized的使用及优化

Ayue、

synchronized

【MongoDB学习笔记】手把手教你配置Python操作MongoDB

恒生LIGHT云社区

数据库 mongodb #python

Springboot如何使用Aspect来实现切面日志

@零度

Java springboot aspect

云小课|云小课带你快速掌握云数据迁移CDM

华为云开发者联盟

EI智能体 数据湖治理中心 云数据迁移 CDM

【CSS 学习总结】第三篇 - CSS 选择器的权重和优先级

Brave

CSS 12月日更

语音信号处理6:语音信号的线性产生模型

轻口味

28天写作 12月日更

Linux之head命令

入门小站

Linux

Java 中接口和抽象类的 7 大区别!

王磊

API治理技术实践-上

中原银行

中原银行 API治理

这18个网站能让你的页面背景炫酷起来

德育处主任

前端 视觉化 样式 前端特效 css特效

阿里云李飞飞:国内首部云原生数据库教材《云原生数据库:原理与实践》

博文视点Broadview

能源互联,激荡十年

钛禾产业观察

能源互联网 新能源

如何在 K8s 集群中使用 Nocalhost 开发 APISIX Ingress

API7.ai 技术团队

Kubernetes 网关 Nocalhost Apache APISIX Ingress Controller

百度智能云实战——静态文件CDN加速

百度Geek说

后端 H5 移动开发

一个支持断点续传的大文件分片上传的小模块

为自己带盐

dotnet 28天写作 文件上传 12月日更

又双叒叕获奖了!OceanBase 荣获2021年度技术卓越奖&年度最佳创新企业奖

OceanBase 数据库

新闻动态 OceanBase 开源 获奖 IT168

给弟弟的信第21封|遇事不决问搜索引擎

大菠萝

28天写作

Gitee Premium完成与OceanBase开源数据库适配

OceanBase 数据库

OceanBase 开源 开源中国 自主研发

为何建议大家升级到Kafka2.5.x?

Kafka中文社区

盘点 2021|前端女程序员普通的一年

小月

盘点2021

PassJava 开源 (四):整合MyBatis-Plus实现CRUD

悟空聊架构

mybatis 28天写作 passjava 悟空聊架构 12月日更

Kafka的Topic和Partition是不是有个数限制?

Kafka中文社区

低代码实现探索(八)后台模型api

零道云-混合式低代码平台

《Nacos架构与原理》官方电子书发布啦!

捉虫大师

nacos

前端开发之多环境下react的配置

@零度

前端开发 React

推出Amazon Kinesis Data Analytics Studio —— 与流数据快速交互

亚马逊云科技 (Amazon Web Services)

分析

dart系列之:和null说再见,null使用最佳实践

程序那些事

flutter dart 程序那些事

模块七作业:王者荣耀商城异地多活架构

危险游戏

架构实战营

焱融科技与趋动科技携手解决一站式存算难

焱融科技

云计算 分布式 云原生 高性能 文件存储

软件交付优化:数据洞察下的智慧决策_数字化转型_InfoQ精选文章