当组织进行规模化敏捷，并想把看板作为一种敏捷方法应用的时候，问题就来了，可否规模化看板？Klaus Leopold在 上演讲的中进行了这样的解释：看板本身就具有规模化的能力，所以从严格意义上来说，这一问题的答案不可能是“否”，因为规模化看板仅仅是当前状态的一步改进。规模化看板意味着运行更多真正的看板，产生更多的改进。

在敏捷组织中，所有的团队都应该使用敏捷方法，这是一个误解。有许多不同的方法可以使用，团队必须应用对团队有效的方法，并且根据他们的情况进行调整。Klaus表示，组织就是一个活生生的社会系统。团队在组织中并不是孤立的，他们互相连接，并通过交互产生价值。

InfoQ采访了Klaus，谈论了用看板管理项目集，在团队和项目集层面部署和连接看板板，在完整的交付周期中管理进行中的工作，以及看板带来的好处。

InfoQ：您谈到应当不断适应现实的工作环境，而不是去适应一个蓝图，您可否举一些例子呢?

\

Klaus: 在《爱丽丝梦游仙境》中有一个场景，兔子说，“为了能够站住，你必须跑的非常快。”我认为这个例子很好地解释了今天的商业现实。如果你不能不断地调整工作环境来适应一直变化的环境，那么这个世界就会把你遗忘。不幸的是，我没有那么聪明，可以提供一个包括多种实践的蓝图，能够适用于大千世界的所有组织，并让他们在市场上获得成功。我深深地相信，每一个组织必须自己找到答案。

\\

这方面最好的一个例子可能就是日本丰田汽车，他们允许竞争对手进入他们的工厂，并演示给他们如何生产汽车。可以参看如Mike Rother编写的《》一书。尽管很多公司照搬丰田公司的实践，但没有一家公司能够像丰田那样成功。所以，这完全不是采用别人的最佳实践和解决方案就可以成功的，实践仅仅是对包含多个改善步骤的学习循环的表现。如果你采用别人的解决方案来解决你的问题，那么这个解决方案不能解决你的问题也就不奇怪了。

\

InfoQ：在中欧精益看板大会上，你谈到在某个软件开发项目中使用了看板，他们为什么决定用看板？

\

Klaus：我谈到的这个组织几乎在复杂的世界里迷失了。在这个项目中有大约200个人，他们想要完成共同的目标，但他们完全不知道该怎么做，也不知道他们的现状如何，以及他们是否可以达到目标。他们想保持尽可能的最小且无痛苦的变革，因为人们只是厌倦了正在进行的组织变革浪潮，这种浪潮冲击了他们的头脑。他们的想法就是保持团队的正常工作，并且不在变革方面对他们产生太多干扰。所以第一步我们只是想更好地协调团队意见，确保他们在正确的时间做正确的事情。

\\

你可以把公司比喻成一个键盘，每一个按键代表了一个团队。如果你要给客户写一封信，你不会想对团队的有效性进行优化，从而让键盘上的按键按得更快。这几乎不会带来任何更多的产出。当在写一封信的时候，更重要的是你在正确的时间按下正确的按键。当你的公司创建的价值依赖于多个团队的时候是同样的道理。

\\

当你在这个飞行水平（Flight Level）开始你的改进之旅时（参见 和)，团队不需要在他们的工作方式上进行很大的改变。实际上，团队是用看板还是Scrum，或是其他的方法都没关系。跨团队基本的建立流程是确保每个人在正确的时间做正确的事情。

\

InfoQ：您可否详细阐述一下看板是如何引入到这个项目中的？

\

Klaus：这是一个很大的问题。我来尝试概括最重要的事情：在开始的时候，我们组建了一个跨功能和层级桥梁的变革团队，由他们引领变革。他们是有关变革疑问的主要联系人，并且主导引入变革的所有活动。变革团队所做的第一件事情就是。有了这些信息，我们就可以准备系统设计的工作坊。团队提名代表来。

\\

在开始的时候，我们整个团队只有一个用于协调的看板系统。后来，越来越多的团队决定在团队层面使用看板。这是非常棒的，因为是团队拉动了变革 -- 没有人告诉他们必须要用看板！当然，我们完全支持他们的决定。

\

InfoQ：为什么团队建立自己的看板板很重要，而不是建立一个标准板?

\

Klaus: 我认为很大一点原因是主人翁意识。当我建立了我的系统，我会理解它的意图以及如何工作。所以，如果有些地方没有预计那样有效果的时候，我就会有种内在的动机来改善我的系统。然而，如果一个聪明的人提出了一个板，然后告诉我这样工作应该最有效，那么我的目标就是告诉这个聪明的人他错了！如果人们不是自己设计这个系统，他们试图规避这个系统的概率就会变大，而不是出于对他们有利而使用他们。

\

InfoQ：在您的讲演中，您曾提到在团队中协调用项目站立会议，您可否解释一下是怎么做的吗？

\

Klaus：那其实不是什么大问题。团队派出代表参加一周两次的协调会议。目的是协调跨团队的工作 – 谁需要谁的信息，谁可以帮助谁解决工作上的阻碍、我们有什么依赖等等。我真正喜欢的是团队轮流派代表的原则：每周有一名不同的人代表他的团队。相比于自己的小团队花园，这种方式对于理解整个项目的情况真是非常有帮助。情况就不再会是“只有我们团队的这几个家伙是很好的，而其他的人都是累赘。”， 而很可能是“我们可以一起做什么让项目成功？”另外，这也培养了团队之间的领导力。我并不是高地人原则（Highlander Principle）“无敌模式”的铁粉，我认为我们需要在不同层面上有更多的领导，而不是单点故障方式，就像看板Master等。

\

InfoQ：您曾给出过一个例子，描述了在完整的交付周期将看板板与管理在制品数量（WIP）连接起来，您可否解释一下它是怎么工作的吗？

\

Klaus：连接系统是规模化看板的一种方式。然而，在看板的上下文中讨论规模化却有点困难，因为在规模化时，你真正所做的仅仅就是解决一个问题。我在现实中遇到过两种典型的问题，而规模化是一个解决方案：

\\

（1）聚合服务

\\

我经常看到一种模式：服务A始终依赖于服务B。例如看板系统中，前端开发的服务始终等待后端开发的服务，如下图所示：

\\

(点击图像以放大)

\\

\\

这种依赖性必然会增加了大量的周期时间（Lead Time）。我看到的方案通常是只把这两个服务合并成一个服务，例如“前端和后端开发”。我曾看到过很多这样的实现。最简单的就是把两个团队合并成一个更大的团队。但是，这种方式只有在人数有限的情况下才是有意义的。我还经常看到的一种方式是，团队并不合并，但他们用共同的看板系统来进行协调工作。

\\

（2）连接服务

\\

连接也类似。同样有两个服务彼此依赖，但现在的情况是，服务B要用服务A的输出作为输入。例如：想象一下有一个开发服务和一个整合服务。当开发完成的时候，他们把工作转给整合。当这两个服务不连接时，他们就把工作项放入到无限缓冲区中，例如“准备2整合”，这基本上就是这个板的完成栏。从开发的角度看这个工作可能已经完成了。然而，在客户的角度上这一任务并没有完成，因为它必须与整个系统整合并且还需要发布等等。看板在很大程度上就是通过客户的眼睛来看整个世界，因此把两个服务连接起来就变的有意义了。另外，减少无限缓冲意味着你有一个可预见的工作流。

\\

(点击图像以放大)

\\

\\\\

为了解决这个问题，你只要把这两个服务连接起来，然后在“准备2整合”栏写上在制品数量限制。你实际要做的是，你通过下图中的方式连接两个单独的服务，以一种面向服务的方式实现规模化。这就是一个真正的SAFE（规模化敏捷的一种方法）方式。规模化看板意思就是做更多的看板。你不需要用一个蓝图去做，因为这只是常识 – 这只是你的组织怎么工作的。你可以从 “”这篇博客文章中查看更多内容。

\\

(点击图像以放大)

\\

\

InfoQ：您可否阐述一下应用看板给该项目带来的一些好处吗？

\

Klaus：最大的好处肯定是，为了达到共同的目标：项目的成功，所有团队互相协调他们的工作。在开始的时候，让大家都关注在工作流上而不是使用上是非常困难的。不开始新的工作并不合适，因为我们已经达到了在线制品数量限制，并且还要专注于改进系统。然而，它完全得到了回报：仅仅两个星期之后，史诗（Epics）的周期时间减半，另一方面，我们看到了产出在上升，团队也减轻了很多压力。结果就是，我们能够做到在短期内交付更多的东西，团队成员们也会感到更加快乐。

\

关于被采访人

Klaus Leopold是一位具有多年经验的计算机科学家，帮助不同行业的组织用精益和看板开展他们的改进之旅。他是《》（2012年由Hanser Verlag 在德国发布）的合著者，也是《》（将于2015年5月由Wiley发布）英文翻译的合译者。Klaus是第一批全球精益看板的培训师和教练。他在2014年旧金山的看板社区得到了名为“杰出成就和领导”的Brickell Key奖。Klaus还是Stoos管理网络的创始人之一。他主要的兴趣是在团队之上的敏捷性，尤其是针对30到500人规模的项目。他经常在自己的博客中发表各种最新的见解，你也可以关注他的Twitter帐号 。

查看英文原文：

感谢对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。