敏捷开发 - 面向过程管理：Kanban方式
敏捷开发 - 面向过程管理：Kanban方式
看板本身源于日本丰田公司对精益制造的实践，后延伸到敏捷开发领域；它的核心是JIT（Just In Time）: “让正确的物资，在正确的时间，流动到正确的地方，数量是刚刚好的数量。” 本文主要介绍看板的定义，核心实践以及在研发领域的实践等。@pdai
什么是Kanban
看板本身源于日本丰田公司对精益制造的实践，后延伸到敏捷开发领域；这里之所以要学习原始含义，是很多开发者并不明白看板的核心，即JIT（Just In Time）: “让正确的物资，在正确的时间，流动到正确的地方，数量是刚刚好的数量。” @pdai
看板的原始(精益制造)含义
看板源自精益制造。尽管具体实践不同，看板开发方法和精益制造中的看板原理是一致的。从精益制造出发，可以帮助我们更好地理解看板的本质。
看板源自精益制造
精益制造是上世纪50年代起，从丰田公司实践中演化出来的，又被称为“丰田生产方式”。丰田生产方式的两大支柱是‘准时化’和‘自働化’，看板是运营这一系统的核心工具。
看板（Kanban）一词来自日文，本义是可视化卡片。如下图所示，看板工具的实质是：后道工序在需要时，通过看板向前道工序发出信号——请给我需要数量的输入，前道工序只有得到看板后，才按需生产。看板信号由下游向上游传递，拉动上游的生产活动，使产品向下游流动。拉动的源头是最下游的客户价值，也就是客户订单或需求。
基于看板的拉动系统实现准时化
准时化又叫即时生产（Just in time – JIT）是丰田生产方式的一个支柱。看板形成拉动系统，各环节根据看板信息，仅在在需要的时间，生产需要数量的必要产品。这将带来生产库存的降低，甚至实现生产过程零库存。库存又被称为“在制品（WIP ——work in progress）”，是已经开始但没有完成的工作，它们堆积在工序间或临时仓库中。库存降低带来的直接收益是：
- 降低成本：库存减少增加了运营现金的使用率，同时降低管理和仓储开销。
- 缩短交付周期：消除或缩短产品在工序间的库存等待时间，缩短了从开始制造到交付的周期时间。
- 提高制造过程的灵活性：在低库存水平下，调整生产的计划更加容易。
降低库存更重要的作用是暴露制造系统中的问题。下图中的湖水岩石是一个经典隐喻，水位代表库存多少，岩石代表问题。水位高，岩石就会被隐藏。生产系统中库存多时，设备不良、停工等待、质量不佳、瓶颈过载等问题都会被掩盖。库存降低后，这些问题都会显现出来。没有了临时库存的缓冲，设备运转不良或停工等待立即会凸显出来；没有了库存等待时间，上一环节输出的质量问题也能即时得到反馈。这就是所谓“水落石出”，暴露问题是解决问题先决条件，不断暴露和解决问题，带来生产率、质量以及灵活性的提高。
自働化
自働化是丰田生产方式的另一支柱，它的准确含义是自动停机（Auto-No-Mation），指出现问题时（如某个环节有次品），机器能够自动感知异常，并立刻停机或停下整个生产线。丰田认为，这相当于把人的智慧赋予了机器，称其为“人字旁的自动化”，所以用“働”而非 “动”字。图中比较了自动化与自働化在概念和实践上的不同。
自働化把质量内建于每一个制造环节，出现异常时，杜绝继续产出不合格产品，并且不把不合格产品输入到下一环节。这就是 “内建质量”（build quality in），而不是让质量依赖于最后的检测环节。
其次，自働化带来“停止并修正”（Stop and Fix）的文化，发生异常时，立刻停止生产，分析根本原因，并加以解决，防止问题的再次发生。“停止并修正”是持续改善的基础。
精益制造（丰田生产方式）既带来直接经济结果，又带来深层次的文化和思想变革。精益是制造业的革命，是既大规模生产之后的全新范式。精益思想的影响早已超越制造领域，精益服务、精益医疗，甚至精益行政都被广泛实践，产品开发也不例外。然而，开发和制造特点不同，决定无法照搬精益制造的实践。产品开发需要从自身特点出发，发展完备的实践体系。
产品制造产品开发影响工作对象具体、可见的物理产品抽象、不可见的信息产品开发的价值、价值流动不可见，管理价值流更加困难。有必要采取适当的措施，可视化价值和价值流动。完成单个任务的时长固定——完成前后两个加工任务的时间相同，且可以精确预测。不固定——每一个开发任务都是全新的，完成的时长不同，且不能完全预测。在生产中可以追求或逼近零库存。产品开发中，由于任务时长的不确定性，零库存可能会导致开发步骤间的等待。不同任务的延期成本相同差别很大在生产中一般采取先入先出（FIFO）的队列管理方式；开发中用需要应用比先入先出更灵活的队列管理方式，以优化经济结果。对可变性和错误的态度制造是重复的过程，消除可变性能够提高质量。不确定性(可变性)是产品开发价值的一部分，完全消除差异是不可能的产品开发必须接受不确定性，并通过必要的试错来验证它们，以增加价值。可变性不能完全消除，需要在考虑开发过程的可变性。
开发领域的看板模式
在开发领域看，“让正确的物资，在正确的时间，流动到正确的地方，数量是刚刚好的数量。"这种思路同样适用开发领域。
假设一个小组的工作流程为一个pipeline。如果里面的testers一周只能测试5个features，那么即使developers一周能实现10个新features，整个小组一周也只能交付5个features。这里，testers就是pipeline中的瓶颈。
假如这个瓶颈没有被发现，那么testers面前的任务就会堆积如山，尽管如此，整个小组的效率并没有得到提高。
如果问题得不到解决，developers辛辛苦苦实现出来的新features无法及时投放市场，最终将可能导致错失商机。更有严重的是，如果testers为了提高效率，降低对质量的要求，将有可能导致低质量的代码进入到产品中。 从另外一个角度来说，如果团队及时发现瓶颈所在，就能对此作出调节。比如，他们可以调派更多的testers，或者让部分developers帮助完成部分的test automation工作。
看板的核心实践
Kanban从脱胎自丰田公司的工程管理方法以来，在不同领域都有发展出具有领域特色的实现形式。虽然形式多样，但是它们始终遵循着下面一些核心原则。
可视化工作（价值）流
产品开发的加工对象称为信息，它的特点是抽象且不可见，这提高了价值流的管理难度。看板开发方法把可视化工作流作为基础实践，先让价值和价值流动具体可见，然后才是管理和优化。下图是看板开发方法中的一个典型可视化案例，被称为看板墙（Kanban wall）。
图中的每个卡片代表一个价值项，如：功能需求、缺陷、技术概念验证等。它们所在的列，表示其所处的阶段。这些价值项，每经过一个阶段（图中的列）都会产生新信息，价值得以增加。例如，需求经过分析阶段，注入了新信息，价值更高。
价值流是价值项从左至右的流动过程，是信息的产出过程，也是价值增加的过程。
价值流动可能会被阻碍。比如，编码因对第三方接口错误而无法进展；测试因没有设备而停滞。图中，红色卡片是对问题和阻碍因素的可视化。标识阻碍因素并推动其解决，促进价值流动。
最终限制系统端到端的流动速度的关键点在于系统瓶颈之处，改善端到端的价值流速，必须从解决瓶颈问题开始。发现看板墙上的瓶颈并不困难，找到最长的队列就可以了，这就和交通系统的瓶颈处，总是出现长长的等待车队是一个道理。上图中的队列出现在测试处，不难看出，测试是价值流动的瓶颈。
价值、价值流，以及问题和瓶颈的可视化，是改善价值的起始，也是其它看板实践的基础。
显式化流转规则
价值项的“流转规则”是看板开发方法中最典型流程规则，它定义了一个价值项从一个阶段进入下一阶段所必须达到的标准。下图中，给出了某团队其中一项流转规则的实例，定义了从分析阶段进入开发阶段所必须达到的条件。
“流转规则”的显式化，让质量内建于各个阶段——这与精益制造中内建质量的思想是一致的。除各个“流转规则”外，其它重要的流程规则也可以或者需要被显式化，如，团队的协作规则、优先级的定义规则等。
流转规则显式化更重要的意义在于，它是“持续改进”的出发点和结果的载体。没有显式化的规则作为依据，讨论改进就没有基础，而变得主观和随意。改进的结果通常也需要落实到显式的流程规则当中，让改进稳步进行，避免低效的反复。显式化规则不是为了限定团队的工作方式，而是为了帮助团队更好的改进。这就像，丰田的生产现场必须有明确操作规程，但如果这个操作过程长时间没有变化也同样是一个问题，因为，持续改进是精益思想的核心之一。
限制在制品数量
限制在制品数量是看板开发方法的核心机制。如上图中所示，列标题右面的数字标识了该阶段允许的在制品的最大数目（进行中和完成的价值项的和）。在制品数目小于这个数字时，才可以从前一阶段拉入新的工作。图中，分析阶段的在制品限制数目是3，而实际在制品数目是2，可以拉入新的工作。测试阶段的在制品数是3，达到了上限，就不允许拉入新工作。
限制在制品数量形成一个与精益制造类似的拉动机制。当一个环节有空余的能力（在制品数目未达上限）时，则从上游拉入新的工作，拉动的源头是最下游的交付或客户需求。与产品制造类似，使用使用拉动系统的好处如下：
- 加速价值流动：限制在制品数量，减少了价值项在阶段间的排队等待，缩短了价值从进入系统到交付的时间，加速了端到端的价值流动。
- 暴露问题：限制在制品数量，让湖水岩石效应产生作用。它让过去被隐藏的问题，如团队协作不良、需求定义错误、开发环境低效、资源分配不均衡等得以显现。
许多号称使用“看板”的团队，并没有限制在制品数量，他们当然也不会得到上述收益。精益制造通过看板向上游传信号，拉动生产。而看板开发方法通过限制在制品数量形成拉动系统，缺乏这一核心机制就不成其为看板。
度量和管理流动
快速、顺畅的价值流动是看板开发方法的目标。快速流动带来快速的价值产出和快速反馈，它对业务成功至关重要；顺畅流动，意味着稳定和可预测的价值交付能力，这与流动的绝对速度同等重要。
度量为改善价值流动提供方向参考，同时为改善的结果提供反馈。看板开发方法没有定义特定的度量方法，累积流量图是实际应用较为普遍的一种。下图是一个典型的累积流量图，左面的斜线是累积已经开始的价值项（如用户需求）数目，右面斜线是累积完成价值项的数目。两条斜线的垂直距离表示某个时刻已经开始但还没有完成的价值项数目，也就是在制品的总计数量。两条斜线的水平间距表示价值项从开始到完成的周期时间，也就是从概念到交付的响应时间，它是价值流动效率的一个重要衡量。斜线的斜率反应的是价值交付的速率，也就是每周可以交付的价值项数量。
累积流量是一个综合的价值流度量方法，可以通过它得到不同维度的信息。例如，我们设想用限制在制品的数目的方式，可以缩短周期时间、而对交付速率影响有限。但实际效果如何还要通过事实来检验，通过实验来度量。图中的数据基本验证了这一假设，让改进更有方向，结果更可衡量。同样的数据有不同的呈现方式，下图基于相同的数据，它突出了在制品数目和周期时间的变化趋势，以及两者的关系。从图中可以看出，周期时间的降低略滞后于在制品数量的降低，这符合精益理论，因为只有在积累的队列被处理完后，对交付周期的改进才能够显现出来。
而下图反应的是系统流量（每周交付价值的数量）的变化趋势，为改进提供了信心。
以上只是一个度量实例。度量不是目的，而是管理和优化价值流的手段。对于特定的组织，度量什么应该由目标和现状决定。
协同改进
应用可视化、限制在制品数量、以及价值流度量，能够暴露产品开发中的问题和瓶颈。但发现问题还不够，重要的是如何去解决它们，对此看板开发方法给出了两个建议——团队协作及应用科学方法和模型。限制在制品数目本身就能够激发协作，例如在前面图8的看板墙，可能会出现以下的顺序场景
- 测试遇到问题(如输入质量太差)而被阻塞 ，在制品数量达到上限
- 因在制品数量达到上限，根据规则，测试不能从上游（实现）拉入更多的工作
- 实现阶段已完成的工作无法进入下游测试环节，实现阶段的在制品数量很快也达到上限
- 实现要想开始更多的工作，就必须关注下游的问题，并做出反应，如提高本环节的输出质量，或者是给予帮助
- 实现和测试的协作使价值流动更加顺畅
上图是”kanban – Successful Evolutionary Change for Your Technology Business”一书的封面插图，它反映了发生在看板墙前面的协同改进。看板开发方法的基本假设是：产品开发的目标不是单个环节效率的最大化，而是端到端价值流的提升。看板通过拉动机制暴露了限制价值流动的瓶颈，并激发团队协作，改善价值流动。
解决瓶颈问题的方案可能在瓶颈处，如临时加班、分配更多资源、或相邻环节的支持等。但很多时候解决瓶颈问题的方案在别处，例如提高瓶颈之前环节的输出质量，调整职责分配，甚至是重新设计工作流。
对于偶然出现的问题，只需要临时性解决方案。如突发性高负荷，可以通过暂时的相互支持解决。而对于系统性问题，如持续的负荷不均衡，则需要长期的方案和更加系统和科学的模型指导，如系统思考、精益思想、排队理论等，这些模型本身不属于看板方法的一部分，但它们让长期的改进有章可循。
kanban实践
从上述看板的核心实践中可以看出基本实践流程。
我在网上找了些实践的内容，在具体的实践时可以参考，如下来源于 https://cloud.tencent.com/developer/article/1756761
下图也很具有参考性
卡片的设计可以参考如下， 来源于http://t.zoukankan.com/IT-Evan-p-14731409.html
对于完工定义和就绪定义可以参考如下
Scrum和看板Kanban的区别
kanban 看上去和Scrum有些相似，那有何区别呢？下面我将用一个表格来表现两者的不同。可以参看这篇文章：What is kanban? 在新窗口打开
有的团队把Kanban和Scrum两种方法糅合成一种叫做Scrumban的方法。这个方法吸取了Scrum中固定长度的Sprint和各种角色（Product Owner、Sprint Master等等）概念，同时也吸收了Kanban中“Focus on Flow” 和 “Limit Work In Progress”等原则。但是，刚开始采用Agile的团队建议只采取Scrum和Kanban中的一种，在熟练掌握所选方法后才根据团队特点进行相应的糅合或创新。
参考文章
看板原始含义和核心实践部分整理自：上书房_张强精益产品开发-看板开发方法 在新窗口打开
其它参考：
https://www.jianshu.com/p/5f0843ebe5ab
https://cloud.tencent.com/developer/article/1756761
http://t.zoukankan.com/IT-Evan-p-14731409.html