打破部门墙。
——W. Edwards Deming
识别价值流和ART
这是SAFe®实施路线图系列的第五篇。点击这里查看整个路线图。
实施路线图的前四项“关键举措”确立了变革的紧迫感，以及有效实施SAFe所需的关键知识和专业人员：
有了紧迫感和强大的联盟，现在是实施SAFe的时候了。本文介绍了下一个关键步骤：识别价值流和敏捷发布列车（ART）。价值流和ART是组织实施SAFe的支柱，，对成功完成这一过程至关重要。试图走捷径或轻而易举地完成这一步，就像在你试图加速的同时把脚踩在刹车上一样。但是，如果这一步做对了，组织就会在成功转型的道路上越走越远。
详细内容
识别价值流和敏捷发布列车(ART)需要了解一种新的组织模式，该模式经过优化以促进促进价值在跨职能部门、活动和边界之间的流动，其包括以下步骤：
- 识别
运营价值流（operational value streams） - 确定支持运营价值流的系统
- 确定开发和维护这些系统的人员
- 定义包含系统和人员的
开发价值流（development value streams） - 添加构建
完整业务解决方案（full business solution）所需的人员 - 确定实现开发价值流的ART
以下各节将介绍这些活动。
价值流
价值流是理解、组织和交付SAFe价值的主要结构。如图1所示，每一个价值流都是用于创造价值的一系列长期步骤：从概念到为客户提供有形的结果。就像任何精心设计的故事（narrative）一样，价值流确定了一个按时间顺序排列的活动流程。
- 触发点 – 某些重要的事件触发了价值的流动，可能是客户的采购订单或新功能请求。当交付了某些价值（货物、客户购买或解决方案部署）时，，它就结束了。
-
步骤 – 中间的
V型标志（chevrons）是企业用来完成这一壮举的步骤[1]。例如，图2描述了在本网站上发布你正在阅读的文章所需的步骤。
- 价值 – 当价值流执行所有步骤时，客户获得价值。在图2中，当用户可以阅读这篇文章并增加她对SAFe的了解时，她就获得了价值。
- 人员和系统 – 价值流还包含了从事工作的人员、他们所操作的系统以及信息和材料的流动。例如，在图2中，写文章的人、维护网站的人、使网站正常运行的WordPress应用程序以及亚马逊的网络服务托管系统都是价值流的一部分。
-
前置时间 – 从触发到价值交付的时间就是
前置时间（lead time）。缩短前置时间可以减少上市时间。 缩短前置时间的最简单方法是识别和减少（或消除）非增值活动和浪费的延迟。这是精益思想的主要关注点。
价值流的类型
请注意，有两种类型的价值流[1]，如图3所示。
- 运营价值流 – 包含使用开发价值流创建的业务解决方案提供最终用户价值的步骤和人员。
- 开发价值流 – 包含开发运营价值流所使用的业务解决方案的步骤和人员。（这些是SAFe投资组合管理的价值流。）
SAFe主要关注的是开发价值流。毕竟，在最短的可持续交付时间内交付新的解决方案是SAFe的重点，而开发价值流则帮助企业了解如何实现目标。然而，必须首先识别企业的运营价值流，以确定支持它们的开发价值流。
识别运营价值流
对于一些组织来说，确定运营价值流很容易。许多只是公司销售的产品、服务或解决方案。然而，在大型企业中，这项任务会很复杂。价值流通过分布在组织的许多部分的各种应用、系统和服务流向内部和外部客户。
在这些情况下，识别运营价值流是一项重要的分析活动。图4提供了一组问题，可以帮助利益相关者完成这一识别过程。
识别大型企业中的运营价值流并非易事。它需要认识到组织更广泛的目标，并明确了解价值的具体要素如何流向客户。为了帮助你，在下面的章节中提供了两个例子：一个来自医疗保健领域，另一个来自金融服务领域。
医疗保健提供商运营价值流示例
第一个运营价值流的例子是医疗保健网络提供商，如图5所示[2]。
为了说明问题，这个例子侧重于医院，特别是代表支持患者治疗的流程和信息系统的价值流：从收治到治疗和结算。
这个运营价值流的触发点是病人到达医院。在患者接受治疗并为所提供的服务付款后，医院将获得全部价值，如图6所示。
V型标志（chevrons）（价值交付的主要活动）上面所标示的人员就是执行运营价值流中各个步骤的人员。
金融服务运营价值流示例
第二个业务价值流的例子是银行机构[3]。图7说明了在这样一个组织中可能存在的各种价值流。
红色的矩形突出显示了下文会进一步说明的“消费者银行贷款”价值流。价值流是由客户搜索并找到银行的贷款产品和利率而触发的，当客户带着利息偿还贷款时，价值流就实现了。图8突出显示了这些步骤和执行这些步骤的人员。
(注：客户也是该价值流的直接参与者。)
价值流定义模板
价值流定义模板（value stream definition template）可用于进一步阐述和理解所识别的运营价值流的特征。图9提供了一个示例。
识别支持运营价值流的系统
一旦确定了运营价值流的步骤，下一个活动就是确定为支持该价值流而开发的系统。对于较大的价值流，重要的是将系统与价值流中各个步骤的联系绘制出来。这样可以使人们更深入地了解它是如何运作的，如图10中的消费者贷款示例所示。
确定开发系统的人员
一旦确定了支持运营价值流的系统，接下来的活动就是估算构建和维护这些系统的人员数量和定位，如图11所示。
定义开发价值流
下一步是确定开发价值流，这些流代表开发这些系统所需的步骤以及开发这些系统的人员。由于这些价值流与运营价值流不同，因此组织需要考虑触发因素和价值是什么。该系统在运营价值流中支持和实现更好的操作，因此价值是系统中的新功能或修正的功能。触发因素则是驱动这些功能的需求和想法。
这些触发因素可以用来确定开发价值流的数量。如果大多数需求需要触及所有系统才能实现新功能，那么可能只有一个开发价值流。然而，如果系统是分离的，则可能有几个。无论如何，开发价值流应该大部分或完全独立，能够自行开发和发布，没有太多的价值流内部依赖关系。在图12的例子中，大多数需求都会触及前三个系统或最后一个系统，但很少会触及所有四个系统，因此存在两个开发价值流，每个价值流都能够独立于另一个开发、集成、部署和发布。
添加构建完整业务解决方案所需的人员
开发价值流努力提供创新的业务解决方案，因此需要的不仅仅是开发团队的贡献。参与业务解决方案交付的每个人（IT运营、法律、市场营销、财务、技术支持、合规、安全等）都被认为是开发价值流的一部分。考虑到这一点，下一步是确定这些额外的个人和团队，他们是上一步确定的开发价值流的一部分。
在图13的例子中，第一个开发价值流侧重于贷款申请流程，包括进行营销以编制宣传材料和开展吸引客户的活动。还包括法律团队成员，以确定所提供贷款的相关条款和条件。第二个开发价值流是开发管理贷款偿还的核心银行系统，也包括进行营销以管理与现有客户群的持续沟通。这两个开发价值流都包括支持团队，以应对任何可能出现的客户问题，以及运营团队，以管理这些系统在生产中的稳定性。
开发价值流跨越边界
一旦确定了开发价值流，下一步就是开始了解如何组建敏捷发布列车（ARTs） 来实现这些价值流。ART包含了提升价值流所需的所有人员和其他资产。第一步是了解组织中哪里创造了价值，因为那是人员、流程和系统所在的位置。当这样做的时候，很明显，开发价值流会跨越许多边界。企业之所以会有这样的组织方式，有很多原因：历史、功能上的便利、集中化的效率、收购、地理环境等等。因此，完全有可能没有人了解持续开发和增强有助于提供价值的系统所需的一系列完整事件。此外，改进的尝试往往倾向于功能上的局部改进，这可能导致一个功能或步骤的优化，但端到端流程的优化很少。
正是由于价值流的长期性，引发了精益组织的不同思考方法。为了解决这个问题，企业应用系统思维（原则2，应用系统思维），来了解系统中的各个部分需要如何共同完成流程的改善。通常情况下，大型企业的组织结构都是按职能划分的。此外，人员往往是按地域分布的。但是，如图14所示，价值却跨越了这些界限。
识别ART
最后一项活动是确定实现价值的ART。经验表明，最有效的ART具有以下特征：
- 50 – 125人
- 专注于整体解决方案或一组相关的产品或服务
- 长期稳定的团队，持续交付价值
- 尽量减少与其他ART的依赖
- 可以独立于其他ART发布
根据工作人数的多少，ART设计有三种可能的方案，如图15所示。
- 一个ART中可以容纳多个开发价值流 – 当几个相关的产品或解决方案可以用相对较少的人员生产时，一个ART可以提供多个价值流。
- 单一的开发价值流可以包含在一个ART中 – 通常，一个价值流可以用100个或更少的从业人员来实现。许多开发小组已经被组织成大约这个规模的单位，所以这是一个常见的案例。在这种情况下，ART与价值流大致相同。大家都在这个ART里！
-
大型开发价值流需要多个ART – 当涉及到很多人的时候，就必须将开发价值流拆分成多个ART，如下一节所述，形成一个
解决方案列车（Solution Train）。
将大型价值流拆分成多个ART
大型开发价值流在大型企业中非常常见，通常需要进行一些额外的分析。在可能的情况下，列车应该集中在一个单一的、主要的解决方案上，或者该价值流中一组密切相关的产品或服务上。这是一个相当简单的设计：一个ART提供一组定义明确的有价值的东西。
然而，在需要许多人提供单一解决方案的情况下，当团队一起工作，同时开发具有高度相互依赖性的功能和组件时，这种方法最有效。这就导致了围绕特性领域（feature areas）或子系统组织ART的相对常见的模式。
-
特性领域ART对
流动（flow）和速度进行了优化。在这种情况下，列车上的各个团队，以及整个列车本身都可以提供端到端的功能。好处是显而易见的，这也是为什么它们是首选。但要注意子系统的治理，否则系统架构会衰减，最终降低速度。通常情况下，一个系统架构师（一个或多个个人，甚至一个小团队）致力于维护架构的完整性。 - 子系统ART的应用、组件、平台等经过优化，可提高架构的健壮性以及子系统和服务的重用性。同样，好处也是显而易见的，因为这可以提高开发和重用效率。（面向服务的架构就利用了这一点。）然而，根据系统架构中关注点的分离，这种情况下的价值流会产生更多的依赖性，并需要ART之间的协调。
没有一个正确的解决方案，大型系统通常需要两种类型的ART。一个典型的例子是，多个ART基于一个共同的平台提供服务或解决方案。在这种情况下，可能有一个或多个平台ART（platform ART）支持特性ART（feature ART），如图16所示。
还有一种常见的模式，即ART在一个更大的价值流中实现特定的环节（segments）。这看起来似乎并不完全是端到端的，但实际上，价值流的“开始和结束”是相对的概念。在这些环节中，输入、价值、系统的类型可能大不相同，从而形成了一条逻辑分界线。
当然，这些模式的组合也经常出现在更大的价值流中，如图17中的最终示例所示。
最后，还有其他一些基于地域、口语、成本中心等因素的ART设计和优化方法，这些因素都可能影响ART的设计。但这些都是远远不够理想的。
SAFe价值流和ART识别研讨会
如图所示，这个过程中涉及到批判性思维和分析。为了帮助识别价值流，Scaled Agile, Inc.提供了一个价值流和ART识别工作坊工具包，包括一个研讨会和其他工具，SAFe项目顾问（SPC）可以用来指导利益相关者。该研讨会提供了一个结构化的方法来识别价值流和定义ART，从而梳理出企业的价值流。该工具包提供了一种经过验证的、系统化的方法，通过考虑依赖性、协调性和约束条件来优化ART设计。
价值流和ART识别研讨会通常在与关键利益相关者的Leading SAFe课后直接进行。目的是让他们完成对价值流的识别，设计ART的过程，在他们对SAFe实现的精益-敏捷开发有了基本的了解之后，再选择首次ART启动的日期。
由于没有任何设计是完美的，所以企业有时会在学习了更多知识后需要重复这个研讨会，这是加速路线图步骤的一部分。这样做可以让企业加深其对价值流和ART的理解，并将新的学习成果融入到组织设计中。
下一步
这篇文章介绍了团队如何做识别价值流和设计ART的工作，这些工作构成了转型的基本组织结构。
现在是时候进行下一步了，创建实施计划，这是SAFe实施路线图的下一篇文章。
了解更多
[1] Allen Ward, Lean Product, and Process Development. (video) Lean Enterprise Institute, 2004
[2] Contributed by Jane Tudor, Justine Johnston, Matt Aaron, Steve Mayner, and Thorsten Janning.
[3] Contributed by Darren Wilmshurst, Murray Ford, Per-Magnus Skoogh, Phillip Manketo, Sam Bunting, and Virpi Rowe.
[4] Knaster, Richard and Leffingwell, Dean. SAFe Distilled, Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.
更多资源
Value Stream and ART Identification Workshop Toolkit for SPCs.
Last update: 28 September 2019
