开发者学堂课程【阿里巴巴研发效能提升实践系列公开课：利用看板帮助效能可视化价值流动】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/608/detail/8870
利用看板帮助效能可视化价值流动
目录
一、回顾内容
二、如何提升研发效能
三、明确研发效能改进的关键
四、可视化端到端的价值流动过程
五、如何可视化交互过程
六、优酷基于Aone看板服务的可视化实例
七、及时发现问题和瓶颈
八、总结
一、回顾内容
1.研发效能的定义
持续快速相互加载的能力
2.为研发效能提供度量体系
关于流动效能的持续发布能力
需求响应周期
关于资源效率交付的速率或者是吞吐率
关于质量的内部质量和交付质量
二、如何提升研发效能
首先观察研发效能度量所处的位置
研发效能为组织效能服务，研发效能的提升是源自于各个方面的实现，比如说产品探听、创新和探索的实践；协助管理的实践、需求管理的实践
三、明确研发效能改进的关键
1.在开发过程中、在效能改进过程中经常犯这样的错误-看到哪里就改进哪里，问题是：问题的关键或者问题的答案经常不在能看到的地方。
2.在研发过程中，可以看见各个部门，可以看见各部门的人是否在工作或者资源的使用率
（1）问题
目标对齐问题、协作问题、进度对齐问题、集成问题、公共环境问题、质量问题、交付模式问题、需求的沟通和反馈问题
（2）结论
各个局部是光照亮的地方，但问题通常不在那里，或者根源不在那里。如果问题在局部或者根源在局部，往往都已经被解决了；那些难以解决的问题往往是系统性的问题，是跨部门的问题，是往往不容易被看见的问题：焦点、公共环境稳定性的问题、对齐协作问题。
3.如何看见问题
其实是很难的，但是是有方法的
在产品开发界非常有智深的Donald Reinertsen说过一句话：产品开发中的根本问题，几乎从来不是停滞的资源（工程师），而是停滞的产品需求（用户价值）。
工程师效率不高或者负载不高不是根本问题，需求不动才是根本问题（一个批量-开发完成之后等待击沉了）
4.产品交付中的问题
（1）分支及协作模式
支模式就是要求做一个大继成。
（2）部门间进度或技术不对齐
进度不对齐-比如说依赖与物流部门，物流部门给本部门的IPI可能要很迟才能给本部门，本部门开发完的东西就停滞了，用户的需求也不动。
技术不对齐-比如说接口两个部门没有商议好，就会导致需求停滞了。
（3）阻碍不能及时发现和解决
（4）需求不清晰或错误
（5）技术和开发环境问题
（6）测试和集成环境问题
比如说项目做完了，但是没有测试的地方。
（7）返工和质量问题
...
5.需求停滞对研发效能的负面影响
（1）延迟交付
（2）隐藏风险
需求里面的问题不能得到及时发现，错误的假设、业务的假设都得不到发现。
（3）降低质量
错误的假设不能得到及时发现，很迟的时候才发现，往往就是在错误的假设的上面犯了更大的错误。而且后面发现的质量问题就不是当初引入的人去解决了，可能要求赶工，更有甚者使用不干净的方式来解决。
（4）增加开销
①管理开销（过程中的需求，都要去管理、汇报）；
②技术开销（如果是大集成，就需要很多的部门去集成）；
③沟通、相互依赖带来的开销。
（5）降低激励
如果开发完一个需求，直接交给下一个环节支付给用户，然后看见结果，当然对于部门来说激励很高；
如果开发完一个需求，需要等待某个队列里面非常久的时间之后才能交付，那对于部门来说激励很低，最后无论出现了怎么样的结果，往往也不会再关注它了。
（6）减缓学习
学习是在一次次错误中学习，如果需求停滞了，自然而然就缓解学习
四、可视化端到端的价值流动过程
下图是一个看板
1.端到端的价值交付过程
选择
设计
待评审
待开发
开发中（需求、前端、后端、测试、依赖、完成）
待测试
测试（验收）
待开发（发布）
2.需求卡片（蓝色纸条是需求卡片）
需求卡片要从左到右经历各个阶段：设计->待评审->待开发->开发设计->需求->待测试->测试->分布
每一个需求卡片代表的是一个需求，不是一个任务。因为需求代表了用户价值
所以知道了可视化联盟第一点->用户价值驱动
因为需求是可交付的、可发布的，发布完可实现用户价值
3. 开发中的过程
（1）开发中是一个比较宽的列，它被分成了各个子列（细分的列）
第一列叫是需求
需求是蓝色纸条（需求）
黄色纸条（任务）分属与前端、后端、依赖、完成
最后一个子列是完成-任何一个任务完成了都可以放在完成这一列
（2）泳道
在开发中的过程中横向的道称之为泳道（图中橙色框框）
在有一个泳道里面是一个需求及需求下属的任务，其中这些任务被分布在不同的列里面，这些列代表的是各个部门或者各个模块（前端、后端）。其中最后一列是完成，表示任务的完成
（3）需求什么时候可以放在待测试列
等所有的任务完成之后需求就可以进入了待测试列
（4）需求进入待测试列后，任务怎么办
任务清空了->因为测试的人关注的是需求并不是任务。
（5）任务被清空之后，需求进入下一列，泳道也被清空了
泳道也被清空了，泳道原来的地方就没有东西，这个地方就可以等待下一段需求的进入
（6）左右模块对齐
在这过程中，可以看见任务，但是任务的完成是需求交付服务的，它必须向需求对齐，称之为左右模块对齐，也就是说完成任务并不是最终的目标，完成需求让它快速进入下一列直至交付才是的最终目标。但是这个就需要本身模块对齐，包括本身负责的模块以及本身所依赖的模块。
（7）前后职能拉通
这个看板反映的是端到端的价值交付过程
从选择一个需求直到发布介绍，它涉及到不同的职能：产品职能、开发职能、测试职能，最后的验收也是产品的职能
把整个过程进行拉通：为了相互需求让整个链上的东西能够形成一个很顺畅的协助
五、如何可视化交互过程
1.用户价值驱动
在看板上流动的一定是交互的东西
比如说用户需求、用户提出来的需求、产品规划的需求、用户问题的修复、技术改进类的需求，它的来源不同，到达频率不同，处理的规则不同，它们的占比可能各自有各自的占比，这些类型要分析清楚
业务需求：用户需求、产品规划需求、用户问题修复
支持性需求：技术改进类需求
2. 前后职能拉满
（1）其实要保证一定是端到端的，从用户需求提出直到发布结束、选择，就是说从众多潜在的机会中选择接下来要投入的需求就绪，中间可能有一系列过程，直到需求就绪。
（2）就绪是对开发就绪。也就是说需求被澄清和处理了，对技术团队就绪，比如知道了它的验收标准，比如知道它的对外的依赖等等。然后中间再经过一个开发的过程，这个技术的过程包括开发和测试，直到待发布。
（3）待发布就是完成了技术开发。
（4）完成了技术开发之后需求可以随时发布
中间还有其他阶段，这些阶段可能因各个团队不同而不同，有些团队可能在选择和就绪之间会特别强调评审；有些团队可能是选择直接设计，设计是指产品和UED工程师共同设计；有些团队会把UED作为单独的阶段；有些团队更多是开发者自测，它可能测试和开发是一个是一个环节；有些团队可能对于测试它又分成了一个更多的一个功能测试，或者系统的测试分的更细。但是更希望做到的是一个端到端的，称之为前后拉通。
3. 左右模块对齐
在这个在这个看板里面，把它更加实力化，就是可以看到有选择有就绪，有待发布也有已发布。把中间的阶段也列出来了，比如说分析、待评审、测试
需求泳道
在这个泳道里面它有一个需求以及需求下属的任务，保证这个任务分属于不同的模块
六、优酷基于Aone看板服务的可视化实例
1.结构
从以确认到以选择（没有待开发-在选择和开发之间还有一个设计的阶），到开发中，开发中的时候可以看见，这里有一个泳道，这个泳道里面，它其实也是包含了第1列的需求。再后面是任务、再测试，然后接下来待发布、已发布。
就是刚才讲的用户价值驱动每一个大的卡片是一个需求，在需求开发中的时候，要做到左右模块对齐。
对其他区分了需求和任务，可以看到这里任务有不同的颜色：任务黄色的表示没有完成的任务，灰色的代表的是已经完成的。
当然它是一个端到端的过程，它反映了前后只能拉通，以实现一个端到端的价价值交付流程。
2. 结论
可视化端到端的价值流动过程，帮助找到效能提升的关键。用户价值驱动，前后职能拉通，左右模块对齐，是可视化价值流动流动的基础。
七、及时发现问题和瓶颈
1. 瓶颈和队列
比如说某一列很多需求并行在一起（这个图还不够极端-它这里面有6个值）。如果测试是一个瓶颈，你就会发现它的待测试率会越积越长，当然这个6个值已经可能是问题了。究竟是测试人员不够呢？还是测试环境问题呢？还是开发问题发现了bug没有及时解决呢？这都是在它暴露了问题之后，需要去讨论的。
2.关键的缺陷
在这个图中看到箭头指向的是一个大概形状的东西，这个需求下面在测试中有两个bug（其中解决了0个），当然可以设置-比如说在看板上，只显示二级以上的bug。
3.重点关注的需求
比如说菜鸟的需求需要重点的关注，那么这个就可以做一个标签。现在标签标签再那个灰色的图标（当然标签的颜色可以调整-比如说调整成红色的，它就更加显眼，这个都是可以自己人为手工调的）。
4.阻碍和问题
图中的图标是一个静止的状态，表示需求遇到了。问题，而需求一旦遇到问题，它除了在下面有一个阻碍向（0、1）之外，整个需求就变红了。
5.到期或即将到期的需求
会设置需求完成的时间-当这个需求已经到期或者即将到期的时候，就会在这里面有个红色的标记表示哪一天应该完成，比如说这里面8月28号应该完成，但还没有完成的。
即将到期是什么意思
比如说在这里面设置，如果后天和明天截至，或者今天即将到期的需求上面会写着今天、后天或者明天到期或者即将到期的需求。如果已经到期的话就直接写日期
6.中断
某一列已经空下来了，马上就绪的需求马上都已经开始开发了，但是部门后面没有供给了。
7.扩展
其实这些都是阻碍顺畅交付需求的各种因素。
总结一下，这个其实是经过在很多团队里面，指导过程中、辅导过程中、实践过程中，总结下来应该关注的问题，而一旦解决了这些问题，就能保障需求能够顺畅的去流动。
只是暴露问题，但问题的原因需要团队去关注、去解决的。
在事实上也发现了，比如说在闲鱼，在优酷发现，其实有很多时候不解决问题，是没有看到问题或者是说即使意识到问题，也没有看到问题他真正的影响在哪里；但是一旦看到了问题也意识到问题的影响，大家都还是有意愿去解决的。
所以说可视化端到端的过程，实际上是看到问题，但是是以需求的流动为线索来可视化端到端的过程，那么什么时候去看这个问题呢？事实上现在是基于了一个站会上面去看这个问题：比如说今天在优酷、在闲鱼、在天猫大家都会去有一个站会的制度。
其实有可能很多团队有站会，但他们站会的效率纪律的确是与别人是不一样的，他们站会关注的是需求流动的状态，可以想一想，关注的是事，不是人。在这里面，去以事情为线索，会过每一个需求的状态，特别是有有问题的需求，也就是在这个里面列出了6类需求。
站会状态有两种选择，一种是从左往右（是一个比较自然的数据去看每个数据的状态），还有一种是从右往左
但是从右往左更好，因为更关注的是需求的交付，其实是用结果来驱动它的，比如说关注测试中的需求如何让它更快的交付，待测试的需求如何更快的开始测试开发中的需求，如何尽快的达到可测试的状态，所以这就是站会要求的。这个从右向左解释体现价值，拉动出价值，拉动需求的交付，这个价值来拉动整个开发的过程，促进价值顺畅的流动，以提升顺畅和快速交付价值的能力，这是对于研发效能的一个基本的定义
八、总结
1.为了提升价值交付能力，必须能找到改进的关键所在
2.产品交付中的关键问题从来不是停滞的资源（工程师），而是停滞的用户需求
3.可视化端到端的价值流动过程，帮助找到效能提升的关键
4.用户价值驱动，前后职能拉通，左右模块对齐，是可视化价值流动的基础
5.以可视化价值流动为基础，即时暴露价值交付过程中的问题和瓶颈
