开发者学堂课程【研发效能提升和敏捷实施36计：照亮问题——效能提升从可视化交付过程开始】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/615/detail/9376
照亮问题——效能提升从可视化交付过程开始
内容介绍：
一、如何可视化端到端的交付过程
二、可视化到底可视的是什么
三、如何做可视化
四、如何检验可视化效果
五、在TB上建立可视化的交付过程：
六、思考题
三个不等于是我们要克服的障碍
第一，以流动效应为核心提升团队的持续交互能力；
第二，要以用户价值为核心去规划探索有效的需求获得明确的产品；第三，以长期效应为核心去城建优质的软件资产，达到一个持续的高效。
本次课主讲以流动效应为核心提升团队的持续交互能力，在整个提升交互效应过程中的三个核心，以流动效应为核心这件事情上，我们要改变从原有以局部的资源效应为核心，慢慢地往以用户价值流动效应为核心这个方面切换，要做好这一点，必须从三个方面入手，
第一，可视化交互端的交互过程；
第二，管理价值流动的过程；
第三，通过度量反馈方式做磁性改进。
一、如何可视化端到端的交付过程
可视化目的是看到价值流动的过程，这样为我们后来价值的流动，顺畅流动奠定一个基础。
二、可视化到底可视的是什么
可视化并不是一个陌生的世界，在很多敏捷设施里，大家使用看板墙、各种纸条、电子的工具等来进行可视化的实践，其中褒贬各不一样。
从一个故事来讲解可视化，故事发生在一个酒吧门前，一个路灯下面一个醉汉正在找着什么，十分钟过去了，警察一直在旁边静静地看着他，忍不住了走上前去问这个醉汉，你在找什么呀？醉汉说：“我在找我的钥匙啊。”警察看了看这个地方也不大，也没有钥匙啊，就问他：“你的钥匙是丢在这了吗？”醉汉说：“不是，我的钥匙不是在这。但是只有这能看啊。因为这里有光。”钥匙在英文里是key，也可以翻译成关键或者答案，从这个故事看待，光照亮的地方不一定是答案或者关键所在，而我们在研发过程中会不会犯同样的错误呢？光能看见但却不是答案所在的地方去努力呢？
在研发过程当中，我们也是找到了一些光的地方，但不是key所在的地方。从组织汇报期来看，是测试开发产品的职能我们更容易看到局部的值，我们看到的是人是否繁忙，但研发过程中问题在哪里？这是我们要考虑到的，真正思考的地方，研发过程中的问题究竟出现在哪里呢？
下面我们来看一看研发过程中经常遇到的问题；比如集成问题、目标对齐问题、需求的沟通和反馈、协作问题、进度对齐问题、交付模式问题、公共环境问题、质量问题等等。这些问题其实往往不产生在局部，真正的是在整个系统中，从这些问题可以看出涉及到很多职能，整个交付过程都关注的问题，这些问题将会带来什么样的影响？即产品交付中的各类问题都会导致需求停滞，停滞的需求又从根本上损害研发功能。
实际在产品开发过程中，需要关注什么？
产品开发中的根本问题，几乎从来不是停滞的资源（工程师），而是停滞的产品需求（用户价值）。因此在保证以流动效应为核心的前提下，发现影响需求流动的一个关键应该是把光照在真正的问题所在，看到整个交付协作的过程。
那么我们光照亮的地方应该在哪里？所以我们可视化可视的是交付端到端的流动过程。
三、如何做可视化
（1）、第一步是用户价值驱动，识别有效的流动单元。
流动即为需求。
流动的价值类型包括产品规划需求、用户日常需求、技术改进需求、问题和缺陷；这四个需求是交付的主体内容，也是看法流动的内容，对于不同的团队做不同的分析。同时也要了解不同需求的来源，到达的频率，处理规则以及占比（估计值，对于不同的团队可能是期望值；团队不同时期的占比也会不同）。
（2）、第二步是前后职能拉通，定义端到端的价值流。
需求的流动过程从进到出，进是进入开发团队，出是走出开发团队，即不上线的过程，在这个过程中，我们先选择，其次分析、待评审、就绪（对开发就绪）、实现、待测试、测试、待发布、已发布。在整个端到端的过程中，会涉及到不同的职能，比如：我们从产品开始，产品这边会做需求方面的分析，再到交互视觉效应，再到技术开发，再到测试。
前后职能拉通是非常重要的概念，源于我们要改进用户价值流动效应，为了改变用户价值的流动效应，我们要真正拉通组织中的各个职能，无论产品，开发，必须把他们放到一起去，给用户价值最快的响应，流动效应最大化，缩短流动效应时间。在条件允许的情况下，向两边拓展，这样才能做到用户效应的最快响应，真正端到端的敏捷。
（3）、第三步左右模块对齐，反应环节内的任务协作。
从需求的角度来看，实际上是需求的分解与合并，在交付过程中，需求可能被拆分成不同的任务。
在敏捷开发中，我们追求的是无差别的特性团队。需求被分为ios、安卓、外部依赖。我们是通过任务的完成来交付需求，需求对用户是有价值的，所以在这里我们称之为左右模块对齐，是任务像需求对齐，尽快交付这个需求，我们把这个结合起来看，左右模块对齐就是为了更快地去交付一个需求，让这个过程更加顺畅。
在这过程中，我们也可以管理外部的依赖，比如我的需求依赖于外部的某一个平台，可能要去改一个平台的接口，那么可以把它当成一个外部依赖任务把它可视化出来，要完成整个需求我就知道相关的任务有哪些,也能更好的看到问题的瓶颈，需求不能交付究竟是什么原因。
（4）、第四步明确流转规则，赋能团队本地决策内建质量。需求在什么情况下可以向下一个阶段流动，我们需要把这个规则定义清楚，比如说，什么样的需求能通过评审走到就绪这个环节，首先我们要知道需求对于开发团队是清楚的，需求拆分的非常小，需求的外部依赖得到了承诺等等，我们这里面用的就绪，只有这些东西才能称之为就绪，就绪后面的开发过程我们已经准备好了，我们才能顺畅。定义成规则也非常重要，他让我们能真正做到内建质量，即让每一个阶段的质量能有保障，它的要求是明确的，这才能保证我们的需求顺畅流动，不要把问题集中到后面爆发。自定规则的时候并不是给我们谈判用的，是为了让我们更好协作.
规则还有一个作用，是用来改进的，是我们现有流程的机线，如果哪个部分做的不顺，我们就需要改变它，改进它，改进体现在对于规则改进的形成。流转的规则是我们协作的基础，也是改进的基础，也是质量保证的重要手段。明确规则给上游提出标准，为下游的流动也提供整入的标准。
团队可以选择去定义不同阶段的规则，不同团队关注的点也不一样，这里面我们特别注重待开发，待开发对于开发团队是一个输入，输入很大程度决定输出的质量。待测试是开发团队的输出，这阶段规则也很重要，质量不来源于测试。
可视化价值流的基本步骤：
四、如何检验可视化的效果？
对照检查清单：
1、能反映需求端到端的交付过程吗？
2、能即时体现影响价值流动的瓶颈和问题吗？
3、能依据可视化的信息协作和做决定吗？
的确反应这个过程，端到端的交付过程，包括协作过程，环境间的，环境内的，这是一个重要的基础，这些基础果真做到的话，再加上一些小小的技术手段，怎么体现阻碍，怎么体现 bug，怎么暴露需求已经到期了这些问题，怎么标识需求已经到期了这些问题。就需要做到第二点，即时体现影响价值流动的瓶颈和问题。如果在第三点的基础上，再看到规则，并且让每个团队的成员拥有它的话，就可以依据可视化的协作决定。无论如何，做到以上三点，我们就可以为价值的顺畅流动奠定一个非常坚实的基础。定义这个规则，规则更多是说，在针对这个流动阶段的质量的检查清单，当然，规则不能一味地加上很多很多规则，只要关键的几条就可以了。
怎么通过有意义的数字化可视出来？
为未来有效的数据化奠定基础,建立和完善规划和交付闭环机制，包括业务规划、产品交付、工程能力。
五、在TB上建立可视化的交付过程：
1、用户价值驱动，识别有效的流动单元。
2、前后职能拉通，定义端到端的价值流
3、左右模块对齐，反应环节内的任务协作
4、定义流动规则，赋能团队本地决策内建质量
实际TB上的具体操作：
进入 teambition 后，会看见一个项目空间，首先，我们要建立一个新的项目，需要创建一个敏捷开发的模板，包括需求管理、迭代规则、测试管理、缺陷跟踪、版本管理、统计回顾等，同时包括了三种形式的流动单元，即需求、任务和缺陷。
往往团队里会包括产品的需求，也有可能包括技术改造的需求，所以我们需要添加一种新的任务类型，即接改类需求，就可以产生一个新的工作流和新的任务类型。
添加完成后，我们将看到四种任务类型。有了任务类型之后，我们接下来设置任务的工作流，任务工作流默认为待处理、测试中、已完成，把任务拖到任务工作栏中。
关于技改类需求，往往我们会采用同一个工作流，技改类工作流会比需求类工作流任务少，一般可以覆用，可以上来，同时修改名称为需求默认工作流。接下来为工作流配置，我们需要添加更多的状态进来。若两个开发任务已经完成，另一个还在进行中，那么这一个开发任务的环境内部相互协作。
除了这些，还需要定义需求流转规则
定义流动规则：需求流转规则
已选择：
l 由业务方和开发团队代表共同完成
l 初步沟通和确认后，明确优先级放入从已选择队列
就绪（待开发）：
l 开发、测试和产品达成一致，定义明确的验收标准
l 大需求，已拆分为工作量在两周以内的故事
l 与关联方（如有）确认相关计划
l 识别大的技术风险并定义应对方案
l 指定需求 Owner
待测试：
l 通过持续集成环境的检验，部署在测试环境
l 开发对照验收百年准进行了自测
l 通过 Show Case
待发布：
六、思考题：
1、影响你们团队交付协作的问题是什么？
2、如何通过可视化的方式暴露这些问题？
