读《精益开发实战》时知道了看板方法，当时的粗浅理解是「可视化管理」，因为我个人更喜欢电子看板，团队迟迟没有引入「物理看板」，2015 年使用「电子看板」半年后还是回到了基于甘特图的老路。由于缺乏理论基础，总是在按照传统的项目管理思路使用看板，新瓶装老酒，感觉怪怪的。
David Anderson 在《看板方法》开篇以春天樱花季去东京皇居东御苑公园游玩的经历说明「看板并不只供制造业使用」，由此引出两个核心概念：Pull System 和 Work-In-Progress Limit。公园本身就是一个拉动系统，游客便是在制品。游园的高峰期，通过发放卡片的方式来控制园内的人数，当所有卡片发放完时，新到的游客必须在园外的桥上排队等候，等待其他游客离园后回收的入园卡。
第四部分以「公路」和「海湾轮渡」为例说明 Bottelnecks。先来看看「能力受限资源」的例子：
华盛顿 SR-520 公路是连接西雅图与其市郊柯克兰（Kirkland）和雷蒙德（Redmond）两区的高速公路，每天有 8 个小时处于严重的双向交通瓶颈状态。经历浮桥跨过华盛顿湖前，这条高速公路由三车道变窄成双车道，导致高峰期只发挥了 20% 的吞吐潜力，堵车长达 7 公里。
「非即时可用资源」并非瓶颈，但是，它们看起来很像瓶颈。普吉特海湾的轮渡系统是一个典型的例子：
普吉特海湾的三个轮渡系统把吉赛普（Kitsap）和奥林匹克半岛（Olympic Peninsulas）与西雅图市区连接在一直。其中一个是连接埃德蒙兹（Edmonds）东侧和金斯敦（Kingston）西侧的处在 SR-104 公路上。在地图上，这条轮渡航线显示为 SR-104 公路的一部分。通常它被标记为「收费」，而不是明确说明「到这里你得上船摆渡」。
开车到轮渡时，需要先付费，然后在一个等候区等候。等待时间大概需要 30 分钟，因为渡轮需要花 30 分钟时间渡过普吉特湾；之后渡轮还需要花 10 到 15 分钟卸下车辆，在返航前又需要花差不多的时间载上全部新的车辆。通常轮渡公司会投入两艘渡轮，因此每艘渡轮的运输时间差不多是 50 分钟一趟。在高峰时间，可能会投入 3 艘渡轮，把每次摆渡的等待时间控制在 35 分钟左右。
在我的团队，后台开发是「能力受限」，7 人项目组只有 1 人负责后台，既要设计 DB、REST API 还要对接 iOS / Android 和 Web 后台的功能开发。我本人是「非即时可用」，A 项目产品经理找我评审需求时，我可能在和 B 项目架构师评审设计；B 项目找我讨论下个月工作计划时，我可能在做 S 项目发布……使用物理看板后，站立会议拉动卡片时我们俩将被标注为阻塞（Block），想想还有点儿小紧张呢 :D
再次回到东京皇居东御苑公园的例子，WIP Limit（游客上限）在这个示例中是确定的，但是在软件项目中任务通常无法精确估算，和朋友讨论时我经常被问到：
* 有些功能半小时能修改完，有些要一两周，怎么统一；
* 今天刚确认的需求明天又变了；
* ……
David Anderson 在书中把上面的问题称做：Variability。
第 19 章作者深入讨论了「变异性的根源」，分为「内部变异」和「外部变异」。结合 19 章重新阅读本书第三部分，就能够理解作者为什么提出了 Value Stram / Work Item Type / Delivery Cadence / Prioritization / Class-of-Service / Operations Review 等关键活动了。
最后，David Anderson 在书中介绍的看板方法起源于「维护项目」，对于产品研发型项目如何应用看板还要进一步学习，希望能够在下一本书《看板实战》中找到答案。
原文链接：http://www.jianshu.com/p/9735dfdfe87a