本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 创建开发价值流映射
以下是创建开发价值流映射（DVSM）的步骤：
+ [步骤 1：明确价值流](#step-1)
+ [步骤 2：定义起点和终点](#step-2)
+ [步骤 3：确定涉及的团队](#step-3)
+ [步骤 4：培训参与者](#step-4)
+ [步骤 5：映射价值流步骤](#step-5)
+ [步骤 6：评估每个步骤的速度和质量](#step-6)
+ [步骤 7：明确约束](#step-7)
+ [步骤 8：持续改进](#step-8)
## 步骤 1：明确价值流
价值流映射重点在于为客户提供价值。应尽可能狭义地定义此价值流。理想情况下，其范围应涵盖一个[小型跨职能团队](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)能为客户提供的所有内容：该团队包含从业务到 IT（包括开发与运营）的所有个人。如果组织已经按价值流和产品团队进行结构化，那么开发价值流就是一个单一价值流及其相关的产品团队。否则，开发价值流可能会流经数十个团队和数百人，这很正常。
例如，对于保险组织，相应的价值流可能是面向客户的索赔输入界面。该界面需要从业务到 IT 各部门团队的协作。评估整个理赔部门的范围会过于宽泛，因为其侧重于组织，而不是为客户提供的价值。
## 步骤 2：定义起点和终点
价值流映射的起点是业务部门已定义并已确定优先顺序的可交付成果，其已准备好启动。每个团队都有自己的*准备就绪*定义。有关在组织中定义此术语的更多信息，请参阅 [Walking Through a Definition of Ready](https://www.scrum.org/resources/blog/walking-through-definition-ready)（Scrum 博客文章）。在许多情况下，*准备就绪*意味着可交付成果已从一般待办事项中移出，可在冲刺待办事项中使用或已添加到看板面板中。DVSM 不应包括待办事项、细化、优先级确定或满足团队*准备就绪*定义所需的任何其他步骤。
**注意**
尽管在待办事项列表中花费的时间以及确定优先级和细化流程不在开发价值流映射的范围内，但这些任务可能会导致您的组织出现严重延迟。您可以使用相同的精益流程为这些活动创建单独的价值流映射。
价值流映射的终点是您团队的*完成*定义。有关在组织中定义此术语的更多信息，请参阅 [Definition of Done](https://www.leadingagile.com/definition-of-done/)（Leading Agile 博客文章）。*完成*表示您已成功检测和验证可交付成果。理想情况下，它包括在生产环境中向最终客户交付，以及通过监控证明产品已成功实施、运行和采用。
## 步骤 3：确定涉及的团队
DVSM 涵盖向客户提供特定价值所需的所有人员、流程和技术。如果向客户提供价值的团队存在依赖项，请在 DVSM 流程中加入该团队。如果团队在向客户提供可交付成果时与其进行互动，处理与该流程或可交付成果相关的工单，或者影响完成可交付成果的能力，则该团队被视为*依赖者*。在映射过程中经常会出现新的依赖关系，因此无需预先确定所有团队。首先列出预期团队的概要清单。
创建开发价值流映射时，通常会包括以下团队：
+ 产品
+ 业务
+ 开发
+ Quality
+ 基础设施
+ CI/CD 平台
+ 操作
+ 架构
+ 站点可靠性工程（SRE）
+ 变更与发布
+ 安全性
将小组规模定为不超过 5-8 名可以代表这些团队的参与者。如果您发现需要 8 名以上的参与者才能充分代表每个团队，请将映射分成若干部分，分别由较小的小组在独立映射实践中完成。然后，您可以组合各部分，构建一个从起点到终点的完整开发价值流映射。
## 步骤 4：培训参与者
选择团队将用于创建 DVSM 的工具。您可以使用带便签的白板、在线白板应用程序、Microsoft Visio 甚至 Microsoft Excel。您可以为协作阶段选择一种工具，然后将映射迁移到其他工具中以进行正式演示。为协作阶段选择工具时，请考虑是所有参与者都将亲自参加，还是会议将有远程参与者。如果某些与会者是远程参与，您可以选择一款为所有参与者提供平等贡献机会的应用程序。
指导参与者熟悉工具和流程。让参与者做好准备，并设定期望：所有参与者都将积极参与，并独立向价值流映射添加步骤和数据。问责制对于开发价值流映射过程的成功和速度至关重要，而协作有助于确保 DVSM 并非单线程。如有必要，请提供所选工具的培训。
在计划的映射会议之前，对参与者进行基本流程培训，并确认其有权使用所选工具。这可以防止在映射会议期间出现延误，并使团队代表能够尽快开始贡献和参与。
## 步骤 5：映射价值流步骤
与参与者一起，明确在价值流起点和终点之间发生的所有步骤。您可以通过明确起点和终点来开始该流程，然后协作定义前几个步骤。随着 DVSM 开始发展壮大，参与者逐渐熟悉流程，可请求参与者独立向面板添加方框和数据。为确保将所有步骤都考虑在内，请利用您对 SDLC 的了解不断追问“接下来怎么办？”
要求参与者将较大的任务分解为可管理的步骤，尤其是在这些任务涉及多个所有者的情况下。但是，请确保步骤单元不要过小。步骤过多会难以完成映射和明确价值流中最重要的约束。
创建开发价值流映射时，通常会包括以下步骤：
+ 开发
+ 单元测试
+ 集成测试
+ 功能测试
+ 回归测试
+ 安全验证
+ 性能测试
+ 用户验收测试
+ 缺陷工作流程
+ 变更咨询委员会（CAB）批准
+ 变更工单
+ 请求工单和 SLA
+ 文档
+ 架构审查
+ 数据审查与批准
+ 基础设施预调配
+ 网络和防火墙变更
+ 生产部署
+ 日志记录和可观测性编排
+ 冒烟测试
+ 生产事件工作流程
将这些步骤按顺序排列，并用流程箭头连接。识别*成功路径*，即开发过程中没有遇到任何异常或错误的流程。同时，识别*失败路径*，即产品在开发流程中的任何步骤失败时发生的流程。
## 步骤 6：评估每个步骤的速度和质量
在此阶段，您可以确定拥有每个步骤的人员，并评估该步骤的速度以及该步骤产生高质量结果的频率。询问负责这项工作的人员，其交付的人员，以及由于问题而被退回的频率。
首先明确每个步骤的所有者。*所有者*是负责执行该步骤中工作的团队。为了便于明确映射中的责任归属，您可以为每个团队指定不同的颜色。如果一个步骤有多个所有者，可将该步骤分成多个较小的步骤，以使每个团队都能提供自主数据，并妥善记录交接环节。
对于价值流映射中的每个步骤，请求步骤所有者提供以下信息。数据应来自经验性的平均场景，而不是从系统或数据来源中提取。通常，对于 DVSM 范围来说，提取和标准化这些数据的工作量过多。此外，数据通常不正确或不包括难以跟踪或衡量的元素。因为目标是改进其使用的系统，所以请相信工作负责人能够精准把握以下指标：
+ **前置时间（LT）**：这是该步骤从开始到结束的持续时间，即从所有者接受工作至交接该工作为止。它包括花在处理可交付成果上的所有时间以及所有停机时间，例如等待所花的时间。作为前置时间的一部分，务必跟踪 SLA 和团队之间的交接流程。
+ **流程时间（PT）**：这是假设没有中断或停机时间的情况下，一个人完成该工作所花的时间。这有时被称为*增值*时间，即为可交付成果增加价值所花时间的衡量指标。
+ **完成准确率（%CA）**：这是该步骤交付准确、不需要任何返工且无需退回的工作或数据的时间百分比。不准确的可交付成果示例包括下游步骤报告的错误数据、错误表单、错误、缺陷、瑕疵或事件。
务必确保所有团队均已参加，并且一个团队不能代表另一个团队发言。每个团队都应该有自主权，以为其拥有的步骤提供数据，并讨论可能对速度和质量产生重大影响的交接问题。这可能会导致与大量人员进行沟通以收集数据。
## 步骤 7：明确约束
明确严重影响速度和质量的约束：
+ 与速度相关的约束出现在前置时间与流程时间之间差距最大的步骤中。这表明该步骤浪费了大量时间，例如因等待而流失的时间。
+ 与质量相关的约束出现在完成准确率分数较低的步骤中。这表明修复缺陷的重复工作浪费了大量精力和时间。
这些步骤为提升软件开发流程的速度和质量提供了最大的机会。
在整个价值流中，您可以为所有步骤添加前置时间或流程时间，以获得整个价值流的累积前置时间或流程时间。您也可以将所有步骤的完成准确率分数相乘以确定平均值。这可以帮助您了解整个系统的工作需要多长时间，以及在任何给定步骤中正确完成的可能性。
## 步骤 8：持续改进
在明确开发价值流映射中的约束并确定其优先顺序后，您可以使用其推动软件开发流程的改进。与利益相关者和步骤所有者合作，通过消除交接、浪费的时间和过多的处理来提升速度和质量。
实施更改后，请与步骤所有者一起重访 DVSM，并评测更改是否成功。根据更改更新 DVSM，然后明确新的约束并确定其优先顺序，以推动持续改进。新的约束通常出现在映射的不同部分，或者约束从低优先级升级到高优先级。