看板方法：可视化Everything

前一篇：看板方法：苦逼的程序猿

     这几个主题没啥逻辑关系，想到哪写到哪，算是看板方法学习和实践的总结。

    看板方法最直观的感觉就是可视化，今天聊聊可视化了哪些东西。

一、价值流可视化

1、敏捷推行为什么比较难？

     由传统的研发流程向敏捷转变比较难，特别是对于大公司，尤其是已经有多年IPD经验的公司。

      敏捷，除了思维模式的不同，研发流程也发生了很大的变化，对现有的体系和角色影响都比较大。

      从我接触的敏捷项目来看，很少有成功的，大多不伦不类，形似大于神似。

披着羊皮的狼

2、看板一定会成功吗？

     看板方法遵循最小侵入原则：不改变原有流程，不影响原有角色职责。

      这也是 《看板方法：科技企业渐进变革成功之道》这本书副标题想表达的含义：作者希望通过看板方法，循序渐进的走向敏捷。

      看板方法帮助团队发现过程中的问题和瓶颈，在解决这些问题的过程中，持续改进。

      看板方法是自驱型的改进方法：自己发现问题，自己改进，倾向于自治。

3、可视化价值流

      这是一个典型的看板样例，里面有几个要素：价值流、在制品数量、完成标准。

价值流可视化

     首先，要明确什么是价值：对应于研发的需求、特性、Story等，能够体现用户价值。

      价值流：价值从开始到交付所经过的流程，例如，分析、设计、开发、测试、发布等。

       第一，采用团队实际的使用流程，而不是官方流程。只有团队成员一致认可的流程，执行起来才不会有问题，实施改进也比较方便。

       第二，不同的团队可以采用不同的流程，不一定非要统一，允许有差异性。

      第三，看板是持续演进的，包括价值流，不是一成不变的。

二、内建质量标准可视化

1、内建质量

       在戴明的十四条管理原则中有这样一条：

停止依靠大规模检查去获得质量（Cease dependence on mass inspection）。

靠检查去提高质量，太晚了，无效而且昂贵。质量不是来自检查，而是来自植入源头，改进系统过程。检查、扔弃、降级、返工不是改进系统过程的正确方法，当质量不到位时，检查总比不检查好，而检查也只可能是唯一可用的方法，但损失已造成，有的无法弥补，有的可以返工但仍会增加开支。

1．检查是一个非常有限的工具
2．奖励检查人员多发现缺陷十分有害
3．检查要统一标准，责任要明确到个人

     在《持续交付 发布可靠软件的系统方法（英文版）》里面也提到了内建质量（Inner Quality），表达的意思是一致的。

2、可视化完成标准（Defination Of Done）

      大家注意一下上面看板下面的位置有个Defination Of Done，就是这个流程的任务的完成标准。时刻提醒看板使用人员关注完成标准，从每个流程开始构建质量。

      完成标准同样也是团队成员一起讨论达成一致的。

三、问题&风险可视化

       如果是物理看板的话，可以通过不同的颜色来标识，在有风险的价值项上再贴上一个风险卡，大家可以注意一下有两个卡片帖子一起的那种。

      有些看板系统是支持标识阻塞问题和风险项的，如果不支持的话，可能需要自己定制规则。

物理看板

参考：

《看板方法：科技企业渐进变革成功之道》迷你书

电子看板还是物理看板-鱼与熊掌可以兼得吗？

减少浪费、提升研发效率，如果你对精益研发感兴趣，请关注《精益研发》专题，共同交流，欢迎投稿。