《精益开发与看板方法》—2-5 哪些地方可以运用看板方法

2-5  哪些地方可以运用看板方法

一般认为，看板应当是运用在需要高效能的制造业上，但其实看板是一种流程控制的方法，因此只要有流程的地方，基本上就可以派得上用场，并没有局限于制造业。如果从精益开发的原则为出发点的话（就是第1章的七个原则：消除浪费、增强学习、尽量延迟决策、尽快交付、授权团队、嵌入完整性、着眼整体），则看板方法可以适用于各行各业，即使是很难数据化的工作，例如几个比较有趣的地方：公园赏花人数流量的控制，位于东京市区的皇居东御苑公园，对园内参观人数的管制就是使用看板[1]；或是著名的麦当劳得来速（Drive-Through）流程，日本星巴克咖啡，甚至台湾一些传统饮食店习惯用夹点餐纸条的方式……等行业也都有用到。本书把焦点放在软件开发以及可以运用于个人身上的看板方法。

看板方法运用在软件业

l   运用于“软件开发”
看板方法属于敏捷开发的一员，但因为它只专注于流程的管控，因此也能够适用于非敏捷的阵营，而且即使是运用在传统的开发方法当中，对于开发效能仍然有显著的帮助。
看板之父安德森称看板方法为一种限制半成品（WIP）数量的流程管制，它不是一种开发方法（虽然它是在软件开发的环境下创造出来的），虽然它也很适合拿来管制软件开发时的流程，但它仍然只是一种运用于精益原则之下的高效能流程管制。目前有许多专家正不断为它加入新的元素，希望它能成为一个完整的开发方法，因此就诞生了 Scrum + Kanban = Scrumban 等结合 Scrum 和看板的新开发方法[2]，这对于那些既熟悉Scrum的运作又想要取得看板效能的开发人员而言是一个莫大的帮助。

l   运用于***
维护工作一直是看板方法表现得最好的领域，这也正好是其他许多敏捷开发方法最受人质疑的地方。平心而论，维护工作就是接到请求后，便设法解决问题，然后在适当的时机进行部署，替换掉先前的问题。这种直观的工作，实在也没有必要运用敏捷开发的渐进式开发方法或是切割成多个迭代来完成，直觉地采用看板方法的流程控制方式，恰好最能满足客户急着获得改善的需求。
“看得见的多任务工作”[3]这是我最喜欢推荐给IT部门主管的运维利器。它的功能是让IT部门知道自己在忙些什么？一般IT部门为了维持正常的运作，必然会产生工程师每个人同时背负多个任务的状况，使工程人员不得不经常性加班，工作常常因此而延误。为什么呢？有些工程师忙得要命，却也有人轻松地闲在那里，看板方法是解决这个问题的良方，就是让忙碌能够看得见，为什么看得见呢？因为它们（所有的工作、由谁来做、谁负责什么）都陈列在看板上面，因此就无所遁形了，这是看板方法六个实践的第一条——可视化（Visualize）。

l   运用于“软件测试”
所谓“看得见才能测试”，所指的是运用看板方法让：（1）开发流程与测试流程能够透明化，让我们看得见瓶颈所在；（2）让测试工作井然有序，让主管及团队成员都能知道整体的进度（这是拉动系统适用在测试工作上的一个最佳佐证）。

运用于个人：个人看板（Personal Kanban）[4]

看板方法也能够运用在个人身上，值不值得采用呢？当然值得，因为团队的效能[5]绝对会因为个人效能的提升而得到改善。因此，不只是开发团队应该采用看板方法，个人也应该将它来运用于生活。我们将在第5章谈到个人看板，运用提升个人效能的敏捷方法。附件里的精益咖啡（Lean coffee）则是一种个人看板运用，应用在团队交互学习的讨论会。

运用于云端：自动化流程控制

目前几乎所有制造工作流程引擎的厂商都在考虑如何引入看板方法，原因很简单，因为它可以让整个团队看到流程上的瓶颈，然后借此持续提升效能。这种观念正逐渐侵入自动化领域，过去自动化流程就是一心求快求精准，进入到云端领域后，大部分人还以为就是朝向无边界的方向追求，甚至有人以为让程序代码优化都是一种浪费，因为云端太无限了[6]，应该足以忽略它。几年过去了，对云端的错误观念已经逐渐修正过来，对于效能的追求还是应该一步一脚印，只有仔细计算才会有精确的数值，而看板方法限制半成品的数目反而能够增加效能的理论，一样适用于云端环境。