2013 精益看板大会：看板之父 David J. Anderson 访谈实录

如果要在硅谷的风云人物中再树立一座丰碑的话，那么软件开发工业的“看板之父”David J. Anderson 当与 Dijkstra[1]，Kernighan[2]，UML 三剑客（Three Amigos）[3] 和 GoF 四侠（Gang of Four）[4] 比肩并立。在今年 4 月于芝加哥市中心召开的北美精益看板大会上，InfoQ 对 Anderson 进行了采访。Anderson 的公司“David J. Anderson and Associates”组织了本次会议。

InfoQ：我最近遇到了一个曾经带领过 Scrum 软件开发项目的同事，他说他现在正在使用看板，这让我觉得很惊讶。我问他使用了看板后实施过程有什么变化，他说他根本不觉得 Scrum 和看板间有太多区别。很显然他并没有领悟到看板的真谛。这让人联想到敏捷刚出现的时候——在真正理解敏捷之前，每个人都认为他们正在实施敏捷。我觉得类似的情况十分典型，而有关于看板的材料似乎也很缺乏。你的书是看板方面的圣经，那本书大概有 300 多页。如果让我用几句话来概括下 Scrum，我想说 Scrum 就是“具有时限的迭代”、“尽早策划 sprint 会议（Scrum 中的 sprint 指迭代，其原意为“冲刺跑”）”、“结束时进行回顾”、“对开发速率进行测量”、“每日举行 scrum 会议以沟通项目的状态和问题”。我想，您是否可以像我刚才那样快速扼要地向我们解释一下看板？

David：我们已经意识到了看板实施中存在的问题。我们曾经尝试提供一份只有八页纸的快速入门指南，但那只在过去有用，而现在需要进行更新。原先，例如在 2008 年的时候有一些关于看板的小册子，但现在我们已经对看板有了更好的理解，而且也已经能更清晰地阐述看板，所以是时候推出些能让读者在一小时之内读完的看板材料了。

“精益看板大学”计划发布“看板官方指南”。

InfoQ：您觉得这份“官方指南”大概什么时候可以完成？

David：现在已经开始了，目标是在年内发布。我已经在写“看板书”的第二版，预计在今年秋季的早些时候可以完成。自从第一版发布以来，我们已经有了很多收获。我们从传授看板的过程中学到了很多，也从提供咨询和其他咨询师那里学到了很多东西。当这本书的第二版完成时，我们会从中提炼出一个“官方指南”。

InfoQ：如果我现在就想启动一个看板项目，您能告诉我该怎么做吗？我该怎么开始，怎么分析眼下的事情，怎么把看板推荐给管理人员？

David：关于这个已经有一些教程了，例如我去年在波士顿精益会议上做的报告。

我们首先教会人们去思考：客户以及其他外部利益相关者的不满是什么？内部团队的不满是什么？换句话说，你要解决什么问题？是什么引起大家的不快？通过这种方式我们可以理解造成现有问题的可能原因。

然后我们让他们来定义“需求源”。在敏捷的世界中，我们经常会听到类似这样的话：“需求源就是产品的负责人”。但实际上需求源并不是产品的负责人，产品的负责人只是中间人。所以，帮助人们回溯并发现需求的真正来源十分重要，需求可能来源于营销或者市场部门，监管和规划机构，也有可能是某个特定的消费者或者细分市场。

我们也经常让人们去明确（项目的）目标。例如，对于一个做移动应用的公司来说，他们的产品可能会有 iPhone 版本、Android 版本以及传统的 Symbian 版本。我假设 Symbian 版本只能接受最小程度的应用变化，否则一些比较传统的使用 Symbian 手机的银行用户将无法再使用应用；相反，iPhone 版本则可以兼容所有最新的产品特性。因此，我们要帮助人们发现风险，并让他们理解让客户感到满意的服务应该具有怎样的水准。这就是一个需求分析的练习。所以，这再次体现了我们是以理解顾客和员工的想法为出发点，然后进行需求分析。

下一步就是（交付）能力分析。这要对现有的跟踪系统进行观察，并从中提取有关交付时间和频率的历史数据，这样就可以了解我们现有的交付能力。目前还有公司根本没有记录任何历史数据，不过这种情况正在不断减少。一般来说，大家都有譬如 JIRA 那样的跟踪系统了。这些系统可以帮助我们理解现有的交付能力，这样我们可以把从需求分析中得到的用户需求与实际交付能力相比较，然后发现其中的差距。我们会以上述这些分析为出发点设计看板系统。

InfoQ：可以让一个（对看板）比较外行的项目经理去做（设计看板系统）吗？

David：也不是不可以，但是一般来讲我们还是推荐让受过专门训练的人员去做。挂一块板在墙上，然后往板上粘几个便条或许可以对工作和工作流进行可视化，但这并不是在设计一个以“提升服务”为目标的看板系统。看板是一个以服务为导向的方法，也是一种对服务进行改善的机制。所以，你需要明白你正在提供什么服务，这些服务满足了什么需求，而你现有的交付能力与需求相比究竟如何。

InfoQ：这样是否会形成一个准入门槛？在作出一项重大的投资前，人们总是想要对情况有所了解。

David：我要澄清看板并不是解决问题的银弹。在 BBC 公司，使用看板后各个部门的生产效率提高了 7-8 倍；而且，一个仅仅为 BBC Worldwide 的商业站点制作网页的部门，通过“提前交付”增加了 100 万美元 / 年的广告创收。他们的交付效率提升了 7 倍，这样交付所需的时间减少了，并且每年产生了 100 万美元的额外广告收入。这就是正确使用看板后可以得到的效益。

InfoQ：但是从项目经理的角度来看，这听起来就像是个营销传奇。我该如何评估在我所处的环境中是否能产生类似的效果？

David：我不认为这是传奇。曾经有人提交了一些关于看板的案例研究，研究报告中说看板使得生产力提升了 4 倍。我看了下报告然后说：“嗯，这差不多是正常的水平”。你到这个会场上去逛逛，可以找到 100 个人跟你说类似（看板使得效率大幅提升）的话。

InfoQ：这些成果确实很引人瞩目，但是有个问题，就是我们不知道哪些项目可能没有成功地使用看板，然后悄悄抛弃了它。

David：我们已经知道有些公司仅仅是读了“看板书”，然后在没有任何帮助的情况下就获得了成效。从商业角度来看，这听起来确实有些吓人。如果仅仅从阅读“看板书”中就可以获得类似的结果，那么人们就不会再去购买看板教练的服务了。在北美，有大量这样低层次看板系统，当他们升级到更高层次的看板系统后将可以获益更多。

现在市面上看板很流行，你肯定听说过很多类似这样的：有人告诉你他们在墙上挂了块板，然后监控板上的工作流等等。但是，这是低层次的看板系统，是从网络上学会的一些东西。敏捷社区，尤其是北美的敏捷社区中对于看板的理解十分缺乏。他们没有关注看板更高层次的内容，关注这种系统化思维的、面向服务的方法。他们甚至都未必认识到，进行工作中的有限拉动系统（work in progress limited pull system）是必要的。他们没有去理解看板系统设计中的核心动力。

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

感谢杨赛对本文的审校。

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