看板先驱：David J. Anderson采访实录

David J. Anderson是将看板应用于软件开发的先驱，他最近来到了巴西。InfoQ巴西站对David进行了一次关于“精益、敏捷与看板”的采访，下面是采访中的精彩对话。

InfoQ 巴西站（以下简称infoQ）：您是怎样将“精益”与“敏捷”这两种思想联系起来的？

David: 显然，这两种思想有很多相似之处。而区别在于，“精益”这种思想实际上体现了一种追求完美的理念，而“敏捷”则意味着在信息不完善的情况下取得进展，并且在获知更多事实后对原有的问题进行修正。许多持有“精益”观念的人会执着于完美，纠结于是否应该在信息不完全的情况下向前推进。在他们的观念里，返工即浪费。而“敏捷”则并不追求完美，这是“精益”与“敏捷”间的一个关键区别。

我认为还有另一个区别，就是在这两种思想中，对“人”的定位不同。“精益”是从体系的角度来看的，其认为，人所在的体系会在很大程度上影响一个人的表现；所以如果要体现对人的尊重，就要设计一个合理的体系，使得人能够高效地工作。而“敏捷”则更加以人为本，尊重“人”作为一个个体存在。“敏捷”具有无政府主义（自由意志）论者的观点，其相信人可以通过自我管理做正确的事情。所以对于“人”，“精益”和“敏捷”这两种思想的看法区别很大。

政治因素对于“敏捷”社区——尤其是美国的“敏捷”社区——是有一些影响的，其中有些人非常地以人为本，是自由意志论者和无政府主义者。有种观念在“敏捷”社区中很流行，他们认为既然人性本善，那么就应当允许人们做自己想做的事情，而且我们应当相信他们。就个人而言，我认为这个想法实在有些一厢情愿。

从历史上看，纯粹的共产主义对“敏捷”社区有一定的影响。他们会认为，所有的管理者都是恶的，所有控制他人的企图都是恶的，所有对他人进行决断的企图都是恶的。我并不认为这种看法是正确的，而且我觉得持有“精益”观点的人也不这么看。“精益”认为应当对体系进行建设，其中一些人负责构建体系，另一些人负责管理体系，“改善文化（Kaizen Culture）”并不具备自我管理性。所以“敏捷”和“精益”对于个人和组织的看法存在很大不同。

如果有人想的是按部就班地工作，领取薪水，然后回家干自己的事情，为家庭操心，这对我来说完全没问题——一个人的热情不在工作上并不是什么要紧的事情。我相信很多持有“敏捷”观点的人认为，团队中的每一个人都应当对其职业抱有极大的热情。我觉得在比较大的一些公司里这种想法很不现实，而且也没法大规模地在实践中进行操作。在仅有6个人的创业公司里，依靠个人对事业的深厚感情是可能的，但对一个300人的大公司则很不现实。

InfoQ：那对团队进行授权呢，是否和您刚才说的相违背？

David: 授权并不是让人为所欲为，也不是假定人就是能够通过自我管理把事情做对。授权是划定事情的边界，就像我们教育小孩时给他们做规矩。我们会告诉小孩子一些规定，比如他们应该在几点上床睡觉，他们可以在哪里玩，他们是否可以跑出院子，他们只能在游泳池的浅水区游泳，他们不能使用跳水板……等等，诸如此类。所以授权是清晰地告诉人们事情的边界在哪里，然后让他们在边界内发挥主观能动性。

InfoQ：您最近又给看板添加了一项核心实践，即“实施有组织的反馈”，您为什么觉得要增加这一项呢？

David: 其实这一项并不是我加的，我只是使它更突出了。在我的《看板：技术企业的成功变革》这本书中，有一整章是关于这个话题的，我只是没有把它列为一项核心实践而已。但我意识到这是一个错误，因为我们发现组织层面的反馈通路在实践中并没有充分应用。有时候，如果一项实践没有得到贯彻，那就需要把它变得更显眼，而把它加入到核心实践列表中就是这个目的。所以这并不是什么新东西，我只是加以强调而已。

InfoQ：您说看板是根据生产能力来调整需求的一种形式。您能跟我们谈谈这样做的好处吗？我们应当如何让业务人员相信其重要性呢？

David: 我们要同时针对生产能力和我们的能力来调整需求。而且很显然，我们应当避免使自己负担过重。如果我们的负担过重，那么我们的生产力会下降，产品的品质会降低，而且通常花的时间也会更多。而通过建立平衡，我们可以提升生产能力，加快速度。我们可以做更多的事情，而且质量也会变得更好。

对于业务人员来说，他们必须明白什么叫根据能力来控制需求。也就是说，我们必须根据产能来配给需求，因为总会有超出我们能力的需求存在。人类的创造力是无限的。人们会想出各种各样的新软件，最重要的是要正确评估其中的风险、回报和收益。

所以帮助企业对其想法进行分析，并帮其厘清其中的风险和收益是很有价值的。而且要根据我们的实际能力，帮助他们选择出能达到供需平衡的最佳方案。 我们会努力提高产能，但同时他们也要学会怎样从很多想法中选择出最棒的那一个。

如果我们可以同时做到这两件事：一是提升我们的能力，二是对需求进行控制/改善需求中的风险管理，那么一切就会更为和谐。我们之所以会发现需求越来越多，原因之一是因为未来具有不确定性，而业务人员为了规避这种不确定性，会说“干脆把什么都做了吧”。显然这并不实际，所以我们需要帮助他们更好地评估风险，帮助他们理解所面对的不确定性。这样他们就能够对自己做出的选择更有信心。

InfoQ：现在有对看板的误会和误解吗？如果有的话，哪种误会或者误解是最常见的，或者是最严重的呢？

David:Alan Shallaway就“关于看板的误解”这一问题发表了一篇文章，这是一个很好的参考。我认为现实中 误解很多，其中一个是关于“板（board）”的。其实 Agile Alliance中已经有了一个页面，讨论的就是在看板中使用板作为敏捷实践。看板方法并不是因为有块板而得名，它叫看板是因为它采用了一种虚拟的看板系统。这种拉动式的系统（pull system）在过程中对工作量进行限制，然后把工作提交推迟到精益开发人员所说的“最后责任时刻（Last Responsible Moment）”，板只是将这个过程可视化的一个工具。

看板系统是最先出现的，“板”是随后加入的。“板”起先叫做“卡片墙（card walls）”，在敏捷社区中十分普遍。“板”并不是什么新的东西，也没有什么创新，使用虚拟的看板系统才是具有创新性的。

还有其他很多不断重复的误解，其中一个就是看板只能用于运维和IT运营（IT operations），不能在大项目中使用，这显然是错误的。在2007年，我们做了一个1100万美金的项目，团队有50多个成员，这个项目就使用了看板。

所以很久以前，我们就开始在大项目中使用看板了。你也可以使用看板来帮助你提高预见能力，提升项目中的风险管理。预见性和风险管理在项目管理与治理中显然十分重要，能让你确保项目交付的时间。

遗憾的是，认为看板只能用于运维或者IT运营，而不能用在大项目的管理中，这种误解十分普遍而且经常出现。即使在敏捷社区中，这种误解也时常发生。

InfoQ：看板会把我们带回到瀑布式开发，这种误解是怎么回事呢？现在还有这种误解吗？

David：这种误解在2007年到2009年间曾十分常见，但是现在不太能听到了。这主要是因为早期看板的例子都是一些使用传统的软件开发生命周期方法，或者是其他非敏捷方法（例如“个体软件过程（Personal Software Process）”或者“团队软件过程（Team Software Process）”）的团队做的。所以看板早期的例子都不是敏捷的。

我引入看板就是为了对那些拒绝敏捷的团队进行改进，所以早期的看板都应用在非敏捷的项目里，这也是很自然的。 但是，现在使用看板已经非常普遍了，大约在超过50%的项目中大家会把看板加到Scrum之上，所以我认为这种误解现在很大程度上不存在了。

InfoQ：您最近提出要考虑增加一项实践“允许有想法并鼓励创新”，为什么您过去没有这样的想法呢？您是否看到了增加一个“看板负责人（Kanban Master）”的必要性?

David: 实际上，我加入这个实践的初衷是因为要鼓励领导力，然后让人们知道在看板的原则中领导力和管理是不同的。管理者对系统的设计负责，还对所有的策略以及改变或者是重新制定策略的决定负责，这没什么问题。但是我们想让参与工作的每个人——不管是独立工作者，还是管理者——都作出具有领导力的行动。

具有领导力的行为是指，既然并非所有的事情都很完美，所以可以对其提出改进意见，或者让大家看到其实我们可以做的更好。如果你不具备领导能力，那么你就没有持续进步的动力。大家都可以耸耸肩说：“哦，反正就是这样了，回去干活吧！”这样永远都不会有进步，所以领导力是一种很神奇的东西，它是一种催化剂。

最近有个类似的例子，Håkan Forss是来自瑞典的看板顾问，他最近读了 Mike Rother的一本书 《丰田套路（Toyota Kata）》。这本书促使他提出了看板的三个关键性做法，即“看板的三个套路”。

一是每日立会，促进对项目进行改善。二是对业务操作回顾，促进对内部工作流程和看板系统的改进。三是上下级关系，即更高级别的管理者对其下级管理者进行指导：“我们的系统运行的怎么样？”，“我们的策略正确吗？”，“我们收集的指标正确吗？”，“我们可视化的东西正确吗？”。这样我们就能理解我们周遭的环境，并对其作出改善。

InfoQ：社区现在是不是已经习惯了“看板负责人”？

David: 不是这个意思，我们不鼓励“看板负责人”（直接对等于Scrum负责人）这个想法。但我觉得找一个看板教练是有价值的。看板教练通常不同于敏捷教练。敏捷教练往往是团队的一员，每天与团队在一起工作。

而看板教练往往一个月只过来两到三天，与大家讨论策略、可视化和指标，帮助大家理解他们现有的产能并考虑如何进行提高。所以看板教练并不需要每天都在团队里。

InfoQ：InfoQ最近发表了一篇题为“看板，敏捷的下一步”的文章，你觉得这篇文章怎么样？

David: 如果他们是在讨论看板的的市场前景的话，我觉得看板确实正在成为软件过程市场中的下一个明星。有很多证据表明，我们确实需要看板方面的培训、辅导、咨询，以及看板软件、模拟和游戏——各种诸如此类的东西。所以我觉得从市场角度看的话，看板正在发展成为下一个热点。如果从历史角度来看，从CMMI，然后到RUP，到XP，再到Scrum，那么看板就是下一个。

但如果他们指的是必须先进行Scrum，然后再使用看板，那么这就完全错了。对于很多组织来说，Scrum并不容易应用，它与许多公司的文化都有所冲突，导致人们对其十分抵触。

而另一方面，看板是为易于使用设计的。它以你正在做的东西为出发点，它是Scrum之外的一个选择。如果我们等着人们克服对Scrum的抵触心理，那么他们就会丧失一个重要的机会，即如果他们早点使用看板，那改进就会快得多。如果已经在使用Scrum，但是觉得有必要作出进一步改善，那么在后期加入看板也是个好主意。如果尚未使用Scrum，那么就应当考虑使用看板，随时都可以。

InfoQ：在 Jurgen Appelo的书《管理3.0》中，他提到了“文化基因（memeplex）”。他认为Scrum之所以如此成功，得到如此广泛的接受，一个原因是现在Scrum已经完全改变了“文化基因”，您怎么看这件事？

David: 我不想就这一点进行争论，但我觉得真正挑战在于是否真的能够将原有的“文化基因”完全抹去，然后用全新的一套去替代？尽管Scrum已经非常成功了，但现在对它还是有很多的抵触。在采用Scrum时有许多备受质疑甚至失败的例子。最近一个比较可靠的市场调查显示，Scrum的市场占有率大约在15%，这比RUP的市场占有率要高，RUP获得过的最高市场占有率是11%。所以15%已经很不错了，因而你应当问的是，在15%之中有多少Scrum的实现是有问题的？

但是先让我们大胆地假设，这15%之内的所有Scrum都很成功，那么仍然有85%的市场呢。这正是我想要解决的问题。怎么才能做的更好，怎么才能帮助这些已经在使用敏捷的人把Scrum做得更好，并且尝试开拓和帮助剩下的85%的人？我觉得Jurgen说的大部分关于Scrum的事情都很对，也很准确。但是，在世界上还有很多更为有趣的问题亟待解决，在管理学和软件过程领域也是如此，而我更感兴趣的是剩下的空间。我相信在Scrum社区中有很多人都有兴趣改进Scrum。

关于受访人：

David J. Anderson在高科技行业拥有30年经验，并曾在诸如Sprint、Motorola和Microsoft这样的大公司使用创新的敏捷方法带领软件开发团队，使得团队拥有卓越的生产力和产品质量。David是三本书的作者，包括《软件工程的敏捷管理》，《看板——技术企业的成功变革》以及《敏捷管理课程：通往“看板”之路》。

译者注：memeplex: 即“模因复合体”，也有直接音译作“谜迷复合体”，本文中意译为“文化基因”。memeplex是基于达尔文进化论观点解释文化进化规律的一种新理论。它认为，在文化领域内存在着一种类似DNA的文化复制因子——模因（meme），模因通过人与人之间的相互模仿得以复制和传递，从而推动着人类文化的进化。

查看英文原文：Kanban Pioneer: Interview with David J. Anderson