总结

在本章中，我解释了软件如何主导世界，它对公司生命周期的影响，以及如果公司想要保持竞争力，就需要加速软件交付。这有助于通过让您的工程速度可见来改变与管理团队的对话方式。

衡量对公司重要的指标，并专注于能力。首先从DORA的四个关键指标开始，并结合来自SPACE框架不同维度的更多指标。但请记住，指标会塑造行为，因此在选择指标时要小心。

通过选择正确的指标，您可以使您的DevOps转型和加速变得可衡量和透明。

本章大部分内容集中在效率上：做事正确。只有OKR才关注有效性：做正确的事。OKR与精益产品开发也相关，相关内容将在第18章《精益产品开发与精益创业》中提到。

在下一章中，您将学习如何规划、跟踪和可视化您的工作。

案例研究

Tailwind Gears是一家制造公司，生产许多不同的零部件，这些零部件集成到其他产品中。公司有五个不同的以产品为中心的部门，共有600多名开发人员。每个部门都有自己的开发流程。有些使用Scrum，有些使用SAFe，还有些使用传统的瀑布模型方法（验证模型或V模型）。其中两个部门构建的软件组件用于关键系统，因此受到了严格的监管（如国际标准化组织（ISO）26262和通用良好实践（GxP））。这些软件的编程语言从嵌入式C和C++代码（用于硬件和芯片），到移动应用（Java；Swift），再到Web应用（JavaScript；.NET）不等。

与开发流程类似，公司工具的使用环境也非常异构。部分团队仍在使用本地部署的Team Foundation Server（TFS）；一些团队使用Jira、Confluence和Bitbucket，还有一些团队使用GitHub和Jenkins。部分团队已经有了持续集成/持续部署（CI/CD）实践，而其他团队仍然是手动构建、打包和部署。部分团队已经以DevOps方式工作，并操作自己的产品，而其他团队则将生产发布交给一个独立的运维团队。

Tailwind Gears面临以下问题：

  • 高层管理层无法看到开发进展。由于各个团队的工作方式不同，没有统一的速度衡量标准。

  • 各个部门报告发布周期缓慢（从几个月到几年不等），且失败率较高。

  • 每个部门都有自己的团队来支持各自的工具链，导致了大量的重复工作。例如，模板和流水线没有共享。

  • 很难将开发人员和团队分配到具有更高商业价值的产品上。工具链和开发实践差异过大，且上手时间过长。

  • 开发人员对自己的工作感到不满意，生产力低。一些开发人员已经离职，且在市场上很难招到新的人才。

为了解决这些问题，公司决定实施一个统一的工程平台，并计划统一开发流程。该计划的目标如下：

  • 加速所有部门的软件交付。

  • 提高软件质量，降低失败率。

  • 通过提高协同效应并仅拥有一个平台团队来负责统一的工程系统，节省时间和金钱。

  • 通过将开发人员和团队分配到更具价值的产品上，提升软件的价值。

  • 提高开发人员满意度，以留住现有人才并使招聘新开发人员变得更加容易。

为了使转型可见，公司决定衡量以下四个DORA关键指标：

  • DLT

  • DF

  • MTTR

  • CFR

由于目前没有统一的平台，这些指标将通过调查收集。计划是逐步将团队迁移到新的统一平台，并在该平台上使用系统指标。

开发人员的满意度是转型的重要组成部分。因此，还增加了两个指标：

  • 开发人员满意度

  • 对工程系统的满意度

这是来自至少三个 SPACE 维度的六个指标的混合。目前没有衡量沟通和协作的指标。随着转型的推进，这一指标将被添加到系统中。

进一步阅读

以下是本章的参考资料，您也可以通过这些资料深入了解相关话题：