DevOps的价值流优化–完整指南

译文
运维 系统运维
价值流优化将决定企业的成功。深入阅读本完整指南,了解如何分析您的价值流并使其保持最新。

【51CTO.com快译】价值流优化 (VSO) 是一个本质上复杂且具有挑战性的过程,可用于提高企业价值流映射的效率。您可以在此处简单的了解软件价值流的基础知识,但本质上,VSO通过提高运营效率,使企业和品牌能够简化从供应商到客户群的产品流程。

Gartner 最近分享了他们关于价值流决定 DevOps 成功观点,这一预测正是优化价值流的重要性所在:

价值流优化的挑战

创建基本价值流图后,下一个逻辑步骤就是通过考虑独特的业务需求、客户反馈、内部审查和数据分析来进一步优化和改进它。也就是说,不管价值流优化效果有多么明显,它都会带来许多挑战,

使其比听起来要困难得多。一些最常见的挑战包括:

跨组织透明度

定义价值流的目的是在整个价值链中创建透明度。虽然目标是明确的,但这个过程也可能是一项非常敏感的练习。

早期表现良好的部门可能会出现瓶颈,缺乏能力,或者最糟糕的情况是没有真正为产品增值。出于这个显而易见的原因,政治议程和个人抱负可能会挑战价值流优化。

虽然目标是创造更好的流程,但组织面临的问题是只覆盖价值流的一部分。最坏的情况会导致次优和性能下降,而最好的情况是会导致非有害变化。

不了解全局

通常,IT 组织是敏捷议程的领跑者。它建立在精益生产的基础上,精益生产是生产中的一个很著名的概念。但1992 年制定的敏捷宣言现在是将原则转移到软件开发和 IT 以及最终业务的其他部分的最著名的尝试。

在公司中实施价值流不仅仅是一项业务 IT 活动。虽然敏捷和类似的迭代方法是 IT 的第二天性,但在业务的其他部分建立必要的理解和接受可能是一个挑战。

VSM 涉及通过包括供应商、托运人、采购、质量保证、开发、销售、交付等在内的多个内部和外部利益相关者链对信息和数据流进行记录和分析,这使得让每个人都保持一致变得非常具有挑战性页。

不仅内部流程五花八门,不同部门的目标和目标也相互矛盾,进一步优化是一场艰苦的战斗。

安全问题和漏洞

再一次,简化和优化价值流的显而易见的方法似乎是确保不同利益相关者和团队之间透明且轻松的信息流。然而,这带来了维护信息安全的挑战,因为软件漏洞可能导致数据泄露、时间损失和其他

类型的网络攻击。

这就是为什么价值流优化需要每个团队尽可能多地解决安全问题。 

有缺陷或低效的软件

只有当软件功能和特性使品牌能够这样做时,优化才能成功并产生预期的结果。任何类型的软件如果无法在每个发布周期中始终如一地测试和强制执行合规性,也将无法交付价值,即使您已将其映射到您的流程中。

无论是您的内部利益相关者(如部门员工)还是外部利益相关者(如客户),有缺陷或质量差的软件往往会导致价值流优化过程失败,因为它被所有人拒绝。

不可避免的筒仓

当我们谈论组织结构时,DevOps 的一项关键原则是消除孤岛以确保信息的自由透明流动,从而实现轻松高效的价值流映射。话虽如此,包括开发、测试和运营在内的三个团队总是表现出一定程度的独立性。

尽管有持续的测试试图确保增强的信息流,但孤岛仍然不可避免。这就是为什么组织现在不再分散,而是转向集成以确保最高质量的软件交付。 

如何优化价值流

以下是一些旨在帮助您提高效率的关键步骤。

构建“大局”

尽管存在所有障碍,您仍需要确定每个阶段的低首次成功率和潜在浪费率。精益流程管理表明,在软件交付方面可能存在 8 种不同类型的浪费:

  •  传输——识别不必要的数据传输
  •  库存—— 将完成的功能存储在库存中而不发布
  •  运动——通过物理和数字方式确保信息的移动性
  •  等待——耐心等待特定角色、权限、构建、测试结果或部署
  •  过度生产——创建可能使用的功能或流程
  •  过度处理——运行比软件验证所需的更多的测试
  •  缺陷——那些本可以更早发现的错误和错误
  • 技能——过度使用或未充分使用特定角色

确保您为其分配的每个流程和资源都为客户或您的内部程序增加了价值。例如,寻求手动管理批准需要时间,并且不会为内部流程增加任何价值。因此,您可以选择消除它或进行自动化

重新评估价值流图

一旦确定了潜在的浪费和弱点,您就有了重新评估 VSM 的数据。提出棘手的问题以确保映射符合您的业务需求,并且每个步骤都为整个流程增加了价值。确保没有意外或不确定性,因为它们会导致工作、时间和财务资源的浪费,同时影响软件质量。

在您完成评估过程后,评估您的 VSM 指标和标准。从交付增量产品所需的总时间开始。在技术术语中,这称为周期时间或 CT。

  • 是否符合您的预期?
  • 或者它是否超过了您想要的时间限制? 

您通常有可能对产品的周期时间 (CT) 感到惊讶,因此它可以作为优化的激励因素。一般指标包括:

  •  周期时间 (CT) ——完成特定阶段所需的时间
  •  增值CT——增加实际价值所需的时间
  •  非增值 CT—— 可归类为浪费的时间
  •  First Time Right (FTR) ——特定阶段在第一步成功的比率

使用 VSM 指标进行价值流优化

访问这些指标将使您能够分析您的 CT、FTR 和其他值是否在您的预期范围内。例如,如果测试软件的特定功能不应超过 1 小时,但平均需要 1 小时 45 分钟,您就可以确定您需要修复流程或团队,或者也许两个都。

制作一个比较图表,这样您就可以更好地了解预期/理想指标与实际指标之间的差异。请记住,差异的存在并不一定意味着有改进的空间。它还可能表明您的 VSM 指标过于雄心勃勃或完全不准确。

优化过程将涉及使每个指标尽可能接近理想值,同时调整您自己对某些值的期望。

例如,您可能认为某个步骤的首次正确率应为 95%,但在重新评估时,可能会发现可用工具的效率和流程的复杂性使其不合理。

流量和资源利用

为了进一步改进流程,您还需要根据资源利用率映射流程。它将表明您获得的流量或输出是否值得您用于获得该输出的所有资源。您可以创建一个图表或一个矩阵,根据您所花费的努力和资源来绘制您所做的增强和改进。

您的实施应该从占用最少资源并同时显着改善流程的优化开始。然后,您可以逐渐转向确实提供更高流量但也需要大量努力的优化。

如果您想在资源利用陷阱上获得更多灵感,请花 10 分钟观看 Henrik Kniberg 制作的这个小视频。

总结 

在价值流优化方面,没有简单的出路。它带来了广泛的挑战,您需要确保详细评估所有内容以获得正确的结果。你的流程应该是精心设计的,并且注重细节,以确保你生产的软件质量是一流的。

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】

 

责任编辑:梁菲 来源: DZone
相关推荐

2022-01-24 07:20:05

DevOps软件开发

2020-10-29 06:19:56

DevOps

2020-03-26 10:02:15

价值流工作流CIO

2019-04-22 08:10:08

CPU优化服务器

2021-10-27 08:00:00

DevSecOps开发安全

2023-11-29 09:00:00

KubernetesDevOps

2024-07-03 14:14:07

2017-05-03 09:02:41

DevOpsPython微服务

2024-08-05 09:58:24

2020-09-22 12:22:32

Windows TerWindowsLinux

2015-08-24 15:13:52

DevOps主机数据中心

2022-07-06 23:48:00

DevOps开发CIO

2024-04-25 08:00:00

DevOps架构软件开发

2023-12-26 08:00:00

微前端React

2024-07-18 09:07:04

Python窗口操作

2022-05-31 08:00:00

加密货币数字化比特币

2021-12-09 09:00:00

软件测试负面测试指南

2023-11-03 12:52:00

缓存系统设计

2023-10-20 09:00:00

2022-10-25 11:06:43

点赞
收藏

51CTO技术栈公众号