精益看板方法从理论到实战 （2）—— 可视化价值流动实践（上）
上一篇，我们介绍了什么是看板方法，并总结了看板方法的5个核心实践。接下来，我们将逐一解析这些实践在具体上下文中的应用。本篇将介绍"可视化价值流动“，如下图所示，它是所有看板方法中第一个也是最基础的实践。
本篇开始介绍看板方法中的第一个实践——可视化价值流动
我们将从一个重新设计看板系统的案例开始，帮助大家理解看板系统和看板墙设计的原则。
2.1 团队背景介绍
这是一个初具规模的创业公司的创新团队，为行业客户开发本地部署的私有网盘产品。团队当时共有开发测试约30人，以及负责不同行业及总体负责的产品经理共6人。我之前辅导过他们需求和测试实践，团队基本能贯彻敏捷需求方法，较为持续的交付用户价值；接口自动测试能与开发同步完成，并做到接近100%的功能覆盖。但总体上团队的交付能力满足不了产品的需要，内部协作略显无序，质量也有下滑趋势。
企业网盘开发明显分成两类技术，一类偏底层，如：分布式文件系统，集群管理，以及包括性能监控、负载均衡等在内的底层服务等；另一类偏前端，如：与PC资源浏览器的深度融合，Web应用开发，IOS和Android移动客户端开发等。前、后端在部署上相对独立，技能上相差很大。所以团队很自然地被分成了前端和后端两个团队，各自有所属的测试，并分别按两周的固定周期迭代开发，看上去比较敏捷。
2.2 初始的看板系统设计
团队的初始看板设计
上图是团队看板系统的初始设计，前、后端团队各自用Jira[1] 构建了看板墙，另外还有一个独立的Bug管理系统。
看上去不错，任务从左往右流经各个阶段，状态清晰，分配给谁也一目了然，团队成员能很方便的了解自己要做的工作。但，它也有明显的不足。
首先，看板系统对产品经理不友好。用户需求被分解成前后端团队任务，在各自的看板上流动。一旦分割，产品经理就很难再找到对应的任务，也不再关注这些任务。上图中“视频文件在线播放”这个用户需求，就被拆分成了前后端的任务，各自管理。对产品经理不友好只是表象，产品经理代表的是用户，问题的实质是：“这个看板系统并没有反应用户价值端到端的流动过程“。
其次，它并没有反应团队协作过程。需求被拆分成前、后端任务后，一般后端团队先行开发，在迭代中安排自己的任务，而前端团队则滞后一个迭代，以便基于后端提供的服务集成和联调。由于任务之间缺乏关联，团队间的协调，相当程度要依赖项目经理的协调，这其中既包括计划的同步，联调的安排，也包括问题的界定和Bug的处理等。例如：测试过程中发现的后端Bug，通常是前端团队过滤后再转过去的，而后端这会儿正在开发下一批需求。新需求和老Bug哪个优先级更高？我们当然希望优先解决Bug。而事实却正好相反，新需求一般有明确的期望完成时间，而Bug却没有，再说bug多没意思，这时就需要项目经理来重新安排，项目经理成了团队运作的枢纽。
最后，它不能即时和清晰的展示问题和瓶颈。没有清晰展示价值流动过程，导致价值流动中的瓶颈和问题也不能很好的体现出来。比如我们无法从看板墙上看出哪些用户需求出现了停滞，那个环节是瓶颈。这些问题更多的存在于团队及个人之间的协作中，而不是单个人或单个团队中。
2.3 看板系统的重新设计
质量管理之父戴明说过：“如果你不能以一个清晰的过程展示你所从事的工作，你就不知道你在做什么”。这句话用在这个看板系统上是合适的，正因为没有清晰的展示，团队就无法基于它协作交付价值，瓶颈和问题也无法即时暴露。
戴明是质量管理之父，也是“系统思考”的布道者，他的很多思想即使在今天敏捷和精益的背景下，也充满真知灼见
为解决以上的问题，我与团队一起重新设计了看板系统。下图是改重新设计的看板系统。这一次我们用了物理看板墙，并把前后端团队的看板墙进行了合并。让我们从左到右，来解释一下它的设计。
重新设计后的看板
原始需求的提出： 左边的蓝色卡片是原始用户需求，产品经理对它们简单地归并、拆分和过滤后，统一放入需求池（pool），等待进一步处理。
需求的设计： 产品经理团队从需求池中选择优先级较高的进行产品设计，决定要不要满足该需求，以什么方式满足等。设计完成的需求，进入待澄清列，等待与开发团队澄清。
需求的澄清和就绪： 每周，开发团队和产品经理进行会议，选择适当数量的高优先级需求[2]进行澄清，充分讨论和更详细的描述这些需求，确保产品、开发和测试对需求达成一致的理解[3]，并明确定义验收标准，需要时还会对需求进行拆分。经过这一步处理，原始需求被转化并称作故事（story）[4]。为了区分故事和原始需求，团队不再用蓝色纸条，而是用白色的纸条来代表一个故事，从这一步开始，产品经理也将基于故事来跟踪和沟通和验收需求。故事放入“就绪”列等待实现。
故事的拆分和开发实现： 经过充分沟通后“就绪”的故事随时可以开始实现。开发要做的第一件事是分解它——前后端团队在一起，将工作分解为子任务。图中蓝色和黄色纸条就是这些任务，它们隶属于不同的模块，分别是后端的数据、集群和应用模块；前端的Web，PC和Mobile模块。注意，这些模块虽然从左到右排列，但他们之间是并列的没有先后关系。蓝色的是开发任务，黄色的是接口自动化测试任务，这也是黄色纸条只出现在后端模块的原因。所有的子任务和它们所属的故事被放在同一行，称为“泳道”。其中，最下方一条是技术泳道，放置并非直接来自用户的工作，如：代码重构和技术预研等。
故事的开发： 单个任务完成后被放入“实现中”阶段的最后一个子列——“完成”列，它代表的是子任务而不是故事的完成。一个泳道中所有的子任务都完成后，则对应的故事也就完成了，可以进入“待验证”阶段等待测试，这时子任务就可以从看板墙上清理出去，泳道也空出可以接受下一个需求了。现实中，对较为复杂的需求，团队会指定一个开发人员作为总体协调，在将需求移入待验证前，他会再次确认所有集成和自测工作都已经完成。
测试人员验证故事： 测试人员从“待验证”列将故事拉入“验证”列进行测试，并用红色纸条标记发现的Bug，与开发人员沟通解决。测试工作完成以及对应的Bug被解决后，需求进入“待验收”列。
产品经理做最后的验收： 产品经理定期验收实现和验证完毕的故事，确保其与最初的设想一致和解决了用户的问题，再根据市场的最新情况确定发布计划。
2.4 重新设计的看板系统发挥的作用
重新设计的看板解决了前文所提及的问题，但它究竟起到了哪些实际作用呢？下图反应了它的特点。
重新设计后的看板系统的特点
首先，它体现了用户价值端到端的流动。在这个看板系统中，流动的单元回归了用户的价值（需求），而不再是原先的任务。并且它反应了价值端到端的流动——从用户的问题出发，到交付用户解决方案结束。上图中，看板墙的最左边是代表用户的产品工作，中间是开发和测试工作，最右边又是产品的工作。
其次，它反映了团队协作交付价值的过程。团队工作的本质是协作交付用户价值，这个看板系统反应了这一本质，它包括了各个环节间的移交和等待；也包括实现阶段内需求如何被拆解成各个模块任务，拆分后子任务又是如何合并和整体移交的。这为团队基于看板系统协作提供了基础。
最后，它反应了价值交付过程中的缺陷、问题和瓶颈。问题和Bug即时体现到看板墙上，并与所属需求关联，促进团队更快的去解决。如果某个环节流动不畅，需求就会在该环节积压形成瓶颈，这为团队指明改进方向。例如：站会上团队从右往左审视每一列需求，当靠右的测试有问题或有Bug阻碍时会优先解决，而出现拥塞的瓶颈列也是团队要重点关注的。
这个看板系统的设计并无花哨，只是忠实反应了团队协作交付价值的过程。也正因为此，才更接近团队工作的本质。看板系统改造完，我问了团队以及负责这个产品的副总裁三个问题。
第一：看板系统能全面地反映需求交付过程吗？
第二：瓶颈和问题能在看板墙上得到即时体现吗？
第三：团队可以根据看板墙上的信息协作和做决定吗？
对这三个问题的肯定回答，一直是我设计看板系统的底线要求。前两个他们给出了明确且肯定的回答。第三个问题的回答则没有那么肯定，这个看板系统能提供了决策所需要的大部分信息，但团队要据此协作和做决定，还需要清晰的价值流转和团队协作规则。规则也是看板系统的一部分，这对应着看板方法的下一个实践——显式化流程规则，我们将在近期文章中讨论。
总结
可视化价值流动是看板方法的第一个实践，也是其它几个实践的基础。例如，常有人告诉我“控制在制品的数量”这个实践实施难度很大，但每次进行深入分析，往往会发现价值流还没有理清，要控制的在制品是什么都不清晰，又何谈控制？又例如，没有很好的价值流的呈现，又何谈显式化流程规则？何谈流动管理？更不要说持续改进了。当然可视化价值流动只是第一步，是比不可少的基础，看板系统的应用和运作，还要靠其它几个实践。
下期预告：
这个实例展示了什么是可视化价值流以及它的意义。然而团队因目标和背景不同，其价值流动的过程也必然不同，我们无法照搬别人的看板墙设计。如何结合团队的目标和上下文，来设计自己的可视化价值流方案呢？下一篇我将介绍可视化价值流的具体的方法，我们将了解到看板墙的设计元素、设计步骤、原则以及实用模板。
相关文章：
精彩推荐：
文中注释：
Jira是一个电子的项目管理工具，它也支持敏捷和精益的交付模式 ↩
何谓适当数量，优先级如何确认？我们将在介绍管理工作流实践时讨论 ↩
在这一步团队会采用实例化需求实践的方式对需求澄清，它是一个敏捷需求实践，以会议或小型工作坊的形式进行，产品、开发和测试针对需求进行沟通，澄清需求的目标、用户使用流程和业务规则，三方达成一致并最终生成需求验收标准 ↩
故事是敏捷开发中的表示需求的术语，它以简短语言描述用户的具体需求，故事通常应该是完整可测试的，且规模相对较小，以便团队基于它进行充分的沟通和迭代交付 ↩