探索持续改进

  • 5 分钟

持续改进是 DevOps 分类中的 8 项功能中的一种。

了解需要持续改进的原因

持续改进涉及并要求进行度量。 如果不进行度量，如何确定改进？

Forrester 于 2017 年发布的报告《更快的软件交付将加速数字化转型》显示，提前期和进程时间之间存在巨大浪费。 这提醒我们，如果不进行度量，就不会知道差异，或不知道组织正在制造多少浪费。

在度量了特定浪费对进程的影响后，就可以轻而易举地对工作进行优先级排序以进行改进。

示意图显示了 123 天的提前期与 39 天的进程时间之间的巨大浪费。这相当于等待时间为 84 天。

来源：Forrester，《更快的软件交付将加速数字化转型》，2017 年 3 月 9 日，Diego Lo Giudice、Christopher Condo 和 Christopher Mines、Luis Deya 著

但是，如果不进行度量，如何改善客户体验？ Forrester 的研究表明：“已测试和已使用的功能之间的微小重叠意味着开发人员需要更好的客户见解。” 已测试的应用程序功能与已使用的应用程序功能之间的重叠约为 35%。

关系图显示了已测试的功能与已使用的功能之间 35% 的重叠。

如果不度量新功能的使用情况和影响，如何构建合适的软件？ 有 65% 的几率会出错，知道其中的区别是至关重要的。

什么是持续改进？

连续且坦诚地观察你的 DevOps 流程可使团队能够确定可能的改进点。

所有的改进都需要改变，但并非所有的改变都是改进。 这就是为什么度量对于使用 DevOps 的组织来说是成功的关键因素。 正如 Peter Drucker 所说，“如果无法度量，就无法改善。”

缺乏有效的反馈机制使得难以提高应用对业务的影响。 这就是为什么有必要创建一个环境来促进以学习为中心的 DevOps 改进方法，并着重于基于数据进行调整。 示意图显示我们应该通过度量和影响来进行改进。度量应该引起积极的行为改变。组织应发展为不断学习和反馈的做法，以实现软件交付性能的持续改进。

度量值和指标

首先，让我们考虑一下度量值。 根据 Nicole Forsgren、Jez Humble 和 Gene Kim 的《加速》一书，软件交付性能的四个最重要的度量值是：

  • 更改的提前期：衡量软件交付性能的速度。 从提交代码到代码在生产环境中成功运行所需的时间
  • 部署频率：直接或间接度量响应时间、团队凝聚力、开发人员能力、开发工具有效性以及 DevOps 总体团队效率。
  • 平均还原时间：发生服务事件时，还原主应用或服务通常需要多长时间。
  • 更改失败百分比：失败的生产更改（例如软件版本和基础结构配置更改）的百分比。

DevOps 领导层有责任度量诸如操作运行状况指标、使用情况、速度和实时站点运行状况之类的内容。 换句话说，度量影响，而不是活动。 指标仅在可操作时才有用。

尽管 Scrum 团队度量了团队能力、团队速度、燃尽和 bug 数量，但这些指标仅在团队范围内才有意义。 但是对于 DevOps 领导层而言，保持对影响的关注很重要。

重要

度量影响，而不是活动！

我们度量的内容：

使用情况

速度

实时站点运行状况

  • 获取
  • 参与
  • 满意度
  • 变动
  • 功能使用情况
  • 生成时间
  • 自测试时间
  • 部署时间
  • 学习时间
  • 检测时间
  • 沟通时间
  • 缓解时间
  • 客户影响
  • 事件预防措施项
  • 老旧实时站点问题
  • 每个客户的 SLA
  • 客户支持指标

我们不监视的内容：

  • 初始估计
  • 已完成的小时数
  • 代码的行数
  • 团队容量
  • 团队燃尽
  • 团队速度
  • 找到的 bug 数

重要

指标会影响业务成果。

使 KPI 与习惯保持一致很重要。 它有助于实现良好的业务成果。

加强 KPI 并组件成功团队的重要习惯应包括：

  • 团队自治和组织协调：生成的内容、方式和原因。 需要在整个组织中具有共同的节奏或心跳，才能使所有领导和功能团队透明有效地进行协作。
  • 以客户为中心：所有努力都必须对客户价值产生直接或间接的影响。
  • 生产至上的思维模式：在开发、测试和运营支持期间不区分如何处理功能和 bug 的思维模式。 一切都应该自动化、版本化，并在生产中进行微调。
  • 转移质量和快速失败：鼓励在功能交付周期中尽早对测试和安全性进行审查、验证和批准，以提高质量和快速失败的思维模式。

示意图显示指标、KPI、习惯和业务成果之间的关系。指标支持 KPI，KPI 应遵循实现业务成果的习惯。KPI 示例包括提前期、部署频率、平均还原时间和更改失败率。这些 KPI 应遵循以下习惯：团队自治和组织协调、以客户为中心、生产至上的思维模式，以及快速提升质量。这样有助于实现业务成果，如加快上市时间、提高质量、减少浪费以及实现端到端安全。

持续反馈

接下来，让我们考虑如何使用持续反馈进行协作。

谈论最多的新式应用开发人员来自初创企业。 他们为什么如此成功？ 因为他们的精益实践不受多年优化过程的束缚。

精益初创企业已经建立了令人难以置信的积极持续反馈文化，从而为开发、交付和完善想法提供了一条最佳途径：

  • 及早发布，经常发布
  • 从最低限度的可行产品开始
  • 使用假设驱动的开发
  • 通过客户反馈持续改进

示意图显示了持续反馈的周期。我们首先进行构思，然后生成代码，并度量结果，最后收集数据。这个过程将帮助我们学习并产生新的想法。持续反馈可最大程度地缩短循环的总时间。

通过价值流映射进行持续改进

当我们进行度量和反馈时，改进将成为数据驱动的测试。

支持持续改进的一种有效方法是通过价值流映射。 价值流是是组织为满足客户请求而进行的一系列活动。

价值流映射是一种非常有效的方法，可用于了解和解决工作完成方式中的断开连接、冗余和缺陷。 它不仅仅是一种工具，还是一种基于团队的方法，我们认为这是行之有效的管理做法的基础。

通过价值流分析，可以分解交付过程并度量提前期、周期时间和空闲时间，从而帮助团队对工作流进行基于数据的调整。

这些度量值有助于团队进行规划、确定效率变化并确定潜在的流程问题。

示意图显示了交付过程的各个阶段。提前期是所有阶段的总时间。空闲时间是两个阶段之间的时间。进程或周期时间是某个阶段的持续时间。

提示

提前期和周期时间越短，团队的吞吐速度越快。

我们需要能够识别出不必要的非增值工作与必要的非增值工作之间的区别，以帮助识别过程改进未来的变化。

不必要的非增值工作是真正的浪费：客户不重视它，组织也不必为了保持生存能力而去做。 它消耗资源而不给产品增加任何价值。

关系图显示提前期包括不必要和必要的非增值进程时间，以及值添加进程时间。

数据驱动的 DevOps：指标有助于指导你的历程

DevOps 转换是一个历程，而引导自己完成 DevOps 之旅的最好、最有效的方法就是通过数据驱动的 DevOps。

示意图显示了 DevOps 历程的流程。团队开始转型并确定快速获胜。自动化可帮助表现欠佳的成员发展为表现中等的成员。自动化增加了人工处理的测试要求。堆积如山的技术债务会阻碍进展。技术债务和复杂性的增加会导致对更改进行额外的人工控制和流程层，从而降低工作速度。不懈的改进工作将带来卓越和高性能！绩效卓越的精英人士利用专业知识，从环境中学习，实现生产力的飞跃。

建议建立一种整体方法来度量 DevOps 的有效性，并使 DevOps 转换计划透明化。 通过专注于可突出成功的指标，创建一种文化，以促进 DevOps 所需的学习和实验。 通过庆祝正确的行为而不是惩罚错误的行为来表彰那些成功。