• Five_reasons
  • Cal2_20220108
  • Hardware-agile-practice
  • 2020-scrum-guide-banner
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • 敏捷思维 领导力 企业培训 国际Scrum联盟认证
  • 汽车行业敏捷开发课程
  • CSM A-CSM Scrum敏捷实践
  • 敏捷领导力认证培训  CAL认证培训 CST CSP
  • 30天软件开发 敏捷规模化实践 Scrum精髓 敏捷文化
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • Scrum敏捷培训 Scrum敏捷企业内训
  • Scrum敏捷软件开发管理 企业内训 Scrum转型
【Scrum模式语言13】价值流(value stream)

译者导读:

在参与产品开发的过程中,你是否遇到过这些问题:编写很多不必要文档;开发了需求列表中没有的功能;在沟通确认和寻找信息上花费掉很多的时间;多个人负责同一个任务,经常需要交接等等?这些问题都属于浪费,所有追求高效的组织都要考虑如何识别和消除浪费。价值流是精益的核心思想之一,它的作用就是通过跟踪产品从概念到交付的全部路径,从而识别别出流程中各个环节中存在的浪费,而 Scrum 则提供了一些消除浪费的工具。

原文:


产品负责人定义好了一个愿景,现在正在寻找创造价值的方法,我们将价值定义为对我们希望服务的某个或某些人有利的东西。


对于成功的产品来说,不仅是产品理念,其开发的过程和从产品概念到上市的历程也同样的重要。简单的开发就像是农业社会,原材料随手可得,小贩(葡萄主)可以把它们直接卖给客户(一个饥饿的旅行者)。当生产变得越来越先进,产品背后的流程也越来越复杂(比如酿酒)。不同于简单农产品所需的劳动力技能,复杂工作需要创新和资金,这些都离不开团队合作。智力型的工作依赖一个更加开放的系统,在这个系统中,开发网络间的输入与相连接形成了密集网络。构建一个复杂的产品,比如汽车或软件程序,可能需要许多团队,并且需要他们深刻理解如何协调团队之间的工作。不过,光有执行----好的流程和好的人----还是不够。


因此产品负责人创建了一个生态系统,其中的元素相互构建,为产品的演进不断增值。在这个生态系统的中心,有一个流程向利益相关者提供持续的产品增量:价值流。


价值流构建组件,包括工件(待办列表、产品组件)以及引导和配合创建这些工件所需的过程(通过事件和合作)。价值流中的人员则在建立、颁布和改进这些用来指导工件创建的流程上起作用。


价值流是动态结构,产品负责人可以根据不断变化的业务条件、利益相关者关系,甚至产品的增值内容对其进行调整。然而,从组织的角度来看,Scrum 价值流的开发组件只由一个组织组成:Scrum 团队。Scrum 团队负责所有开发活动,并且不和其他团队间进行重大交接。


丰田通过丰田生产系统(TPS)成功地生产出了大量的各种型号的高质量汽车。这个生产体系由世界级的流程、良好的员工培训和消除浪费措施组成。然而,这些流程并不是凭空产生的;许多流程反映了从原材料到销售批次的路径结构。这就提出了至关重要的问题:谁设计装配线或其机器人?谁决定在每个工作单元的过程指令卡上写什么?这类活动就属于构建价值流的范围。乐购(Tesco)通过分析他们的价值流(从供应商到门店销售),发现了重大的改进机会。并通过改进价值流,让“供应的商品开始更快地流动”,使得“乐购及其供应商的成本更低,销售额更高”。“他们成功地重新设计了供货网络,这帮助他们十年内就在英国零售市场上从中型百货零售商成长为世界第三大零售商”。


产品待办列表、Sprint 待办列表和Scrum 板与后续的其他许多模式一起组成了一个整体,即逐步进行交付的工作流。价值流可以部分看做是为产品提供培育的组织结构和流程。同时它也是一种时间结构,定义了从概念到分析、设计、交付和持续产品维护的价值生命阶段。产品增量定期地、按时地从产品待办列表、Sprint 待办列表和Scrum 看板中通过 。


这些工件体现了产品负责人和开发团队的工作流程。为了消除交接过程,每个价值流对应一个Scrum 团队。交接会造成反馈延迟,进而导致返工----这是一种致命的浪费(muda)。为了提高效率,Scrum 团队需要有产品负责人的业务洞察力和跨团队的开发能力。尽管商品和服务可能有多个源头并流经 Scrum 团队,但一个价值流不会把增值开发分配给多个团队。


产品和价值向下游流动时,也会得到相应的反馈。在市场营销和开发过程中会产生新的需求、缺陷报告和产品创意,这会影响到后续的工作。许多上游流其实是由 Scrum 框架内反馈机制产生的,尤其是在Sprint 回顾和 Sprint 计划中;但缺陷报告和其他反馈可能会随时出现。为了提供最大的价值,团队可能会中断开发周期,以纠正缺陷和培养对产品的自豪感。大部分的价值流利用客户支持功能处理来自最终用户和客户的请求,其中包括对此类请求进行分类,以便将操作问题、用户错误从缺陷报告和产品延期请求中区分开来。这是第一道“防线”,产品负责人是下一道,负责过滤和处理这些请求。大多数对应的下游流发生在称为“定期产品增量”的离散交付中,但高性能的价值流可以使用更多增量响应式部署来提供快速响应。


任何给定的产品都可以支持多个价值流,因此一个 Scrum团队可以管理多个价值流。通常每个 Scrum 团队都会服务于多个利益相关方,也就意味着通常会产生多个价值流。

显然客户、用户和顾客都是利益相关者,不过 Scrum 团队应该维持一个能让工作压力更小、更有趣、更有成就感的一个价值流。在价值流中,有少量的关键模式描述较小的整体。本章余下的大部分内容包括这些模式。其中一些模式反映了与生产相关的过程。


这些典型模式有:

• 第45节 产品路线图----可供选择的价值路径地图。

• 第46节 Sprint 和 Sprint 待办列表----产品增量的时间和内容维度。

• 常规产品增量--视觉组件的实现


除了专注于产品本身,重要的是记住价值流是一个持续改进的实时系统,并且这种改进工作是有许多模式可以使用的。


一些典型的模式有:

• 26 Kaizen Pulse----在执行基准和尝试改善之间交替进行开发。

• 36 Sprint 回顾----相较于改进产品,更清晰地专注于改进过程。

• 92 Scruming the Scrum----使用 Scrum 框架本身作为管理流程改进工作的工具


本文把价值流描述为仅与通用框架 Scrum 密切相关的一种通用结构。每种产品都有自己的价值流,其源自使产品产生价值的原材料或创新。Scrum 团队希望通过价值流图来探索其自身价值流的特性。你可以从 Mike Rotherr 的丰田 Kata(丰田 Kata:为改进、适应性和卓越结果管理人员)中了解到价值流图的细节。这样的分析可以帮助 Scrum团队改进现有的 Scrum 模式,或者添加与特定业务需求密切相关的新模式。


——译者:Wang Yang

校对:Emma Ye



参考资料:

(1)A Scrum Book:41 value team