原文：
annas-archive.org/md5/ec167da03c90d6a18edd50835461d337译者：飞龙
第六章：从生产失败中恢复
我们生活在一个不完美的世界。我们首先看到漏洞逃入我们的生产环境。然后，我们可能会发现，当我们开始向 DevOps 实践过渡时，我们在理解上的一些空白会影响我们在生产环境中的交付方式。随着这些问题得到解决，我们可能会遇到其他超出我们控制范围的问题。我们能做些什么呢？
在本章中，我们将探讨如何减轻和处理生产环境中发生的故障。我们将研究以下主题：
-
生产环境中的错误成本
-
尽可能防止错误的发生
-
通过混沌工程进行故障演练
-
使用事件管理流程解决生产中的问题
-
通过回滚或前移修复来解决生产失败
从失败中学习
生产失败可能在产品开发过程中的任何阶段发生，从首次部署到支持成熟的产品。当这些生产失败发生时，根据其影响，可能会对客户所看到的价值产生不利影响，并有可能毁掉企业的声誉。
通常，我们不会在生产失败发生之前看到这些失败带来的教训，直到失败发生后，或者通过阅读其他组织（甚至竞争对手！）发生类似失败的情况。
我们将研究一些著名的生产失败案例，希望通过事后回顾来汲取经验教训。以下是一些示例：
-
healthcare.gov在 2013 年的上线 -
2022 年 Atlassian 云服务中断
其他的教训将来自本章的其他部分。
healthcare.gov（2013 年）
2010 年，美国通过了《患者保护与平价医疗法案》。该法案的关键部分，通称为奥巴马医保，是通过一个名为healthcare.gov的网站平台，让个人通过多个市场找到并注册负担得起的健康保险计划。该平台要求在 2013 年 10 月 1 日上线。
healthcare.gov在那一天上线后立刻遇到了问题。上线初期，网站需求为 250,000 次，是预期的五倍，导致网站在前两小时内崩溃。到第一天结束时，只有六个用户成功提交了健康保险计划的申请。
一场大规模的故障排除工作随之展开，最终使得网站能够承载 35,000 个并发用户，并在 2013 年 12 月注册期结束前为 120 万用户登记了健康保险计划。
关于healthcare.gov灾难的几份报告之一由 Dr. Gwanhoo Lee 和 Justin Brumer 编写。在报告中（见www.businessofgovernment.org/sites/default/files/Viewpoints%20Dr%20Gwanhoo%20Lee.pdf），他们具体指出了这样一个庞大工程的挑战，包括以下几点：
-
在有限时间内开发复杂的 IT 系统
-
政策问题导致实施过程中的不确定性
-
高风险的合同，且时间有限
-
缺乏领导力
Lee 和 Brumer 还指出了从门户网站设计和开发的早期阶段开始的一系列失误，这些失误最终导致了项目的失败。包括以下几点：
-
政府政策与门户网站技术实施之间缺乏对齐
-
不充分的需求分析
-
未能识别和减轻风险
-
缺乏领导力
-
对坏消息的漠视
-
僵化的组织文化
-
对项目管理基础知识的忽视
修复 healthcare.gov
在healthcare.gov的首次灾难性发布后，其中一项举措就是 Tech Surge，即由硅谷软件开发人员接管，重构了healthcare.gov网站的主要部分。Tech Surge 中的团队作为小型团队以初创公司心态运作，习惯于使用敏捷方法，进行紧密合作，使用 DevOps 工具如 New Relic，并利用云基础设施。
Tech Surge 的一个分支是由 Loren Yu 和 Kalvin Wange 领导的一小组程序员，他们被称为Marketplace Lite(MPL)。他们最初是作为 Tech Surge 的一部分，和医疗保险和医疗补助服务中心(CMS)的现有团队一起工作，向他们展示新的工作方法，例如通过聊天而非电子邮件进行协作，同时重写网站的登录和注册新计划部分。
MPL 继续在healthcare.gov上工作，因为许多其他开发者的合同到期了，Tech Surge 的其他开发者也在继续合作。它继续与 CMS 一起改进系统测试，并逐步推出修复措施，正如当时政府问责局(GAO)报告中所示。这些努力开始取得了显著成果。MPL 重新编写的其中一部分，即用于注册新医疗保险的工具App 2.0，仅限呼叫中心进行软启动，但它取得了极大的成功，成为了注册新申请的主要工具，适用于那些有简单病史的人群。
MPL 和技术冲击小组的工作，以及随后在进一步的注册期间healthcare.gov的成功推出，为敏捷和 DevOps 思维及实践提供了一个试验场。18F 等机构和美国数字服务局接过接力棒，开始指导其他联邦机构将敏捷和 DevOps 应用于技术项目。
Atlassian 云故障（2022）
2022 年 4 月 5 日，Atlassian 超过 200,000 个客户组织中的 775 个失去了对 Atlassian 云站点的访问，这些站点服务了如 Jira 服务管理、Confluence、Statuspage 和 Opsgenie 等应用程序。许多客户在服务恢复之前，已经无法访问其站点长达 14 天，直到 4 月 18 日剩余的站点恢复服务。
站点故障的根本原因追溯到 Atlassian 用来删除旧版 Insight 实例的脚本，Insight 是 Jira 的一个流行独立插件，Atlassian 在 2021 年收购了该插件。Insight 最终被捆绑进 Jira 服务管理中，但遗留的应用痕迹仍然存在，需要被删除。
出现了沟通错误，负责运行脚本的团队接收到的是站点 ID 列表作为脚本的输入，而不是 Insight 实例 ID 列表。结果是站点被立即删除。
Atlassian 的云架构由多个租户服务组成，这些服务处理多个客户的应用程序。全面恢复服务将会影响那些站点未被删除的客户。Atlassian 知道如何恢复单个站点，但从未预料到需要恢复当前面对的大量站点。Atlassian 开始恢复客户站点。恢复大量站点需要 48 小时。手动恢复所有缺失的站点将需要数周时间；显然，Atlassian 需要实现自动化。
自动化工作是为了帮助 Atlassian 找到一种方法，以便一次性恢复多个站点。自动化从 4 月 9 日开始运行，成功地在 12 小时内恢复了一个站点。到 4 月 18 日最后一个站点恢复时，大约 47%的站点已经通过自动化得到了恢复。
更大的问题是与受影响客户的沟通。Atlassian 最初是通过一个客户支持票得知这一事件的，但当时并没有立即意识到受影响的客户总数。这是因为删除站点时，也删除了包含客户信息的元数据，而这些信息通常会被客户用于创建支持票。恢复丢失的客户元数据对于客户通知非常重要。
Atlassian 无法直接联系受影响客户，导致了一个重大沟通问题的加剧。那些未被 Atlassian 联系的客户开始在社交媒体平台（如 Twitter 和 Reddit）上寻求有关事件的消息。Atlassian 于 4 月 7 日发布了一条通用推文。Atlassian 的首席技术官 Sri Viswanath 于 4 月 12 日发布了更详细的博文。在事件解决后，事后复盘报告于 4 月 29 日公开发布。
来自 Atlassian 停机事件的教训
Atlassian 的停机事件在技术和客户服务方面都带来了挑战。事后复盘总结了四个主要的学习点，Atlassian 必须改进这些方面，以防止类似的停机事件发生。这些教训包括：
-
将删除生产数据的过程更改为软删除，这样更容易恢复，并且数据只有在经过一定时间后才会被删除。
-
针对多个站点、多个产品的数据，针对更大范围受影响客户的具体流程。
-
考虑大规模事件的事故管理。Atlassian 为某个客户的网站制定了流程。现在，它需要考虑影响大量客户的大规模事故。
-
在事故发生期间改善客户沟通。Atlassian 在掌握事故原因和纠正措施后才开始沟通。这种延迟沟通让事故在社交媒体上扩展开来。
但我们也能从中汲取更广泛的教训。生产中的故障可以发生在从第一次部署到产品生命周期的任何阶段。无论是刚开始使用 Agile 和 DevOps 的公司，还是像 Atlassian 这样的公司，在使用 Agile 和 DevOps 取得成功之后，都有可能发生故障。对于这些公司来说，处理生产故障的关键在于确保流程能尽可能根除故障，进行故障演练以确定最佳流程，并在发生故障时建立合适的处理流程。
为了帮助我们应对这一挑战，我们转向了一个不断发展的学科，称为站点可靠性工程（SRE）。这一学科由 Google 的 Ben Treynor Sloss 创建，最初目的是将软件开发方法应用于系统管理。SRE 最初被视为一种混合方法，利用开发团队用于传统系统管理操作的方法，它已经发展成 DevOps 中的一个独立分支，确保在自动化部署之后，系统操作的持续可靠性。
第一步是规划和预防。我们从查看 SRE 用于防止生产故障的保障措施开始。
预防——拉动安灯（Andon）绳。
安灯绳在精益思想中占有特殊的地位。作为丰田生产系统的一部分，如果你怀疑生产线上有问题，你可以拉动围绕生产线的安灯绳，这会停止生产线。人们会赶到安灯绳拉动的地方，查看缺陷并确定首先如何修复缺陷，然后采取哪些步骤防止未来再次发生类似问题。
丰田生产系统的创始人大野耐一通过安灯绳实践自働化，赋予每个人停止工作来检查和实施持续改进的权力。
对于站点可靠性工程师，以下的理念和原则被用作实施安灯绳并确保持续改进的方法：
-
通过查看服务级别指标（SLI）、服务级别目标（SLO）和误差预算来规划风险容忍度
-
通过发布工程执行发布标准
-
与发布协调工程合作进行产品发布
让我们更详细地探讨这些理念。
SLI、SLO 和误差预算
许多人熟悉服务级别协议（SLA）的概念，即如果服务未达到可用性或响应性的门槛，供应商将需要支付约定的性能水平，通常以信用额度的形式进行补偿。
如果我们查看 SLA 期望实现或维持的目标或阈值，这称为 SLO。一般来说，SLO 有三个部分：
-
要测量的质量/组件
-
测量周期
-
质量必须达到的要求阈值，通常以期望值或范围的形式写出
要测量的质量或组件被称为 SLI。常见的 SLI 包括以下几种：
-
延迟
-
吞吐量
-
可用性
-
错误率
对于每个 SLO，在测量周期内未达到阈值的时间称为误差预算。通过密切监控误差预算，SRE 可以评估风险是否可接受，以便推出新版本。如果误差预算几乎耗尽，SRE 可能会决定将焦点从功能开发转向更多的技术工作，例如增强可恢复性和可靠性的支持工具。
团队通常希望了解误差预算，以可允许的时间为单位。以下表格可能会提供有关每月和每年最大可允许误差的指导：
| SLO 百分比 | 每月允许 误差预算 | 每年允许 误差预算 |
|---|---|---|
| 99%（1%误差范围） | 7 小时 18 分钟 | 87 小时 39 分钟 |
| 99.5%（0.5%误差范围） | 3 小时 39 分钟 | 43 小时 49 分钟 45 秒 |
| 99.9%（0.1%误差范围） | 43 分钟 50 秒 | 8 小时 45 分钟 57 秒 |
| 99.95%（0.05%误差范围） | 21 分钟 54 秒 | 4 小时 22 分钟 48 秒 |
| 99.99%（0.01% 误差范围） | 4 分 23 秒 | 52 分 35 秒 |
表 6.1 – 按允许的每月和每年时间划分的误差预算
实施 SLOs 的过程通常从评估产品或服务开始。从那里，查看构成产品的组件或微服务：哪些部分如果不可用，会导致客户的不满？
在发现对客户满意度至关重要的组件后，选择那些用于捕获和设定目标（SLOs）的测量指标（SLIs），确保这些测量指标能真实反映潜在问题，并且目标是现实可达的（任何测量指标的 100% 都是无法实现的）。从一小组 SLOs 开始，将这些 SLOs 告诉客户，让他们理解 SLOs 在提升产品质量和期望方面的作用。
SLIs、SLOs 和误差预算应作为政策文档，但该政策是可以调整和改变的。经过一段时间后，重新评估 SLIs、SLOs 和误差预算，检查这些测量指标是否有效，并根据需要修订 SLIs 和 SLOs。
发布工程
为了确保 SLOs 得以保持，站点可靠性工程师需要确保发布给客户的任何内容都是可靠的，且不会导致服务中断。为此，他们与软件工程师合作，确保发布的内容风险较低。
Google 将这种协作称为发布工程。SRE 的这一方面遵循以下原则：
-
自助服务
-
高速度
-
封闭构建
-
政策/程序执行
现在让我们来看一下发布工程哲学的这四个部分。
通过自助服务模型实现发布自主权
为了实现敏捷，参与的团队必须是独立且自我管理的。发布工程过程允许团队自行决定发布节奏和实际发布的时间。自动化有助于团队在需要时按需发布。
追求高速度
如果团队选择更频繁地发布，通常是以更小批次的高测试覆盖率代码进行发布。更频繁的小批量发布降低了中断的风险。如果你有较大的误差预算，这尤其有帮助。
确保封闭构建
我们希望在构建和发布过程中保持一致性和可重复性。构建输出应与创建者无关，确保输出相同。这意味着，从测试到生产的依赖项和工具（如库和编译器）的版本应保持标准化。
当然，如果生产环境中出现问题，一种有用的故障排除策略是所谓的 cherry-picking（挑拣），团队从最后一个已知的 良好 生产版本开始，从版本控制中获取并逐个插入每个更改，直到发现问题。强有力的版本控制流程确保构建是封闭的，并且支持挑拣操作。
严格执行政策和程序
需要访问控制标准的自动发布过程，以确保在正确的构建机器上使用正确的源创建构建。关键是避免添加本地编辑或依赖项，只使用存储在版本控制中的经过验证的代码。
我们讨论的这四个原则实际上在处理发布过程中的以下部分时得到了应用：
-
持续集成/持续 部署 (CI/CD)
-
配置管理
我们第一次看到这些部分作为 CI/CD 管道的自动化实现出现在 第三章， 提升效率与质量的自动化。现在，让我们看看如何将这些过程与自动化联系起来。
CI/CD
发布过程从提交版本控制开始。这会启动构建过程，自动执行不同的测试，具体取决于分支。发布分支会运行单元测试以及适用的系统和功能测试。
测试通过后，构建会被标记，以便跟踪构建日期、依赖项、目标环境和修订号。
配置管理
配置管理工具使用的文件存储在版本控制中。配置文件的版本与发布版本一起记录，作为审计轨迹的一部分，以便我们知道哪个版本的配置文件与哪个版本的发布相关联。
发布协调工程
向客户发布新产品或功能时，可能会比现有产品的迭代发布面临更高的期望。为了促进新服务的发布，谷歌在 SRE 内创建了一个特殊的咨询职能，称为 发布协调工程 (LCE)。
LCE 的工程师执行多个职能，旨在确保发布过程顺利进行。这些职能包括以下内容：
-
审核产品或服务以确保可靠性
-
协调多个参与发布的团队
-
确保完成与发布相关的技术任务
-
确认发布是 安全的
-
培训开发人员与新服务的集成
为了帮助发布协调工程师确保发布顺利进行，创建了一个发布检查清单。根据产品的不同，工程师会定制该检查清单，添加或删除以下检查项：
-
共享架构和依赖
-
集成
-
容量规划
-
可能的故障模式
-
客户行为
-
流程/自动化
-
开发过程
-
外部依赖
-
发布规划
我们已经看到 SRE 使用的技术和流程，以确保产品发布或代码发布已准备就绪。我们已通过 SLIs、SLOs 和错误预算看到了容错能力。但我们是否知道当发生故障时，SRE 是否已做好准备？
判断的一种方式是模拟故障并观察反应。这是 SRE 使用的另一个工具，称为混沌工程。让我们看看其中涉及的内容。
准备工作 – 混沌工程
2015 年 9 月 20 日，亚马逊网络服务（AWS）在美国东部 1 区（US-EAST-1）发生了停机事故，超过 20 个服务出现故障。这些服务影响了许多大公司如 Tinder、Airbnb、IMDb 的应用，以及亚马逊自己的服务，如 Alexa。
在 AWS 发生故障期间，能够避免问题并保持完全运行的客户之一是 Netflix，这家流媒体服务公司。它能够做到这一点，因为它创建了一系列名为猩猩军团的工具，相关内容可以在netflixtechblog.com/the-netflix-simian-army-16e57fbab116的博客文章中找到，这些工具模拟了 AWS 可能出现的问题，使得 Netflix 的工程师能够设计出增强系统弹性的解决方案。
在多次 AWS 故障中，猩猩军团证明了它的价值，使 Netflix 能够继续提供服务。很快，像 Google 这样的其他公司也开始希望应用相同的技术。这股支持浪潮最终促成了混沌工程学科的诞生。
让我们更深入地了解混沌工程的以下几个方面：
-
原则
-
实验
混沌工程原则
混沌工程的关键是进行生产环境中的实验。尽管在生产环境中进行可靠性实验似乎充满风险，但这种风险通过对系统弹性的信心得到了缓解。
为了引导信心，混沌工程从以下原则开始：
-
基于生产环境稳态行为构建假设
-
创建模拟现实世界事件的变量
-
在生产环境中运行实验
-
自动化实验
-
最小化实验的后果
让我们详细讨论这些原则。
基于稳态行为进行实验
在设计实验时，我们真正想要关注的是系统的输出，而不是系统中各个组件的表现。这些输出形成了环境在稳态下行为的基础。混沌工程的重点在于验证行为，而不是验证单个组件的功能。
那些将混沌工程视为 SRE（站点可靠性工程）关键部分的成熟组织知道，这种稳态行为通常构成了 SLO（服务水平目标）的基础。
创建模拟现实世界事件的变量
基于已知的稳态行为，我们考虑现实世界中可能发生的假设场景。你考虑的每个事件都成为一个变量。
Netflix 的“猩猩军团”中的一个著名工具，Chaos Monkey，基于 AWS 中虚拟服务器节点不可用的事件。因此，它只测试这一条件。
在生产环境中运行实验
在预备环境或类似生产环境中运行实验是有益的，但最终，你需要在生产环境中运行实验，以查看它对实际流量处理的影响。
在 Netflix，Chaos Monkey 每天在生产环境中运行。它会查看每个正在运行的集群，并随机停用其中一个节点。
自动化实验
从混沌工程实验中学习的好处，只有当实验持续且频繁地运行时，才能显现出来。为了实现这一点，自动化实验是必要的。
Chaos Monkey 在初次推出时并未受到 Netflix 工程师的欢迎。每天，这个程序会故意在生产环境中制造错误，这让他们感到不太舒服，但它确实不断暴露出实例可能消失的问题。有了这个问题，工程师们就有了找到解决方案并增强系统弹性的任务。
最小化后果
因为你是在生产环境中进行实验，所以也有可能影响到同样使用该环境的客户。你的任务是确保实验带来的后果得到最小化。
Chaos Monkey 每天运行一次，但仅限于工作时间。这是为了确保如果发现对生产环境的任何负面影响，能够在大多数工程师在场时发生，而不是在凌晨 3 点等非工作时间，这时只有少数工作人员值班。
在这些原则的基础上，接下来让我们应用它们并探讨创建实验。
在混沌工程中运行实验
在生产环境中进行实验需要规划和开发流程。实验的目标是找出那些可以增强弹性的薄弱环节，以确保 SLO（服务水平目标）得到保持。目标不是破坏 系统。
在《混沌工程：实践中的系统弹性》一书中，理查德·克劳利写了一个章节，讲述了为 Slack 创建灾难剧院流程的内容。他概述了以下步骤：
-
确保有一个安全网到位。
-
准备演练。
-
执行演练。
-
对演练结果进行总结。
现在让我们详细检查每个步骤。
确保环境已准备好应对混沌
混沌工程的目标是找出系统弹性中的弱点，而不是关闭环境。如果现有环境没有容错能力，那么进行实验是没有意义的。
确保服务有备用容量。这个备用容量应该容易上线。
一旦备用容量和资源被识别并分配好，制定一个计划，允许移除故障资源并自动用备用容量进行替换。
准备演练
对于克劳利来说，一个演练从一个问题开始：哪个关键组件或服务会失败，从而影响系统的弹性？这成为演练的基础。
Crowley 然后以此为基础，展开工作，扩展为在开发、预生产和生产环境中运行的演习。他制定了一个检查清单，确保以下每个项目都在演习中得到满足：
-
描述将要故障的服务器或服务，包括故障模式，以及如何模拟故障。
-
确定开发和生产环境中的服务器或服务，并确认在开发环境中模拟的方法是否可行。
-
确定如何检测故障。是否会生成警报并显示在仪表板上？是否会生成日志？如果无法想象如何检测它，仍然值得执行演习以确定检测故障的方法。
-
确定冗余和缓解措施，这些措施应当能够消除或减少故障的影响。同时，确定在故障发生时应运行的操作手册。
-
确定应该邀请哪些相关人员为演习提供他们的知识。这些人员也可能是演习发生时的第一响应者。
准备工作最终在与相关人员的会议中完成，讨论演习所需的后勤工作。当所有准备工作就绪时，便是时候开始演习了。
运行演习
演习应当在执行前广泛告知所有参与人员。毕竟，他们将参与这次演习，目标是创建一个更具弹性的环境。
Crowley 执行演习时使用以下检查清单：
-
确保每个人都知道演习正在被录音。如果每个人都同意，可以进行录音。
-
审查在准备阶段创建的计划，并根据需要进行调整。
-
在开发环境中宣布演习开始。
-
在开发环境中制造故障。记录时间戳。
-
查看是否为故障生成了警报和日志。记录时间戳。
-
如果有自动恢复步骤，给它们一些时间来执行。
-
如果使用了操作手册，按照操作手册的指引解决开发环境中的故障。记录时间戳以及是否有任何偏离操作手册的情况。
-
确定是否有“开始/不开始”决策，以便在生产环境中复制此故障。
-
在生产环境中宣布演习开始。
-
在生产环境中制造故障。记录时间戳。
-
查看是否为故障生成了警报和日志。记录时间戳。
-
如果有自动恢复步骤，给它们一些时间来执行。
-
如果使用了操作手册，按照操作手册的指引解决生产环境中的故障。记录时间戳以及是否有任何偏离操作手册的情况。
-
宣布演习结束并宣布“全清”。
-
进行总结。
-
如果有录音，将其分发。
演习完成后，演习的关键部分是进行总结，这一过程从宣布演习结束开始。我们来看看如何创建一个学习总结。
事后总结以便学习
Crowley 建议在练习体验仍然新鲜时进行事后总结。在总结过程中，只呈现事实，并总结系统表现得如何（或未能表现）。
Crowley 提出了以下启动问题，以帮助展示学到的内容。这些问题可以作为模板使用：
-
事件检测和恢复的时间是多少？
-
当我们在生产环境中运行练习时，最终用户注意到了吗？我们如何知道？有没有解决方案可以让答案是没有？
-
哪些恢复步骤可以自动化？
-
我们的盲点在哪里？
-
我们需要对仪表板和运行手册做哪些更改？
-
我们需要在哪些方面进行更多练习？
-
如果这种情况意外发生，我们的值班工程师该怎么做？
练习的结果和总结中的回答可以形成接下来增强系统韧性的建议。可以重复进行练习，以确保系统能正确识别并解决故障。
灾难剧场可以作为执行混乱工程练习的有效框架。该练习的灵活性取决于你的系统已经有多强的韧性。
即使定期进行混乱工程练习，生产环境中仍然可能发生不良事件，影响到客户。让我们看看如何通过事件管理来解决这些生产问题。
问题解决 – 促成恢复
对于 SRE 来说，健全的事件管理流程在生产环境出现问题时非常重要。一个好的事件管理流程能够帮助你达成这些必要的目标，通常被称为三大 C：
-
协调响应
-
沟通事件参与者、组织中的其他人员以及外部感兴趣方之间的互动
-
控制事件响应
Google 在 Andrew Stribblehill 所写的《站点可靠性工程：Google 如何运营生产系统》的管理事件章节中，识别了他们的事件指挥系统所需的元素。这些元素包括以下内容：
-
明确的事件管理角色
-
一个（虚拟或物理的）指挥所
-
一个实时更新的事件状态文档
-
清晰的交接给他人
让我们详细看看这些元素。
事件管理角色
一旦确认你所面对的确实是一起事件，就应该组建一个团队来处理问题，并共享信息，直到事件解决。团队会有明确的角色，以便正确协调。让我们详细了解这些角色。
事件指挥官
事件指挥官可能最初是报告事件的人。事件指挥官通过将必要的角色委派给其他人来体现三大 C。任何未被委派的角色都假定属于事件指挥官。
事件指挥官将与其他响应人员合作以解决事件。如果有任何障碍，事件指挥官将促使其去除。
运营负责人
运营负责人将与事件指挥官一起工作。他们将运行解决事件所需的工具。只有运营负责人可以对系统进行更改。
通讯负责人
通讯负责人是事件及其响应的对外代表。他们负责与外部团体和利益相关者的沟通。他们还可能确保事件文档保持更新。
事件规划/后勤
规划和后勤将与运营人员一起解决事件的长期问题，如安排角色间的交接、订餐和在缺陷跟踪系统中输入票证。他们还将跟踪系统如何偏离常态，以便在事件解决时恢复正常。
事件指挥中心
一个战情室是所有事件响应团队成员集中合作解决方案的地方。这里应该是外部人员可以与事件指挥官和其他事件响应团队成员会面的地方。
由于分布式开发，这些指挥中心通常是虚拟的，而不是一个实体房间。互联网中继聊天（IRC）聊天室或 Slack 渠道可以作为集中在一个地方的媒介。
事件状态文档
事件指挥官的主要责任是记录与事件相关的所有活动和信息在事件状态文档中。这是一个动态文档，旨在频繁更新。一个 Wiki 页面可能足够，但通常它一次只能由一个人编辑。
适当的替代方案可能是 Confluence 页面或一个共享在公共 Google Drive 或 Microsoft SharePoint 文件夹中的文档。
Google 维护了一个事件状态文档模板，可以作为起点使用。
设置清晰的交接
正如我们在本章中看到的 Atlassian 事件，事件可能持续几天甚至几周。因此，角色的交接至关重要，特别是事件指挥官。必须确保每个人都清楚交接已发生，以最小化任何混淆。
在事件处理中，可能有一些有助于解决问题的行动，包括回滚或前进修复。如果根本原因被诊断为最近做出的新更改，这些方法可能有效。我们将在下一部分中详细介绍这些替代方案。
坚持不懈 – 回滚或前进修复
如果生产故障的原因是一个新更改，快速解决方案可能包括恢复到更改之前的系统状态，或者如果找到了修复方法，立即通过 CI/CD 流水线运行并立即部署。
一些回滚或修复推进的方法包括以下几种。让我们详细了解它们。
使用蓝绿部署回滚
蓝绿部署利用两个生产环境：一个是在线环境，另一个是备用环境。在线环境是客户使用的环境，而备用环境则作为备份。更改在备用环境中进行，然后将备用环境切换为在线环境。你可以看到这种部署方式的示意图：
图 6.1 – 蓝绿部署：环境切换
正如前面的图示所示，两个环境仍然存在，但只有一个环境能接收客户流量。这个安排将持续，直到更改部署到备用环境中，或者需要回滚，如下图所示：
图 6.2 – 蓝绿部署：回滚
蓝绿部署在环境是无状态时效果最佳——也就是说，不需要考虑数据的状态。当数据的状态需要在数据库或易失性存储等工件中考虑时，就会出现复杂情况。
使用特性标志回滚
我们在第三章，《为了效率和质量的自动化》中看到，特性标志允许变更传播到部署中，但在标志被开启之前，变更是不可见的。以同样的方式，如果新特性是生产故障的根本原因，可以将标志关闭，直到新特性被修复，如下图所示：
图 6.3 – 使用特性标志回滚
使用特性标志回滚可以快速恢复到以前的行为，而不需要对源代码或配置做出广泛的修改。
使用 CI/CD 流水线推进
向前推进或修复推进是通过开发错误修复来解决事件的方法，允许其通过 CI/CD 流水线，从而能够部署到生产环境中。这是一种有效的解决事件的方法，特别是当更改较小的时候。
修复推进应被视为最后的手段。如果修复推进是唯一可行的选择，可能是因为你的产品架构与依赖组件耦合过于紧密。例如，如果新版本依赖于数据库架构的更改，并且在发现生产故障之前，客户数据已经存储在新的表中，那么在不丢失客户数据的情况下可能无法回滚。
打算通过滚动更新发布的变更应遵循与常规发布相同的流程。快速修复可能不遵循完整流程，也可能没有同样的审查和测试覆盖，可能会通过在系统其他部分引入错误，增加技术债务。
总结
本章我们探讨了生产环境出现问题时的应对。我们通过两个事件开始了本章内容：2013 年healthcare.gov的初始发布和 2022 年 Atlassian 云宕机。我们从这两个事件中学到预防和规划未来事件的重要性。
接下来，我们通过查看 SRE 学科的重要部分，探索了准备工作的方式。SRE 通过设定 SLI 和 SLO 来开始这一过程，从而让我们通过错误预算了解风险的容忍度。SRE 还关注发布新变更和推出新产品的过程。
我们通过混沌工程学科练习灾难应对。我们理解了这一学科背后的原则，并学会了如何通过灾难剧场（Disasterpiece Theater）过程来设计实验。
最终，即使有充分的准备，生产故障仍然会发生。我们分析了 Google 事件管理过程中关键部分，并研究了处理事件的技术，如回滚或前向修复。
至此，我们已完成第一部分：方法论 – 通过 CALMR 看 SAFe**®和 DevOps*。接下来，我们将在第二部分：实施 – 向价值流迈进中，探讨 DevOps 的一个关键活动——价值流管理。
问题
通过回答这些问题，测试你对本章概念的理解。
-
什么是 SLI 的例子？
-
速度
-
可用性
-
周期时间
-
可扩展性
-
-
如果你的组织设置了 99%可用性的 SLO，并且每月的可接受停机时间是 7.2 小时，那么你的错误预算是多少？
-
0.072 小时/月
-
0.72 小时/月
-
7.2 小时/月
-
72 小时/月
-
-
以下哪个不是发布工程的原则？
-
自服务模型
-
高速
-
依赖构建
-
政策/程序的执行
-
-
是哪个公司创造了混沌猴和类人猿军团？
-
Netflix
-
Google
-
亚马逊
-
苹果
-
-
以下哪些是混沌工程的原则（选择两个）？
-
去中心化决策
-
围绕价值组织
-
最小化实验的后果
-
在生产环境中运行实验
-
应用系统思维
-
-
在 Google 的事件指挥系统中，哪个角色是事件状态文档的主要作者？
-
运维负责人
-
事件指挥官
-
通讯负责人
-
规划/物流
-
深度阅读
这里有一些资源，供您进一步探索这个话题：
-
www.businessofgovernment.org/sites/default/files/Viewpoints%20Dr%20Gwanhoo%20Lee.pdf——管理关键任务政府软件项目：来自 Healthcare.gov 项目的经验教训，作者为 Dr. Gwanhoo Lee 和 Justin Brumer。深入探讨了 Healthcare.gov 灾难的根本原因。 -
www.theatlantic.com/technology/archive/2015/07/the-secret-startup-saved-healthcare-gov-the-worst-website-in-america/397784/——关于 Tech Surge 和 MPL 特别努力的报道。 -
www.gao.gov/assets/gao-15-238.pdf——GAO 报告，描述了 healthcare.gov 启动初期存在的问题以及朝着所需修复的进展。 -
oig.hhs.gov/oei/reports/oei-06-14-00350.pdf——关于 healthcare.gov 初始启动的案例研究，以及 Tech Surge 带来的变革，这些变革促成了后续版本的成功发布。由 卫生与公共服务部（HHS）监察长办公室（OIG）创建。 -
www.atlassian.com/engineering/post-incident-review-april-2022-outage——由现任 CTO Sri Viswanath 撰写的 Atlassian 云服务中断后的事后回顾。 -
站点可靠性工程：谷歌如何运行生产系统，编辑 Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall Richard Murphy——关于 SRE 的参考书，详细介绍了 SRE 主题的原则和论文。
-
medium.com/kudos-engineering/managing-reliability-with-slos-and-error-budgets-37346665abf6——描述 SLI、SLO 和错误预算之间关系的文章。 -
www.techrepublic.com/article/aws-outage-how-netflix-weathered-the-storm-by-preparing-for-the-worst/——描述 Netflix 如何通过为最坏情况做准备来避免 2015 年 9 月 AWS 中断影响的文章。 -
netflixtechblog.com/the-netflix-simian-army-16e57fbab116——Netflix 博客文章，解释了 Simian Army。 -
principlesofchaos.org——混沌工程原则的资源库。 -
混沌工程：实践中的系统韧性，作者 Casey Rosenthal 和 Nora Jones——混沌工程的参考书，描述了混沌实验的原则和论文。
-
《网站可靠性工作簿：实施 SRE 的实用方法》由Betsy Beyer、Niall Richard Murphy、David K. Rensin、Kent Kawahara和Stephen Thorne编辑—实现 SRE 实践的参考书。
-
www.linkedin.com/pulse/service-recovery-rolling-back-vs-forward-fixing-mohamed-el-geish/—Mohamed El-Geish 撰写的博客文章，讨论了恢复策略、回滚与前向修复。
第二部分：实现—迈向价值流
在 Gene Kim、Kevin Behr 和 George Spafford 合著的《凤凰项目：IT、DevOps 与帮助你的业务获胜的小说》一书中，我们介绍了三种方法。这些方法概述了我们如何向 DevOps 和 CALMR 转变。
第一种方法强调朝着流动的方向努力。为此，我们将围绕价值流进行组织和结构化，目的是可视化执行步骤和参与这些步骤的人。作为一个价值流工作将帮助我们优化流动。在[第七章]中，我们将看到如何建立我们的价值流。
在第一种方法之后，我们来到了第二种方法，重点强调反馈循环的放大。为了找到我们的反馈，我们会查看可以用来评估价值流的指标，在第八章中有详细介绍。
最后，我们来到了第三种方法。第三种方法强调向持续实验和学习转变。第九章将讨论如何打造一个持续学习的组织，并介绍通过持续学习改进价值流的方法。
本部分旨在建立一种简单的方法来实现价值流管理，这是 DevOps 中的关键实践。
本书的这部分包含以下章节：
-
第七章，映射你的价值流
-
第八章，衡量价值流绩效
-
第九章，通过持续学习迈向未来
第七章：绘制你的价值流图
价值流是 SAFe® 的重要组成部分。在我们回顾 第二章 时，曾在“共享责任文化”部分看到过这一点，我们探讨了 SAFe 精益敏捷原则，并得出了原则 #10：围绕价值进行组织。同样地，价值流在 DevOps 中也扮演着关键角色。在《凤凰项目：IT、DevOps 和帮助你的企业成功的小说》中，作者 Gene Kim、George Spafford 和 Kevin Behr 提出了“三种方式”这一概念。第一种方式是利用价值流来建立流程，这正是我们在本章中要探讨的内容。
我们将探讨如何发现组织的价值流并寻找未来的优化空间。总的来说，我们将关注以下活动：
-
使组织的思维模式与价值流保持一致
-
为开发价值流设定背景
-
绘制开发价值流图
-
寻找改进领域
让我们来看看如何让组织从价值流的角度去思考运营。
使组织的思维模式保持一致
关注价值流将要求组织进行重大变革，这可能最终导致文化的改变。这些变革努力通常是持续改进旅程的开始。
我们将首先评估一个此类转型的例子：通过实施路线图采用 SAFe。在审视这个路线图时，我们将看到识别价值流在其中发挥了关键作用。
另一个转型指南的例子是由 Cecil “Gary” Rupp 在《通过价值流管理推动 DevOps：使用成熟的 VSM 方法改善 IT 价值流交付，以便在数字经济中竞争》一书中提出的，涉及八个步骤，构成了价值流管理（VSM）计划。正如本书中所描述的，VSM 计划是 VSM 联盟的参考方法，VSM 联盟是一个致力于推进方法来改善 VSM 的个人和组织群体。
我们将看到，这两种变革指南之间有显著的重叠。因此，可以在 SAFe 转型中实施 VSM（价值流管理）计划，两者互为补充。考虑到这一点，让我们从 SAFe 的实施路线图开始，来审视价值流。
向 SAFe 过渡
实施路线图是组织采用 SAFe 的主要模式。该路线图从建立变革代理联盟开始，培训他们适应新的工作方式，然后通过价值流来实施这一过程。路线图可以进行定制，以适应组织的需求。
实施路线图的步骤如下：
-
达到转折点以采用 SAFe。
-
培训倡导者和变革代理。
-
培训高管和领导者适应新的工作方式。
-
为变革代理创建一个精益敏捷卓越中心。
-
识别价值流。
-
制定实施计划。
-
准备启动第一个 敏捷发布 列车 (ART）。
-
培训 ART 并启动。
-
指导 ART 执行。
-
启动额外的价值流和 ART。
-
将 ART 指导扩展到投资组合。
-
通过检查和适应加速并继续前进。
我们可以看到，这个路线图与之前讨论过的科特变革模型（第二章，《共享责任文化》）一致，特别是在以下表格中所示。
| 科特变革 模型步骤 | 适用的实施 路线图步骤 |
|---|---|
| 创建紧迫感 | 达到采纳 SAFe 的临界点 |
| 引导强大的联盟 | 培训倡导者和变革代理人，培训高层和领导者新的工作方式，创建精益敏捷卓越中心 |
| 创建愿景 | 识别价值流，创建实施计划 |
| 传播愿景 | 创建实施计划，准备启动第一个 ART |
| 授权他人执行愿景 | 准备启动第一个 ART，培训 ART 并启动 |
| 庆祝短期胜利 | 指导 ART 执行 |
| 整合胜利来创造更多变化 | 启动额外的价值流和 ART，将 ART 指导扩展到投资组合 |
| 将新变化扎根于文化中 | 启动额外的价值流和 ART，将 ART 指导扩展到投资组合，加速并继续通过检查和适应 |
表 7.1 — 科特变革模型与 SAFe 实施路线图的映射
我们可以看到，识别价值流是启动第一个 ART 和随后的 ART 的重要部分。考虑到这一点，我们可以看看启动 VSM（价值流管理）计划的步骤，以帮助识别价值流。
转向价值流
VSM 方法论在《推动 DevOps 与价值流管理：通过经过验证的 VSM 方法提高 IT 价值流交付，以在数字经济中竞争》一书中由 Cecil “Gary” Rupp 提出。在这本书中，作者将精益思维中的改进 Kata 模型应用于创建和维持一个或多个价值流。
VSM 方法论概述如下步骤：
-
承诺精益
-
选择价值流
-
学习精益
-
映射当前状态的价值流
-
映射价值流的理想未来状态
-
制定改进（Kaizen）计划，以达到未来状态
-
实施改进计划
-
重复这个过程
现在我们理解了映射价值流的整体战略，接下来让我们仔细看看在下一部分中识别价值流的过程。
为开发价值流设定背景
开发价值流所做的工作应用于解决方案，而这个解决方案在客户与组织之间获取价值的更大背景中起着作用。这一更大的背景通过组织可能拥有的运营价值流来体现。
我们初步了解了操作价值流和开发价值流之间的差异，操作价值流详细描述了客户的需求以及公司的解决方案如何满足这些需求，而开发价值流则展示了开发和维护解决方案所需的步骤，在第二章，共享责任文化中有提到。在本节中，我们将展示如何利用有用的工具（如 Gemba 走动）来创建一个操作价值流。最后一步是找到操作价值流所使用的解决方案，这些解决方案将成为开发价值流的基础。
为价值流识别做好准备
绘制操作和开发价值流可能是一个庞大的工作量，面对组织的复杂性时，这可能会令人沮丧。在进行这项工作之前，一些准备工作是必要的。
价值流绘制通常通过组织内部的不同成员参加的工作坊进行。在举办这样的工作坊之前，您可能想确保组织已经确定以下事项：
-
价值流的范围
-
将会面以识别价值流的团队成员
-
通过 Gemba 走动了解客户的观点
让我们更详细地审视这些内容。
确定范围
组织的规模可以是小型的，也可以是庞大的，这取决于组织的历史或设计、生产和维护的产品或解决方案的数量。在发现组织和开发价值流之前，组织应该为发现设定适当的范围。
卡伦·马丁和迈克·奥斯特林在他们的书籍《价值流图绘制：如何可视化工作并与领导对齐进行组织转型》中将范围列出为价值流章程。在书中，他们为价值流章程收集了以下内容：
-
价值流。
-
特定条件：限制允许的场景数量可能会有帮助。如果是这种情况，您可能需要设置仅带来期望场景的小范围条件。
-
触发事件：启动价值流活动的事件。
-
需求率：这是触发事件发生的频率。
-
流程中的第一步和最后一步。
-
边界/限制。
-
改进时间框架：这有助于确定应该首先进行的可能的未来状态改进。
-
当前状态的问题和需求。
-
可衡量的目标条件。
-
对客户和业务的价值。
-
负责的团队成员。
让我们在下一节中看看绘制价值流图所需的成员和角色。
创建团队
一次价值流图绘制活动可能需要几天时间。在这期间，许多人将被召集提供他们的专业知识，并填写操作和开发价值流所需的价值流章程项目。
在《价值流映射：如何可视化工作并为组织变革提供领导力对齐》中详细列出以下角色：
-
执行赞助人：这可能是最终对结果负责的 C 级领导者。他们将监督整个过程，并跟踪价值流朝未来状态的进展。
-
价值流冠军：这是一个负责价值流绩效的人。他们在价值流映射中将扮演关键角色。
-
促进者：这是确保价值流映射顺利进行的人。
-
物流协调员：此人负责为价值流映射做好所有必要的安排。这可能包括为面对面映射会议预订房间或准备虚拟会议所需的网络协作会议配置。
-
会议参与者：映射团队的成员将组成其余的团队。这将是一个多样化的团队，他们了解价值流战略要素，并直接经历开发价值流将采取的战术步骤。
应向这些人展示宪章，以便他们为映射研讨会做好准备。可能会出现关于可能情况的问题。他们应被带到研讨会上，以便向所有人传达。
通过 Gemba 漫步理解客户的视角
因为操作价值流直接涉及客户，理解客户的视角非常重要，以便解决方案更有价值。通过 Gemba（也称为现场考察）漫步是实现这一点的一种方式。
通过 Gemba 漫步，VSM 团队成员将前往客户现场，从客户的视角查看价值流的工作方式，并确定是否需要任何改进。
在进行 Gemba 漫步时，通常有利于从价值流的最后一步开始向前工作。这有助于保持客户视角的关注，重视向客户交付的价值。
Gemba 漫步应该经常发生，以理解不仅客户的心态和价值流从客户角度的影响，还有价值流改进是否达到了预期效果的情况。
通过价值流管理推动 DevOps：使用经过验证的 VSM 方法论提高 IT 价值流交付，以在数字经济中竞争 概述了以下步骤作为 Gemba 漫步策略：
-
确定目标和目标。
-
提前通知客户 Gemba 漫步访问及其原因。
-
VSM 团队成员应该以小组形式访问。
-
追踪价值流的流程。
-
发现过程及其相关活动中的任何问题。不要归咎于个人。
-
记录您发现的内容。
-
识别根本原因。五个为什么技术，即反复问*为什么？*五次，是一种有效的追溯根本原因的方法。
-
倾听。
-
跟进推荐意见。
-
重复走一遍以确认推荐的变更已经实施。
-
重复走一遍，以发现其他 Kaizen（持续改进）机会。
剩余的价值流识别将在专门的研讨会上与团队成员一起进行。让我们仔细看看在研讨会中如何识别一个运营价值流。
创建运营价值流
在价值流研讨会的初期活动中，你需要识别运营价值流以及作为开发价值流最终产品的解决方案。
运营价值流通常根据其如何为客户提供价值，分为以下四类：
-
数字化支持的产品或服务：该运营价值流处理客户对产品或服务的在线请求。电子商务销售就是一个很好的例子。
-
制造：该运营价值流负责创建客户购买的实体产品。
-
软件产品：该运营价值流负责交付给客户的软件产品。
-
支持：该运营价值流关注支持客户的活动工作流，通常是内部客户。
下面的图表展示了这四类运营价值流的示例：
图 7.1 – 运营价值流示例
识别运营价值流的类别可以让绘图团队查看客户的旅程，并识别所需的可能解决方案。然后，他们可以概述客户为寻找价值所采取的步骤，并为每个步骤创建一个注释。
然后，团队会制定一系列步骤，形成他们的组织价值流，如下图所示，这是我们在第二章中首次呈现的运营价值流，共享责任的文化。
图 7.2 – 运营价值流示例
确定价值流步骤可能需要在绘图团队之间进行反复讨论，尤其是当存在多种条件时。评估最常见的条件可能更有意义。如果在运营价值流的候选数量上没有达成共识，可以考虑将所有候选方案提出，并观察它如何影响开发价值流。
当我们能够识别以下特征时，我们就能很好地定义一个运营价值流：
-
运营价值流的类型
-
名称
-
价值流描述
-
客户（们）
-
触发因素
-
客户所获得的价值
-
组织所获得的价值
当操作价值流的步骤确定后，接下来的任务是找出操作价值流依赖的解决方案。
寻找解决方案
一旦操作价值流的步骤被识别，下一步是查看每个步骤并确定该步骤是否通过解决方案来实现。SAFe 将解决方案定义为产品、系统或服务。解决方案可以是客户直接接触的内容，也可以仅限于内部使用。
解决方案与操作价值流步骤的映射不是一对一的。有些步骤可能需要相同的解决方案，而有些步骤可能不需要解决方案。
也有可能一个解决方案支持多个操作价值流。这样的解决方案及其相应的开发价值流可能在组织中是集中管理的。
我们为示例操作价值流识别了以下解决方案：
图 7.3 – 解决方案和操作价值流示例
一旦我们找到了解决方案，就离找到创造和维持这些解决方案的开发价值流更近了。我们将在下一节探讨如何确定这些开发价值流。
映射开发价值流
在 SAFe 中，发现开发价值流让我们更接近将这些价值流建模为 ART 或甚至更大的解决方案列车。
在映射解决方案如何作为开发价值流进行开发时，我们将集中于以下几个方面：
-
过程和工作流
-
参与该过程的人，如供应商和客户
让我们通过考虑用于开发解决方案的过程来开始我们的映射之旅。
寻找过程和工作流
在查看开发价值流时，我们可以首先将开发价值流视为一个黑盒，只有输入和输出可见。从那里开始，我们可以拼凑出中间的步骤。
开发价值流的初步“黑盒”通过识别以下特征形成：
-
开发价值流的触发点
-
开发价值流的第一步
-
开发价值流的最后一步
-
解决方案的需求率
黑盒的映射可以从确定解决方案开始，如下图所示：
图 7.4 – 开发流黑盒的初步映射
当价值流映射团队的成员就触发点、第一步、最后一步和需求率达成一致时，便可以开始填写第一步和最后一步之间发生的所有步骤。
连接各个环节
目前，映射团队开始填充开发价值流的第一步和最后一步之间的各个步骤。《价值流映射：如何可视化工作并对组织转型进行领导对齐》的作者建议步骤数应在 5 到 15 步之间，或者过程模块。
需要记住的是，在映射过程中，我们需要查看这些开发价值流的当前状态，确保不会遗漏过程中存在的瓶颈和弱点。如果不了解当前开发价值流的工作方式，很难想象出我们开发价值流的理想未来状态。
以下图表详细说明了我们示例开发价值流的各个步骤：
图 7.5 - 包含步骤的开发价值流
一旦确定了各个步骤，团队现在的任务是详细描述每个步骤。让我们看看这部分过程涉及的内容。
详细阐述每个步骤
现在步骤已经确定，我们应该看看每个步骤内部发生了什么。以下特征对于理解单个步骤中的内容非常重要：
-
批量大小（如果已定义）
-
缺陷
-
现有队列形式的在制品（WIP）
-
必要的批准
-
步骤指标，如前置时间、周期时间和等待时间
-
资源
请注意，前面的列表代表了步骤之间信息和材料自由流动的障碍。记录当前状态对于确定未来状态非常重要。我们将在寻找改进机会部分讨论这些问题。
在全面评估每个过程步骤后，下一步是确定谁负责执行每个过程步骤，以及谁将接收完成的产品。让我们来看看这个部分。
找到过程背后的人
确定涉及的人有助于查看潜在的未来状态开发价值流，以确定是否涉及了正确的团队或人员，以及现有团队是否能够承载工作量。
我们将专注于价值流中每个步骤内的以下两个角色：
-
执行过程步骤中工作的人。
-
过程步骤中工作完成后的接收人。他们可能是内部客户，因为他们接收来自过程步骤末端的信息和材料，继续下一步的工作，或者他们可能是外部客户。
通过我们收集的信息，我们对当前开发价值流的现状有了很好的了解。接下来，我们将看看是否存在改进的机会。
寻找改进的机会
一旦确定了开发价值流的当前状态，映射团队可以寻找改进的领域，并创建一个未来状态的开发价值流。他们还将创建一项改进计划，朝着这个未来状态迈进。
为了达到未来状态，映射团队需要对当前状态的开发价值流应用度量。这些度量将在每个步骤中收集，然后整合到评估整个开发价值流的度量中。
当前状态的开发价值流和未来状态的开发价值流的完整图景被保存在一个 DevOps 转型画布中。这个画布将整个研讨会的工作集中在一个地方，让我们能够看到当前的状态和目标的方向。
让我们通过检查当前状态度量来开始审视未来的状态，看看我们的开发价值流步骤。
流程步骤度量
在研讨会中，我们在每个步骤中识别度量，以确定该步骤是否为阻碍流动的瓶颈。通过进行这些测量，我们旨在找出瓶颈，并在未来状态的开发价值流中获得最佳结果。
我们为当前状态的开发价值流中的每个步骤衡量以下度量：
-
交付时间
-
流程时间
-
完成百分比和 准确性（%C&A）
现在让我们仔细看看这些度量。
流程时间和交付时间
在查看单个流程步骤时，我们想知道从它离开前一个步骤或触发点，到它离开当前步骤的时间总和。这个总时间被称为交付时间。
在交付时间内，可能会有等待时间，团队在执行流程步骤时可能在等待批准或审查。或者，也可能有价值添加工作的时间。这些流程步骤中的活动期间被称为流程时间。
我们之前在第四章，利用精益流保持工作流畅中讨论过周期时间，在那里我们看到周期时间与批次大小和团队已经处理的队列大小有关。如果团队在处理一批项目，周期时间将通过以下公式与流程时间相关：
使用这个公式，如果团队一次只处理一项工作，它的周期时间和流程时间将是相等的。
让我们看一个来自我们开发价值流的例子，重点关注价值流中的两个步骤：构建和集成测试。如果构建和测试是手动进行的，没有自动化，那么在构建步骤完成后，可能会有延迟，直到有人接手完成的构建并开始集成测试。集成测试需要 3 小时才能完成。构建到集成测试的典型交接延迟是 5 小时。这使得集成测试的流程时间等于 3 小时。因此，集成测试的交付时间是流程时间（3 小时）加上交接延迟时间（5 小时），即总共为 8 小时。
需要注意的是，提前时间和过程时间之间可能涉及不同的时间尺度。过程时间涉及工作日历（每周 5 个工作日），每个工作日包含 8 小时。提前时间通常使用标准的 7 天一周日历，每天包含 24 小时。在过程时间中可能会有例外，特别是在地理分布的开发环境下，允许跟随太阳的工作方式。团队还应明确区分工作周与日历周之间的不同。
%C&A
另一个过程步骤指标并不是由执行过程步骤的人员决定的，而是由过程步骤的信息或材料的接收者决定的，以便他们能够执行下一个过程步骤。
这些客户或接收者将被询问他们收到的交付物中有多少比例是无缺陷的，并且可以直接使用。这一比例被称为%C&A。
了解%C&A 很重要，因为它有助于识别改进的机会。低%C&A 得分的过程步骤将有更长的提前时间，因为需要进行返工。
让我们看一下开发价值流中的两个步骤：构建和集成测试。如果构建步骤产生的构建失败率是 20%，那么当它进入集成测试步骤时，%C&A 将是100% - 20% = 80%。
一旦确定了所有过程步骤的单个过程步骤指标，就可以计算整个开发价值流的复合价值流指标。
价值流指标
在发现单个过程步骤指标后，映射团队成员可以计算整个当前状态开发价值流的指标。这些指标是复合指标；也就是说，它们是通过将单个过程步骤指标相加或相乘得出的。
以下一组指标用于确定开发价值流的整体表现：
-
总过程时间
-
总提前时间
-
活动比率
-
滚动的%C&A
让我们看看如何计算这些指标。
总过程时间和总提前时间
我们希望评估开发价值流从最初的触发到功能发布所需的时间。这可以通过将每个过程步骤的提前时间相加来计算。这个总和称为总提前时间：
另一个需要关注的复合指标是开发价值流中有多少时间是活跃的开发时间。为此，我们可以将每个过程步骤的过程时间加在一起。这个总和称为总过程时间：
总过程时间和总提前时间用于计算下一个我们要看到的指标。
活动比率
一旦我们知道了总流程时间和总交付时间，我们可能想要查看开发价值流的生产力。为此，我们将查看总流程时间与总交付时间的比例。这个比例被称为 活动比率：
我们现在有了衡量开发价值流生产力的标准。接下来我们将查看的度量标准显示了质量是否嵌入到价值流中。
滚动 %C&A
记住，%C&A 是负责下一个流程步骤的人员根据交付物是否可用于后续处理而给出的每个流程步骤的测量标准。为了确定整个价值流的 %C&A，我们需要查看滚动的 %C&A。
为了确定滚动的 %C&A，我们将所有流程步骤的 %C&A 相乘。然后我们将该值乘以 100 得到一个百分比：
诸如流程时间、交付时间和 %C&A 等度量标准提供了重要数据，帮助我们确定瓶颈出现的位置。为了改善我们的开发价值流，我们需要看到理想的未来开发价值流是什么样子的。现在，让我们来探索如何做到这一点。
识别未来的开发价值流
在识别开发价值流的过程中，可能会有很多关于价值流步骤应是什么样子与实际是什么样子的讨论。这种不同的看法有助于理解“理想的”开发价值流，并且可能为开发价值流的演变提供输入。
映射未来状态价值流可能会在当前价值流映射完成并开始运行以收集数据后进行。这些数据对于突出流程中的瓶颈和其他薄弱环节非常有价值。
Karen Martin 和 Mike Osterling 在 Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation 中建议，在接近未来价值流时，应该考虑以下视角：
-
确定价值流中的正确步骤
-
寻找流程流动
-
寻找持续改进
让我们详细查看这些视角。
修复流程和步骤
精益思维的一个关键点是消除浪费。我们可以通过寻找那些不增值的流程和步骤并将其移除，来将这一点应用到我们的未来状态价值流映射中。我们首先将步骤分为增值、必要的非增值和不必要的非增值工作。我们尝试优先去除不必要的非增值工作。接下来，我们重新评估必要的非增值工作，看看它是否可以减少，或者是否可以重新分类为不必要的非增值工作并予以消除。
在去除这些步骤时，重要的是考虑这些步骤最初的目的，并确保即使去除步骤后，这个目的仍然可以成立。一个例子是价值流末端的检查步骤。这个步骤的目的是确保质量。如果价值流中包含了各个层级的自动化测试步骤，那么检查步骤就可以被去除，而不会影响质量。
修复价值流的另一种方法可能是增加额外的流程和步骤。如果重点是消除浪费，增加步骤可能看起来有悖常理，但即使是暂时性地增加步骤，也能让团队在价值流中建立新的工作方式，以便以后去除不必要的非增值工作。如果我们关注提高质量，我们可能希望在价值流中增加测试步骤，同时保留检查步骤，这样当我们对测试结果有信心时，就可以去除检查步骤。
寻求流程
仅仅确保价值流中有正确的步骤可能还不够。我们还希望确保工作在价值流中的各个步骤之间流动，没有问题或延迟。因此，我们会确保价值流中正在发生流动。
我们为每个价值流步骤收集的指标（处理时间、交付时间和%C&A）对于修复流程非常重要。它们有助于确定哪些步骤是价值流中的瓶颈。我们寻找那些交付时间包含长时间等待的步骤。我们还关注那些%C&A 百分比较低的步骤，因为这些步骤表明可能正在进行返工。
一旦我们找到了瓶颈步骤，就可以应用 Eliyahu M. Goldratt 在其著作《目标》中提出的约束理论。约束理论详细阐述了处理瓶颈并实现流动的以下步骤：
-
确定瓶颈。
-
决定如何克服瓶颈。
-
聚焦于克服瓶颈，服从所有其他的关注点。
-
克服瓶颈。
-
一旦瓶颈被克服，可能会出现其他瓶颈。返回到第一步来处理它们。
在特定步骤中消除瓶颈可能会在其他步骤中引入新的瓶颈，但总体的指标（总处理时间、总交付时间和滚动%C&A）将显示出改进。
寻求持续改进
优化步骤和消除瓶颈的结合可能为我们提供更好的价值流，但现在我们还需要确保有方法确保绩效在改善。因此，我们将建立两个到五个关键绩效指标（KPI），并定期跟踪它们的测量值。这些 KPI 可能涉及成本、质量、安全和士气等方面的测量。
在收集并计算当前和未来状态开发价值流的信息后，将这些信息放置在一个地方进行参考可能会有所帮助，特别是在我们寻求改善我们的价值流时。我们将看一个这样的地方——DevOps 转型画布。
DevOps 转型画布
DevOps 转型画布可以作为绘制开发价值流的背景，也可以用于识别未来状态和实施步骤，以带我们走向那里。
DevOps 转型画布包含当前状态价值流的区域，并且具有以下特征：
-
触发器
-
第一步
-
最后一步
-
需求率
-
价值流指标（总流程时间，总交付时间，活动比例，以及滚动 %C&A）
为了识别理想的未来状态，DevOps 转型画布包括以下领域，供工作坊期间填写：
-
目标价值流指标（总流程时间，总交付时间，活动比例，以及滚动 %C&A）
-
边界/限制
-
改进项
一个示例的 DevOps 转型画布如下所示。
图 7.6 – DevOps 转型画布
在工作坊完成后，工作开始于改善我们的开发价值流，并衡量改进的效果。这是我们将在下一章深入探讨的主题。
总结
在本章中，我们对价值流进行了全面的探讨。我们看到，将我们的活动与价值流对齐是 DevOps 中采用的一项关键方法，并且是通过实施路线图转型 SAFe 的重要组成部分。
我们首先审视了我们组织的现状。我们准备好让团队着手绘制我们的价值流，并通过 Gemba 走访了解我们是如何接收工作的。从这个检查中，我们看到了我们的流程以及其中的任何不足。
然后，我们着手发现并绘制我们的价值流。我们首先绘制了连接我们与客户之间的操作价值流。从那里开始，我们着手研究操作价值流如何通过解决方案为客户创造价值。有了这些解决方案，我们继续研究创建和维护这些解决方案的开发价值流。最后，我们查看了指标，以了解开发价值流的现状，并在努力迈向未来状态开发价值流时衡量我们的改进。
现在我们已经确定了我们的开发价值流，我们将寻找反馈，以查看我们的改进是否产生了预期的效果。下一章将向我们展示如何收集这些反馈。
问题
-
以下哪项在进行价值流绘制时没有被识别？
-
触发器
-
需求率
-
位置
-
第一步
-
-
以下哪项标识完成一个过程步骤所需的时间，从前一个过程步骤移交开始计算？
-
需求率
-
交付时间
-
流程时间
-
周期时间
-
-
谁决定过程步骤的%C&A？
-
客户
-
在过程步骤中工作的人
-
在下一个过程步骤中工作的人
-
在前一个过程步骤中工作的人
-
对于剩余问题，使用以下示意的价值流：
图 7.7 – 价值流示意图
-
总过程时间是多少？
-
0.5 小时
-
2 小时
-
1 小时
-
5 小时
-
-
总交付时间是多少？
-
5 小时
-
3 小时
-
1 小时
-
10 小时
-
-
活动比率是多少？
-
1.0
-
0.66
-
0.25
-
0.5
-
-
滚动的%C&A 是什么？
-
100%
-
490%
-
90%
-
400%
-
进一步阅读
-
《凤凰项目：关于 IT、DevOps 和帮助你的企业赢得胜利的小说》，作者：Gene Kim, George Spafford, 和 Kevin Behr – 一本关于 DevOps 的“必读”入门书籍。书中介绍了我们用来审视 VSM 的三种方法。
-
www.scaledagileframework.com/implementation-roadmap/– SAFe 上的一篇文章，讨论了实施路线图。 -
www.scaledagileframework.com/development-value-streams/– SAFe 上的一篇文章，讨论了开发价值流及其与运营价值流的关系。 -
《通过价值流管理推动 DevOps：使用经过验证的 VSM 方法改善 IT 价值流交付，竞争数字经济》，作者：Cecil “Gary” Rupp – 这是一本关于 VSM 的参考书，包含了价值流映射的指导。VSM 联盟使用的资源。
-
《价值流映射：如何可视化工作并为组织变革对齐领导力》，作者：Karen Martin 和 Mike Osterling – 关于如何进行价值流映射的参考书。
-
《目标》，作者：Eliyahu M. Goldratt – 本书介绍了约束理论。
第八章：测量价值流表现
在上一章中，我们通过参考《凤凰项目：关于 IT、DevOps 以及帮助企业成功的小说》中的三种方法，开始了对价值流的探索。第一种方法是通过建立价值流来实现流动。
本章超越了价值流的建立，转向验证它们的表现。对于本章，我们关注第二种方法：增强反馈回路。要遵循第二种方法，我们需要寻找并关注来自价值流的反馈。
我们可以使用度量标准作为反馈机制。出现了几种度量框架，如DevOps 研究与评估（DORA）指标和 Flow 框架®，它们可以作为反馈回路。
本章将涵盖以下主题：
-
创建良好的度量标准
-
查看 DORA 指标
-
查看 Flow 框架®和 Flow 指标
-
在 SAFe®中的度量标准理解
让我们首先了解如何获得有效的反馈。
创建良好的度量标准
我们最初在第五章《测量流程与解决方案》中看到过可以应用的不同类型的度量标准，我们在该章中查看了以下三个领域的度量：
-
开发过程
-
环境
-
提供的客户价值
可以充分覆盖这三个测量领域的度量标准集称为关键绩效指标（KPI）。
KPI 是用来衡量个人、团队、价值流或在我们案例中的敏捷发布列车（ART）是否实现其目标的度量标准。KPI 在特定时间点以及在给定时间段内进行评估，以突出趋势和目标的偏移或接近。
KPI 应该是客观的度量标准，而非受意见或解释影响。
在审视这些度量时，我们提醒大家避免使用虚荣指标，这些指标提供了不错的信息，但实际上并没有提供有意义的数据。比如网站的点击次数或某个服务的累计订阅者数量。
要设置 KPI，让我们看看下面的图示步骤，正如kpi.org所建议的那样。
图 8.1 — KPI 建立过程
让我们详细看看每一步。
描述目标或预期结果
在审视预期目标时，理解它是战略性目标还是更具战术性的结果非常重要。理想的目标应该是一个简洁、具体的结果，而不是一个广泛的目标。
这样，KPI 与目标和关键结果（OKR）是不同的。OKR 通常描述广泛的战略目标，预期的结果作为衡量该战略目标是否实现的标准。以下表格显示了一个 OKR 的示例：
| 目标 | 关键结果 |
|---|---|
| 我们通过卓越的可用性和服务在每个机会中让客户满意 | 到第三季度，我们的可用性得分从 6 提高到 9 |
| 到第三季度，我们的客户满意度得分从 7 提高到 10 | |
| 每月活跃用户的比例从 56%提高到 65% |
表格 8.1 — OKR 示例
KPI 指示是否达成了具体目标。一个 KPI 的例子是测量净推荐值（NPS）调查结果，通常来自忠实客户。
如果你已按照上一章节所示进行价值流映射，第七章，映射你的价值流，那么你期望的价值流未来状态就是你的 ART 或价值流可以努力实现的有效战术目标。
了解衡量目标的方法
为了实现你的目标，你需要了解衡量标准是如何工作的。是否有直接的衡量标准与目标相对应？如果有，这些应当是你使用的指标。
然而，如果你无法直接衡量目标，会发生什么呢？在这种情况下，你可能需要考虑提出假设，并通过实验来衡量假设的结果。
为每个目标选择衡量标准
既然目标已经设定，并且为每个目标定义了可能的衡量标准，是时候缩小选择范围，选取最重要的测量标准了。在大多数情况下，五到七个 KPI 就足以充分反映价值流的情况。集中精力关注几个关键的衡量标准，比沉浸在大量数据中要更有效。
我们希望我们的 KPI 具备以下特征：
-
回答有关我们表现的问题，以符合我们的目标
-
提供制定策略所需的清晰信息
-
有效且可以验证
-
鼓励员工表现出期望的行为
-
不难获取
现在我们有了衡量标准，接下来需要确定我们的价值流的理想值是什么。
如有必要，定义复合指标
可能有些衡量标准单独无法提供所有的信息来达成预期结果。这在目标是无形的情况下尤其重要，比如客户满意度。
如果是这种情况，你可能需要将单个衡量标准汇总成一个复合指标，以便于分析。
定义目标或阈值
我们希望看到自己在 KPI 上的表现。为了评估我们的表现，我们需要为每个 KPI 设定一个目标值。这个目标值应处于最佳表现的阈值范围内。阈值还应定义为表现不佳的标准。
定义并记录已选的衡量标准
现在我们已经定义了 KPI，并为良好、满意和差的表现设定了目标值和阈值。接下来是扩展和详细说明有关 KPI 的其他信息。
以下附加信息在收集和分析 KPI 时可能有帮助：
-
其预期目标
-
KPI
-
KPI 的描述
-
衡量标准的类型
-
计算该度量标准的公式
-
计量单位
-
测量数据的存储位置
-
谁负责测量并对其负责
-
数据来源
-
收集和报告的频率
-
负责验证的人员
-
负责验证的人员
-
KPI 展示的方法
对于开发价值流，可能可以从一套标准的 KPI 开始。这种标准由 DORA 制定，并在年度调查中进行考察。让我们来看一下这些指标，并看看它们在新的开发价值流中的适用性。
DORA 指标
自 2014 年以来，DORA 的 Nicole Forsgren、Gene Kim、Jez Humble，以及 Puppet 的 Alanna Brown 每年都会发布一份详细说明 DevOps 采纳状态的报告。每年，他们都会详细介绍 DevOps 采纳的总体情况以及受访者在采纳 DevOps 实践方面的成熟度。
2016 年，他们概述了一些旨在衡量不同组织中 DevOps 实践吞吐量和稳定性的指标。这些指标被称为 DORA 指标。
年度报告作为 DevOps 实践融入程度及其效果的晴雨表。每年，报告都会指出 DevOps 运动的以下几个方面：
-
关键 KPI
-
基于 KPI 的组织绩效水平
-
即将到来的趋势
现在让我们逐一查看这些方面。
DORA KPI 指标
《加速：DevOps 状态报告》通过以下四个指标来确定参与组织的绩效水平：
-
交付时间
-
部署频率
-
变更失败率
-
平均修复时间
前两个指标衡量组织的速度，或组织将变更交付到生产环境的速度。第三和第四个指标则衡量组织的稳定性，或者说组织在保持生产环境运行方面的能力。
让我们更详细地了解这些指标。
交付时间
我们在前一章节中讨论过交付时间，第七章，映射您的价值流。在这一章节中，我们看到每个过程步骤都有一个交付时间。总交付时间是所有过程步骤的交付时间之和。
DORA 指标关注的是变更的交付时间 —— 即从提交代码到版本控制库到将代码部署到生产环境的时间。这是总交付时间的一个子集。书籍《加速：构建与扩展高性能技术组织》的作者，Nicole Forsgren、Jez Humble 和 Gene Kim（所有人都是 DORA 指标定义的关键贡献者）指出，交付时间应该排除与设计相关的任何交付时间。这主要是因为设计交付时间何时开始计时存在不确定性。交付时间更容易测量且抗干扰性强。
让我们来看一下下面这个示例价值流的插图：
图 8.1 — DORA 前置时间的示例价值流
在上图中，我们看到通过持续集成，自动化在非生产环境中执行测试。如果没有发现错误，则该过程需要 4 小时，之后变更会被部署到暂存环境中。
在暂存环境中，可能没有进行自动化测试。这或许可以解释为什么从暂存环境到生产环境的迁移时间需要 40 小时。
所以，对于这个价值流，我们将每个阶段的时间加总（4 小时 + 40 小时），得出总前置时间为 44 小时。
部署频率
DORA 指标考察的是组织成功将代码部署到生产环境的频率。
如果我们继续使用我们的价值流示例，其前置时间为 44 小时，或 1.83 天（因为前置时间是按照 24/7 日历进行度量的），我们可以看到他们每月大约部署 16 次。
变更失败率
该指标是对部署过程质量的考察。它衡量发布到生产环境时，服务是否会出现降级或失败的情况，需要通过回滚、修补或实施热修复来进行修复。
确定变更失败率来源于检查部署记录，并查看是否有任何部署直接导致了生产环境的失败。
假设在我们的价值流中，我们查看了过去 12 次部署。在这 12 次部署中，生产环境遇到了三次问题。
我们的变更失败率将通过以下计算得出：
= 3/12 = 25%
恢复时间
该指标考察的是在生产环境中发生的服务故障。在这些故障中，恢复服务需要多长时间？
通常，当发生多个故障时，恢复时间指标以平均恢复时间（MTTR）表示，即恢复的平均时间。
在我们的价值流中，对于过去 12 次部署中的三次失败，如果每次失败的修复时间分别是 3 小时、2 小时和 7 小时，那么平均修复时间将是以下计算结果：
对于前述的四个指标，DORA 进行了响应的聚类分析，并确定了四个绩效水平。我们来看看这些级别。
DORA 指标绩效水平
每年在《加速：DevOps 状态》报告中，DORA 会分析反馈，查看受访者的表现水平。从四个 DORA 指标的 KPI 出发，他们创建了以下四个绩效水平：
-
精英
-
高
-
中等
-
低
每年的调查报告都会改变各个层级的标准。这是由于不仅每个组织的实践有了整体改善，行业整体的实践也在提升。2021 年的报告显示，Elite 或 High performer 层级的受访者人数相比往年有所增加，这表明持续改进在采用 DevOps 实践中的重要作用。
2022 年《DevOps 状态报告》在这些绩效水平上发生了重大变化。首次移除了 Elite 层级。调查结果表明，表现最好的群体的表现不再达到去年 Elite 层级的标准。需要更多的数据来寻找可能的原因。
《DevOps 状态报告》中的新兴趋势
为了适应变化的时代，调查还包括了一些关于组织环境的辅助问题，以便观察新兴的方面。最近的两份报告（2021 年和 2022 年）包含了以下附加内容：
-
自 2018 年以来，DORA 增加了另一个指标：可靠性。这个指标不仅衡量软件交付的表现，还衡量组织维护其环境或运营表现的能力。
-
DORA 自 2019 年以来一直在研究云基础设施的采用，指出云技术的采用是一项促进技术，能够提高所有四个 DORA 指标的 KPI。
-
2021 年的报告开始调查 SRE 实践的采用情况，作为寻找与可靠性相关性的一个途径。
-
除了调查技术 DevOps 实践外，DORA 还扩大了调查范围，涵盖了集成到开发过程中的文档和安全实践。
-
由于 COVID-19 大流行对既定工作模式的冲击，调查中增加了衡量组织在避免员工倦怠的同时，能够继续交付的复原力的问题。
-
作为安全实践调查的一部分，2022 年《DevOps 状态报告》调查了公司是否采取措施确保其软件供应链的安全。这些措施属于两个标准化框架之一：软件工件供应链等级（SLSA）和 安全软件开发 框架（SSDF）。
DORA 指标提供了一个很好的初步视角来衡量 KPI，但通常并非所有价值流所做的工作都直接与提供客户价值相关。为了衡量这些 KPI，采用 Flow Framework® 并衡量 Flow Metrics® 可能是一个不错的选择。接下来，我们来看看 Flow Framework® 模型。
Flow Framework® 和 Flow Metrics®
Flow Framework® 模型在 Mik Kersten 的书籍 Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework 中有详细描述。在这本书中，Kersten 解释了如何从基于项目的设计转向使用长期价值流进行产品开发。
为了衡量价值流的表现，Kersten 提出了流程框架®，这是一种流程文档结构，并使用流程度量®来衡量这些文档。
Kersten 最初制定了流程框架®，以衡量他所在公司 Tasktop 的软件交付流。通过审视 Tasktop 的价值流，Kersten 确定了他希望监控的以下四个结果：
-
价值
-
成本
-
质量
-
幸福感
他将这些项目与四个流程项相关联，这些流程项是 Tasktop 的价值流所做的工作类型。为了跟踪这些流程项的进展，Kersten 找到了四个这些流程项所表现出的流程度量®。
让我们通过检查四个流程项来开始了解流程框架®。
流程项
Kersten 确定了价值流所做的以下四种类型的工作：
-
待交付功能
-
缺陷修复
-
风险规避
-
技术债务减少
每个项目在利益相关者和这些项目的价值方面都有独特的差异。
功能
功能是带来直接商业价值的项目。客户从价值流中拉取功能，以提供他们想要或需要的解决方案。这项工作被认为是价值流将交付的主要类型的工作。
在 SAFe® 中，流程框架®的功能可以映射到功能，即将工作项分解为用户故事和启用故事，这些故事的时间框定为一个 程序增量 (PI)。
缺陷修复
价值流可能还会致力于修复发现的任何缺陷。这些修复可能是开发过程中发现的缺陷，也可能是已进入生产环境的缺陷。无论缺陷何时被发现，客户都会作为解决方案的一部分来拉取修复。
SAFe 没有直接识别修复缺陷的单独工作，但这类工作通常作为价值流使用的工作跟踪系统的一部分进行追踪。例如，当使用 Jira 的价值流识别出一个单独的问题类型（缺陷），以追踪修复缺陷的工作量。
风险规避
价值流可能会在合规、安全、治理和隐私等重要 非功能需求 (NFRs) 的组织中工作。这些非功能需求可能与它们所在的行业相关，这些行业可能有重要的合同要求或需要遵守的法规。旨在降低风险的项目由价值流交付给不同的利益相关者。这些利益相关者通常是组织内部的人员，如安全或治理团队。
在 SAFe 中，旨在满足非功能需求并减轻或消除风险的项目被称为合规启用项。时间框定为 PI 的合规启用项被识别为 ART 在一个 PI 内完成的功能，而以故事大小为单位的合规启用项则由 ART 内的个别团队进行处理。
技术债务减少
降低技术债务是价值流进行的重要工作。如果技术债务未能管理到可控水平，其他流动框架®项（特性、缺陷修复和风险规避）的交付将会受到架构不足的影响。
SAFe 将流动框架®的债务项归类为使能项。在讨论流动框架®的风险时，我们已经看到过合规使能项。其他类型的使能项有助于维持产品或解决方案的架构。
基础设施使能项由 ART 和团队使用，以增强开发过程。这类工作包括自动化测试和部署的集成与维护。
架构使能项直接改善 ART 产品或解决方案的架构。为了使这些改进能为未来特性所利用，一系列架构使能项被创建，这些被称为架构跑道。
探索使能项允许 ART 团队成员研究未知技术或确定最佳的功能实现方法。尖峰（Spikes）是探索使能项的常见例子。
使用流动框架®进行测量的价值流将其工作划分为这四个流动项。现在，我们将看看应用于这些项的度量。
流动度量
在流动框架®中，我们希望看到我们的价值流在所有工作类型中的表现。为此，我们将对每个流动项应用以下度量：
-
流动速度®
-
流动时间®
-
流动负荷®
-
流动效率®
此外，我们还有一个指标——流动分布®，这样我们可以看到价值流在哪些流动项上投入最多。
现在，让我们深入了解每个指标。
流动速度®
流动速度®查看在标准时间单位内完成的流动项数量，无论其类型如何。以下图表说明了一个价值流的流动速度®：
图 8.3 — 流动速度®的插图（版权 © 2018 Tasktop Technologies, Incorporated. 保留所有权利。经许可发布）
这类似于在 Scrum 中测量速度。一个稳定且运行良好的价值流将保持在多个时间周期内流动速度®的一致性。
流动时间®
流动时间®是完成单个流动项所需的时间，从它被接受到价值流中，到它从价值流中发布为止。流动时间®包括活跃时间和等待时间。以下图表说明了流动时间®：
图 8.4 – Flow Time® 插图（版权 © 2018 Tasktop Technologies Incorporated。保留所有权利。经许可发布）
Flow Time® 和交付时间的区别在于后者是一个客户指标。使用 Flow Time® 时，我们旨在确定开发我们的产品或解决方案所需的时间长度。
Flow Load®
我们在 第四章中讨论了大量 WIP 带来的问题，利用精益流动保持工作进行。Flow Load® 是 WIP 的一种衡量标准。如以下示意图所示，我们可以看到正在进行的 Flow Items 数量与 Flow Load® 的关系：
图 8.5 – Flow Load® 插图（版权© 2018 Tasktop Technologies Incorporated。保留所有权利。经许可发布）
记住，正如大量 WIP 会导致更长的交付时间和较低的性能，高 Flow Load® 值是性能降低的标志，这将导致更长的 Flow Times® 和降低的 Flow Velocity®。
Flow Efficiency®
我们之前看过 Flow Time®，并看到它包括了价值流在积极工作时和在某个过程步骤上等待时的时间。你可以通过观察积极时间与 Flow Time® 的比率来计算效率。
以下示意图通过计算 Flow Efficiency® 来完成我们之前关于 Flow Time® 的示例：
图 8.6 – Flow Efficiency® 插图（版权 © 2018 Tasktop Technologies Incorporated。保留所有权利。经许可发布）
Flow Efficiency® 类似于在 第七章中介绍的活动比率，绘制你的价值流。不同之处在于 Flow Efficiency® 关注的是价值流的开发视角。
Flow Distribution®
在查看到目前为止的 Flow Metrics® 时，我们还没有考虑正在测量的 Flow Item 类型。接下来我们将通过 Flow Distribution® 来指导我们判断价值流的工作是否平衡。
Flow Distribution® 查看某个价值流完成的 Flow Items 数量，并衡量每种类型的 Flow Item 占总 Flow Items 数量的百分比。Flow Distribution® 的计算通过以下示意图演示：
图 8.7 – Flow Distribution® 插图（版权 © 2018 Tasktop Technologies Incorporated。保留所有权利。经许可发布）
在 SAFe 中，通过查看 Flow Distribution®，ART 可以确定特性和使能器的适当分配比例，从而在交付客户价值和确保所需改进之间保持适当平衡。
在 SAFe 中的度量
在查看组织的价值流（作为 ART 实现时）时，Scaled Agile 建议从以下三个方面评估其表现：
-
成果
-
Flow
-
能力
让我们看看在 SAFe 中如何衡量这三个方面。
在 SAFe 中衡量成果
衡量成果的主要机制来源于建立和衡量价值流的 KPI。
我们在 第五章，衡量过程和解决方案 中看到了一些衡量客户成果的 KPI 框架，如 海盗（ARRRR）指标和适用性指标。为团队或 ART 确定 KPI 集合在本章前面已讨论过。
验证来自 Epic 的效益假设可能会导致理想的结果。Epic 开发通过创建 最小可行产品 (MVP) 并使用前导指标来衡量假设的价值，从而进行实验性地完成。密切监控前导指标会产生证据，验证或否定 Epic 假设，允许我们在进一步的 Epic 开发中进行 转向或坚持。
ART 上的敏捷团队还希望衡量他们在每个迭代中创建的迭代目标，以及他们为每个 PI 创建的 PI 目标。这些目标帮助团队集中精力，不是完成每个特性和故事，而是确保交付客户价值。
在 SAFe 中衡量 Flow
团队或 ART 决定采用的一些价值流 KPI 将与确保交付价值的表现相关。Scaled Agile 推荐使用 Flow Framework® 中的 Flow Metrics® 来确保 Flow 成功地实现产品交付。前面部分已经讨论了这些 Flow 项目和对应的 Flow Metrics®。
此外，Scaled Agile 还推荐一种额外的 Flow 指标：Flow 可预测性。该指标衡量团队和 ART 规划 PI 并实现 PI 目标的能力。
为了衡量 Flow 可预测性，团队和 ART 使用 SAFe 程序可预测性度量 (*PPM)。计算 PPM 时，团队查看 PI 规划期间确定的 PI 目标的原始业务价值。然后，他们将这些值的总和与在 PI 结束时的检查与适应研讨会上确定的已承诺和未承诺 PI 目标的实际业务价值进行比较。该度量通过以下公式确定：
以下表格显示了团队 PPM 计算的一个示例：
| PI 目标 | 计划（原始） 业务价值 | 实际 业务价值 | |
|---|---|---|---|
| 承诺目标 | 将索引速度提高 50% | 9 | 4 |
| 构建并发布电子商务功能 | 10 | 10 | |
| 构建并发布智能搜索功能 | 8 | 4 | |
| 未承诺目标 | 向数据库中添加 2,000 个新产品并对其进行索引 | 7 | 7 |
| 使用比特币支持购买 | 5 | 0 |
表 8.2 — 团队 PPM 计算示例
在前表中，承诺和未承诺 PI 目标的实际业务价值总和为 25。计划的业务价值总和为 27。然后，团队的 PPM 为 25/27：
图 8.8 — 团队预测性汇总示例到 PPM（© Scaled Agile, Inc. 版权所有）
上图显示了创建 PPM 的汇总过程。ART 通过对组成 ART 的各个团队的 PPM 值取平均来获得 PPM。
在 SAFe 中衡量能力
从更宏观的角度来看，采用 SAFe 的企业致力于实现业务敏捷性，在这里，战略与执行相结合，通过频繁交付客户价值来实现业务成果。
在 SAFe 中，业务敏捷性通过自我评估组织不同部门所实践的以下七项核心能力来衡量：
-
团队和技术敏捷性
-
敏捷产品交付
-
企业解决方案交付
-
精益组合管理
-
组织敏捷性
-
持续学习文化
-
精益敏捷领导力
团队和 ART 使用 DevOps 健康雷达评估他们在采纳 DevOps 原则和实践方面的能力。让我们来看看如何使用 DevOps 健康雷达。
DevOps 健康雷达
DevOps 健康雷达是一个工具，列出了与持续交付管道的四个方面相关的所有活动。DevOps 健康雷达的示意图如下：
图 8.9 — DevOps 健康雷达（©Scaled Agile, Inc. 版权所有）
对于持续交付管道的每个 16 项活动，团队和 ART 根据其在执行活动方面的成熟度进行自我评分。评分范围从 Sit（1 到 2），Crawl（3 到 4），Walk（5 到 6），Run（7 到 8）到 Fly（9 到 10），即顶峰。
团队和 ART 应定期使用 DevOps 健康雷达自我评估，以跟踪其 DevOps 性能的成熟度。此评估可在 Scaled Agile Framework 网站上免费获取，网址为 www.scaledagileframework.com/?ddownload=38794。我们将在第三部分中探讨持续交付管道及其活动。
摘要
在本章中，我们希望通过通过扩大反馈回路来采用第二种方法，确保我们走在正确的道路上。我们将为价值流使用的关键反馈回路通常是度量指标。
在选择指标时，我们希望将其视为 KPI。我们了解了如何从期望的目标开始，查看与这些目标相符的指标，精炼要收集的指标集合，并将它们收集为 KPI。
我们首先查看了作为 KPI 集合的一部分可以使用的一个标准指标：DORA 指标，它构成了年度《加速 DevOps 状态报告》的基础。通过收集这些指标并持续改进，可以通过与其他组织的比较，识别一个具有基准绩效水平的价值流，这些数据来自年度报告。
如果要查看除了提供客户价值之外的其他类型工作，可以查看 Tasktop 创建的 Flow Framework®。通过 Flow Framework®，我们概述了定义价值流所做工作的四个流动项，并为每个流动项设置了四个流动指标®，同时将流动分布®应用于一组流动项。
现在我们已经了解了如何查看反馈的测量指标，我们将进入第三种方式，应用持续实验和学习。在下一章中，我们将探索如何实现这一点的方法。
问题
-
一个价值流应拥有的最佳 KPI 数量是多少？
-
2 到 4
-
5 到 7
-
6 到 9
-
10 到 12
-
-
哪一项不是 KPI 的特征？
-
是有效的并且可以验证
-
鼓励员工做出期望的行为
-
回答关于向目标进展的问题
-
很难收集
-
-
哪一项不是 DORA 指标 KPI？
-
周期时间
-
部署频率
-
变更失败率
-
平均修复时间
-
-
DORA 指标的哪些 KPI 衡量稳定性？（选择两个）
-
交付时间
-
周期时间
-
部署频率
-
变更失败率
-
平均修复时间
-
-
哪一项不是 Flow Framework® 中的流动项？
-
特性
-
项目
-
风险规避
-
技术债务减少
-
-
哪一项不是 Flow Framework® 中的流动指标®？
-
流程速度®
-
流程负载®
-
流程可预测性®
-
流程时间®
-
进一步阅读
要了解更多关于本章中讨论的主题，请查看以下资源：
-
《凤凰项目：IT、DevOps 和助力业务成功的小说》 由 Gene Kim、George Spafford 和 Kevin Behr 编写
-
f.hubspotusercontent00.net/hubfs/8944057/The%20State%20of%20Value%20Stream%20Management%20Report%202021.pdf– 来自价值流管理联盟的 2021 年《价值流管理状态报告》 -
kpi.org/KPI-Basics– 介绍如何定义 KPI 以及如何制定你的 KPI 集合 -
www.devops-research.com/research.html#reports– DORA 和 Puppet Labs 发布的《加速 DevOps 状态报告》的所有版本的登陆页面 -
cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling– DORA 发布的 2019 年《加速 DevOps 现状报告》的发现 -
cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report– 2021 年《加速 DevOps 现状报告》的发现 -
《从项目到产品：如何在数字化颠覆的时代中生存与发展，运用 Flow Framework》 由 Mik Kersten 撰写 – 这是 Flow Framework®各个方面的参考书，包括 Flow 项目和 Flow 指标
-
flowframework.org/flow-metrics/– 来自 Flow Framework® Institute 的 Flow 指标分析 -
www.scaledagileframework.com/devops/– 这是scaledagileframework.com网站上的一篇文章，其中提供了 DevOps 健康雷达的描述等内容。 -
www.scaledagileframework.com/metrics/– 这篇来自scaledagileframework.com网站的文章阐述了 KPI、Flow 指标和其他评估形式之间的相互作用
第九章：9
带着持续学习迈向未来
到目前为止，我们已经通过《凤凰项目：关于 IT、DevOps 与帮助你的企业成功的小说》中提到的三种方式来研究价值流管理。通过第一种方式——建立流动性，我们探讨了如何确定并绘制我们的开发价值流。在第二种方式中，我们通过采用有意义的 KPI 来加强我们价值流中的反馈回路。
现在我们来看第三种方式：持续学习和实验。DevOps 的一个关键部分是认识到转型之旅没有终点。也就是说，你的组织将不断改进并设定进一步的目标，以创造更强大的价值流。随着你不断发现和优化，未来的价值流将会更加完善且没有尽头。
在本章中，我们将通过讨论以下主题来研究如何为你的价值流寻找未来状态：
-
采用持续学习文化
-
利用改进 Kata 来识别未来状态的价值流
-
将精益改进周期的所有部分作为改进 Kata 的一部分来实施
让我们从深入探讨持续学习开始我们的探索。
理解持续学习
1990 年，彼得·先锋（Peter Senge）出版了《第五项修炼：学习型组织的艺术与实践》。在书中，他描述了公司要成为学习型组织所需具备的特质或学科。
学习型组织允许员工通过自己的努力促进学习。这种学习推动组织的持续转型，使其不断追求改进。在今天的商业环境中，学习速度比竞争对手更快的组织具有显著的优势。
先锋（Senge）识别了学习型组织必须具备的以下五个特点或学科：
-
个人精通
-
心智模型
-
共同愿景
-
团队学习
-
系统思维
当组织在前四个学科上取得进展时，第五个学科——系统思维，将帮助组织进入下一阶段，成为学习型组织。
让我们仔细看看每个学科，看看如何在该学科上变得精通，并朝着成为学习型组织的目标前进。
个人精通
组织无法学习，除非组织内部的个体学习。组织内部的个体寻求成长并持续学习。先锋称这种动力为个人精通，它是传播到整个组织的种子。
建立个人精通的个体将发现两个在其发展中起作用的工具：
-
愿景：个体学习他们对自己重要的东西
-
视角变化：将当前现实视为有助于或阻碍愿景的因素
随着个人发展愿景并通过个人精通看到当前现实，他们会遇到愿景与当前现实之间的张力。这些张力是自然存在的，包括创造性张力，即愿景与当前现实之间的差距，以及情感张力，即个人在面对创造性张力时所感受到的情绪。
除了创造性张力和情感张力，个人还可能意识到结构性冲突。这些结构性冲突是当无法应对创造性和情感张力时，感到无力或不配的压倒性情绪。
在遇到前述的张力和结构性冲突时，以下反应可能会作为应对机制出现：
-
让我们的视野逐渐消退，以实现一个更简单的目标
-
冲突操控，即我们专注于避免我们不想要的东西
-
采用意志力策略，即个人通过压倒性的力量克服张力、冲突及其他阻力，以实现愿景
为了确保我们通过意志力策略来发展个人精通，个人必须诚实并拥抱真理。这使得能够从多个角度看待创造性的张力，并允许从多个角度出击以实现愿景。另一种有效的策略是学习不仅仅发生在意识层面。擅长个人精通的人允许潜意识发挥作用。一个例子就是不断重复一项新技能，直到它成为肌肉记忆。
随着个人发展个人精通并朝着愿景前进，以下一些变化会逐渐显现：
-
理性和直觉开始融合。这使得能够从多个角度看待问题。
-
个人开始看到自己与世界之间更多的联系。
-
同情心开始建立。
-
个人看到整体，并开始致力于那个整体。
这些特质是组织从个人身上所需要的。因此，组织必须朝着允许并鼓励员工走向个人精通的方向努力。它们需要创造一种鼓励愿景创造的氛围。它们必须赋予个人自由去探究并寻求真理。有时，这可能涉及质疑现状。这些自由会造就更好的个人，进而促进组织的成长。
随着个人在个人精通方面的成长，他们可能会改变他们的愿景和对当前现实的认知。这种变化会影响他们已经创造并使用的心智模型。接下来，我们将探讨这些心智模型的意义。
心智模型
我们之前看到，当个人发展个人精通时，他们会遇到创造性的张力，或者他们会看到他们的愿景与当前现实之间的差距。这种创造性的张力可能源自他们对世界运作方式的认知。这些认知，简单来说，就是作为学习型组织的心智模型。
思维模型塑造了学习者的感知，并服务于以下两个主要目的：
-
它帮助个人理解周围的世界
-
它告知个人如何采取行动
思维模型为个人和组织提供有关当前情况下某个特定问题有效的解决方案。因此，学习型组织通过在面对新信息时改变其思维模型而受益。
以下是个人和学习型组织在增加或改变思维模型时所需要的内容：
-
促进个人意识和反思技能的工具
-
试图制度化实践并将其与思维模型联系起来的基础设施
-
促进探究并允许对现有思维进行挑战的文化
森吉（Senge）确定了几个工具，帮助轻松改变思维模型。让我们仔细看看这些工具。
反思性实践
反思性实践是学习过程中进行反思的行为，以判断新信息是否符合现有的思维模型，或者是否需要创建新的思维模型。
反思是调整思维模型的关键工具。那些允许反思的人在这个领域做得很好。
宣称的理论与实际使用的理论
培养反思性实践技能使得进行比较变得容易。一个这样的比较是，宣称的理论与该理论应用之间是否存在差距。
以下是典型的比较方法，用以判断现有思维模型是否有效：
-
质疑抽象跃迁：看看你所看到的是否基于事实，还是仅仅是一个泛化的观点。
-
左栏分析：将某人所思考的内容（写在左栏）与他们所说的内容（写在右栏）进行比较。这个由克里斯·阿吉里斯（Chris Argyris）创造的练习使我们能够看到思想与实际说法之间的差异，揭示我们的先入之见和偏见。
左栏分析可以帮助人们了解他们真正的想法和感受，并以更透明的方式传达这些想法。正确使用时，这种方式可以让对话更具生产力，因为它带来了透明度。
为了进行左栏分析，找一张纸将其分为两栏。选取一次最近的对话，将对话中说的话写在右栏。回忆你对所说内容的想法和感受，并将它们记录在左栏，将想法与所说的内容对齐。
以下表格展示了一个左栏分析的例子。
| 我 在想什么 | 说了什么 |
|---|---|
| 他难道不知道我已经够忙了吗？我不确定还能应付更多。 | 老板：你能帮我个忙吗？我：我想可以。什么忙？ |
| 真的吗？三个月前我就已经失败了！他真想让我在纽约的更大人群面前再失败一次吗？ | 上司：由于你三个月前在会议上表现出色，我和市场团队想知道你是否愿意下个月在纽约的会议上发言。 我：那确实很吸引人。 |
| 我怎么才能逃避这个任务？ | 上司：太好了！让我给你发关于会议的详细信息。 我：好的，谢谢！ |
表格 9.1 – 左列分析，展示了思考与言语之间的区别
定期检查和调整思维模型的能力是第五项学科——系统思维的一个重要推动力。在面对新信息时不调整思维模型，会阻止组织看到整体，从而无法以整个系统的视角进行思考。
一个发展思维模型的例子来自 Scrum。Scrum 团队通常会用故事点来估算故事的工作量。Scrum 团队通常通过计划扑克来估算故事点。在计划扑克中，团队成员聚集在一起，协作发展1 点故事的概念，这个概念指的是完成一个故事所需的最小努力量，并作为相对比较其他故事的基准。
在计划扑克中，团队成员聚集在一起，并被分发一套卡片，上面标有故事点数。产品负责人朗读故事，团队成员分别选择一张卡片，上面显示他们认为该故事所需的故事点数。Scrum Master 作为协调员，随后倒数计时，所有成员同时揭示他们的选择。那些选择不同值的成员被邀请解释他们选择的原因。这个全体成员的讨论帮助团队构建一个关于如何看待整个团队工作的模型。
随着组织中对思维模型的认同逐步建立，它就成为了共享愿景的基础。让我们看看这个共享愿景有多重要。
共享愿景
在第二章《共享责任的文化》中，我们探讨了生成型文化。请记住，生成型文化的成员专注于共同的使命。共享的使命激励成员，团结团队成员，赋予他们专注力，去做任何必要的事情。
这个共享的使命可以被看作是共享愿景，这是 Senge 所说的学习型组织的一项学科。共享愿景简单来说，就是对“我们到底在建设什么？”这个问题的回答。
许多组织从外部导向或注重外部的愿景开始，比如超越其他竞争者。这种类型的愿景存在问题，它们往往是短暂的；一旦实现了目标，接下来怎么办？最好的愿景是内在的，或者说是专注于内部的，这些愿景会让学习型组织在不同情况下不断前进。
另一种可能无法作为共享愿景延续的愿景是消极愿景。消极愿景描述的是组织想要避免的事情，而不是它想要成为的样子。这种思维方式分散了组织所需的能量，剥夺了组织实现长期愿景的机会。回避策略也意味着组织无法改变其命运。这类愿景仅在短期内有效，无法为组织提供任何长期愿景。
共享愿景来自个人愿景。由个人掌控力产生的个人愿景来源并不一定来自领导者或预定的过程。组织中的任何人，只要保持清晰的愿景，并积极质疑当前现实，都能分享他们所发现的东西并邀请他人跟随。
随着愿景的传播，分享愿景并邀请他人跟随时可能会出现多种反应。以下是可以预见的几种反应：
-
招募
-
认同
-
承诺
-
合规性
-
不合规
-
冷漠
在上述列表中，前三项（招募、认同和承诺）是有利的反应，能够帮助将个人的愿景转化为共享愿景。列表中的其他反应（合规、不合规、冷漠）则是达成广泛共识的挑战，而这种共识是愿景成为组织共享的必要条件。
将一个愿景从个人转变为组织的过程确实包含了几个挑战。大量不同的观点可能削弱专注力，并在组织内引发冲突。共享愿景和当前现实之间的差距可能让组织中的人感到沮丧。人们可能会忘记自己是集体的一部分，从而失去彼此之间的联系。
分享愿景可能需要创新的合作方式。在《哈佛商业评论》的一篇文章中（hbr.org/2011/07/are-you-a-collaborative-leader），Salesforce 公司的 CEO 马克·贝尼奥夫邀请了 5000 名员工参加一场虚拟的离线管理会议。结果立竿见影：公司全员参与的对话迅速展开。对话持续了数周，并促成了一个更具赋能感和使命感的公司。
共享愿景的其他建议来自 Empuls 的 Veena Amin 撰写的博客文章（blog.empuls.io/organizational-vision/）。在文章中，她给出了以下建议：
-
统一组织：领导者的任务是找到并汇聚组织的各个部分，传达愿景。
-
让每个人都参与进来：一旦大家都聚集在一起，领导者应与每个人沟通，即使他们的角色在组织中看似不重要或不核心。
-
设定上下文：优秀的领导者会找到一种方式，将愿景与组织当前的状态联系起来。
-
转变控制：愿景的完善需要一种合作方式，这通常意味着要牺牲控制权。为了实现这一点，可能需要在组织层面移除一些控制。
在共同愿景的创建过程中，组织通过应对这些挑战，改进了其他领域的能力。通过个人掌握，愿景将朝着理想现实迈进。个人掌握的过程改变了组织的心智模式。我们会看到，通过团队学习，启动个人掌握并实现心智模式的改变，以达成共同愿景的过程。让我们来探讨团队学习的内容。
团队学习
当从当前现实到共同愿景的个人掌握之旅时，个人需要通过学习来完成这段旅程。一开始，这种学习是个体进行的。有效的团队最终会汇聚在一起，作为一个集体进行学习。这种汇聚就是团队学习。
实现团队学习不是通过团体培训来完成的。团队学习的主要机制来自于组织之间频繁的对话机会。这种对话可以采取以下形式：
-
对话：这种对话形式允许组织达成共同理解
-
讨论：这种对话形式通常是不同观点的交换，随后进行审视，通常是为了看哪种观点占上风
在这两种形式中，组织试图超越个人的理解，达到共同的理解。通常会交换多个观点。对话与讨论的关键区别在于：对话允许不同的选择出现，而讨论则只有一个观点：获胜。
赛基谈到了实现团队学习的对话所需的三项必备条件：
-
能够提出假设，审视它们，并超越这些假设
-
所有参与者都能够把彼此看作同事和平等的人
-
拥有一个专门的引导者，可以为团队保持对话的上下文。
通过前述组件，领导者可以通过对话保持团队的学习。他们帮助团队保持对目标的所有权。
团队学习的另一种机制是意识到防御性惯例。随着团队意识到当前现实与共同愿景之间的差距，防御性惯例可能会出现。一位优秀的引导者可以识别防御性惯例并以以下方式处理它们：
-
直接向组织询问问题的原因
-
将防御性惯例视为团队学习未发生的信号
团队学习的一个例子是“群体编程”。这一实践由 Woody Zuill 开发，是“结对编程”实践的延伸。在群体编程中，团队的一名成员担任“驾驶员”角色，而其他成员则担任“导航员”。“驾驶员”执行主要任务，通常是编写代码，并从“导航员”那里获得反馈。在一段时间后，“驾驶员”角色会轮换给其他团队成员。
群体编程作为一种团队学习方法非常有效，因为团队在合作的过程中，他们同时学习并分享新的见解。
随着团队一起学习并获得对共同愿景的共识，改变思维模型，第五种学科——系统思维出现了。让我们来看一下这个最终的学科，它使学习型组织能够真正繁荣。
系统思维
系统思维是学习型组织通过其他四个学科的适当实践和技能发展所获得的视角转变。学习型组织可以看待自己，看到组成部分和相互联系。
系统思维源自于在开始和改进其他四个学科（个人修炼、思维模型、共享愿景和团队学习）的努力积累。在某些时刻，组织达到了某个学科的成熟水平，能够扩展到系统思维。
当个人调适到个人修炼的状态时，他们开始看到整体以及自己在集体中的角色。这种意识是系统思维的必要部分。
集体整体的意识会影响个人已建立的思维模型。个人的思维模型转变为学习型组织中共享的集体思维模型，并且定义了角色。
对集体思维模型的改变为组织的共享愿景铺平了道路。组织成员对这一共享愿景产生了承诺。他们与团队领导一起合作，通过对话学习如何将共享愿景传递到整个组织，并扩展这一愿景，使其包括学习型组织中的每个人。
可视化系统思维的一种方式是冰山模型。正如 ecochallenge.org 网站上的这篇文章所详细介绍的那样（ecochallenge.org/iceberg-model/），系统思维类似于冰山，只有 10%暴露在水面上，而 90%在水面下，这部分影响着可见部分。
冰山模型详细描述了以下四个层次：
-
事件层次：这是系统思维中唯一可见的层次。这代表了我们对外部世界的感知。
-
模式层次：这个层次试图解释我们在事件层次的感知。
-
结构层次：这个层次解释了我们观察到的模式背后的原因。
-
思维模型：这代表了创造结构的态度、信念和假设。
作为一个采用五大领域的学习型组织，成员们在不断发现的过程中，更多地了解自己以及如何改进。组织定期纳入新的学习，持续改进。让我们通过改进 Kata来看一下这一过程的样貌。
应用改进 Kata
改进 Kata 是源自丰田生产系统的模式之一，并在 Mike Rother 的书籍《丰田 Kata：为改进、适应性和卓越结果管理人员》中有详细描述。在改进 Kata 中，我们通过以下四个步骤朝着改进的方向前进：
-
我们设想我们的理想未来状态。
-
我们审视当前的状态或状况。
-
我们确定下一个目标，使我们更接近理想的未来状态。
-
我们进行实验，在计划-执行-检查-调整（PDCA）或精益改进循环中评估和学习，看看结果是否将我们更接近理想的未来状态。
改进 Kata 四个步骤的示意图如下：
图 9.1 – 改进 Kata
使用改进 Kata 的一个例子是敏捷回顾会。回顾会是团队定期举行的会议，在会议中，团队会考虑以下问题：
-
做得好的方面是什么？
-
做得不好的方面是什么？
-
我们应采取哪些行动（包括保持有效的做法）来实现改进？
前两个问题让我们探索当前状态和未来状态。第三个问题则启动了向理想未来状态前进的行动。在 Scrum 中，这些行动被添加到团队的工作待办事项中，团队可以在这些事项上工作。通过这种方式，团队利用 PDCA 学习循环朝着理想状态前进。
通过目标逐步实现理想的未来状态，需要不断的实验。这些实验是在遵循 PDCA 格式的学习循环中进行的。让我们看看在每个精益 改进循环中会发生什么。
关闭精益改进循环
持续改进是精益思维的核心。改进应融入到未来的工作中，并通过有效性进行衡量。
为了使我们的价值流采用这种方法，必须将其工作视为一个学习循环。这个循环最流行的模型是精益改进循环或PDCA循环。
这个循环与 W. Edwards Deming 相关，他称之为谢瓦特循环（Shewhart cycle），以纪念 Walter Shewhart。这一循环在下图中有所说明：
图 9.2 – PDCA 循环
如前面的图所示，该循环有四个活动阶段：
-
计划：确定采取什么迭代步骤。这可能是一个在待办事项列表中优先级较高的步骤。制定实施该步骤后可能发生的结果假设。
-
执行：将该步骤添加到你的价值流工作流程中。
-
检查：检查（或持续检查）你为价值流测量的指标。
-
行动（或调整）：执行这一步骤是否达到了假设？如果达到了，就保留该步骤。如果没有，可能需要通过制定另一个假设来进行调整。
这个周期可以在短期和长期内执行。在 SAFe®中，实践 Scrum 的 ART 团队将每个冲刺进行这个周期的操作，并与其他 ART 团队一起，在每个程序增量（PI）中执行这个周期。
总结
本章中，我们探讨了价值流如何通过采纳持续学习和实验来遵循第三种方法。我们看到，这一切始于组织成为学习型组织的旅程。它们通过个人精通、心理模型、共享愿景、团队学习和最终的系统思维五大学科来磨练自己的学习。
学习型组织朝着共同愿景迈进的一种方法是遵循改进卡塔。在改进卡塔中，在确定了理想的未来状态之后，识别当前状态。然后，价值流识别一个目标并进行实验。实验在 PDCA 周期中进行，学习成果用于判断价值流是否更接近或远离理想的未来状态。
精益改进周期或 PDCA 周期被用作改进卡塔的实验框架。价值流规划实验，执行实验，并检查结果是否验证了实验的假设。根据结果，价值流会做出调整。
这完成了本书的第二部分，我们讨论了如何在价值流中对齐工作，如何衡量价值流交付价值的效果，以及如何根据价值流的指标，走上持续学习的道路以改进价值流。在第三部分，我们将探讨在 SAFe 中，作为 ART 的价值流如何通过流程和技术的结合（称为持续交付管道）来执行交付价值的任务。
问题
通过回答这些问题来测试你对本章概念的理解。
-
在个人精通中，是什么与愿景产生了冲突？
-
虚拟现实
-
当前现实
-
渴望的现实
-
过去的现实
-
-
哪些类型的讨论有助于团队学习？（选择两个）
-
冲突
-
对话
-
讲座
-
讨论
-
独白
-
-
改进卡塔的第一步是什么？
-
确定理想的未来状态
-
确定当前状态
-
确定一个目标
-
执行 PDCA 周期，以迭代达到目标
-
-
PDCA 周期中的C代表什么？
-
结论
-
停止
-
检查
-
资本
-
进一步阅读
-
《凤凰项目：关于 IT、DevOps 和帮助你的业务成功的小说》 by Gene Kim, George Spafford, and Kevin Behr – 我们使用这本书及其三种方法讨论价值流的创建和维护。
-
《第五项修炼：学习型组织的艺术与实践》 by Peter M. Senge – 在学习如何成为学习型组织时的参考书。
-
valshebnik.com/blog/left-hand-column/：本文优秀地描述了左手列分析，包括定义、示例和危险。 -
hbr.org/2011/07/are-you-a-collaborative-leader：本文探讨了领导者如何与公司合作和分享。 -
blog.empuls.io/organizational-vision/：本文探讨了分享组织愿景的益处、技巧和窍门。 -
ecochallenge.org/iceberg-model/：描述冰山模型的文章，展示系统思维。 -
《丰田方式：管理人员的改进、适应性和优异成果》 by Mike Rother – 关于改进方式的详细方法。
第三部分：优化 – 启用持续交付管道
在 SAFe®中，持续交付管道是过程和自动化的结合，允许价值流（作为敏捷发布列车（ARTs）实施）按节奏开发和部署，但在适合组织时按需发布。
我们将从持续探索开始探索持续交付管道。通过持续探索，我们将把新解决方案或增强的想法设置为实验，以便详细阐述、研究和为 PI 计划设置优先级。
在持续集成阶段的持续交付管道中，我们将开发我们的实验。在编码后，我们将开始自动化过程，以允许测试和打包（如果测试成功）。
在持续部署期间，我们将努力将我们的解决方案部署到生产环境。我们将努力在不干扰生产环境和客户的情况下部署这些变更，同时允许在生产环境中进行测试。我们将讨论如何在第十二章中执行部署和发布分离的方法。
最后，我们将按需发布。这使我们能够向客户交付价值。我们将监控发布，确保验证我们实验的假设，并且在安全性或可用性方面不会对生产环境造成不良影响。
本书的这一部分包括以下章节：
-
第十章，持续探索与发现新功能
-
第十一章，解决方案开发的持续集成
-
第十二章，持续部署到生产环境
-
第十三章，按需发布以实现价值
第十章：持续探索与发现新特性
在持续探索阶段，产品管理团队与敏捷发布列车（ART）内外的人一起工作，寻找能够为客户提供价值的特性，探索客户的需求与愿望，验证新特性在当前架构中的可行性，并为 ART 准备待开发的新特性。
正如我们在以下插图中看到的，持续探索是持续交付管道的第一阶段，它为后续的开发建立了触发点：
图 10.1 – 持续交付管道（© Scaled Agile，版权所有）
简而言之，本章将讨论以下活动：
-
假设客户价值
-
协作与研究
-
关于架构的讨论
-
综合工作
产品管理在持续探索阶段所做的工作对 ART 来说非常重要，因为它有助于为 ART 执行共享任务或愿景设定背景。让我们来看一下产品管理为即将到来的项目增量（PI）所做的准备工作。
假设客户价值
“如果我问人们他们想要什么，他们会说更快的马。” 这句常被（可能错误地）归于亨利·福特的话，突出了产品经理在寻找新特性或新产品时遇到的问题。客户可能根本不知道自己想要什么，或者无法想象那些来自不同思路或创新方法的产品和特性。
通过解决产品开发中的未知问题的一种方法，是采用埃里克·里斯（Eric Ries）在《精益创业：当今企业家如何利用持续创新创造极为成功的企业》一书中强调的方法。在这本书中，里斯展示了一种与客户协作进行迭代式产品开发的方法，其中一些方法体现在他提出的学习循环中，即构建-衡量-学习循环。
构建-衡量-学习循环是一个迭代式的产品开发循环，在这个过程中，精益创业公司通过实验发现与客户产生共鸣的产品和特性。该循环的以下部分是在客户参与下完成的：
-
构建：通常，第一次迭代中出现的最小可行产品（MVP）是启动与客户学习过程的关键。
-
衡量：与客户的对话或度量指标的应用，帮助确定什么有效，什么无效
-
学习：凭借从先前收集到的度量数据中获得的知识，做出是否调整方向或坚持下去的选择
构建-衡量-学习循环在以下图示中得以说明：
图 10.2 – 构建-衡量-学习循环
构建-衡量-学习循环与精益改进或 PDCA 循环的周期相同，后者在《第九章》中讨论过，通过持续学习迈向未来。构建发生在 PDCA 循环的计划和执行阶段。衡量则是我们在 PDCA 循环中的检查步骤。一旦完成衡量步骤，我们通过转型或坚持来学习（或调整）。
在明确了构建-衡量-学习循环的三个部分后，让我们来审视第一个循环以及它如何使用 MVP。
使用 MVP 进行构建
创建 MVP 是精益创业公司学习之旅的第一步。它为这些初创公司提供了一种检查手段，用来判断他们是否走在正确的道路上。虽然不同的人对 MVP 的定义有不同的看法，包括我们稍后会探讨的 SAFe®，但我们先来看看 Eric Ries 在《精益创业：今天的企业家如何运用持续创新创建极具成功的企业》中提出的定义。
根据 Ries 的说法，MVP 不一定非得是一个实际的产品，或者是最终形式的产品。唯一的必要条件是它能向顾客传达产品或服务的某种信息。
以下是 Ries 引用的作为 MVP 示例的几个例子：
-
Dropbox 制作了一个视频，帮助顾客理解基于云的文件存储和同步的概念，并解释其相对于竞争对手的优势。
-
Groupon 最初是一个 WordPress 博客，顾客通过电子邮件请求提供作为新博客文章发布的 PDF 优惠券。
-
总部位于奥斯丁的初创公司 Food on the Table 开始提供服务，通过与第一位顾客紧密合作，聚合顾客购物清单和食谱中的食材，并在当地杂货店完成采购，从而定义服务内容和工作方式。
这些例子表明，MVP 是为了回答以下问题而构建的：
-
我们的产品或服务应该是什么样子？
-
我们的产品或服务能与顾客产生共鸣吗？
-
我们能提供这个产品或服务吗？
初创公司通过与顾客对话，并将创新会计应用到对他们来说重要的指标中，来回答这些问题。让我们来看一下创新会计中使用的衡量标准。
使用创新会计进行衡量
创建 MVP 的目的是验证或推翻 Ries 所说的“信念假设”。在看“构建-衡量-学习”循环时，MVP 经历三个里程碑。这些里程碑有助于评估 MVP 的进展，并说明学习中的关键检查点：
-
确立基准：创建 MVP 是一个基准，用于验证“信念假设”是否有效。这个假设也可以被视为一个假设，实验（MVP）可以验证它。
-
调整引擎：根据客观数据，我们应该着眼于做出调整，帮助我们更接近目标。
-
转型或坚持：根据我们收集的数据，可能促使我们继续当前的路径并进行进一步的优化，或者进行转型。转型可能会让我们为产品或服务选择不同的道路。
对于客观数据，我们要避免虚荣指标。我们之前在第五章中讨论过 Ries 最初对指标的标准，即衡量过程和解决方案。以下品质在此重复：
-
可操作性：这个指标是否显示了清晰的因果关系？换句话说，通过执行相同的操作，你能否复制出相同的结果？
-
可访问性：价值链中的每个人是否都能访问相同的数据，并且这些数据是否能被所有人理解？
-
可审计性：报告是否有可信度？
当然，最好的数据来源是直接的消费者反馈。在许多情况下，如果你无法理解指标所传达的信息，你可能需要通过采访客户来获得进一步的洞察。
通过从真实的指标或客户反馈中收集到的客观数据，接下来需要做出决策，以确保初创企业的持续性。我们是否需要为我们的 MVP（转型）走不同的方向，还是继续当前的方向并增加更多的改进（坚持）？让我们来分析决定中涉及的因素。
学会转型或坚持
根据客户反馈或客观数据，精益创业法有一个问题需要回答：我们当前产品或服务的方向是否能让我们实现目标，并为客户提供价值？如果可以，那我们就继续沿着这条道路走，增加更多的功能。如果不行，我们则需要毫不犹豫地转向另一个方向，或者进行转型。
转型可能是对产品或服务的一个或多个方面进行改变。Ries 列举了以下几种转型，旨在帮助产品或服务提供更好的价值：
-
缩小范围转型：产品或服务的某一功能比其他任何功能都更能引起客户的共鸣。你将专注于这个功能，并使其成为产品或服务的核心。
-
放大范围转型：产品或服务本身并未提供足够的客户价值，但如果作为另一个产品或服务的功能捆绑在一起，可能会证明其价值。
-
客户细分转型：产品或服务不仅满足了最初目标客户的需求，还能满足其他客户的需求。
-
客户需求转型：在与客户合作时，你可能会发现通过不同的产品或服务可以提供更大的价值。例如，Potbelly 三明治店最初是一家提供食物的古董店。
对于大多数类型的转型，产品或服务会发生变化，通常会发生到完全不同于原始产品或服务的程度，但也有一些转型，MVP、产品或服务会被放弃。
面对任何类型的转型前景时，保持客观判断是否转型或坚持非常重要。许多初创公司失败的原因是他们没有及时转型，或者转型过晚。
现在我们已经了解了如何创建我们的 MVP 并通过构建-测量-学习循环验证我们的假设，让我们来看一下 SAFe®如何将构建-测量-学习和创新会计纳入 SAFe 精益创业循环，这一循环将实验应用于史诗的执行。
SAFe®精益创业循环
在 SAFe 中，史诗是一项重要的产品开发工作，不限定在特定的时间框架内。史诗描述了一个组织可能希望对产品进行的长期变更。ART 团队将史诗作为实验，用以指导可能的产品开发。
请注意，虽然史诗和项目可能有相似的定义，但史诗的范围是灵活的。项目有明确的开始和结束日期，以及固定的范围，所有需求必须通过完成构建交付物的任务来满足。而史诗实际上为实验奠定了基础，实验可能会也可能不会完成。
史诗由精益商业案例描述，精益商业案例是一个简短的文档，概述了史诗的需求、可能的解决方案选择以及实验提案。实验以史诗假设声明的形式编写，描述了提议的价值、业务成果的假设、通过领先指标衡量实验的结果以及可能作为约束的任何非功能需求（NFRs）。MVP 被包含在精益商业案例中，作为实验的实施内容。
史诗的假设声明通过概述提案、其潜在收益、拟议的衡量标准和约束条件，为实验设定了基调。以下是一个史诗假设声明的示例，详细描述了一个提议的披萨无人机配送服务：
| 史诗描述 |
|---|
-
针对居住在城市地区的客户…
-
希望快速便捷披萨配送的客户，
-
PizzaBot 2022…
-
是基于无人机的自动化披萨配送系统…
-
那些能快速、轻松地从餐厅配送披萨的客户。
-
与当前基于汽车的披萨配送（标准配送方式）不同，
-
我们的解决方案通过使用更便宜的电力而非汽油来降低开销成本。
|
| 商业成果 |
|---|
-
更好的客户体验，配送时间更快（披萨更热）
-
通过减少送货司机并节省燃料来降低开销成本
|
| 领先指标 |
|---|
-
平均配送时间减少
-
开销成本减少
-
更高的 NPS 调查分数
|
| 非功能需求 | 必须遵守有关商业空中无人机使用的当地条例 |
|---|
表格 10.1 – 史诗假设声明示例
史诗中的 MVP 与 Ries 的定义有所不同。在这里，MVP 指的是一套最小的功能特性，用于构建一个初步产品，供客户使用。这些特性将由 ART 开发。
领先指标度量用于验证我们实验的假设。它们可以告诉我们是否走在正确的道路上。我们希望我们的度量是可操作的、可访问的和可审计的，这样它们就不是虚荣指标。我们还希望它们是真正的领先指标，即在最早的时刻就能可靠地预测潜在价值，而无需等待趋势的出现。
SAFe 精益创业周期确实以 Eric Ries 提出的构建-测量-学习循环为模型。在 SAFe 精益创业周期中，ART 与史诗按以下方式合作：
-
构建：开发并发布 MVP 给客户
-
测量：史诗的精益商业案例中定义的领先指标度量决定了客户的反馈
-
学习：根据领先指标度量，必须做出决策，决定是坚持继续开发 MVP 之外的功能；还是转变方向，按照现有状态完成史诗，并创建一个包含新假设的新史诗；或者停止该史诗，不再开发 MVP 之外的内容。
以下图表展示了 SAFe 精益创业周期，概述了史诗的路径以及根据假设验证可能发生的路径：
图 10.3 – SAFe 精益创业周期（©Scaled Agile，保留所有权利）
这一活动的结果是史诗的待办事项列表。每个史诗都概述了一个实验，其中包含潜在价值的假设陈述和一个 MVP，使我们能够执行该实验。
基于构建-测量-学习循环的 SAFe 精益创业周期，产品管理建立价值假设和 MVP 作为验证假设的实验，但产品管理并非单独进行此操作。他们与他人合作，在周期的构建部分共同完善假设和实验。我们将在下一节探讨这种协作。
协作与研究
产品管理需要来自不同人员的输入，每个人对解决方案的需求都有独特的看法。优秀的产品经理知道，他们必须与这些人合作，发现能够构成利益假设基础的特性，或者 MVP 必须具备的功能。
在这里，我们将看看良好的产品管理需要形成 MVP 的两个方面。以下方面构成了产品管理开展 MVP 相关活动的基础：
-
与客户和利益相关者的合作
-
研究以引出产品特性和非功能需求（NFRs）
让我们从产品管理协调的主要协作开始。
与客户和利益相关者的合作
最好的产品是团队共同创造的。从早期阶段到设计、实施和测试阶段——最终导致发布，这一过程都是如此。
产品开发与以下人员合作，定义产品的特性：
-
客户
-
系统架构师或工程师
-
业务负责人
-
产品负责人或团队
让我们来审视产品管理与这些团队合作所创造的关系。
客户
客户是价值的最终裁定者。毕竟，他们是你为之构建产品的人。他们的反馈是评估产品是否满足需求的最直接来源。
除了那些可能不知道自己需要什么解决方案的客户，产品管理团队还必须关注那些只专注于做增量改进的客户，因为这种做法可能不会有助于产品的长期战略。
系统架构师
系统架构师从架构角度最了解产品。他们理解由启用工具确定的能力，以及由非功能需求（NFRs）识别的约束。
产品管理团队与系统架构师合作，了解新特性的平衡、使用启用工具进行长期开发、以及维护和减少技术债务的重要性，这一点至关重要。同时，系统架构师也需要了解客户的需求和关注点。因此，产品管理、系统架构师与客户之间的密切合作至关重要。
业务负责人
业务负责人是从组织角度来看最关键的利益相关者。他们需要确保 ART 开发的解决方案与组织的使命和整体战略保持一致。
产品管理与业务负责人合作，了解 ART 可能处理的特性优先级。
产品负责人和敏捷团队
ART 上的敏捷团队负责开发、部署、发布和维护解决方案。每个敏捷团队中的关键人物是产品负责人，他们作为内容权威，帮助团队详细描述故事和验收标准，并接受完成的故事。
因为团队最接近实际工作和实施，他们对产品和用户关注点的洞察不容忽视。优秀的产品经理会采纳敏捷团队的反馈。
现在我们已经了解了产品管理与哪些角色进行合作并接受反馈。接下来，我们应该审视这些反馈将以什么形式呈现。
研究活动
产品管理通过以下几种研究活动与客户、业务负责人和产品负责人合作，获取客户需求的洞察，并了解产品如何创造价值：
这些类型的活动可以分为以下几类：
-
与客户的主要市场调研
-
通过前往现场（Gemba walks）和客户拜访，了解客户体验
-
次级市场调研，以进一步深入了解客户的思维方式
-
精益用户体验（Lean UX）来建立实验
让我们来逐一审视这些活动。
主要市场调研
初级市场调研特点是产品管理和客户之间的直接合作。此类直接合作可能包括以下方法：
-
焦点小组
-
用户调查或问卷
-
创新游戏
焦点小组、调查和问卷直接询问产品或服务的问题。它们可能会涉及潜在的未来需求，但有时客户无法超越短期产品使用的想象。
这就是创新游戏的作用所在。创新游戏是*《创新游戏：通过协作游戏创造突破性产品》*（作者：卢克·霍曼）中描述的几项活动。在书中，游戏有助于发现未被言明的需求、客户如何看待成功以及你的产品如何与客户需求契合。
初级市场调研通常在组织内部进行，但也可以在其他地方收集到更多的见解。此时，Gemba 走访和客户现场访问就显得尤为重要。我们现在来了解一下它们。
Gemba 走访
Genchi genbutsu在日语中意为“亲自去看并理解”。Gemba 走访是一项体验genchi genbutsu的活动。它最早应用于丰田生产系统，是精益思维的核心内容。在 Gemba 走访中，人们会亲自到产品使用的地方，了解实际环境。
《精益创业：今天的企业家如何利用持续创新创造极其成功的企业》（作者：埃里克·里斯）中的一个 Gemba 走访的例子。2004 年丰田赛那迷你货车的设计由横谷裕司主导。他在北美市场的经验较少，而赛那的目标市场正是北美。因此，他提出了一项计划：在一辆现有的赛那迷你货车中，进行一次覆盖加拿大各省、美国五十个州及部分墨西哥的公路旅行，同时采访客户。
横谷发现，北美客户比日本客户进行更多的长途汽车旅行。另一个发现是，迷你货车需要更好地服务于通常占据车内三分之二空间的乘客：孩子们。根据这些数据，横谷添加了更多具有儿童吸引力的功能，以便更好地适应长途旅行。
这些功能的选择产生了深远的影响。2004 年款赛那车型的销量比前一年增长了 60%。
二级市场调研
二级市场调研是指不涉及与客户直接合作的活动。这些活动有助于了解客户和市场。
一些让你了解客户需求和愿望的活动包括以下内容：
-
创建人物角色，虚构的客户代表
-
使用同理心图了解客户的想法和情感
-
通过旅程地图检查客户的旅程，包括情感
这些文档在与客户会面时可以进行完善和修改。
精益用户体验（Lean UX）
在开发功能时，我们希望使用类似于 Build-Measure-Learn 的 PDCA 学习循环。这种增量学习循环帮助我们将史诗细化为功能。
这种类型的一个循环来源于 Jeff Gothelf 和 Josh Seiden 所著的《Lean UX: Designing Great Products with Agile Teams》一书。书中提到的 精益用户体验（Lean UX）是一种心态和过程，通过逐步发现产品功能并验证客户价值。
Scaled Agile 已将这一过程模型调整为适用于 用户界面（UI）和 用户体验（UX）团队以外的领域。以下来自 Scaled Agile 的图表展示了这一过程：
图 10.4 – 精益 UX 过程图（© Scaled Agile, Inc. 保留所有权利）
让我们逐步分析过程的每个步骤。
构建效益假设
在开发初期，无法知道哪些功能能够让客户感到满意，因为环境中的不确定因素和风险尚未明确。增量设计周期的第一部分旨在建立一个假设，假设该功能被开发并发布后，能够实现预期的可衡量的业务结果。如果该功能是史诗的 MVP 一部分或是史诗进一步开发的一部分，那么这个效益假设可能与史诗的假设相关。
协作设计
有了效益假设，ART（产品管理、系统架构师、业务负责人、产品负责人和敏捷团队）成员与客户需要共同合作，生成作为产品设计元素的工件。
构建最小可市场化功能
最小可市场化功能（MMF）是指功能包含的最少量功能，以验证或推翻某个效益假设。ART 可以通过迭代方式实现这一点，以便了解他们在效益假设上的进展情况。
有时，MMF 可能是一个轻量级的工件，没有功能，目的是生成客户反馈，如原型或线框图。其他时候，MMF 可能会被开发并发布，以便客户可以评估并提供反馈。
评估
MMF 发布后，我们等待看看客户的反应。我们可以通过观察和 A/B 测试收集客观数据，也可以通过调查问卷向客户询问反馈。
根据数据，我们可以决定效益假设是否得到了验证。这可能会让我们继续开发、重构，甚至调整方向放弃该功能。
合作和研究活动的结果让我们理解客户的需求，并根据这些需求设计功能。以下工件可能是这一活动生成的：
-
了解客户需求
-
风格指南
-
标志
-
UI 资产
-
原型
-
模型或线框图
-
角色画像
-
客户旅程地图
当产品管理团队努力理解产品特性时，系统架构师需要了解产品的架构，并知道哪些使能者是维持产品功能流动所必需的。我们来看看系统架构师在持续探索中的角色。
架构解决方案
作为产品架构的维护者，系统架构师需要跟踪产品的功能，并通过创建使能者来增强这些功能，同时理解由非功能需求（NFRs）所识别的系统限制。
与 ART 团队或组织中的其他成员合作，系统架构师将探索产品的以下方面，以确保满足非功能需求（NFRs）：
-
可发布性
-
安全性
-
可测试性
-
操作需求
让我们更详细地审视这些方面。
架构可发布性
通常，按照组织的决策，将新功能发布给客户是可取的。我们仍然希望将生产环境部署作为开发节奏的一部分，但实际发布则变成了一项商业决策。因此，我们希望将部署和发布分离。
架构可能在实现部署与发布的分离中发挥关键作用。部署与发布的分离依赖于诸如功能标志（Feature Flags）等技术，而架构必须能够支持这些技术。这些功能标志可以轻松实现新功能的持续部署，而在关闭时不会干扰当前的功能。当功能标志被开启时，新功能被认为已经发布。功能标志的应用包括金丝雀发布和暗发布（Dark Launches）。具有松耦合组件的架构允许每个组件拥有独立的发布计划，这使得需要不同发布策略的组件能够各自独立实施。
最终，发布策略通常与组织的战略或商业目标相关。发布可能需要响应市场需求或超越竞争对手。能够灵活发布是一个竞争优势。我们将在第十三章中看到这一远见的好处，按需发布以实现价值。
设计安全性
尽管 DevSecOps 强调将安全性测试“左移”，即在开发过程中提前测试安全漏洞和问题，但 DevSecOps 方法在此开始，架构师会在绘制新功能时将安全性考虑在内。这使得安全性从一开始就被纳入设计，而不是事后补充的思考。
为确保在初步设计中包括安全性问题，必须执行以下实践：
-
威胁建模：审视当前产品的基础设施、架构、应用程序以及拟发布的功能，以识别可能的安全漏洞、攻击者和攻击路径。
-
合规管理：确保产品符合已知的行业安全法规标准，如 HIPAA、FedRAMP 和 PCI。这些标准中的要求主要涉及安全性和隐私保护。
这些实践的输出通常作为 NFRs 维护并向 ART 传达。NFRs 是 ART 开发的特性的工作约束。这些约束应该作为开发继续进行的持续测试套件的一部分。
确保可测试性
测试是确保功能正确、质量高、安全性好并且准备部署的主要方式。如果一个解决方案不能进行测试，ART 无法了解其进展或者是否可以实现价值。
正如我们之前所看到的，松耦合架构允许通过在不同时间表上发布组件来提高灵活性。这种灵活性延伸到设计允许更多测试发生的系统。具有定义良好接口的组件的系统，允许通过使用尚未准备好与其他组件集成的组件，替换为返回有效输出的虚拟代码或逻辑，来进行更频繁的系统级测试。
使用Strangler 模式，现有的遗留架构可以演变为基于现代松耦合应用程序编程接口（API）的架构。由 Martin Fowler 创造的 Strangler 模式将遗留的单体系统建立了一个面向这些实体的接口。新的代码逐步替换接口的各个部分。最终，所有遗留系统的功能都被新代码所取代。
另一个考虑测试性的设计方面是能够在各个层次上执行自动化测试，从单个代码函数到用户故事，最终到功能。自动化测试允许更频繁地执行测试。频繁的测试可以增加对系统质量和安全性的信心。
可测试的架构对于实施工作的敏捷团队有益。测试驱动开发（TDD）试图首先创建测试，形成对系统行为的初始理解。行为驱动开发（BDD）继续在更高层次上理解系统的行为。
维护操作
一旦特性通过了所有测试，架构设计的考虑因素不应该改变。系统架构师必须确保该架构在非生产或者暂存环境以及最终的生产环境中轻松运行。
这其中的第一个方面是可测量性。架构应允许在不同环境（如分阶段和生产环境）中监控其资源，以判断当前系统是否存在不良性能。当阈值被违反时，应设计警报。这种从低到高资源使用的测量能力通常被称为全栈遥测（full-stack telemetry）。
另一个方面是能够将所有度量记录到日志中，以便在发生事件时便于检索。架构师应该理解架构中哪些方面能够提供可作为日志捕获的洞见，以便运营人员可以将这些度量添加到日志工具中，该工具包括时间戳和搜索功能。
可发布性在确保架构易于操作方面起着作用。特性标记（Feature Flags），作为将生产环境的部署与客户发布分离的常见工具，可以作为回滚机制，在发生事件时通过停用受影响的特性来实现回滚。另一个需要考虑的回滚机制是在生产环境中建立蓝绿部署。CI/CD 管道中的可靠自动化，包括强大的自动化测试，可以支持 修复前进（fix-forward）的情况，其中事件修复可以尽快推送到生产环境。
架构师工作的输出包括解决方案意图，证明史诗（epic）效益假设所需的最小架构概念，以及 NFRs（非功能性需求），它们作为所有从史诗中派生的特性和故事的约束条件。
此时，产品管理和系统架构师已经完成了对特性在价值和架构影响方面的初步思考。其他人需要发挥他们的作用，从进一步细化和优先级排序，到为 PI 规划做好特性准备。让我们现在来看这些步骤。
综合工作
产品管理已收集了关于客户需求的知识和额外的研究，这些内容可能有助于预期的价值。系统架构师已着手确保当前已有或即将提供支持的架构功能。产品管理与业务所有者、产品所有者、敏捷团队及其他相关方合作，完成以下活动：
-
完成特性的定义
-
使用 BDD 来概述验收标准
-
使用 加权最短作业优先法 (WSJF) 对程序待办事项中的特性进行优先级排序
-
为 PI 规划做准备
综合的目标是为即将到来的 PI 做好 ART 的准备。为此，我们将创建以下工件：
-
对 ART 将要开发的内容有清晰的愿景
-
一份路线图，详细说明产品的演进，通过展示可能的解决方案何时交付
-
已定义特性的待办事项列表
让我们详细审视一下在综合阶段完成的这些活动。
完成特性
记住，我们一开始是从作为实验进行的重大产品工作（epics）开始的。我们通过开发 MVP（最小可行产品）来开始我们的实验。MVP 将是一个功能集，用于验证史诗的利益假设。使用精益 UX 方法，我们进一步将 MVP 细分为 MMFs（最小市场功能），这些最初是基于在了解客户需求和期望后产生的假设。产品管理和系统架构师的研究为此添加了更多细节。现在是时候完成完善工作，以便其他 ART 团队可以接手。
一个好的功能将包含以下三个部分：受益人、利益假设和验收标准。让我们更详细地讨论这些部分。
受益人
当我们考虑组织或客户的价值时，现在必须考虑我们产品或服务的最终用户。有时，最终用户不是购买该产品或服务的人。在这些情况下，我们可能需要挑战客户对于最终用户需求和期望的假设。
利益假设
我们希望在开发和发布该功能时，能够说明其对客户或组织的好处。因此，我们可以使用以下格式来创建我们的利益假设：
*如果{proposition}，{*则利益}
我们的命题是对功能的描述。利益是预期的价值输出。
我们可能希望包括一些我们认为能够证明或反驳我们利益假设的指标。如果是这样，我们可以使用以下格式来包含我们的衡量标准：
我们相信{proposition}将导致{benefit}，并且当{metric}时，这将得到证明。
例如，假设我们之前在本章中定义的空中披萨无人机的史诗。一个可能的功能是增加一个内置加热单元，在送披萨的过程中保持披萨的温度。以下陈述可以作为该功能的利益假设：
我们相信，内置加热单元的无人机将通过确保披萨送达时不会变冷来提高客户满意度，并且当我们查看 NPS 调查结果时，这将得到证明。
在这里记住要避免使用虚荣指标——这些指标可能会产生正面反应，但通常无法表明是否真正实现了预期的价值。
验收标准
验收标准是确认实现已完成并且利益得以交付的衡量标准。它们是包含该功能后的系统行为描述。
通常，要评估一个利益假设是否已被验证，可以将多个验收标准映射到一个单一的利益假设声明上。
由于验收标准描述了系统的行为，我们将在下一部分中讨论如何使用 BDD（行为驱动开发）技术编写验收标准。
使用 BDD 编写验收标准
在上一节中，我们探讨了接受标准的作用。接受标准的一个关键作用是，它们描述了功能包含时系统的行为。这种描述会转化为组件的期望行为，以用户故事或代码功能的形式呈现。
我们在 Gherkin 格式中指定期望的行为。Gherkin 格式采用以下结构：
GIVEN (the initial conditions)
WHEN (an input that triggers the specific scenario occurs)
THEN (the desired behavior happens)
WHEN 和 THEN 可能包含一个或多个条款，描述相应的条件和行为。
延续我们关于为披萨无人机配置内置加热单元功能的示例，我们可能希望以下语句作为接受标准：
假设加热单元已安装并 加热完毕…
…当披萨在配送过程中被放入加热单元时…
…那么，当披萨送达时，它将是热的。
采用这种格式的接受标准可以作为自动化验收测试的基础。这些自动化验收测试使用 Cucumber 进行执行，Cucumber 是一种运行 BDD 测试的测试工具。
使用 WSJF 优先排序
一旦产品管理根据受益方、效益假设和接受标准指定了功能，就会将其放入项目待办事项中。
项目待办事项是 ART 可以处理的功能列表。由于 ART 在一次性处理的功能数量上有限，因此产品管理需要对功能进行优先排序，使工作更具聚焦性。
有多种标准可以用来确定在项目待办事项中功能的优先级。SAFe 提倡参考原则 1：采取经济视角，我们最初在第二章中看到过这一点，共享责任文化，在对功能进行排序时需要关注这一点。
我们从关注功能的延迟成本（CoD）开始经济视角的分析。延迟成本是指如果我们推迟发布功能，价值将会减少多少。延迟成本可以由以下几个因素构成，且这些因素可以相对估算：
-
用户业务价值：与项目待办事项中的其他功能相比，预计该功能将产生多少价值？
-
时间紧迫性：如果一个功能未能及时实现，是否会导致价值下降？我们是否错过了一个重要的市场机会？
-
风险减少或机会启用（RR/OE）：是否有其他重要方式能使某个功能降低风险，或者让组织接触到新市场？
SAFe 关注的另一个因素是工作的大小。我们希望优先处理最短的工作。处理时间较短的工作并快速获取价值比从较大的工作开始更容易。
SAFe 将对延迟成本和工作大小的关注结合成一个公式，称为 WSJF。这个公式可以具体如下所示：
如果我们查看前面的公式并代入我们的 CoD 因素，可以将公式改写如下：
产品管理可以与业务负责人、系统架构师以及其他相关方在精炼会议中合作，确定每个特性的 WSJF 值。参与者根据四个组成部分（用户商业价值、时间紧迫性、RR/OE 和工作量）的相对价值进行判断，通常使用修改过的斐波那契数列（1，2，3，5，8，13，20，40，100）来评估。
让我们看看产品管理如何与其他方合作，计算不同特性的 WSJF 值。
小组将召开会议，审查所有特性。然后他们会决定哪个特性的用户商业价值最小 – 该特性的用户商业价值将标记为1。接着他们会查看其他特性，并决定它们的用户商业价值与参考特性相比如何。如果它们被认为相同，它们也会获得1。如果其他特性更大，他们将在斐波那契数列上标出一个数字，表示它比参考特性大多少。
下表展示了在进程中确定用户商业价值的协作过程：
| 特性名称 | 用户商业 价值 | 时间紧迫性 | RR|OE | 延迟 成本 | 工作量 | WSJF |
|---|---|---|---|---|---|---|
| 内置加热单元 | 8 | |||||
| 无人机防御系统 | 1 | |||||
| 反推力推进器 | 5 |
表 10.2 – WSJF 协作示例 – 用户商业价值定义
该过程会重复进行时间紧迫性、RR/OE 和工作量的计算。对于上表，表示用户商业价值、时间紧迫性、RR/OE 和工作量的列，必须至少有一个1。下表继续展示我们的示例，其中时间紧迫性、RR/OE 和工作量也已定义：
| 特性名称 | 用户 商业价值 | 时间 紧迫性 | RR|OE | 延迟 成本 | 工作量 | WSJF |
|---|---|---|---|---|---|---|
| 内置加热单元 | 8 | 8 | 1 | 1 | ||
| 无人机防御系统 | 1 | 13 | 3 | 2 | ||
| 反推力推进器 | 5 | 1 | 1 | 5 |
表 10.3 – WSJF 示例继续 – 时间紧迫性、RR|OE 和工作量定义
CoD 通过将用户商业价值、时间紧迫性和 RR/OE 相加来计算。WSJF 通过将 CoD 除以工作量来计算。下表完成了我们特性 WSJF 的确定：
| 特性名称 | 用户商业 价值（UBV） | 时间紧迫性（TC） | RR|OE | 延迟成本（CoD） = UBV+TC+RR|OE | 工作量（JS） | WSJF（CoD/JS） |
|---|---|---|---|---|---|---|
| 内置加热单元 | 8 | 8 | 1 | 17 | 1 | 17（第一） |
| 无人机防御系统 | 1 | 13 | 3 | 17 | 2 | 8.5（第二） |
| 反推力推进器 | 5 | 1 | 1 | 7 | 5 | 1.4（第三） |
表 10.4 – WSJF 确定示例 – 完整
在项目待办事项中的新功能定期进行优化会议，使产品管理能够了解需要优先完成的功能。这将影响项目愿景和产品管理将在 PI 规划中与 ART 沟通的路线图。
准备 PI 规划
有了优先级排序的项目待办事项，产品管理和 ART 的其余成员可以了解即将到来的 PI 的初步工作范围。理想情况下，这些活动应该至少在实际 PI 规划事件前一个月完成，以便及早发现任何意外情况。
业务负责人将准备一份演示文稿，帮助 ART 了解业务背景，并说明所选功能的开发如何与整体业务战略对接。
系统架构师还将准备一份演示文稿，概述重要的架构说明和变更。这可能还包括 ART 为发布开发的任何重要使能器。
剩下的就是综合结果的输出。产品管理将在 PI 规划之前努力组装以下文档：
-
ART 能够交付的解决方案的愿景
-
功能的路线图及其在产品演进中的定位
-
ART 承诺在下一个 PI 中开发的优先级功能列表
产品管理概述了项目愿景，旨在将 ART 的重点放在共同的使命上。这个愿景将在业务负责人演示之后，通过演示文稿传达给整个 ART。
计划在下一个 PI 中处理的功能集将传达给 ART 上的敏捷团队。团队可以选择他们希望参与的功能，并开始仔细查看这些功能。他们可能希望开始将这些功能分解为故事，就像我们在第十一章中看到的那样，持续集成解决方案开发，并且可能还会寻找任何风险或依赖关系。
摘要
在本章中，我们审视了触发持续交付管道的活动。通过持续探索，ART 检查市场和客户的需求与期望，生成新产品或新功能的创意。
这个过程始于认识到，开发实际上是一个系列的增量构建-测量-学习循环，开始时通过创建一个关于客户价值的假设来进行。
接下来，产品管理和系统架构师开始协作过程。产品管理与客户合作，更深入地了解客户和市场需求。系统架构师研究假设，以了解这些变更对架构的影响。
当研究完成后，ART 会将所学到的知识转化为特性，并对这些特性进行详细阐述，将其放入程序待办列表中并进行优先排序。一组最高优先级的特性将被选定用于即将到来的 PI。这些选定的特性将被传达给 ART，以便为下一个 PI 规划阶段做好准备。
在 PI 规划之后，ART 开始进行开发工作。这一开发工作将进入持续交付管道的下一个阶段——持续集成。我们将在下一章详细探讨持续集成的内容。
问题
-
以下哪个不是持续探索的活动？
-
假设
-
协作与研究
-
开发
-
综合
-
-
产品管理在持续探索阶段与谁合作（请选择三个）？
-
发布列车工程师
-
客户
-
产品负责人
-
Scrum 主席
-
系统架构师
-
解决方案列车工程师
-
-
创新会计被应用于“构建-测量-学习”周期的哪个阶段？
-
构建
-
测量
-
学习
-
所有阶段
-
-
精益 UX 过程创建一个 __________ 来验证或证伪利益假设。
-
最具价值产品
-
可度量的特性
-
最小可行产品
-
最小市场化特性
-
-
系统架构师在评估新特性架构变更时关注哪些领域（请选择三个）？
-
安全
-
成本
-
可测试性
-
重用
-
可发布性
-
进一步阅读
-
一系列来自
scaledagileframework.com网站的文章，作为持续交付管道的参考：www.scaledagileframework.com/continuous-delivery-pipeline/ -
持续交付管道系列中的参考文章，讲述持续探索：
www.scaledagileframework.com/continuous-exploration/ -
来自 scaledagileframework.com 的参考文章，详细介绍了史诗故事和 SAFe 精益创业周期：
www.scaledagileframework.com/epic/ -
来自 scaledagileframework.com 的参考文章，详细介绍了如何在 SAFe 中使用创新会计和领先指标度量：
www.scaledagileframework.com/guidance-applied-innovation-accounting-in-safe/ -
本文描述了 Scaled Agile 为 SAFe 适配的精益 UX 过程：
www.scaledagileframework.com/lean-ux/ -
关于 Strangler 模式的解释，并举例说明如何实施：
www.techtarget.com/searchapparchitecture/tip/A-detailed-intro-to-the-strangler-pattern -
关于在 SAFe 中编写 Feature 的指南，并结合了 Feature 编写画布：
medium.com/product-manager-tools/writing-effective-features-58a240e69222 -
精益创业：今天的创业者如何通过持续创新创造极具成功的企业 由 Eric Ries 著 – 这本书定义了 Build-Measure-Lean 循环、创新会计、商业转型（pivot）以及什么是最小可行产品（MVP）。
-
精益 UX：与敏捷团队设计伟大产品 由 Jeff Gothelf 和 Josh Seiden 著 – 这本书最初解释了精益 UX 流程，一种迭代的产品设计方法。
-
创新游戏：通过协作游戏创造突破性产品 由 Luke Hohmann 著 – 这本书解释了创新游戏，一系列由产品管理团队和客户共同进行的协作练习，用以挖掘客户需求和期望。
扫一扫
937
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
