本文要点：

持续交付是现代软件开发的标准技术。但是，持续交付的指标测量还不是很流行的做法。
Steve Smith在《衡量持续交付》中引入的持续交付指标，可用来从稳定性和速度方面衡量持续交付的表现。
将持续交付指标引入开发团队后，就可以针对部署管道思考新的改进方案，因为实体组装团队的价值流需要针对稳定性和速度来做优化。
持续交付指标提供了一个开发流程优化框架，开发团队可以在其中设置稳定性和速度目标，并跟踪进度。
在开发团队中引入持续交付指标需要搭配一个近实时的工具，用来透明地执行原始数据收集和指标计算的任务。

数据驱动决策系列文章概述了数据驱动决策如何支持软件交付中的三大活动——产品管理、开发和运营。

简介

软件产品交付组织需要愈加频繁地交付复杂的软件系统。软件交付工作涉及的主要活动包括产品管理、开发和运营（这里我们的确指的是活动，而不是在谈各个部门，后者是我们不推荐的说法）。在每项活动中，都必须快速做出许多决定以推进交付。在产品管理中，决策主要涉及功能优先级。在开发中，它关联的是开发流程的效率。在运营中，它主要针对的是可靠性。

可以根据团队成员的经验来做出决策。另外可以基于数据做出决策。这将带来更加客观和透明的决策流程。尤其是随着交付速度的提升和交付团队数量的增加，保持透明的组织就能让所有人无需耗时的同步会议，也可以一直走在同样的轨道上。

在本文中，我们探讨了持续交付指标中的数据如何支持开发工作中的活动，以及如何将这些数据用于快速的数据驱动决策。反过来，这会提高产品开发组织的透明度并削弱其官僚风气，最终就能取得更好的业务成果，例如用户对软件更高的参与度和更高的应计收益等。

我们报告了持续交付指标在西门子医疗公司开发活动中的应用案例，这是一个由分布于三个国家的16个软件交付团队组成的大型分布式软件交付组织。

流程指标，而非人员KPI

为了以数据驱动的方式引导开发活动，我们需要一种使用数据来表达开发工作中主要活动的方式。这种数据需要被视为正在发生的事情的流程指标，而不是用于员工评估的人员关键绩效指标（KPI）。这是很重要的，因为如果这种指标被用于员工评估，那么员工可能倾向于以对自己有利的方式来调整要评估的数据。

重点在于，产品交付组织的领导者要将这种数据视为流程指标，而不是评估员工KPI的方法，以实现稳定的数据质量和数据评估过程。

持续交付指标

开发工作中的主要活动是构建产品。在这种环境下，一旦知道了要构建什么产品，开发活动中的一个核心问题就变成了“如何高效地制造产品？”

通过分析软件开发团队的价值流，可以衡量开发流程的效率。价值流具体来说就是代码→构建→部署，可以在团队的部署管道上看到。

价值流中价值流动的速度是可测量的。同样，也可以测量价值流的稳定性。所谓的稳定性和速度这两大持续交付指标做的就是这些事情。这些指标是在Steve Smith的《测量持续交付》中定义的。

借助稳定性和速度这两大持续交付指标，团队就可以对自己的价值流和对应的瓶颈一目了然。他们可以找到最大的瓶颈并投入时间来消除它（与约束理论相一致）。

稳定性持续交付指标分为构建稳定性和部署稳定性。速度的持续交付指标分为代码吞吐量、构建吞吐量和部署吞吐量。（注意：Steve Smith将速度定义为变更的前置时间和变更间隔时间的组合。这是对Nicole Forsegren、Jezz Humble和Gene Kim在《加速》中只关注前置时间的定义的扩展。）应该为每个团队的部署管道持续生成所有指标，从而可视化团队的价值流。

构建稳定性指标包括构建失败率和构建失败恢复时间。

部署稳定性指标包括部署失败率和部署失败恢复时间。

代码吞吐量指标包括主分支提交前置时间和主分支代码提交频率。

构建吞吐量指标包括构建前置时间和构建频率。

部署吞吐量指标包括部署前置时间和部署频率。

所有这些指标都是越低越好（也就是更好的交付效率）。

构建稳定性指标：

构建失败率越低越好。
构建故障恢复时间越低越好。

部署稳定性指标：

部署失败率越低越好。
部署失败恢复时间越低越好。

代码吞吐量指标：

主分支提交前置时间越低越好。
主分支代码提交频率越高越好（但以两次成功提交之间的间隔来衡量，则间隔越小越好）。

构建吞吐量指标：

构建前置时间越低越好。
构建频率越高越好（以两次成功构建之间的间隔来衡量，则间隔越小越好）。

部署吞吐量指标：

部署前置时间越低越好。
部署频率越高越好（以两次成功部署之间的间隔来衡量，则间隔越小越好）。

这样以来，在图表上绘制持续交付指标时，就很容易将良好的行为与瓶颈区分开来。在图上接近X轴的位置代表良好的行为。图上较高的值都代表了团队价值流中的瓶颈。

也就是说，在显示持续交付指标的图表的帮助下，开发团队就可以轻松发现自身开发/测试/部署流程中的瓶颈，并制定数据驱动的优先级决策，以决定在哪些方面进行技术改进以提升开发/测试/部署流程的效率。。

使用持续交付指标来优化自身开发/测试/部署流程的团队，会精心选择最有用的领域进行技术改进投资，例如测试自动化、部署自动化、TDD流程改进和BDD流程改进等。不使用持续交付指标的团队可能不会投资改进自身的开发流程，或者只在发生重大故障后才进行投资，或者会根据团队中主要人员的意见来进行投资。

启用指标

在定义了持续交付指标之后，我们很清楚，只有在可以向团队提供足够支持的情况下，将其引入由16个开发团队组成的组织中才是有意义的。

我们开发了一款内部专属工具，可帮助开发团队轻松地查看自身价值流中的瓶颈。

该工具可以使用团队部署管道内的代码存储库、持续集成构建代理和部署环境中可用的信息来可视化团队的价值流。我们从Azure DevOps服务（例如Azure，Repos和Azure Pipelines）查询所有这些信息。我们改变了Azure DevOps默认的30天存储设置，改为保留365天的历史记录。

软件交付团队的目标是拥有稳定和快速的价值流。基于此，该工具将价值流分为两部分显示：价值流稳定性（在左侧）和价值流速度（在右侧）。

除了价值流可视化之外，该工具还可以自动执行价值流分析。它可以单独检测出价值流的稳定性和速度指标中的最大瓶颈，并以红色显示。这样，团队就可以立即集中精力解决瓶颈，而无需了解其他那么多的可用数据。

此外，该工具还能自动生成缓解瓶颈的建议。这些建议能够帮助团队解决价值流的稳定性和速度方面的最大瓶颈。

除了解决瓶颈的自动化建议之外，我们还希望将这款工具与团队的Slack频道连接起来。这样，团队就能在月底收到一份工具截图，其中概述了当月价值流的稳定性和速度表现。要获取更多详细信息的话，与截图一并提供的还有一个指向该工具的链接。

我们还将与所有团队一起举办小型研讨会，帮助他们熟悉如何将持续交付指标用于设定和追踪稳定性和速度目标。

采用

我们将持续交付指标引入了一个由16个开发团队组成的组织中，这些团队负责的是“teamplay"——这是西门子医疗团队提供的一项医疗领域的全球化数字服务（有关“teamplay”的更多信息，请参见《西门子医疗团队在teamplay中采用持续交付方法》）。

这项任务需要大量的解释工作，因为它引入了一种从价值流分析的角度来看待软件开发的新方法，而这在软件领域并不是常见的事情。这种新方法将部署管道视为价值流的载体或生产线，而价值流将针对稳定性和速度表现进行优化。

我们从与数据收集相关的团队收到了许多反馈，以确保原始数据是健全（sound）的。例如：

仅考虑主分支构建，而不考虑拉取请求构建
特别要包含拉取请求的前置时间，以了解拉取请求的审核等待时间是否存在瓶颈
除了跨所有管道环境累积的部署前置时间和部署间隔时间外，还分别为每个管道环境提供各自的指标
等等。

到现在，持续交付指标已深入到少数开发团队的工作中。有了持续交付指标工具中的可视化概述，团队非常高兴能第一次亲眼看到他们自身价值流（代码→构建→部署）的速度和稳定性表现。

这里的一个关键见解是，开发团队在工作时并不一定会知道价值在部署管道中的流动情况，也就是速度和稳定性的表现。也就是说，开发人员并不知道他们的工作方式如何影响他们的价值流。

持续交付指标工具提供了价值流的概览，并充当了开发团队开发流程的稳定性和速度表现的实时反馈回路。

有一支团队看到了他们的部署稳定性指标后，便意识到了频繁发生的部署失败，同时也注意到了非常快的部署失败恢复时间。接下来的几天内这支团队大大减少了部署失败次数。这里团队的意识是价值流改善的关键动力。改进本身并不难实现。

下面是一个示例，说明了团队如何大致了解其价值流的稳定性和速度表现，并进一步深入研究已确定的瓶颈细节。

团队价值流的稳定性和速度表现的概述。最大的瓶颈以红色显示：

这支团队价值流中发现的瓶颈有：

部署失败率
部署故障恢复时间（中位数）
主分支提交前置时间（中位数和标准差）
构建间隔时间（中位数）

下面显示了对"部署失败率"和"部署失败恢复时间"瓶颈的深入分析：

在"部署失败率"趋势上我们可以看到，从9月开始失败率一直在稳步上升，最近达到了近100％。同样，最近的"部署失败恢复时间"也大幅增加。这意味着部署管道最近几乎都是红色状态。这是团队要解决的最大瓶颈，消除它后才能让价值顺利地流向团队管道上的生产环境。

下面显示了"主分支提交前置时间"瓶颈的深入分析：

在“主分支提交前置时间”趋势上，我们可以看到与过去相比，最近几天的表现有所改善。因此这里的目标是保持现状。

下面显示了对"构建间隔时间"瓶颈的深入分析：

在“构建间隔时间”趋势上，与过去相比，最近几周我们也看到了良好的改进。在这里，目标同样是保持现状。

优先级

我们的团队需要更多关于持续交付指标的经验，以便始终如一地使用手头的数据作为优先级决策的输入。数据分为多种形式：

大多数/中间/最不稳定的管道，表现为
- 失败率
- 恢复时间
最快/中间/最慢的管道，表现为
- 管道环境之间的前置时间
- 环境中各个活动之间的间隔时间

既然有了数据，开发团队（尤其是产品所有者）就必须考虑这些数据，以做出最佳的优先级决策。优先级决策的权衡包括：

投资功能以提高产品效率和/或
根据CD指标数据投资提升开发效率和/或
投资提升服务可靠性

未来的话题

或许我们可以使用机器学习技术，基于部署管道上先前环境中的稳定性和速度数据来预测管道环境中的稳定性和速度表现。这是我们将来可以探索的内容。

此外，我们可能会根据CD指标数据自动在某些管道环境中实施部署。

总结

总而言之，如果团队使用持续交付指标来优化其开发流程，那么该团队便能够以数据驱动的方式逐步优化其工作方式。随着时间的流逝，团队就可以达到一种状态，也就是他们可以有效地构建功能，而不会在价值流中遇到较大的瓶颈。

最后，持续交付指标旨在为持续改进通用软件交付流程提供一种数据驱动的方法。它能够帮助开发流程中的决策过程实现非政治化和透明化。

本文是“软件产品交付组织的数据驱动决策”系列文章的一部分。本系列概述了数据驱动的决策如何支持软件交付中的三大活动——产品管理，开发和运营。上一篇文章阐明了产品管理中由数据驱动的决策。未来的文章将阐明运营中的数据驱动决策以及产品管理、开发和运营中数据驱动决策的组合。

致谢

许多人为本文背后的思想做出了贡献。Kiran Kumar Gollapelly，Krishna Chaithanya Pomar和Bhadri Narayanan ARR帮助实现了最初由Frances Paulisch资助的持续交付指标工具。感谢西门子医疗负责“teamplay”的整个团队引入和采用本文中的方法。

作者介绍：

Vladyslav Ukis 先后毕业于德国Erlangen-Nuremberg大学以及英国曼彻斯特大学的计算机科学专业。他一毕业就加入西门子医疗，并一直致力于软件架构、企业架构、创新管理、私有和公共云计算、团队管理和工程管理。最近几年，他一直在西门子医疗数字生态系统平台和应用（Siemens Healthineers Digital Ecosystem Platform and Applications）“teamplay”上推动持续交付和DevOps转型。

原文链接：

Data-Driven Decision Making – Product Development with Continuous Delivery Indicators

相关阅读：

数据驱动型决策如何支持软件交付（一）：用假设进行产品管理

创作场景

数据驱动型决策如何支持软件交付（二）：持续交付指标助力产品开发