InfoQ：但是克服初入门槛的障碍，先把一只脚跨进大门，然后再有所发展不重要吗？以一家大型的金融公司为例，假定这家公司有着完整而系统的管理层，再假定他们的开发团队有使用看板的想法。那么他们必须说服管理层，尤其是管理层的经理，那么经理可能会说：“你去年说服我使用Scrum，现在你又想让我使用看板，那么我们预期从使用Scrum中获得的收益怎么办呢？” David：这是一个我觉得很重要的，但是对其误解又很多的一点，而且这又是一个在北美的敏捷社区中存在的问题。 很多十分有名的敏捷社区成员把看板描述为一个团队层面的方法，但是看板绝不仅仅是团队层面的方法。第一个看板系统是一个多部门的工作流方法。分别完成于2006和2007年的第二和第三个看板系统，是多部门工作流的实践。看板从来都不是一种团队层面的方法，它是一种组织层面的、工作流层面的方法。看板方法被设计为一个从中间引发的变革，这使得它在市场上与众不同。许多精益顾问，我不是特指精益，但是这在精益中是比较普遍的，他们会告诉你只要行政主管买他们的服务，就一定可以取得成功。所以，精益是一个自上而下的变革。而由于敏捷是面向团队的，或者说是面向开发者的，所以许多敏捷带来的变革是自下而上的。看板系统被设计为由中间引发变革，它更像是一个面向服务的、在各类工作的生命周期中跨越不同部门和不同阶段的工作流程，它涉及到多个团队的协作。要做到这些，你必须是一个中层的经理，这样你就有权限去整合不同的元素。如果你只是一个开发者，那这就远高于你所在的级别。 看板主要就是用来摆脱那些使我的生活一团糟的事情，摆脱其他所有干扰。这使得管理者关注在发生阻塞的关键点上，然后我可以帮助他们尽快排除阻塞然后开展我的工作。最重要的是，这可以让我把精力集中在几件事情上，而不是别人要求的一大堆事。 另一个经常出现的员工的不满，主要是由于优先级不断调整所引发的频繁目标变化。看板可以帮助人们把精力集中在社区中所说的“辣妹问题（Spice Girls question）”上。当你在为看板系统做队列补充（queue replenishment）时，你可以关注接下来两件关键的事。管理顾问Stephen Bungay会让你必须告诉他“什么是你想要的？什么是你真正想要的？”，一旦你决定了就不能再改变主意。因此，一旦某项任务从看板上流过，我们希望它永远不会被丢弃。开发人员和分析师们都认为这很有用，这使得他们只解决人们真正想要解决的问题。而且这样的话质量处于可控状态，所以他们可以集中精力做好，交付，然后进行下一项工作。而自下而上的变革通常可以带来一些改变，然后趋于停滞，除非他们能够进一步实施并且扩大价值。如果不是很有影响力的人在做的话，一般不会有进一步的提升了。我们都看到过病毒的爆发，但是很少看到无人指挥的看板系统自发扩张。 实际上，要正确地实施看板需要中层管理人员的参与，例如主任级别的管理者，在小公司里则需要高级管理层的参与。经过周密规划的实施会为员工们带来心理学和社会学上的好处，会使得他们做出质量较高的工作，并且为他们减轻许多压力，但这并不会直接驱动经济效益。在我的书里，我讨论了“萧条”的好处。但是如果你谈论“萧条”的好处，那你没法把看板作为一项产品或者服务推销出去，也没法让高级行政人员理解他们为什么要为看板埋单。
InfoQ：有没有决策树一类的东西，可以让我们用来判断看板是否能带来您所描述的成效？ David：有的，我们的进阶课程里教这个，实际上“什么时候不应该使用看板”讲起来更容易些。 如果高层管理人员是缺乏耐心的改革家，总是急着想要看到戏剧性的变化，那么你不应该使用看板。但是如果你处在一个文化保守的国家，而且是在某个官僚主义的组织里，那么看板可能略微合适一些。另一个不适用看板的情况是在极度混乱的情形下，或者是在早期调研阶段。看板更适用于进展阶段，而不是调研阶段。你应当可以恰当地描述价值流（value stream，指从概念到产品，然后到客户手中的一系列流程），并且能够定义用户想要什么样的服务。如果你没法说清楚这些，那么你就不该为此建立一个看板系统。 从技术公司的角度看，你需要有配置管理（CM）的能力、版本控制系统、并能够在某些工作正在开发的时候发布另一些工作。与典型的敏捷方法相比，这需要一个更高层次的配置管理能力。假设你开始了某项迭代，然后在工作了几周后进行部署，在这个过程中基本上不会动其他标签或者分支的代码。但是在看板系统中，你可能同时写多个分支，不是每个公司都有这样的技术能力的。
InfoQ：我想能够更好地理解一下实施。比如说你正在管理开发流程，在项目里通常是先建模，然后搭建测试环境，开始具体编码，然后进行测试，最后做代码审阅等等。那么应该在看板的各项中监管上述流程吗？ David：可以这样，但是你也会想要把上下游的流程包括进来。观察一下你目前的监管范围，一旦你可以监管更多东西后，你就也能控制上下游的流程。
InfoQ：我想这种方式正是我们所需要的。团队管理者需要作出实施看板的决定，然后看板是否有效决定了它能否得到延续。如果我们能从小的地方做起，然后作出一些改变，那么看板就可以得到进一步的使用。 David：不管是在发展什么东西的过程中，都有必要去积累“社会资本（social capital）”。你可以通过各种社会学的方法，比如通过提供更佳的透明度去建立信任。当别人理解一个东西的工作原理后，当他们可以问：“我两周前给你交待了这项工作，现在进行的怎么样了？”时，才能产生信任感。信任是逐步累积的，从心理学的角度来说，与需要较长间隔期实现的大承诺相比，不断实现的小承诺能够更好地建立信任。所以要根据你的目标进行交付并建立信任，这也说明了如何在一个自下而上的过程中产生动力。 David：有时在上了两天看板的高级培训课后，有些学员会跑过来问：“我们已经学习了变革、心理学和社会学，你打算什么时候开始教我们使用看板？”但实际上这就是看板的大部分内容。在核心层面上，看板系统仅由一个带有信号机制的“进行工作中的有限拉动系统（work in progress limiting pull system）”组成。再多一些的话，就是理解需求以及如何对限制进行选择。如何才能使得某个组织中脑力工作者的表现发生革命性的变化？这本身就是一个社会学和心理学的议题。
InfoQ：好的，感谢David提供的信息！看板好像肯定会风靡世界了，祝你一帆风顺！
个人简介： David J. Anderson在高科技行业拥有30年经验，并曾在诸如Sprint，Motorola和Microsoft这样的大公司使用创新的敏捷方法带领软件开发团队，使得团队拥有卓越的生产力和产品质量。David是三本书的作者，包括《软件工程中的敏捷管理——商业中的约束理论》，《“看板”——技术企业的成功变革》以及《敏捷管理课程：通往“看板”之路》。
[1]Dijkstra：艾兹赫尔·戴克斯特拉（EdsgerWybeDijkstra），生于荷兰鹿特丹，计算机科学家，是荷兰第一位以程序为专业的科学家。曾在1972年获得过素有计算机科学界的诺贝尔奖之称的图灵奖。 [2]Kernighan：布莱恩·柯林汉（Brian Kernighan），生于加拿大多伦多，加拿大计算机科学家，曾服务于贝尔实验室，为普林斯顿大学教授。他曾参与Unix的研发，也是AMPL与AWK的共同创造者之一。 [3]UML三剑客（Three Amigos）：指UML的三位创始人，Grady Booch、James Rumbaugh和Ivar Jacobson。三人均为软件工程界的权威，除了著有多部软件工程方面的著作之外，在对象技术发展上也有诸多杰出贡献，其中包括Booch方法、对象建模技术（OMT）和Objectory（OOSE）过程。 [4]GoF四侠（The Gang of Four）：指Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides这四位软件设计领域的世界顶级大师。他们合著有《设计模式:可复用面向对象软件的基础》，提出了23种基本设计模式，从理论高度提炼并规范了设计模式，对面向对象设计，软件复用领域产生了巨大影响。 查看英文原文：InfoQ Interviews David J. Anderson at Lean Kanban 2013 Conference | 
