专访看板先驱David Anderson：复杂自适应系统与李小龙的哲学思维

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

国内推广敏捷历经十年。有浅尝辄止者退出，有强力推行者受挫；但敏捷的观念和实践已被广泛传播和采纳—— 灵活应变成为普遍追求，技术卓越成为共识，人们不再怀疑持续集成和持续交付的意义，越来越多的跨功能团队被组建，敏捷的管理和技术实践得以实施，推动产业进步。 棋近中盘，全行业开始拥抱敏捷。与此同时，业界对敏捷的争议之声渐大，其中多数争议集中于有效实施和提升价值。如果缺乏有效实施，敏捷势必不能带来价值；如果不能看到足够的价值，又为什么要大力推进实施。当前种种碎片化的理论和个案分享，已经不能满足主流人群的需求，无法解决实施和价值的矛盾，我们需要完整的方案，既能帮助有效实施，又能有效提升价值。

   

1. 大家好，我们是在北京，我身边的是David J. Anderson。他是Kanban方法的缔造者，也是精益与敏捷领域的先行者。欢迎！David。这是你第一次来北京，对吧？

David:是第一次来。感谢你们的盛情邀请。

   

2. 坦率地讲，Kanban在中国的普及程度还不高，让我们从最基本的开始。你能概括性地向我们的读者介绍一下，Kanban是什么吗？

David:当然。这一切源自我们的一个念头：希望将Kanban信号卡系统引入软件开发流程，我们将使用虚拟卡而不是物理的卡片，当你用Jira或Team Foundation Server这样的软件包来跟踪工作时，你根本不需要使用物理方式。我们引入看板系统的目的是为了限制同时进行的工作的数目、从而减少多任，但更主要的好处是——人们能够延迟承诺，它减少了系统的波动和对优先级重复调整的需要。

（编者按：David 所说的看板信号卡，是指精益制造中的看板卡片，它在精益生产中起到的作用是“拉入新工作的信号”，当一个生产环节需要特定的工件时会通过看板向上有传递信号，说明需要多少数量的什么样的输入，拉入需要的工件。）

因此，我们首先利用虚拟Kanban系统解决过早承诺与优先级重复调整所带来的问题。此后，我们又为其添加了可视化看板墙及其它一些敏捷实践——如看板墙前的站立会议，以及基于看板的度量体系等。

（编者按：David的所说的虚拟看板系统是指，在看板方法中通过限制每一环节的工作项的数目实现了类似精益生产中的看板的作用——只有在某一环节有产能，也即当实际工作项数目小于工作项数目限制时才可以从上游拉入新的工作，之所以称为虚拟看板系统是因为在这一系统中并没有与生产中的看板（信号卡）对应的实体，但以虚拟的机制实现了同样的目的）

通过这样的方式，我们发现我们其实创建了一种催化或激发增量变化的方法，而随着时间推移这将从根本上演进现有流程。由此带来的结果意义重大，因为人们通常会抵触新方法以及新的工作机制。虽然这种抵触往往能够通过人类心理学与社会学分析给出合理解释，但能解释并不代表能很好的解决它。

因此，通过引入虚拟Kanban系统、可视化看板墙以及反馈机制，为我们带来一种意料之外的进化能力。这正好解决了如何导入变革和消除人们对于变革的抵触的问题。

所以我面对两个问题。 第一：人们过早承诺、过度承诺、带来产能过载、多任务、系统波动和重复调整优先级的问题。第二：人们抗拒采用敏捷软件开发技术。这两个问题在某种程度上相互纠结，而Kanban则成为能够同时解决这两个难题的单一方案。

   

3. 那么Kanban是一套流程工具、框架还是其它什么东西？

David:其实我不太希望人们使用框架这个词。框架意味着它并不完备，还意味着它的结构应该非常固定，我们再在这个结构框架上添加更多元素使其趋于完备。我坚信Kanban方法在它所关注的领域已经相当完备——如果大家遵循Kanban所提出的六项实践并切实执行，那么进化能力就将真正融入现有流程当中。

当然你可以预测流程的进化方向，但这与采用特定框架，并在框架中加入所需元素不同。我们从已知的现状开始，每次演进一点，增量变化，希望带来改进。这种增量式革新更有希望带来实实在在的改进。如果结果的确是改进，那么只需坚持向前就可以；如果结果并非改进，你可以回滚到先前版本来取消所做出的调整，回到过去，或者是向前覆盖——也就是用新的变化方案来取代先前的变化。这就是现实中的演进。

2009年，我花了很长时间来认真思考自己曾经审视过的高效利用Kanban的企业，观察他们一直以来所坚持的执行方针并总结出六项实践原则：可视化、限制进行中的工作项数目（work in progress）、管理流动、显式化流程规则、建立反馈循环（如站立会议和运营评审等）、鼓励协作探讨问题并推进实验性的改进。如果大家在工作中将这六大要点执行到位，也就拥有了进化所必需的完整能力。

因此我将Kanban视为一套完整的方法，而且它的关注点非常明确——创建进化能力，从而让企业能够适应业务流程的持续演进。也许人们会说“我们还不清楚流程会最终进化成怎样的形态，所以Kanban机制还不能算完整”，好吧，大家也可以保留这样的观点，但我仍然坚持认为Kanban方法已经非常完整。我不希望人们把它称为一套框架。

   

4. 好的。人们有时会谈起复杂自适应系统。Kanban也属于这类系统吗？

David:复杂自适应系统的概念是，系统要能够对自身进行自行调整，这就是对自适应的定义。而复杂则指初始状态很重要——初始状态会影响最终的结果。

计算机科学家们大都熟悉康威提出的生命游戏，这就是一套典型的复杂系统，其中初始状态将最终决定细胞到底是茁壮成长并生存延续还是走向衰亡。不过康威的生命游戏并不能算一套复杂自适应系统，因为它不能自我调整——它并没有能够自我修改的代码。不过如果大家想开发出一套具备自修改代码及某些反应机制的生命游戏版本，从而使其能够对自身表现加以分析并实现代码修改，那它就将成为一套复杂自适应系统。

（编者按：生命游戏是一套计算机程序用以模拟复杂系统的演进，这个系统有一个初始状态：随机分布的细胞；一套演进规则：什么样条件下细胞会死亡或繁衍。在这个复杂系统中，初始状态的微小不同将对结果产生不可预测的影响。David认为生命游戏不是自适应系统因为规则是固定的，不能自我调整）

复杂自适应系统很有用，因为它从根本上使进化成为可能。它们让实体或者物种在不断变化的环境当中得以生存，因为如果他们太过僵化，那么环境的演变将使其走向消亡。这也是物种灭绝的原因，它们无法再与周边环境相适应。可能是由于周边环境发生改变，例如温度上升或者下降、也可能是其它某些动物（例如人类）迁入并对环境进行改造，总之无法适应环境的物种将会灭绝。因此，如果想要在变化的环境中生存，这种自适应能力是必须的。

通过在组织中应用Kanban，你可以创建出适应能力从而应对不断变化的业务环境。Kanban让我们可以进化业务流程以适应环境，从而保证企业生存和成长。因此，我认为Kanban对于企业来说是一种实现复杂自适应系统的重要途径，也是企业在现有复杂世界中得以立足的基本前提。复杂性是我们无法选择的客观现实，而自适应能力则是我们迫切需要的能力。

   

5. 在过去，人们已经在敏捷领域投入了大量精力，创造了很多框架、工具或方法，例如Scrum和极限编程。我们为什么还需要一个新的方法，它的意义在哪里？

David:根本问题在于人们对变化有天然的抵触情绪，尤其是当人们尝试大规模提高企业的敏捷性，并相信可以通过向数以千计的员工推广敏捷软件开发来达成这一目标时，就会面临许多的抵制。我听说过的几乎每一家试图实现大规模敏捷流程的企业都遭遇过这种抵制，并在项目失败之后不断发起新尝试。

某家在敏捷社区中著名的大型美国银行目前正在努力推动第四次规模化敏捷普及，这是他们十年中的第四轮广泛尝试。这意味着前三次在咨询与培训等方面消耗了数百万美元投资之后，最终遭受失败。员工们肯定已经对此感到极度厌烦，对一次又一次尝试失去了耐性。

因此，有很多人会向你推销一套框架——框架本身并不完备，你可以根据自身的情况分析加入必要的元素使它完整；而且，它会契合你的业务环境项，并且不会遭遇阻力。但证据显示事实并非如此。我本周在中国一家大型移动电话公司看到了一个案例，他们着力推动的，涉及成数千名员工去应用一种新的流程框架，仅仅经过了一年就失败了。

我们为什么要引入新的方法？敏捷领域的最大难题在于人们抵制变革，而整个敏捷社区在这一点上并没有提供本质不同的解决方案。他们提供各种框架、各种方法学，但在如何迁移以及如何实施新方法上却一直没有改变。没人去有效的解决对变化的抵制这个问题，而这正是我在过去十年中一直从事的工作和解决的问题。

我曾经亲历过Sprint公司在推广敏捷流程中所遇到的阻碍，也在摩托罗拉发现过同样的问题。2003年在撰写自己的第一本书时，我已经将这些问题视为一种固有模式。不过敏捷社区并不希望人们发现这一点——他们关心的只是怎样把自己的产品卖出去。他们一直假装抵触情绪根本不是问题，直到今天还是这样，即使在今天的大会上，仍然有不少人在销售自己的框架。他们的摊位上树立着这些特定框架的条幅和海报，却没人愿意真正谈起，很多大型企业都尝试过此类框架，最终却失败了。

Kanban是一种完全不同的提升敏捷性的方案，我们今天把它宣传为通向敏捷的替代路径。其核心在于帮助企业创造一种能力——提升敏捷性，同时又是以演进的方式来实现它，从而把对变化的抵制降到最低的限度。这就是我们需要它的原因。相对现有敏捷方法或者框架来说，Kanban是一类完全不同的东西。

   

6. 对于演进式的变化，怎么能保证演进的方向是正确的呢？你能进一步做出解释吗？

David:坦率地讲，我们已经沿用80年的组织变革模式，最早是可能是由美国的麦肯锡咨询公司在上世纪二十年代提出的，而我认为这套模式从本质上是有缺陷的。它的基本观点是，你有一个正在执行的流程，你定义一个目标——也就是期望的未来流程，接下来你就去管理变革，把你从今天的状态转变为期望的状态。这不靠谱，理由很简单，我们对于未来流程的定义主要基于两种方式：其一，直接从指导书籍得出答案，而忽略对上下文的分析；第二，由外部咨询公司或内部流程组的咨询师来设计。

他们是“伟大的未来设计师”，也就是这些咨询人员对企业运营所处的复杂环境拥有更为英明的认知与判断。但我并不认为他们更英明，现实的环境如此复杂，他们不可能定义出适合所有状况的方案。而且从本质上讲，一线的员工知道这些，他们明白这些对未来的设计是有缺陷的，而这也成为拒绝变化的原因之一。

所以演进式流程采取了完全不同的思维方式。你不会去设计未来的状态和行为，你需要的是适合性标准——一种衡量当前表现是否足够好的方法。如果不是，则在进化的过程中做出变化。基于现状，在某些方面做出小幅度变化后，要去看改进后的新版本是否比旧版本更满足我们的目标，而且对是否满足目标的衡量要与外部环境相关联。

我们要了解客户的期望——他们要什么，关心什么？他们重视交付时间？他们关心质量？或者是应对变化的能力？客户要求是在不断变化的，我们则必须创建适应客户要求的能力。

因此，我们要通过适应性标准来持续衡量我们的绩效（我不太喜欢绩效这个词，或者说敏捷性可能更好），适应性标准将呈现客户要求的满足程度——他们高兴吗？我们的产能满足客户的要求吗？他们满意吗？这些都事关重大。如果我们在对流程做出变更之后发现客户满意度下降了，满足客户要求的能力下降了，交付时间变得更长，或者可预测性变低，那就说明变更有问题。

如果事情变得糟糕，那么我们所做出的变更就不属于改进，我们当然不希望这样的变更继续存在和扩展。我们希望消除它和它带来的后续影响，有两种途径可以选择，要么前滚——用新的变化来替代之前的变化，要么回滚——回到过去的流程版本，但始终要基于适应性标准做出判断。

我们需要适应性标准。我们需要度量指标来衡量绩效表现，而这些指标必须与外部环境、客户需求等保持一致。我希望这能成为我们推进变革的唯一途径，事实上最终应用哪种实践不再重要。过去那种预先设计好一套流程，从一套实践集合切换到另一套实践集合的方法是有根本缺陷的。

   

7. 在现实当中，你曾经见证过哪些由Kanban所带来的实实在在的收益？

David:收益多种多样。我在今天的主题演讲中用四到五页幻灯片阐述了Kanban带来的收益。其中一部分收益来自客户们最为关心的可预测性和交付时间。我们常常看到可预测性方面的巨大改进——它的意义在于我们做出承诺、并最终为客户提供与承诺相符的结果。至于交付时间，我们经常看到交付时间的缩短幅度达到90%，而交付速率则往往能够提高200%甚至300%，这并不是什么稀奇的状况。事实上，， BBC 全球网站的案例，显式他们实现了700%的交付速率提升，这一结论来自Peter Middleton所撰写并发表在管理科学杂志《IEEE Management Journal》上的文章。

我们的结论得到很多大型企业的真实数据的支持，而不是凭空猜想。当听到有人声称“我们在Kanban的帮助下生产力提升了400%”， 我的反应是“应该是这样，这（400%）属于正常范围”，800%或者900%可能是提升的上限了，而200%则是在下限范围。这是因为Kanban将人们的注意力集中在问题本身并引导他们着手改变状况，这一切都将给业务能力带来巨大提升。

除此之外，我们还能列举出其它一些收益。除了经济效益之外，Kanban还能带来多种社会性效益。我们看到组织内的信任度提高了，因为事物更加平衡了，客户和员工都更加满意。总而言之，Kanban带来经济效益的同时也带来了社会效益。

（编者按：这里的平衡是指看板中会强调去平衡系统的产能和外界的要求，例如对一个系统的输入不应该超出它当前时刻的固有产能）

   

8. 好的。着重谈谈经济效益。这样的成果非常惊人，它太好了以至于让人不敢相信。我知道你刚刚已经强调过这一切都有事实做支持。我认为如此显著的变化，背后一定意味着某种范式转变。是这样吗？相对于其它方法，Kanban背后是否有某种范式转变。

（编者按：范式是指对事物的基本认知，例如从大规模生产到精益生产就是一次范式转变，因为它生产中的规模经济性的认知发生了根本的变化；从面向过程到面向对象也是程序设计语言的范式转变）

David:如果Kanban带来范式转变的话，那么就是它让人们开始管理——它让管理者意识到他们事实上在操作一套系统，他们应该思考自己观察到的系统输出或者他们的操作所带来的结果。这套系统是由管理策略所控制和定义的。管理者们采取行为、制定决策、改变策略，这些都影响着系统的绩效。在我们的行业中,长久以来我们一直聚焦于流程，认为流程就是方法——这其实是20世纪早期工业工程的模型，就像我们一直采用的变革方法一样——你有现状，目标状态，然后在这两者之间做出迁移，它们都是20世纪上半叶的东西了。

工业工程的管理模式由管理者、工人与流程工程师构成，其中流程工程师负责设计流程、工人遵循流程。管理者则认为只要让工人切实按照流程要求工作，一切就会运转良好，管理者则从来不需要改变自己的行为方式。

这两种运作机制与Kanban的关联非常符合彼得德鲁克（Peter Drucker）的成果。作为管理科学家，他于上世纪五十年代末提出了“知识工作者”这一概念。他把知识工作者定义为：比其主管更了解如何把他们自己的工作做好的员工个体。到上世纪六十年代，他进一步拓展了自己的成果并指出“所有知识工作者都是管理者。”这样的结论令人感到惊讶，但也极具启发性。我们该如何理解呢？

他是在说，知识工作者作为个体所做出的决策会影响整业务的绩效。传统上，管理者们才会承担这样的职责。过去工人只需出体力，遵从流程，没有任何可能影响企业绩效的决策权。但随着知识工作者的出现，管理者和普通员工之间的界限日益模糊，每个人似乎都在某种程度上承担管理职责，都是管理者。每个人都有能力做出影响企业业绩的决策，这一点在软件开发人员及测试人员身上表现得尤为明显。

作为软件开发人员，他们每输入每一行代码都是一个决策，将影响组织长期的绩效，因为它可以是一行优秀的代码——有好的设计，是好的架构的一部分；也可以是一行糟糕的代码。如果累积了大量的细微的糟糕的决定，那么最终得到的就是一套无法维护而必须加以替换的代码库，带来高昂成本。

因此，德鲁克认为管理者与工人之间尽管有所区别，但还是应该把他们同等看待。这是一个关键点，我们希望通过模糊角色定位之间的界线，做出好的管理决策。在决策制定上，管理者与员工是一样的。也许他们在不同的权限级别做决策，但他们所做出的决定都会真正对公司业绩产生影响。在这样的前提下，就制定让管理者强加给员工的流程这一点，已经没有流程工程师的位置了，因为管理者和员工是一样的，我们希望他们都能提高管理思维。

早在1981年，Barry Boehm就曾经撰写过一本名为《软件工程经济学》的大部头论著。作为结论，这本书认为提高软件开发的最关键点在于改进管理者及其管理决策。而在之后的八十年代、九十年代甚至两千年，伴随着敏捷趋势的兴起，人们还是把重点关注放在流程上，而这已经是20世纪的工业工程模式了。而在Kanban中，我们希望改变着一点，希望把关注重点放在管理本身、思考如何才能做出更好的管理决策。

有鉴于此，我将Kanban方法视着一套管理流程，它与Drucker提出的模糊管理者与员工之间界线是相一致的，它要确保每个人都能做出更好的管理决策。我希望大家不要再把流程看作来自外界，硬性强加给员工的要素。人们需要负起对于自己操作和工作于其中的系统的业绩的职责。

   

9. 是的。在敏捷社区，人们也喜欢讨论自组织团队或者领导力之类的话题。有时候他们会把自组织作为敏捷方法的前提条件。你怎么看这个问题？自组织机制属于前提条件，还是我们需要达成的一种结果？

David:把自组织机制当作前提条件的想法，在我看来有点太过理想化。我并不认为每位成员，或者说来自世界各地受到不同文化影响的员工都乐于接受这样级别的权限；敏捷运动的某些核心理念来自美国本土的一些自由主义者与无政府主义者。但即使是在美国，某些地区的人们也并不欢迎这种人人参与、略显杂乱的运作机制。事实上，无政府主义者与自由主义者往往生活在俄勒冈州、加利福尼亚州或者华盛顿州这些美国沿海地区。

在美国的其它地区，人们往往更为保守和传统。不仅美国如此，在全球范围，我们会发现无政府主义与自由主义信仰就不见得适合所有其它类型的文化。因此我认为很多人其实并不希望被赋予全部权力和全部自治空间。他们只想获得一部分权力与一部分自治空间，同时继续接受来自领导者的指引。他们需要的是前进的方向以及前进过程中所必要的权限。总而言之，他们希望遵循更为明确的规则及权力分配机制。

有鉴于此，在某些文化中采用敏捷方法会带来巨大挑战，尤其是在人们希望被指引的文化中——如果我负责指引团队，那么发生方向错误，我就需要为此负责；如果赋权给大家，大家自主决策，大家就需要为自己犯下的错误承担责任。这一环境下，并非所有人都会感到舒适，这有点过于理想。

我宁愿在对待文化问题方面更加实用主义，即先给员工多一点点的自主空间和权力。我们希望能把决策权下放到实际工作的人员手中，因为这是最快决策的方法，不过我们不应该让这成为先决条件，这也会导致对变革的抵制。

   

10. 你一定看到过很多Kanban实施的真实案例。你认为如何才能将Kanban实施推向成功，又有哪些因素可能导致Kanban实施遭遇失败？

David:值得庆幸的是，我们积累了越来越多的案例——我把它们叫作出师不利或者Kanban的实施失败。但这应该是一种好现象，毕竟它表示人们正努力正确的实施Kanban方法。很多人只是往墙上挂块板子，就急匆匆地宣称“我们开始使用Kanban了”。这显然太过草率，而且肯定无法从中得到太多收益。他们真正需要的是深入理解Kanban系统的概念以及为什么要采用它。但是，一定有一些环境比其它环境更适合使用看板，这对于看板的实施方法会有微妙的影响。

让我们来了解一些基本概念（场景）。首先是研究型的场景，它指我们并不清楚能否做到，甚至不知道该怎么做。就像有些人突发奇想表示“如果能够成功登月，那可是个了不起的壮举。”面对这样的提议，其他人当然会提出一系列疑问，例如“我们如何才能登上月球？我们不知道怎样实现这个目标。之前还没人尝试过这件事，我们甚至不知道该从哪里入手。”在这种情况下，作为负责人你要管理这类工作，就必须为投资者或者纳税人的钱负责。如此一来，管理研究场景最好的办法就是限定的时间和限定的预算进行一次赌博。

这基本上就是一种赌博，我们以一定时间内以一定数量的资金作为赌注。在限定的时间和资金下做出了什么，那当然很好；如果没有做出，则浪费了时间和资金，但也只能到此为止。这样的场景（研究型场景）对于Kanban是不合适的。不过如果我们具备一定程度的确定性——例如了解的目标是什么；如何通过努力生产出需要的产品；了解整个流程需要哪些类型员工的介入；这些员工需要以何种方式工作。这时，我们就可以对整个流程进行工作流建模，并将Kanban系统应用到这一特定工作流之上。

因此比起研究场景，在产品开发场景中，我们知道要什么，怎么做，这一场景适合应用Kanban。即使这样，仍然有可能发生失败，这是因为人们在为导入Kanban做辅导时的一个关键点是判断在开始时我们可以做多少变化，哪些看板元素在一开始时就可以实施。在培训课程上，我们会教授咨询师和内部教练何处理这些问题。我们认为看板的成功实施与我们期望的持续改进文化和演进能力是紧密关联的。

我们把这些与参与培训课程的人员关联起来。当我们听说在实施中的错误时，往往是因为那些没有经过培训的人员在项目初期做出了太多变动，他们没有认真研究自己的决定是否可行，有没有可能引发抵触。在培训课程中，我们会讲授关于人们为什么抵制变化的原因的模型，教他们在特定场景下应用这一模型，从而让他们提前预见阻力、缓解阻力并尽可能避免阻力。

有位非常聪明的朋友几年前发表过一篇博文，题目是《Kanban应该如水一样》。实际上这是引自李小龙先生的哲学思维。当然，李小龙最知名的还是他的功夫电影，但往往被大家忽略的是他曾在西雅图华盛顿大学攻读哲学专业，大家现在还可以买到他的哲学论著，在这本小小的红册子里、李小龙将哲学、佛教禅宗及一些道教理念加以融合。书中的一章专门写了水流，禅宗的思想认为水流环绕着岩石也改变着岩石。水自高山上流下，最终与岩石相遇。

   

11. 这听起来是种非常中国化的理解方式。

David:没错。水流的思维方式绝不是“哦，有石头挡住我的路了，应该把它搬开。”水流会暂时绕过岩石的阻挡，并随着时间推移磨平岩石的棱角、从而使自己前进的道路更为顺畅。我们也希望以同样的方式推动Kanban，岩石就是来自员工的抵触情绪。正因为这样，我们教Kanban教练如何判断岩石的位置，也就是判断来自员工的阻力，看板的第一策略就是绕过石头，避免员工阻力的影响。

如果这样的措施仍然无法见效，我们还准备了其它五个逐步升级的策略，也就是：“既然不得不克服这些阻力，你打算做什么对其加以缓解？你要怎样提高人们的参与感，降低抵触情绪的负面影响，最终扭转对方的观点，得以继续前进”。

因此，在Kanban的实施过程中当然会出现失败案例。发生此类状况的原因主要有两种，其一在于实施者没能选择正确的场景——他们错误地利用Kanban管理那些本应采用限定时间和预算来管制的项目。其二则是他们虽然选择了正确的场景，但却操之过急，在初期引入了太多的变化，而没有遵循“Kanban若水”的基本哲学思路。事实上我们将在下一本Kanban书中把水流与岩石的隐喻作为封面图片。

采访者:那么，Kanban为变化而生，是吗？

David:是的，它的确是为了变化。

   

12. 事实上当我们谈起敏捷时，很多时候指的其实就是Scrum。Scrum在敏捷领域扮演着重要的角色。

David:我认为事实正是如此。自从2005年以来，我觉得Scrum确实已经成为市场上敏捷方法中的主要代表，它也是普及程度最高的解决方案。它受到各类敏捷项目管理工具的高度支持，尤其是人气最高的两种。当然，与之相关的培训计划与认证机制也已经存在。正因为如此，已经有大量供应商、咨询公司、培训机构乃至软件厂商都使用Scrum，他们都在销售Scrum。

因此与其它方法相比，推销Scrum的人数要多得多，而且世界各地许多人，已经将Scrum和Agile这两个词等同看待。

采访者:你有没有经历过人们由Scrum转向Kanban，或者由Kanban转向Scrum的实例？

David:在互联网上，的确有一两个原本使用Kanban，后来因为某些原因而转向Scrum的案例，这些例子很有意思。不过我得说在全球Kanban培训的参加人员当中，至少有一半正在使用Scrum或者其所在企业正尝试将Scrum的进行规模化推广，而在此过程中，他们遇到了某种形式的阻力，我不是说他们都失败了，但大部分都遇到了我们所谓的“挑战”。他们希望普及Scrum，人们有抵触，于是他们接受了顾问的建议，即“你们的方法不太得当，如果方式合理，情况将会大为好转。”而实际上，事情却变得更糟。

人们因此开始参加Kanban课程，他们从自己的现状出发——也就是在Scrum实施过程遭遇挑战。他们尝试把Kanban系统以及其它来自Kanban的元素融入实际操作，Kanban则帮助他们逐步演进，从教科书式的Scrum发展出与目标更相符合的方案。如果需要数字的话，我要说至少有数千人，他们在scrum实施中遇到挑战，并发现Kanban是解决此类挑战的方法。

当然，也有非常少的孤立案例，人们用Kanban之后重新回归纯Scrum，这通常是因为他们的业务出现了剧烈的变化——例如当前产品已经完结，团队进行了全新的重组。我想如果大家面对的是从头开始的项目，譬如一个刚刚组建的团队、一款全新产品或者是一家刚刚成立的企业，这时你必须从头选择一个方法，没有变革阻力的问题。 在这种情况下，大家最适合尝试引入全新框架，比如Scrum。

不过由Kanban转向Scrum的案例非常罕见，而世界范围内约有五成以上的Kanban实施是在Scrum实施遭遇挑战后，希望通过看板来加以改善。

采访者:通过将Kanban加入到Scrum实施方案中取得成功，这背后有一些特定的模式吗？

David:此类案例数量众多，例如BBC就曾经以Scrum为起点进行转型。通常会有400%的生产力提升。

采访者:你所指的绩效是什么？

David:包括对各类数据的统计，例如交付用户故事的数量、吞吐量（或交付速率）有400%改进，交付时间大幅缩短，业务敏捷性的显著提高。Scrum带来的核心挑战之一在于固定的时间盒，一周、两周或者三周。很多企业根本无法遵循此类时间盒，因为他们的外部环境并不是按这样的时间盒安排的。

目前在媒体行业中Kanban的实施案例非常多。BBC就是早期的应用者，雅虎也是。由此开始，在全球我们看到了更多Kanban的规模化应用，其中就包含Globo——巴西的网络媒体、电视媒体外加最大报业出版商。Globo公司甚至将Kanban应用于肥皂剧的后期制作，他们将Kanban应用到电视节目制作而不仅是IT。

此外，Lonely Planet也是个很好的例子，包括Auto Trader（在德国被称为mobile.de)及其它众多媒体企业在内。有很多媒体公司在应用Kanban，为什么？这是因为媒体行业关注的是真实生活，它们不会以一周、两周或三周的时间盒来发生，与正统的敏捷时间盒（如scrum和sprint）相比，它们需要更大的敏捷性。传统方案无法适应大部分业务环境， Kanban则提供了更大的灵活性。

   

13. 我们在两年之前开始谈论精益创业话题，那是一个需要更快反应的领域，精益创业与Kanban之间是否存在互动？

David:我们已经看到一些良好的互动，比如即将发布维也纳的一家名为Tupalo的新创企业在这方面的案例。Tupalo公司的创始人相信Kanban为他们提供了正确实施精益创业的能力，（得益于Kanban）他们的软件开发系统的有很好的可预测性，而且非常可靠并且响应快速，他们有很好的可视性——看板墙，收集的度量指标，这一切提供的成熟度，让实施精益创业的概念成为可能。

他们的看板上有什么不同呢，他们为其添加一个叫“确认”的列。他们在市场上部署新功能，然后等待了数周或者数月后收集数据并与原有业务假设进行比对验证，这体现了极高成熟度和能力。其思路在于，企业可以用两到三个月时间收集数据、与原有业务假设对比，并利用这样的反馈路径，来改善输入到开发系统的创意的筛选机制——对于一家只有15到20人的公司来说，这的确是非常高的成熟度。

这个案例的最终稿的草案已经在我的收件箱里了，会在两到三个月内通过Lean-Kanban大学的网站向大家发布。这只是我们了解到的诸多成功案例中的一个。Kanban与精益创业非常契合，热衷于精益创业的人会发现应用Kanban之后能得到意料之外的良好效果。

采访者:因此，Kanban能够有效推动精益创业？

David:我认为它使精益创业更成熟、更可靠。

采访者:在中国，CMMI以及PMP（或者PMI）的群众基础非常广泛。我估计目前中国约有两千家通过CMMI认证的公司。而中国的PMP则有约六万位。这是个巨大的数字。我们对于那些希望改变或者演进的朋友能提出哪些建议？

David:过去几年我很少讨论这个话题，不过有证据表明，Kanban确实有助于改善企业的成熟程度。它帮助人们提升CMMI水平。目前已经存在一些公开案例研究成果，特别是美国的Hillel Glazer——他是一位成绩斐然的成熟度首席评估师。他在这方面看到了一系列极具戏剧效果的成功案例——不少在评估方面毫无优势的企业仅通过不到三个月的调整就获得三级认证，甚至在九个月内进一步提升到五级。

而我曾经在2010或者2011年就此发表过自己的见解，我记得应该是2010年，当时我在多次会议上作过Kanban如何帮助提升成熟度的系列演讲。Hillel Glazer也多次提出过如何利用Kanban作为CMMI推动手段的倡议。我们双方都在今年十月于美国匹兹堡举行的CMMI协会大会上发过言，他们为Kanban准备了专门的环节。

CMMI协会现在已经从原本的软件工程研究协会（SEI）当中独立了出来，这两大机构都是Kanban的坚定支持者并真正将Kanban视为推动成熟度提升的重要手段。究其原因，Kanban与W Edwards Deming所提出的渊博知识体系的概念非常吻合，能够与后者一样利用统计方法实现改进。

Kanban除了有助将企业的成熟度认证推向CMMI四级与五级之外，还有助于促进一级、二级以及三级这类基本框架的形成。

   

14. 在大约2008年，你曾撰写或者联合撰写过一篇文章，题为《敏捷还是CMMI：为什么不同时拥抱？》。

David:没错，我是联合作者之一。那是一份软件工程协会针对敏捷及CMMI的官方技术说明。

如果把问题换成：组织成熟度是否仍然重要？那答案显然是肯定的。我认为很不幸，CMMI往往被以种种方式所曲解，这是因为他们采用了Philip Crosby的制造业成熟度模型并把结论停留在分层成熟度判定这里，于是人们开始把层级视为追求的目标。

所谓“能力成熟度模型”是根据Edwards Deming的研究成果综合而成的。“能力”一词来自利用控制图等机制来评估能力等级的概念。而成熟度模型则来自Phil Crosby，真正的CMM是指对Deming与Crosby思想进行了融合并将其应用到软件工程领域。

最终Crosby的东西成为主宰，而Deming却被遗忘了。在Kanban之前，我曾试图帮助软件工程协会重新唤起对CMMI根源的认知以及Deming的教导的重视。显然，Deming的成果对于我们在理解客户需求与如何交付，并达成两者的平衡很重要。

组织成熟度也受到了很大程度的误解。人们往往以为这只是一项CCMI五级评估。但事实上，一个成熟的组织需要能够做出优秀决策，拥有适当的风险管理机制，能够从容地应对压力。如果我问大家：做优秀的决策，合理管理风险，从容应对，这算不算是好事？大家当然会给出肯定的回答。

成熟度较低的组织则往往在面对压力时表现得手足无措。他们会做出糟糕的决策而且无法适当管理风险。这与组织的规模无关，一个5人的创业企业可能有很高的成熟度，他们能做出优秀决策、恰当地管理风险且从容应对各种压力。因此对于大多数企业来说，拥有这样的成熟度至关重要。我认为CMMI模式是评估组织成熟度的好工具。

我并不认为CMMI是一种变革模型。因此如果只是对当前表现进行评价，告诉大家这就是我们的模型，依据它做出了差距分析，变革就是弥补这些差距。这种方式非常糟糕。

   

15. 事实上，很多人会把CMMI看作（是这样用的）……

David:是的，我认为这导致了错误的行为。因此我们希望把大家引导向的方向是，利用Kanban方法来导出组织的行为，使其与外部环境匹配——平衡用户的要求和我们的能力；同时把CMMI用作评估我们是否变得更加成熟的一种方法。提升成熟度的理由也很简单，我们当然希望能更好的决策、更好的管理风险管，从容应对压力。

下面再来考虑这样一个问题：大家的外部环境不断变化，我们希望能够在没有风险管理策略下从容应对。因此，这两者（CMMI和敏捷）都是有价值的。我还是为我们能够在《敏捷还是CMMI：为什么不同时拥抱？》中把它们综合起来感到自豪，我认为这篇论文对此进行了深入、有效的研究，而且为自己是该论文的合著者之一感到骄傲。

采访者:在现实情况下，对于大多数企业来说CMMI的级别越高、他们就越不愿意承担风险。

David:没错。这是一种令人感到遗憾的副作用。因为我们花了大量精力来追求评估等级，而一旦达到了五级，我们就开始变得厌恶风险，因为害怕自己会因此而降到四级——但这并不是评估机制本身的实际意图。这显然是一种副作用，我认为这是困扰软件工程协会和现在的CMMI协会的问题。我们该如何鼓励那些已经获得高成熟度等级的组织顶住降级的压力、勇于承担风险？我认为这确实是个有待解决的问题。

采访者:这是你的新书，至少中文版是新书吧

David:这令人激动，《看板》有了中文版。

采访者:它应该会很快出版的

David:它的封面在出版界被称为原样拷贝。你还不能买到它，但很快会出版。据说出版商选择了一位实践者翻译此书——他了解现实中的看板。没有用职业的翻译，而是真正理解Kanban的人来翻译，这很好。西班牙语版、法语版、葡萄牙语版、德语版都是由实践者翻译的。这确保了价值和可读性，希望中文读者能读起来很自然。

（编者按：原样拷贝是指David当时看到的样本，它保留了和英文版完全一样的封面，David喜欢这样）

采访者:坦率的说，这本书对于入门者不好读。至少在我读第一遍时有这样的感觉，花了我很长时间。对于中国读者，你有什么建议吗？

David:对于入门者，有一本小的漫画书，是由这本书的德文译者写的，但内容是英文的。

采访者:是免费书吗？

David:电子版是免费的，我们也有实体版。

采访者:书名是什么？

David:叫"Stop Starting, Start Finishing". 在Lean Kanban大学可以得到，它是一本大概20页的卡通书，介绍了Kanban的基本概念，非常易读。电子版和实体版都有，实体版大约7美元吧。我想它可能是Kanban最简单的起始读物了。

   

16. 好的。下面是最后一个问题，Kanban的未来将走向何处？

David:这个问题可以有多种回答角度。Kanban的市场发展将走向何处？就目前来看，我们认为它在东欧地区——包括俄罗斯、乌克兰、波兰、罗马尼亚、保加利亚以及土耳其——正处于起步阶段，在中国和新加坡也是如此。我希望在未来两年内，我们能够在这些区域内就Kanban的培训与咨询工作发展出更多业务合作伙伴。

在中国、东南亚其它国家以及东欧，提供Kanban相关服务的企业数量正在逐渐增加，其具体形式涵盖软件、模拟、游戏、培训乃至咨询等等，相信这一态势将继续保持下去。我们会推出更多新读物，也很可能出《看板》的第二版。我们还会为教练及顾问定制一本书。我们会公布一系列来自企业的真实案例研究结果，比如说我刚刚提到的Tupalo公司，这些努力将最终被整理成另一本新书。总体而言，我们正在努力打造更多出版物，也期待能在市场拓展与全球化方面取得新成就。

与此同时，Kanban方法本身虽然是完整的，但我们仍然看到它的进化趋势，我今天（Agile china 2013）就在谈看板的深度。针对Kanban深度的评估框架是我们在一次静修会议（retreats）上提出的——在这类小型会议上，我们会邀请一些顾问、培训师或者来自大企业的人士，讨论工作当中的困难、挑战以及新出现的Kanban知识。

我们将继续这些活动。我们已经组织起一个全球性社区，并召开大量会议。这方面的努力及活动将越来越多，我也希望能在中国举办一届Lean-Kanban大会。我想明年将在俄罗斯举行一次会议，同时期待活动能尽早登陆新加坡。我不知道这将把我们带向何处，但我们感受得到自己正在发展一种新的范式，用以管理二十一世纪的知识工作。我们同时看到了Kanban在媒体公司、法律企业、建筑公司以及人力资源部——而不仅仅是软件开发部门——都有良好的发展。

所以， Kanban将迈向更多的知识工作领域。这不是一年或者数年能完成的事，但我们已把它当着长远目标，会坚持很多年甚至数十年。我们的未来会非常成功，因为我们正在以非常务实的方式解决实际问题。

采访者:谢谢你！David

David:谢谢！