摘要：
互联网时代，业务与协作复杂度与日俱增，竞争日趋激烈，提升研发效能已成为软件行业的共同挑战。《研发效能提升和敏捷实施 36 计》是阿里云联合 Teambition 精心打造的系列课程，课程由何勉、张刚、张燎原等国内多位在研发效能领域拥有数十年经验的精益敏捷资深专家担任讲师；将从敏捷项目协作、敏捷需求管理、持续交付与工程实践、设计及代码实践、业务创新 5 大方面，首次系统分享阿里巴巴研发效能提升方法、解析阿里巴巴及业界优秀实践案例，并通过工具的直观演示，帮助企业研发管理者们突破研发效能瓶颈、通往业务成功之路。
“提升研发效能”是产品研发的共同目标。但是，应该从哪里开始呢？本次课程，是研发效能提升 36 计系列课程第二课，两位讲师将分享阿里巴巴的经验——从可视化端到端交付过程、暴露问题开始，开启研发效能提升之路。你将了解到：
可视化什么
如何有效可视化的四个步骤
检验可视化效果的三个标准
注：以下内容是演讲视频的精要整理，点击文末链接可前往课程信息合集页面查看往期视频、PPT 以及最新直播预告。
相信大家对可视化并不不陌生。很多敏捷团队，都会使用实体或电子看板来实现信息透明和可视化。至于效果如何，就褒贬不一了。认为有用并坚持的不少，认为是形式主义的也大有人在。
我们认为，可视化是否有用，首先取决于：“可视化什么?”，
一. 可视化什么？——可视化照亮问题所在
故事发生在酒吧门前，一个醉汉正在路灯下面寻找什么。警察在旁边默默地看着他……，10 分钟过去了，警察忍不住走上前去。
“你在找什么？”警察问道;
“我的钥匙” 醉汉回答 。
“是丢在这吗？”警察看了一眼，并没有发现钥匙，于是问到。
“不是” 醉汉回答。
“那为啥在这儿找？”警察不解地问道。
“只有这里能看得见啊”醉汉很不耐烦的回答。
光照亮的地方，并不是钥匙（key）所在。英文中，“Key” 除了钥匙的意思外，还有 “关键” 或 “答案” 的意思。能够看见的地方，却不是 “关键” 所在，当然也找不到需要的答案。
研发过程当中，我们是否会范同样的错误？很不幸，不但会，而且还非常普遍。
对于研发过程，我们容易看到是：人是否繁忙。我们倾向从汇报线的角度考察各个职能部门的产出，如开发、测试、产品等职能的效率。
然而，导致研发过程的问题,如：集成、质量、进度对齐、需求沟通、环境维护及交付模等。这些问题的根源往往是系统性的，而非局部。它们不是光照亮的地方，也因此容易被忽略。
产品交付中的各类问题会导致需求的停滞，停滞的需求阻碍了价值的顺畅流动，从根本上损害了研发效能。
在软件产品的研发过程中，其实根本问题从来都不是停滞的资源（工程师），而是停滞的产品需求（用户价值）。
这也为研发过程的可视化提供了方向。研发过程可视化，就是要可视价值端到端的交付过程，让我们看到价值流动的过程，以及流动过程中的阻碍、停滞和问题。
可视化的核心是：“照亮问题所在”。
让我们看一个例子。下图是阿里天猫新零售团队两年前的看板。这个看板从左到右分成了多个列，每列代表一个阶段。看板上蓝色的卡片是需求，它们从左到右，依次经过各个列，其中包括：选择、设计、待评审、待开发、开发设计、开发中、测试等阶段，一直到发布。
我们看到，“开发中”这一列比较宽，它分成了若干个子列，最前面的这一列叫“需求”，用以停放需求卡片。其他的子列分别是“前端、后端、测试、依赖”，这些子列中的黄色卡片是需求拆分出来的下属任务。任务完成之后，就移到最后一个子列 —— “完成”列。
“开发中”的需求和其下属的任务处于同一行，我们称之为“需求泳道”。某个需求下属的所有任务都 “完成”后，则需求开发完成,可以继续往后流动到“待测试”，任务则可以清理或折叠。泳道空出，可以准备让下一需求进入。
通过这个看板我们可以看到需求流动的整个过程，看到需求被拆分成多个任务以及团队协作完成任务的过程。它帮助团队暴露和发现问题，促进团队更好地协作交付需求。为团队的高效协作和价值的顺畅流动奠定了基础。
以上是一个具体的例子，团队各自的情况不一样，其可视化模式当然也不一样。团队如何结合团队自身的上下文，设计自己的可视化方案呢？这是我们接下来要介绍的。
二. 如何可视化——四个步骤实现有效可视化
为了结合团队具体的上下文，实现有效的可视化。在实践中，我们总结了 4 个步骤。
第一步：用户价值驱动，识别有效的流动单元
我们首先需要分析的是：团队或组织对外交付的是什么，从而识别有效的流动单元，明确可视化的主体。
下图的示例，来自一个真实团队。他们将流动单元分为四种类型。
产品规划类需求：源自产品设计和规划，服务于长期的业务目标；
用户日常需求：产品使用过程中，来自用户或业务方的日常反馈和要求，开发团队需要及时响应,并按优先级排期开发；
技术改进需求：为了可持续的交付，或技术领先而提出需求，如技术重构、开发测试环境改进以及关键技术的引入等；
问题和缺陷：团队必须即时响应和解决的。
以上四类需求是这个团队需要交付的主体内容，也是看板上的流动单元。
大家可以根据自己团队特点，分析并分类需求，确定看板上的流动单元。在此基础上，我们才可以分析和建模价值流动过程，也就是接下来介绍的第二步。
第二步：前后职能拉通，定义端到端价值流
这里用不同颜色的卡片代表了不同类型的需求。如：绿色卡片代表用户需求，蓝色卡片代表技术改进需求。
团队需要分析和建模需求流动的过程。上图是其中的一个实例，需求从（被）“选择”开始，经过“分析”、“待评审”阶段到达“就绪”阶段（注：就绪指的是对开发团队而言的就绪）；再经过“实现”、“待测试”、“测试待发布”，最后到“已发布”阶段。这个端到端的过程就是需求交付的价值流。
端到端的价值流动过程,涉及不同的职能，如产品设计、交互视觉、开发和测试等。为了提升流动效率，必须拉通组织中的各个职能，实现整个过程的可视化。
一些团队因为条件约束，无法立即做到全面的端到端拉通。条件允许，还是要尽量向两端扩展，才能实现真正的端到端的敏捷和精益。这也为团队的进化提供了方向。
前后职能拉通是快速交付的基础，除此之外，团队还需要关注环节内的协作，特别是不同角色的协作，如：前后端开发团队的协作，与外部依赖方的协作等，它也是促进价值快速流动的重要方面，这就是我们接下来要讨论的“左右模块对齐”。
第三步：左右模块对齐，体现环节的任务协作
环节内任务的协作，从需求的角度来看，反映的是需求的分解和合并。典型的一个例子是：实现过程中，需求被拆分成不同的任务，由不同的职能（如前端、后端、iOS、Andriod、外部依赖方等）完成。
上图中间的“实现”阶段中，绿色卡片所代表的需求被拆分成多个任务（黄色卡片）。这些任务，分属后端、iOS 开发、安卓开发以及外部依赖等。团队的目的不是完成更多的任务，而尽快交付需求。
这就是我们说的：左右模块对齐，也就是任务向需求对齐，尽早交付需求。它促进团队以需求交付为牵引，更有效的协作，并帮助团队发现影响需求交付的瓶颈。
识别有效流动单元，前后职能拉通和左右模块对齐。这三个步骤让需求交付过程清晰可见,并即时暴露流动过程中的问题和瓶颈。
不过，为了让团队更有效协作，我们还必须在此基础上，定义明确的需求流转规则。这也是我们接下来要介绍的第四步。
第四步：明确流转规则，赋能团队本地决策、内建质量
明确流转的规则，就是定义需求向下一阶段流动所必须满足的条件。比如:达到什么条件才能从“待评审”进入“就绪”环节。团队应该定义明确的需求流转规则，并达成一致理解。
明确流转规则帮助团队做到内建质量。所谓内建质量，是让需求在每一个阶段的质量，都得到有效地保证，避免问题在最后的阶段集中爆发，和避免不必要的返工，这也是持续顺畅价值流动的基础。
如何定义规则呢？让我们以“就绪”阶段的准入规则为例。
对开发团队而言，“就绪”是他们的输入，输入的质量很大程度上决定了输出的质量。IT行业里面有一句话：“Garbage in,Garbage out”——输入的是垃圾，输出的就必然是垃圾。
通常，我们期望就绪后的需求能够顺畅地向后流动，而不是问题不断，走走停停。需求进入就绪队列时，问题还没有发生。按项目管理的术语，还没有发生的问题应该被称作风险。典型的有：业务风险——需求是否清晰并理解一致；关联风险——识别对外依赖和得到承诺；技术风险——方案基本可行。
在定义就绪队列的准入规则是，我们应该考虑以上风险。于是，就有了下面的例子。就绪队列准入规则:
开发、测试和业务共同澄清需求，并定义明确交互过程和验收标准
大需求已拆分为工作量在两周以内可以完成和交付的需求
已与业务关联方（如有）确认相关计划
识别大的技术风险并定义应对方案
涉及三个（含三个）开发人员以上的需求，指定好协调人，负责进度协调
上面以“就绪”列为例，定义了流转规则。基于类似的原则，团队可以定义其它环节的流转规则。
明确定义的规则应该由团队定义，并共同拥有，团队对它们达成一致的理解和承诺，并基于它们协作和决策。它赋能团队更好的自主决策。同样重要的是,规则并非一成不变，它是质量保证的重要手段,更是团队改进的基线。
总结 - 可视化价值流的基本步骤
简单回顾一下可视化价值流的四个基本步骤。
第一步: 用户价值驱动,识别有效的流动单元；
第二步: 前后职能拉通，定义端到端的整个价值流；
第三步: 左右模块对齐，反映环节内的任务协作；
第四步: 明确定义流转规则，赋能团队实现本地快速决策，并保证内建质量。
三. 怎样确保可视化效果？——有效可视化的三个检验标准
如何结合团队自身的上下文，设计自己的可视化方案。每团队都可以去实践，相信会产出许多有特色的方案。
那又如何判断，产出的方案是否有效呢？我将基于在实际实施中的经验，给出三条原则，它对应三个问题。
问题一：能反映端到端的交付过程吗？
问题二：能即时体现影响价值流动的瓶颈和问题吗？
问题三：团队能依据可视化的信息协作和做决定吗？
对这三个问题的肯定回答，一直是我设计看板系统的底线要求。事实也证明，做到以上三点，可以为价值的顺畅流动，奠定一个非常坚实的基础。至于如何使得价值流动得更快，就是水到渠成的事了，这部分内容会在后续课程中为大家介绍。
四、总结
不要做“路灯下的醉汉”， “让光照亮问题所在”。这是为了有效可视化,在思维上所必须要有的转变。为了照亮问题所在，可视化的主体必须是需求、需求的流动过程、以及流动过程中的问题和瓶颈。基于这一诉求，我们分享了可视化的四个步骤和三个检验标准。希望它们能帮助你和你的团队照亮研发效能改进的前路。
本文作者：Teambition Developer
原文链接
本文为云栖社区原创内容，未经允许不得转载。