前一篇：看板方法：苦逼的程序猿
这几个主题没啥逻辑关系，想到哪写到哪，算是看板方法学习和实践的总结。
看板方法最直观的感觉就是可视化，今天聊聊可视化了哪些东西。
一、价值流可视化
1、敏捷推行为什么比较难？
由传统的研发流程向敏捷转变比较难，特别是对于大公司，尤其是已经有多年IPD经验的公司。
敏捷，除了思维模式的不同，研发流程也发生了很大的变化，对现有的体系和角色影响都比较大。
从我接触的敏捷项目来看，很少有成功的，大多不伦不类，形似大于神似。
2、看板一定会成功吗？
看板方法遵循最小侵入原则：不改变原有流程，不影响原有角色职责。
这也是 《看板方法：科技企业渐进变革成功之道》这本书副标题想表达的含义：作者希望通过看板方法，循序渐进的走向敏捷。
看板方法帮助团队发现过程中的问题和瓶颈，在解决这些问题的过程中，持续改进。
看板方法是自驱型的改进方法：自己发现问题，自己改进，倾向于自治。
3、可视化价值流
这是一个典型的看板样例，里面有几个要素：价值流、在制品数量、完成标准。
首先，要明确什么是价值：对应于研发的需求、特性、Story等，能够体现用户价值。
价值流：价值从开始到交付所经过的流程，例如，分析、设计、开发、测试、发布等。
第一，采用团队实际的使用流程，而不是官方流程。只有团队成员一致认可的流程，执行起来才不会有问题，实施改进也比较方便。
第二，不同的团队可以采用不同的流程，不一定非要统一，允许有差异性。
第三，看板是持续演进的，包括价值流，不是一成不变的。
二、内建质量标准可视化
1、内建质量
在戴明的十四条管理原则中有这样一条：
停止依靠大规模检查去获得质量（Cease dependence on mass inspection）。
靠检查去提高质量，太晚了，无效而且昂贵。质量不是来自检查，而是来自植入源头，改进系统过程。检查、扔弃、降级、返工不是改进系统过程的正确方法，当质量不到位时，检查总比不检查好，而检查也只可能是唯一可用的方法，但损失已造成，有的无法弥补，有的可以返工但仍会增加开支。
1．检查是一个非常有限的工具
2．奖励检查人员多发现缺陷十分有害
3．检查要统一标准，责任要明确到个人
在《持续交付 发布可靠软件的系统方法（英文版）》里面也提到了内建质量（Inner Quality），表达的意思是一致的。
2、可视化完成标准（Defination Of Done）
大家注意一下上面看板下面的位置有个Defination Of Done，就是这个流程的任务的完成标准。时刻提醒看板使用人员关注完成标准，从每个流程开始构建质量。
完成标准同样也是团队成员一起讨论达成一致的。
三、问题&风险可视化
如果是物理看板的话，可以通过不同的颜色来标识，在有风险的价值项上再贴上一个风险卡，大家可以注意一下有两个卡片帖子一起的那种。
有些看板系统是支持标识阻塞问题和风险项的，如果不支持的话，可能需要自己定制规则。
参考：
减少浪费、提升研发效率，如果你对精益研发感兴趣，请关注《精益研发》专题，共同交流，欢迎投稿。
