详情
看板方法是移动互联时代引领组织变革和改进团队开发过程的强大武器，也是平稳地落实精益和敏捷开发实践的首选工具。本书是带领读者进入看板世界的当然之选，它既提供了完备的理论体系，又有大量来源于实践的操作细节的支持。每一个新概念的引入，都会辅以简单易懂的实践，是一本名副其实的实战书籍。
书名：看板实战
ISBN：978-7-115-40534-0
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [瑞典] Marcus Hammarberg Joakim Sundén
译 霍金健 何 勉 程鸣萱
责任编辑 杨海玲
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
Original English language edition, entitled, Kanban in Action by Marcus Hammarberg and Joakim Sundén published by Manning Publications Co., 209 Bruce Park Avenue, Greenwich, CT 06830. Copyright ©2014 by Manning Publications Co.
Simplified Chinese-language edition copyright ©2015 by Posts & Telecom Press. All rights reserved.
本书中文简体字版由Manning Publications Co.授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。
版权所有，侵权必究。
看板方法既是移动互联时代引领组织变革和改进团队开发过程的强大武器，也是平稳地落实精益和敏捷开发实践的首选工具。本书是带领读者进入看板世界的当然之选，它既提供了完备的理论体系，又有大量来源于实践的操作细节的支持。每一个新概念的引入，都会辅以简单易懂的实践，是一本名副其实的实战书籍。
全书共分为三个部分。第一部分，作者以一个虚构的软件团队实施看板方法的历程为线索，介绍了看板方法的概貌——主要实践，为什么选择这些实践及带来的收益；第二部分则全面细致地介绍了看板方法的原则、实践及其背后的原理，如可视化方法，为什么要及如何限制在制品数量，如何有效管理工作流动等；第三部分是看板的高级实践，如基于看板的计划和估算，精益度量和持续改进等，并用专门的一章探讨了看板方法本身的不足之处，以及如何弥补。
不管对于看板的初学者还是具备一定知识的看板实践者，本书都提供了有益的理论和实践指导。
霍金健 目前任职于百度工程效率部，交付经理，资深敏捷教练。具有多年软件配置管理、持续集成、敏捷过程改进和项目交付管理的实战经验，目前致力于推动互联网创新产品管理和敏捷项目管理能力提升工作。专业书籍《系统工程Petri网——建模、验证与应用指南》中文译者之一。作为业界专家，多次在敏捷中国大会、Scrum Gathering、敏捷之旅等大会上受邀分享企业研发实践心得。
何勉 精益和敏捷产品开发的实践者、咨询师，有15年的产品开发相关经验，担任过产品开发中的各类技术和管理角色，如软件工程师、项目经理、产品开发部门负责人等。近年来专注于在企业及社区推广精益产品开发和精益创业的理念和实践，辅导过各种类型和规模的团队实施精益开发和精益创业实践。
程鸣萱 Agilean公司创始人，毕业于北京大学，敏捷与精益思想的布道者和实践者。帮助平安、华为、招商银行、顺丰等企业引入精益创业、看板方法、数据分析、DevOps等一系列实践，协助它们完成与互联网相关业务的落地与转型。近两年来，作为“软件看板之父”David Andersen和世界精益数据分析大师Alistair Croll的合作伙伴，致力于向中国公司介绍业界前沿并且可以切实落地的理论与实践，帮助期望开拓互联网与移动互联网相关业务的企业以最小的代价快速实现目标。
走进每个敏捷团队的工作环境，最显眼的往往是那块贴满了即时贴的白板。无论使用何种敏捷开发方法，敏捷团队通常都会倾向于使用这种原始，但却能够充分表现项目当前状况的信息源来展示项目状况。虽然不同的团队可能会定义不同的展现信息，或是以不同的方法使用白板，但作为一种可视化的手段，这个信息源在敏捷过程中发挥着重要的作用。
然而，如果采纳精益生产的观点，把重点从对流程的关注转移到对流动的关注，那我们就会发现，白板的作用远不止于“展现信息”。通过为白板赋予更多的意义，任务的流动状况、资源分配的不合理等信息就都可以魔术般地直观展现在白板上——当我第一次应用看板方法的时候，只是通过几个简单的步骤，项目的流动状况就突然之间清晰地浮现在我面前，这些一直在那里却长期被忽视的信息在一瞬间突然让我看到了问题所在。
看板方法是个简单的方法，因为它并不要求设置复杂的规则和流程，也不要求在组织内引入一大堆的框架。理论上，持续关注“可视化”“限制在制品”和“管理流动”就能够清楚地展现项目中的流动性，基于前置时间（lead time）等简单的度量指标就能够持续改进组织的生产率。然而，与此同时，看板方法又是一种并不那么容易用好的方法。要想“以最小的成本创建最大的效益”，在实践看板的过程中，从如何设计看板的展示方式，到如何管理不可替代资源，实践中的每个环节都需要实践者有足够的经验和控制能力。想必读者已经有体会，在运用解决问题的方法时，往往越简单灵活的方法越需要经验和细节的支持——看板方法正是这样一种方法。
这是一本面向看板方法实践者的书，作者几乎完全抛弃了看板方法中深入的理论探讨，把重点放在“如何在组织中应用看板”这个更接地气的主题上。用一个虚构（但却十分有价值）的案例介绍看板，然后逐步深入看板设置、管理和度量的细节，不厌其烦地详尽（甚至是过于详尽）描述了看板方法应用过程中的实践之道。在对看板方法系统性的阐述和深入探讨方面，这本书显然无法和大卫•安德森经典的《看板方法——科技企业渐进变革成功之道》相比。然而，对于初入看板方法门径的读者来说，这本书却更能让你一手拿书，一手操作，从容地在组织内实施起看板方法。从实践方面来说，这是一本绝不会让你失望的书。当然，正如我在前面提到的，要想从看板方法中获得真正大的收益，仅仅在组织内架设起使用看板的习惯是不够的，在应用看板的同时，读者还应该系统性地了解看板背后的思想，通过合理的改进不断进行优化。
翻译一本书绝不是件轻松活，所幸本书的几位翻译者都是看板领域内拥有丰富经验的实践者，他们出色的经验保证了本书的翻译质量。虽然不能说阅读本书的体验完美无缺，但至少我的整个阅读过程轻松愉快，在看板的世界里跟随着作者和译者又体验了一把看板的乐趣。
段念
宜人贷CTO
移动互联网时代的大门已经完全开启，越来越多的企业感受到技术发展和市场变化带来的巨大冲击。如何让企业顺利转型、焕发生机，是摆在每个管理者面前的严峻挑战。
幸运的是，现代管理学之父彼得 • 德鲁克在90岁高龄时，极具前瞻性地指出了未来的方向。在21世纪，企业管理者最重要的工作是提升内部知识工作者的生产率，让知识工作者能够自我管理、自主学习并不断创新。人们不再用产出数量来衡量生产率，质量（价值）变得尤为重要。
大师给出的道路非常清晰，但落地从来都不容易。10年前，大卫 • 安德森将看板方法从丰田制造引入了软件研发当中，并在实践中取得了令人欣喜的结果。近几年来，看板方法从美国传向世界各地，效率提升200%、400%甚至800%的案例不断涌现，为现代企业渐进式变革提出了一条切实可行的路径。
看板方法作为一种组织渐进式变革框架，它当中的许多思想暗合生物进化的规律。正如凯文 • 凯利在《失控》一书中指出的：“生命能够起源于一个笼罩着空气和水这两种介质的行星上，并非偶然。因为清洁、透明的环境，使得器官能够接收来自‘远处’（未来）的含有丰富数据的信号，并对来自有机体的信号进行预处理……在一个变化的环境中，不管这个环境是浑浊还是清澈，能够预测未来的系统都可能存续下去。”看板方法通过将知识工作中本不可见的信号可视化，将团队从混沌状态中解脱出来，教导团队学会用“拉动”的方式工作，即在收到信号时迅速做出恰当的反应，而不是无序地“推动”。
看板方法提升效率的另一个思路是通过限制在制品数目，让知识工作者不再同时开始许多新的工作，而是力求快速完成已经开始的那些。“停止启动，聚焦完成”，当手头工作遇到问题时，专注地尽快将其解决。对于创造性脑力劳动来说，让工作者保持专注和目标的清晰，提供快速、即时的反馈，将帮助他们进入“心流”状态，从而显著提高工作的效率和质量，改善工作者的情绪和体验。
另外，看板方法要求团队将组织处理信号的规则显式化，利用精益度量体系对系统及时进行分析回顾，不断优化信号处理模式。这就形成了一个完整高效的反馈闭环，最终建立一个具备自我完善能力，并能随着组织发展和环境变化不断演进的自适应系统。
看板创始人大卫 • 安德森的著作《看板方法——科技企业渐进变革成功之道》在这一领域堪称经典，但对于初学者来说有些抽象、深奥。本书从大量实际案例出发，浅显易懂，能够帮助人们了解看板的基本概念，并将其迅速应用于实践。同时，我们也要意识到，组织内可能存在几种或十几种不同类型的团队，每个团队有自己的应用领域、局限性和困难，需要采取不同的管理方式。看板方法没有为使用者制定一个普适的框架，每个组织应该根据实际情况建立适合的看板系统，并在实践的过程中不断将其优化。“形兵之极，至于无形”，希望这本书所提供的方法，能够帮助企业走上适合自己的渐进式变革之路，从容应对未来的挑战。
李兴双
中国工商银行软件开发中心副总经理
人类大脑有很多容量专门用于吸收、处理、反应和存储视觉信息。我们看到的信息启发我们当前的行动，并灌输给我们未来的行为模式。如果我们什么都看不到，我们就很难有所反应。
像看板这样的可视化系统因我们对视觉信息的偏好而成为了强有力的工具。举例来说，看一看下面这张简单的地图，你看到了河流、建筑物、道路和其他很多信息。这些信息你一眼就看到了。只一眨眼的工夫，你就了解了环境、形状与实体。
下面是我根据这张地图内容写下的一个列表，这当然是个部分列表。为了避免通篇都是文字，我们对字体做了必要的调整：
读者很快会发现，这个冗长的列表比地图提供的上下文信息少但需要的处理时间却更长。
我们使用看板这类可视化系统的目标是建立我们工作的地图。我们想知道工作的形态和实体，想快速直观地理解系统，想在看板墙上清晰地展示角色、职责、在制品、完成速率、流程结构、阻塞事项等很多内容。
这其中有大量信息。
自从大约十年前我们将看板作为软件开发工具提出之后，我们就发现：
真实地看到工作和流程有助于理解。
一旦我们看到工作，我们就能对其构建出共同的理解，接着就能将困扰软件开发多年的糟糕的流程约定剔除掉。看板墙可以变成一个简单的信息节点，使任何人都能走过来并了解项目的当前状态。
这意味着软件开发团队最终会和业务人员使用相同的语言。IT 部门和公司其他部门间的隔阂将消弭。一个沟通的桥梁建成了。
在本书中，Marcus和Joakim列举了项目使用看板的三个元素：
我个人很喜欢这个列表。
在个人看板（Personal Kanban）中，我们使用前两个（即可视化工作和限制在制品）并将第三个视为自然的结果。但我喜欢这个列表是因为它贴切地说明了如下要点：
工作不应该去适配时间——而是需要流动。
把工作拆散以适应任意的时间节点，对完成速率、避免缺陷和团队士气具有深远的负面影响。不必要的截止日期压力或过于乐观的特性范围对团队和产品都会产生负面作用。这时工作的重心就变成了将工作挤压到截止日期前而不是高质量地完成工作。
高质量地完成工作只有在工作以可持续的节奏流动时才有可能。发现并维持这一节奏只有在在制品小于团队产能的情况下才有可能。在截止日期之前塞入太多工作几乎不可避免地会打破在制品限制。
利用合理的在制品限制，我们鼓励工作的流动。工作是以可度量且质量可控的方式完成的。因为没有了管理太多在制品的开销，产能飙升，这毫不奇怪。
这是Marcus和Joakim希望在本书中介绍的内容的一个缩影。他们在书中给出了大量的细节。如果这是你第一次接触看板，欢迎你。没有比这本书更好的指导书了。
Jim Benson
2013年Shingo大奖作品《个人看板》（Personal Kanban）作者
我是通过Scrum方法开始了解敏捷方法的。当时在一家瑞典的大型保险公司里面，我就像打游击一样开始使用Scrum方法。不久之后，Scrum方法就扩散开来，几年的工夫公司里就有了50多个Scrum团队。但我们还是觉得哪里不对劲儿，因为很多团队的工作流程并不适合Scrum方法固定时间盒的启动停止本质。而且，大多数团队也没有涵盖整个流程，大多数团队都是由处理需求的开发人员组成的，他们在开发完成后会把工作交付给另一个单独的测试团队。
当试图将工作流经的全部流程整合到一起时，我发现很困难。因而我就开始在敏捷社区中调研其他实践。不久，在Joakim的帮助下，我开始学习看板。2010年和2011年我参加了David J. Anderson的看板和看板教练培训。这进一步使我确信看板和精益正是我所寻找的方法。
2008年，我是一家大型瑞典公司IT部门的咨询顾问，当时我作为Scrum Master参与一个横跨三个团队的软件开发项目。为加深对敏捷软件开发的理解，我正在研究精益软件开发——这使我接触到丰田公司令人称叹的故事，同时也学习到精益思想与丰田生产方式的大量文献。这种研究达到顶点的标志是在2009年春天我和《精益软件开发》的作者Mary和Tom Poppendieck一起参观了日本丰田公司。
在2008年底，我的客户得出结论，大多数（如果不是所有的话）客户支付的软件开发工作都很拖延——事情进展得太慢了。他们期望更多开发工作能更快完成，而不要缩减范围或牺牲质量。受到精益思想关于单件持续流的启发，我建议应当停止每隔两到三周一次规划批量工作的Scrum迭代计划会（我们越来越觉得这个节奏是随意的），反而应该聚焦于单个或少数工作项并努力协作使得工作以持续价值流动的方式尽快完成。十几个团队成员达成一致：任何时候开发阶段的工作项不超过两个，测试阶段的工作项也不超过两个，而且只有当工作完成之后才能从待办列表中拉入新的工作项并及时计划。
不久之后，通过Corey Ladas的博客和David J. Anderson的书籍我发现看板方法和我们的做法很类似。2009年，我通过英国的第一届精益看板大会和社区建立了联系。在这里大家关心在不同团队和公司的情形下起作用的方法，我立刻被这种实用的方法吸引了。而在当时我认为大多数敏捷社区都只关注基于信念的方法，比如“Scrum方法告诉我们该如何解决这个问题？”
接下来的一年（2010年），我参加了David J. Anderson在伦敦举行的第一届看板教练工作坊（现在称为Advanced Master Class），一起参加的还有很多资深的实践者，如Rachel Davies、David P. Joyce和Martine Devos。2010年我参与共同创建了斯德哥尔摩精益咖啡，在这里看板爱好者每周都能聚会交流。2011年，我受邀参加了由David J. Anderson主持的首届看板领袖静修班（Kanban Leadership Retreat），成为第一批由David J. Anderson认可的看板培训师。
2010年，我们和当时在Avega 集团的同事Christophe Achouiantz一起着手开发看板实践指南。这一下大获成功，从此开启了一系列欧洲和美国的讲演，包括客户培训、教程和工作坊。我们有时一个人完成讲演，有时两个人一起完成。这种实用的方式和很多参与我们讲演和培训的人产生了共鸣，从而使我们收到了大量正面反馈。
在JFokus大会（这一盛会由Avega 集团的另一位同事Mattias Karlsson组织）的演讲结束后，Marcus接到了来自Manning 出版社的电话，问他是否愿意写书。Marcus立刻想到应该和Joakim一起完成这本书。我们决定让这本书的行文和我们演讲的风格一致，使用实用的方式和轻松的风格。
如果你之前阅读过致谢部分，就会知道都是从感谢家人开始。现在我们理解了背后的原因。因为我们把本该陪伴家人的时间都用来写作了：当他们休息时，当我们应该陪伴他们时，当我们应该陪他们去游乐场时，我们却在写作。他们一如既往地支持我们，没有他们，没有他们的支持，就不会有这本书。
我们想借此机会向社区表达由衷的感谢——我们每天都从社区成员身上学到很多东西，并且日后还会继续学习，很多社区成员都比我们资深。我们站在巨人的肩膀上，衷心感谢社区成员对我们的支持和鼓励。
我们希望在这里特别感谢如下朋友对我们的帮助、鼓励和支持：Christophe Achouiantz、Torbjörn Gyllebring、David J. Anderson、Jim Benson、Corey Ladas、David P. Joyce、Benjamin Mitchell、Karl Scotland、Mattias Skarin、Don Reinertsen、Alan Shalloway、Mary和Tom Poppendieck、Hkan Forss、Måns Sandström、Eric Willeke、Jabe Bloom、Mike Burrows、Dennis Stevens和所有看板领袖静修班上所有的同仁。在斯德哥尔摩精益咖啡系列活动中，我们也收获良多，而且度过了美好时光。特别感谢Hkan Forss和其他所有同仁。
感谢在本书写作过程中的审稿人，你们的反馈非常有价值。特别感谢Rasmus Rasmussen和Viktor Cessan的深刻见解，各位审稿人如下：Adam Read、Barry Warren Polley、Burk Hufnagel、Chris Gaschler、Craig Smith、Daniel Bretoi、Dror Helper、Ernesto Cardenas Cangahuala、Jorge Bo、Karl Metivier、Marius Butuc、Richard Bogle和Sune Lomholt。
特别感谢Jim Benson为本书写序，感谢Danny Vinson为本书校对，感谢Robert Vallmark为本书提供精美[1]的头像——这确实帮助我们改进了本书的视觉效果。
我们非常荣幸和Manning出版社的同仁一起工作，我们相信Manning出版社集结了最优秀的人为我们提供服务。
谢谢Bert Bates帮助改进本书封面的外观，我们很幸运能从一开始就从你那里了解到这一点。当然，非常感谢出版人Marjan Bace邀请我们写作本书。
衷心感谢本书的编辑Beth Lexleigh和Cynthia Kane，是你们不遗余力地审阅和推动让进度回到正轨，是你们的努力把我们的随笔最终变成了一本书。
感谢Manning出版社的其他同仁，排名不分先后：Michael Stephens、Maureen Spencer、Tiffany Taylor、Kevin Sullivan、Mary Piergies、Janet Vail和Candace Gillhoolley。
首先我想感谢上帝——这是我和我所有行为的基石。
感谢Elin和孩子们（Albert、Arvid和 Gustav），谢谢你们无私的支持。我甚至从Albert那里得到了一些设计上的帮助。
感谢我的父母将我养育成人。
感谢社区的所有同仁，我时常向你们咨询问题，由衷地感谢你们。从你们身上我得到了无私的支持和帮助：Torbjörn Gyllebring、Håkan Forss、Måns Sandström、Anders Löwen-borg、Hugo Häggmark、Tomas Näslund、Per Jansson、Kalle Ljungholm，谢谢你们。
感谢Avega 集团和Aptitud（我写作期间的雇主），谢谢你们让我参与这个项目。Avega甚至为此给我酬劳。提供这种厚待给我，这真让人难以置信。这两家公司都很棒！
最后，我要感谢Joakim——如果没有你，这本书将毫无价值，也许可以早点完成，但绝不会有任何人愿意读。从你身上我学到很多东西，并将继续学习。谢谢你，兄弟！
没有家庭的支持，我将无法参与这本书的写作。家人给了我生命，也给了我参与的机会，谢谢你们：祖父母Albin、Ingeborg和Molly，我的父母Ove和Elisabet以及他们的兄弟姐妹及其家人，我的姐姐Anna和哥哥Henrik，谢谢你们。非常感谢我的妻子Anna和我们的孩子们——Alva、Saga、Albin和Iko，你们的支持是显而易见的。
感谢Marcus让我参与本书写作，谢谢你对我进度缓慢和贡献稀松的无尽耐心，感谢你坚持不懈的努力，感谢你接受我并非总是礼貌的批评、推荐和大幅度重写的想法，感谢你在格式调整、像素改变等苦差事中的巨大努力，感谢你推动我但没有逼迫我或让我感到不舒服（其实我自己在逼迫自己），感谢你开朗和乐于助人的性格，总之，Marcus，谢谢你！
[1]精美有趣的漫画头像，我们觉得这并非溢美之词。有人评论Joakim的头像：“这看上去像是意大利版的你——在你吃了太多披萨之后。”而且Jim Benson曾经问为什么Marcus看上去像是Jeff Goldblum。
你是否希望了解工作的情况以及团队中或工作场所内发生了什么？你是否能从只关注少数事情而不是在多个项目中经常切换得到收益？你的客户和干系人是否希望新功能现在交付而不是日后某一天？你是否觉得你和同伴需要不断地改进和学习？
如果回答“是”的话，那么看板就是为你准备的。
你是否希望立即使用看板，而不用花太多时间在抽象理论和历史上，也不用弄清楚不同方法的细微差别？你是否想知道看板社区的人如何在实际中使用看板解决不同的问题？
如果回答“是”的话，那么这本书就是为你准备的。
本书是一本脚踏实地的、没有多余装饰的、实操性很强的看板介绍书籍。本书基于大量实践和观察，也有一些是从我们的同事或我们辅导过的看板团队听说的案例。过去几年中，我们也曾在各种大会中讲演，并活跃于用户组和看板社区之中。
在本书中，读者会学习到简单有效的工作可视化技术：如何设计看板墙，如何跟踪工作及其进展，如何可视化队列和缓冲区，甚至很多实质性细节，比如使用颜色和其他改进措施如何帮你组织并跟进工作项。
读者也会获得很多如何限制工作流程中的在制品的实用建议，比如根据不同上下文设置限制的不同方式，如何知道何时以及如何改变限制。
有了这两个工具（看板和本书）之后，你就已经准备好深入业务并助力工作项流过整个系统，同时你一边学习一边不断优化整个流程了。读者会学习到服务类别的概念，如何在看板世界中进行计划和估算，队列和缓冲区的概念以及如何使用它们，还有很多能帮助团队每日改进的技巧。
请稍等一下，还有很多内容。读者会学习到度量以及如何使用它进行改进，而且我们会介绍几个游戏和练习，读者可以用来帮助理解看板原则并以此将新人带入看板世界。而且，我们有很好的理由专门写了一个章节介绍看板的陷阱和常见批评。
这是一本实用书籍，我们不会花很多时间介绍看板背后的理论及其历史。关于这些主题已经有很多书籍（比如一些关于精益、敏捷和丰田的书籍），而且他们做得比我们能想到的要好得多。但我们也不会撇下你不管，比如为了充分利用我们介绍的实践技巧，有一些理论是需要的，所以我们会介绍这些理论。
这本书不只是入门者的读物。基于我们收到的所有关于看板的问题和很多接触看板有一段时间的人在实用技巧讲演或培训课程中也深受启发的现象来看，和新手一样，即便读者早已不是新手也能从本书收获良多。
接下来让我们看一看这本书！
本书分为四个部分，每个部分的目的不同，以便有针对性地伴随读者学习看板。
我们无法保证你在学完本书之后变成看板大师，但本书会是你学习看板之旅的良师益友。记住结合你在实际尝试中所获得的经验，它们将是学习旅程的一对绝配。
阅读本书时你有几种方式可供选择。
你也可以从头到尾通读全书。这将使你一步一步更深更广地理解看板。我们相信最好的学习体验来自于将本书知识和实践经验相结合。
购买本书之后，你可以免费访问Manning Publications提供的网上论坛，在这里读者可以发表评论，咨询技术问题并获得作者和其他用户的帮助。请访问www.manning.com/KanbaninAction并订阅。这个页面包含用户注册之后如何访问论坛的信息，相关帮助文档的信息以及论坛中的行为准则。
Manning承诺提供一个便于读者和作者以及读者之间进行有意义交流的场所。而作者能参与多长时间并未做出任何承诺，因而作者的贡献是自愿的（也是无薪的）。我们建议读者向作者提出一些有挑战的问题，从而使他们保持兴趣盎然。
只要本书在出版，就可以通过出版社的网站访问作者在线论坛和之前讨论的存档。
在我们一起开始这段旅程之前，读者可能希望更多地了解我们一点儿。简单介绍如下。
Joakim是一个善于思考的人，他是我们活力双雄的大脑。他总在发言之前先让别人发表观点，等他决定之后就会以深思熟虑的观点回应，从而让对方陷入沉思。这有时会让人恼火，因为他们通常只是希望知道该做什么。他具有精益、敏捷和丰田生产系统的扎实的理论知识，同时也有大量的实践经验。
业余时间里，Joakim是美食家和电影迷。在他与人对话时偶尔会引用丹麦教条电影的评论（更多的是针对其周围的各种混乱）。
Joakim有4个孩子（0~9岁），他的妻子是Anna。同时他还努力参与到公司（Spotify）的工作和瑞典及世界范围内的精益和敏捷社区中。他经常在各种国际会议中进行演讲。
Marcus是个实干家，是活力双雄中的“肌肉”。他喜欢先尝试即使结果是失败也不是先想好并一次性做对。这导致他一遍又一遍地重复做事情——这让他很恼火而其他人觉得很好笑。
Marcus以开发者的角度加入精益和看板社区，并对能支持这些想法落地的实践具有强烈兴趣，如测试驱动开发、结对编程、实例化需求和影响地图。
有时间的话，他会写写博客，或者参加救世军[1]活动，或者浏览一下关于铜管乐队的最新新闻。你可以想象一下，尝试把这些事情和工作场景联系起来既困难又无用。
Marcus的妻子是Elin，他们有3个可爱的儿子（分别是5岁、3岁和3岁[2]）。当你读到这段话的时候，他们可能已经移居印度尼西亚了，Marcus在这里参与救世军的工作。他将领导基金会的工作，即救世军在印度尼西亚为6个医院和13个诊所提供服务。当然，这个工作会以敏捷和精益的方式开展，受本书的启发也会应用这里介绍的技巧。Marcus还会在救世军服务的孤儿院中教孩子们铜管乐器。
[1]救世军是一个成立于1865年的基督教教派，以街头布道和慈善活动、社会服务著称。其国际总部位于英国伦敦维多利亚皇后街101号，在全世界有几千个分部，分布在70多个国家，据称有成员200万人。——译者注
[2]是的，两个3岁的儿子是双胞胎。
本书的封面人物是德川家康（1543—1616），他是日本幕府时代德川幕府的开创者。德川幕府自1603年在日本江户（今东京）建立，直到1868年明治维新。幕府将军是日本封建时代的军事领导人，由于权力集中在其手上，所以他是事实上的日本领袖，而天皇只是名义上的国家领袖。德川家康从1600年开始掌权，并于1603年被任命为幕府将军，1605年退位，但一直到1616年去世才将权力交出。他声称终其一生作为士兵或者将领一共参加过90多场战争。他有很多素质使其能处于权力中心，他谨慎、果敢，在正确的时间和正确的地点做出正确的决定。精于算计，当他认为有利可图时就会变换同盟。
我们希望将德川家康的一句名言跟各位读者分享，这句名言对我们的个人成长和职业发展都很适用：“生活有如负重远行，不可急躁，以免跌倒……找出自身的问题而不是别人的问题。”
本书第一部分通过一个实例对看板进行介绍。这一部分的目标是帮读者建立一个实际可用的看板，让读者对看板背后的原则有基本的了解。此外还会涉及一些高级主题吊一下读者的胃口。
我们以一个典型的软件开发团队的小故事开始介绍。在这个故事里，我们为这个团队介绍看板并让他们开始使用看板。如果不喜欢这种讲故事的风格，可以直接跳到下一章。我们在第1章中提到的概念在后续章节中都会详加介绍。
Marcus和Joakim正在一个会议上介绍看板，他们的演讲即将结束，让我们来听听他们都说了什么。
“一言以蔽之，看板是一种基于精益思想[1]的软件开发方法，世界上很多组织都采用了这种方法，所以，在座的各位也可以使用看板，从明天开始用起来吧！我们建议各位，最好先停止接受新工作，而是先把未完成的工作做完。”Joakim总结道，“这就是我们对看板的简单而实用的介绍。但是，正如我们之前提醒的，请牢记一点——你可以从明天开始就使用看板。建立一个看板并使之运行并不难，但这对你却能产生巨大的影响。”
“谢谢各位的到来，我们将会留下来几分钟，如果各位有问题的话可以提出来。”Marcus插话道，他试图结束讨论以便本次演讲能准时结束。
当Joakim开始清理白板和即时贴的时候，Marcus回答了几个简单的问题。Marcus一边告诉大家演讲幻灯片的下载地址，一边向着出口走去。但他还没走远，在距离出口一半的时候，一个女人突然拦下了他。
“怎么回事？你要离开了？千万别告诉我，我们彻底错过了。”这位女士看上去非常失望，而且好像被骗了一样。
“错过了什么？这个演讲？哦，是的，我们刚刚结束，不过你可以看看在线视频。”Marcus回答道。
“哦，不！”她喊道，“我们来这里就是为了这次演讲！但看起来有人把演讲的开始时间弄错了。”这时一位男士领着一群人进入了会场，而她冲着这位男士点点头。
“那好吧，如果你希望参加现场演讲，我们在今年秋天可能会有类似的演讲。”Marcus回答道，试图平复一下对方的情绪。
“那太迟了——我们期望马上就开始。我们整个团队都在这里，今天甚至连业务人员都在我的建议下一起过来参加这个课程了。”她看上去难过极了，“你好，我是Daphne。”她补充道。
“那好，既然如此，你们可以和Marcus和我预约一天的时间来进行咨询，这样如何？”Joakim一边建议一边跟Daphne做了自我介绍。
“是的，我们可以那么做，但这个团队以及协作方已经有太多抱怨了。我们希望能够解决这个问题，而且希望今天学到东西能帮助我们解决问题。”一个威严的男人说道，同时他也赶上了Daphne。
“那你说的究竟是什么问题呢？”Joakim问道。
“整个团队感觉被工作淹没了，而等待交付的人却觉得工作永无完成的那一天。”他明白无误地回答道。
Daphne接着说：“尽管我们有大量工作要做，我们却花了大量时间讨论哪个项目是重要的，应该最先开始的。然而，我们仍然没有办法从中挑出正确的那个最重要的项目。”
“而且……其实，还有很多问题，但我们不想占用你们太多时间。你们现在就要离开了吗？”那位男士说道，把其他要说的问题又咽了回去。
“除非你们有一个更好的建议？”Marcus快速回答道。这听起来像是即将开启一段有趣的挑战之旅。
“我们想做的事情很简单。我想要购买你们两人的咨询服务，就在这里，就现在。”那个威严的男人说道，“你们的演讲稿还在屏幕上播放着，上面写着‘从明天开始’，我可以给你们一个机会用实际行动来证明这一点。你们能抽出多长时间？”他停下来盯着Marcus和Joakim的眼睛。
“我们还有两个小时，然后我们就得走了。”Joakim看着他的手表回答道。
“既然如此，那就在两个小时内帮我们把看板建立起来并使之运行吧。”这个老板模样的男人伸出他的手说道。
“我们没有办法帮你们解决所有问题，只能为你们指明正确的方向。”Joakim看了看Marcus说道。他们互相点了点头：“好，我们现在有两个小时来接受这个挑战。”
欢迎进入看板实战
你已经踏上了看板的学习之旅，本章将通过一个故事介绍看板的基础。不需要具备任何看板基础知识就可以开启本次学习之旅。你可以跟随两位教练Marcus和Joakim（是的，就是本书的作者）的脚步进行学习，他们在本书中教一个软件开发团队使用看板，并帮助他们使用所学来改进他们的工作。
我们通过这个虚构的故事把你轻松地带入到看板世界来学习一些基本的概念。在本章中，你会学习如何使用可视化技术，如看板墙和工作项，以更好地了解工作进展；你也会学到如何限制在制品的数量，并且弄清楚为什么这么做可以促进工作的快速流动并利于识别改进的机会；你也会接触到如何使用度量来进行改进。
关于这一章，我们收到的评论分为两个阵营。很多人喜欢这种讲故事的方式，而其他人好像不太喜欢。如果你也不想从一个故事开始一段学习旅程，那么你可以直接跳到下一章。本章提到的所有概念，在后续章节中，我们都会详加介绍。当然，我们还是希望你能够阅读本章并从中有所收获。读完本章，你应该能够自己建立一个看板并使之运行起来，在过程中可以使用故事里我们教给这个开发团队一些原则。
在本书其他章节，我们将详述：看板原则以及各种变体和实践，这些变体和实践都是由世界各地的看板团队发展出来的。如果你觉得在本书第一部分我们没有告诉你所有问题的答案，那么你一定会在本书的后续几个部分中找到问题的答案。
不过目前最重要的是继续我们的故事。
整个团队都聚集在隔壁的房间里。他们通过描述彼此来向Marcus和Joakim介绍他们自己。根据他们大胆的发言判断，他们对于使用这种相互描述彼此的方法非常在行。
“Adam是一名测试工程师。他已经在这里工作了相当长的一段时间，而且他总是一副怀疑一切的态度，无论是新事物，还是其他人的能力，当然大部分怀疑都集中在其他人工作的质量上。他尝试着用一种友善的方式来表达自己的批评，有时候这种方式能够奏效。”
“Adam喜欢用自己的方式行事。他不喜欢变化，因为变化意味着回归测试。”
“Beth是一名新员工。在团队中，她负责需求分析。这项工作主要包括跟业务人员讨论需求，并把这些需求写下来以便开发人员能理解他们该做什么。”
“Beth总是寻找新的工作方法。”
“Cesar是业务人员。团队现在开发的应用是一个网上银行，第一版实际上是由Cesar独自一人完成的。”
“现在Cesar不再干IT相关的工作，而是负责业务运营。但他还是认为自己是个开发人员，我们经常发现他在做开发工作。”
“Daphne是一个很棒的开发人员。广为人知的一个事件是她在一个小时内写完的代码量比大部分人在一周内写的都多。”
“但她喜欢单枪匹马独自工作，因为其他人会减缓她的工作。如果你询问Daphne，在她看来最佳的工作方式就是跟Cesar坐下来并决定整个应用是如何工作的，然后所有问题就都解决了。所有其他的活动和组织结构对于她而言都是绊脚石。”
“Eric白天是一个开发人员，因为他不得不如此。但是晚上他就变成了吉他高手，在当地的酒吧和其他一些场馆都能听到他的演奏。Eric不久之后就会有一场盛大的演出。”
“写代码是没有问题的，但通常很难了解为什么要这么做。”
“Eric喜欢尽快完成工作，以便能继续回答http://guitar.stackexchange.com[2]上的问题。”
“Frank是IT部门的经理。他的团队里面有36个人，他尽量每个月都和每个人至少沟通一次，不过他还要参加很多其他会议。”
“他很关心产品，但他很难有时间跟进所有的新特性。每当有些空余时间，他总是先考虑如何培养人。”
“太好了，”Marcus说道，“我发现那个房间里面有一张白板，你带了即时贴了吧，Joakim？”
“当然，”Joakim回答道，脸上的表情告诉Marcus请不要问愚蠢的问题。Joakim是一名敏捷教练，随身携带即时贴是很自然的事情。
“好极了，那么我们过去吧。”Marcus说着并带领大家走过去。
“谁能告诉我们，你们到底在开发什么东西？”当大家围着白板站定之后，Joakim问道。
“还是我来吧，”Cesar说道，然后把笔记本电脑拿了出来。
“哦，不，不要用幻灯片！”Eric大叫起来，“直接说吧，我们没有时间用幻灯片。”
“好吧，你也许是对的。”Cesar有点窘，然后回答道，“这是一个简单的介绍。”
这个团队是一个很小的开发团队，所有成员都在这里了。他们为一个大的保险公司服务，负责新发布的手机银行应用。因为这个团队比较小，他们能够掌控大部分工作。虽然也要跟业务部门的其他团队汇报进展，但他们能够自己决定自己的工作，Cesar在每一个重要决定中都有最终决定权。这个团队负责在手机银行这个应用中开发新特性，同时还要支持和维护已经发布的版本。
“你们为什么需要我们的帮助？”Marcus问道。在等待回答的同时，他在一张白板纸上写下挑战作为标题。
“我可以回答一下。”项目经理Frank走上前说道。
“为了跟上快速的交付节奏，我们曾经有过痛苦的经历。公司中的很多项目干系人都有抱怨，主要集中在功能特性没能及时完成。”
“而且事情迅速恶化了，”Cesar说道。“大家不再相信我们工作的质量，而且绝不再相信我们给出的预估和交付日期。”
“然而，”Daphne补充道，“我们感觉到完全被各种工作包围了，根本不知道应该先做哪个工作。当我们试图取悦所有人的时候，却导致工作优先级彻底变化了，所有工作都变成了最高优先级。”
接着，大家还和Marcus和Joakim谈到其他问题。项目干系人直接把工作交给某个团队成员是很普遍的现象。这些项目需求经常是来自公司的高层，作为开发人员很难拒绝。而且，这些需求有些是其他人员已经在干的工作了。Marcus很有耐心地把这些问题作为要点写在白板纸上。
“谢谢你们，也许这已经足够了。”Daphne打断了讨论，“时间过的很快，但你们只有两个小时，不是吗？我们还是实际一点，这些问题已经足够多了。”“好，让我们先回到手头的工作。”Frank有点失去耐心了，“我们从哪里开始呢？”
“我们知道大家很想尽快开始。”Joakim回答道。“但你们需要了解的是，看板和其他方法有些不一样。比如Scrum或者Rational统一过程（RUP），他们会事先定义有哪些角色，应该有什么会议，甚至如何开这些会议，等等。另一方面，看板从你的现状开始，帮你了解现状，助你识别下一步改进的机会。”
“是的，这对我们和大家是很重要的，特别是在了解现状以帮助改进方面。”Marcus插话道，担心Joakim会长篇大论起来，“但我们现在当然可以开始了，而且在我们进行过程中，你们会了解更多。我们将把这一串挑战作为这两个小时交流的议程表。”
“顺便问一下，你们团队名字是什么？”Joakim问道。
“从现在开始，我们就叫Kanbaneros团队。”Frank说道，带着浓重的墨西哥口音。大家立刻都笑了起来，同时Marcus把这个名字写在白板纸上。
“为了让我们的工作更好地可视化出来，我们使用‘展示并讲解’的方式开始，如何？”Joakim开始了介绍。
“你们是如何知道整个团队都在干什么的？工作需求是如何进入你们的流程的？如果你们大家都不知道，那么那些项目干系人怎么可能知道呢，对吧？”Joakim走到白板前拿起一支记号笔。
“你们在哪里记录工作待办列表？”Joakim问道，“我猜你们是不是维护一个需要完成的工作列表？”
“是的，当然。”Beth迅速回答道。Joakim和Marcus能够感觉到她有点被这个问题激怒了，“我会确保把所有需求分类记录到JIRA[1]里面，JIRA 是我们的项目管理工具。”
“并且，我一有机会就会进入这个工具，根据优先级更新工作的顺序。”Frank补充道，而且他觉得项目管理系统很好用。
“这就使得我们清楚地看到谁在干什么以及每个工作相应的进展。”Cesar接着补充道。
“我们现在能访问一下你们的JIRA系统吗？”Marcus指着Daphne的笔记本电脑问道。
“当然可以，”Daphne一边回答，一边打开了笔记本电脑。
“好的，现在让我们把你们正在进行的工作都写下来，”Joakim建议道，“每个工作项单独写在一个即时贴上，尽量简洁一点，只要你们能够大概理解是哪项工作就够了。”他用独特的单手方式在一秒内就把即时贴打开了，以获得大家的赞美（也许只是他的一厢情愿）。他把黄色即时贴发给大家。
“请用粗笔写清楚，不要用圆珠笔。”即便Marcus已经说过上百次同样的话，但每次说的时候，他依然感觉很棒。因为他知道那种细细的涂鸦方式会让人们难以理解，并且很难参与到练习中。“你们写完，就贴在白板上。”Joakim要求大家按照优先级从上往下贴在白板上。这个团队用了几分钟在电脑屏幕和白板之间来来回回走了几圈就把6个即时贴在白板上贴成了一列。当大家重新站定，Joakim面朝大家问道，“你们都同意吗？这就是你们现在正在做的工作？”
“是的。”Cesar，Frank和Beth几乎异口同声的说道。Adam和其他开发人员却沉默地看着地板。
“这件事本身没有对或错之分，”Marcus说道，“重要的是我们能够得到大家工作的真实情况。所以，还有别的工作吗？”
过了几秒钟，Adam清了清嗓子说，“其实，这不是全部内容……我们有很多工作没有记录到JIRA里面。”
“那是些什么工作呢？”Joakim问道，“你能给我几个例子吗？”
很快大家发现那些工作项在工作量和内容方面千差万别，比如：额外的需求，小的支持任务，报答其他部门的帮忙和系统的例行维护。当公司高层希望完成什么事情的时候，他们可能直接在走廊里面就把工作交代给团队的某个成员了，这是常有的事情。
“这些任务是很难拒绝的。”Adam说道，“我们不知道如何排定优先级或者是否可以拒绝某些工作。但我想我们可以把这些工作先说出来。”
“好吧，JIRA中没有记录这些工作。”Beth说道，“如果大家在干的工作没有记录到JIRA中，那么我们就不能相信JIRA里的信息。”
“那么你们该怎么做呢？”Joakim继续问道。
“好吧，我猜如果我们能确保每一项工作都能记录到JIRA中，这个问题就解决了，对吗？”Beth说道，“这样所有的工作就都记录在一个地方，而且也能容易的跟其他人共享这些信息，特别是那些没能跟我们坐在一起的团队。”
“没错。”Joakim说道，“那么使用电子工具有什么缺点吗？”
“撇开我的立场来说，没有。”Eric快速说道。
“嗯，在使用JIRA过程中，我们经常会不知所措。”Beth说道，“我们不止一次地发现，比如，同样的工作由两个人在进行。为了发现这些问题，我们要进行大量的查询。”
“我们该怎么做才能便于我们进行类似的查询呢？”Joakim问道。
“嗯，”Beth继续说道，“我猜我们需要能容易的看到这一切，比如贴在墙上或者别的地方。”
“答对了！”Marcus再也掩饰不住兴奋之情。“把工作贴在墙上！每一项你们在进行的工作，写在即时贴上然后贴在墙上，仅仅这一件小事带给你们工作的变化都会令你们吃惊不已。”根据经验而言，Marcus知道这其实是一件大事，特别是对于很多刚开始敏捷开发的组织而言。
为了在实践中体会这种变化，Marcus建议大家为每个工作项立刻创建一张即时贴，然后贴在白板上。
“每个人都写完了吗？”过了一两分钟后Marcus问道。
之前贴了6张卡片，对应于JIRA中的工作记录，紧挨着这6张卡片，大家又贴了八张新卡片。
“天啊！”Frank大叫道，“这是真的吗？”
“我们早就告诉过你！”Daphne一边说着，一边把双手完全张开，“看看这边，我们接受了太多的工作。”
“我知道，但我从来没有意识到……”Cesar挠着头说，“兄弟们，这段时间对于你们肯定是一段充满压力的糟糕经历。”
“这确实比JIRA中的工作多多了。”Beth一边说着，一边数着即时贴的数目。
“这就是我们一直在说的问题。”Eric再一次调高声调 说道。
大家陷入了沉默，紧紧盯着白板。通过为每一个实际工作创建即时贴，他们用一种实际的方式把正在干的工作显示出来。团队有一种大开眼界的感觉，而Joakim和Marcus已经无数次见证过这种经历。
“这就是你们从电子工具JIRA中挑选的信息，而我们一般称电子工具为‘信息冰箱’，就如同Joakim喜欢这么叫。”Marcus一边看着Joakim，一边说道。Marcus停下来等着Joakim来解释这个隐喻。
Joakim接过这个话题继续解释道：“通过一张大白板进行可视化，可以称为信息辐射源。这种信息呈现是很明显的，并且当人们经过时就可以清楚的看到。而电子工具，我认为，有些时候更像信息冰箱，你必须要打开它到处找寻想要的信息。”他不太确定是否每个人都听到了他的话，因为整个团队站在他面前还在盯着白板上的这堆即时贴。
“让我们来看看你们刚刚提到的挑战。”Marcus插话道，“至少我们已经开始解决其中的一个挑战——谁在干什么和整个团队都在干什么工作，而且我们还简单介绍了优先级处理。”
Beth看着白板上的即时贴，过了一分钟后，她说：“那接下来对于这堆即时贴该干什么呢？”
“是啊，把它们贴到墙上并不能帮助我们完成更多工作并让项目干系人感到满意，对吗？”Daphne补充道。
“嗯，这些即时贴告诉你们，有很多工作在进行中。”Joakim开始说道，“但通过可视化你们的工作，你们能够看到更多信息，比如让每个人都看到所有工作项的进展以及相应的优先级。这将进一步提高工作透明度，并且在面临新工作时，也能帮助你们排定优先级。”他一边说着，一边用手指了指挑战列表。“让我们尝试着把你们的工作流程映射到白板上，然后把即时贴放到正确的位置。”Joakim摘掉白板笔笔帽，准备开始了。
“现在是要把什么映射到什么？”Beth问道。
“哦，工作项在流经你们的系统时，是从一个创意或者客户需求开始，到最终产品特性上线，为客户提供价值是这样吗？”Joakim问道。
“是的，我猜是这样的。”有些人在喃喃自语。
“那工作的起点是哪里呢？”Joakim问道。
“嗯——这很难说。”Frank说道，“这取决于你把线画在哪里。是想法形成的时候，还是我们决定去做的时候，或是得到批准去做的时候？但是我觉得有一点很明确，就是我们要把所有工作记录到JIRA中去，也就是我们的问题处理系统。”
“但是，”Cesar插话道，“在这之前，Beth和我做了大量工作，不是吗？”
“是的。”Beth回答道，“但那有点杂乱无章，因为在我们决定把什么记录到JIRA之前，需要来来回回讨论很多次。有时候它是一个宏大的创意，有时候它只是一个简单的补丁。”
最终大家决定整个工作流程的起点是工作被记录到JIRA时，终点是生产系统上线。
“我不太明白为什么不从头到尾跟踪它们的进展呢？”Daphne说道。
“那好，我们把工作流程的环节在白板上划为不同的列。”Joakim准备开始在白板上画了，但是他突然停下来了。他之前已经试过很多次为团队绘制白板，也知道最终这个白板会沦为他自己的工具而不是整个团队的。幸运的是，这个问题有个简单的解决办法。“还是由你画会更好。”Joakim把白板笔递给Beth。
“为了标示某些工作处于特定的阶段，我们会把即时贴放入对应名字的列中。”Marcus解释道。
“但这些名字或者阶段是什么呢？”Beth看上去有些困惑，因为Joakim没有写下任何名字。
“是的，这就是你们自己需要解决的。”Joakim笑着说道，“我们不能替你们做所有的事。在JIRA中，那些没有完成的工作，你们用什么状态描述？”
“哦，我不清楚，也许是‘未完成’（Undone）。”Frank说道，周围有些人笑了起来。
“用‘输入’（Inbox）来描述怎么样？”Cesar建议道。
“我不知道。”Eric说道，“这让我立刻想到了邮箱，但我痛恨电子邮件。我们能否尝试一下其他的词？”
“‘待办’（Todo）怎么样？”Daphne建议道，“也许这太简单了。”
似乎没人介意，于是Joakim说道，“这是一个好的开始！请记住，我们希望这些名字简单易懂。如果日后你们觉得需要更改，那么到时候就去更改好了。”
“实际上，”Marcus一边说，一边伸出一根指头，“我们建议大家用白板笔在白板上绘制。千万不要做成永久不变的，不要过早地使用胶带和其他东西绘制列，因为那可能使你不愿意去改变。而随着你学习的深入，改变是不可避免的。”
在Marcus说的同时，Beth在白板的最左边画下了一列。她把“待办”写在这一列的最上方。
Joakim说道：“那好，所有那些还没开始的工作对应的即时贴——把它们挪到这一列里面吧。”
于是大家走上前，开始在白板上移动即时贴。在移动的过程中，有一些讨论和问题，主要是关于到底哪些工作项居于这一列，但很快就有三个即时贴被放入了“待办”这一列中。
“好吧。”当大家围在白板前讨论时，Joakim把大家召集过来继续说道，“我们把工作按照优先级从上到下排列起来，让团队之外的人也能容易地看出来。这样做还有一个好处，你能很容易地分辨出每一列中最重要的工作。”
“那接下来你们怎么进行这些工作呢？”Marcus问道，“你们第一件事情一般做什么？”
“我们通常会坐下来讨论设计。如何构建系统？我们能够从已有的平台使用什么组件？我们是否应该使用其他团队的组件来构建新的方案？诸如此类的讨论。”Frank说道。
“基于我们讨论的结果也会形成一些文档。”Beth补充道。
“那这个阶段我们称为什么呢？”Joakim问道。
“我们用‘设计’（Design）作为这个阶段的名字如何？”Cesar问道。
“嗯，可能不太好。其实这个阶段我们还做了大量其他的工作。也许用‘分析’（Analyze）作为名字更好？你们觉得呢？”Frank向Marcus问道。
“我不知道，工作流程是你们的，你应该问问整个团队。大家觉得怎么样？”Marcus向整个团队问道。
“是的——Analyze好一点。”Daphne说道，其他人也一致点头说道。
“那你们现在有什么工作是处在这个阶段呢？”Marcus问道。整个团队讨论后一致同意把两个工作项放到这一列中。
“好了，继续按照你们的工作流分析，一直到‘发布生产环境’（In Production）阶段吧。”Joakim想到了精益词汇，就把它们串了起来，听起来像是一首诗。Joakim快速环顾了一下四周，确认只有他自己沉溺于这种想法中，于是轻轻咳嗽了一下继续说道：“那么，再之后是什么工作呢？”
整个团队继续创建了“开发”（Development）和“测试”（Testing）两列，并把相应的即时贴移动到这两列中。之后，大家开始讨论“已完成”（Done）到底是什么意思。他们决定在工作流中为验收工作加入一步。最终他们把这一列的名字定为“验收”（Accept）。在别人问到时，Adam也意识到三个放入“测试”中的工作项其实早就已经测试完毕，在等着Cesar进行验收批准。于是大家决定把那三个即时贴也移动到“验收”这一列中，同时“验收”列中已经有一个即时贴了。
Adam走上前去，把那三个即时贴从“测试”移到“验收”那一列。
“接下来呢？”Joakim问道。“你们的工作在分析、开发、测试和验收之后，还需要做什么？”
“哦，老兄，我们应该把它们上线。”Eric说道。
“你说‘我们’，你的意思是？”Daphne提示道。
“Ops。”Eric耸耸肩，叹息了一声。
“那是什么意思？”Marcus问道。
“哦，是运维人员。”Frank曾经跟他们打过交道，解释道。“我们公司的运维部门外包给了另外一家公司，这增加了我们产品的上线发布时间。”
“他们做的第一件事情就是回收了我们访问生产服务器的权限。”Daphne小声抱怨着。
“我把这个理解为你们在上线发布之前需要等待一段时间，然后呢？”Joakim问道。
“是的，他们一年部署6次，而且他们不愿意改变他们的做法。”Eric失望地说道。
“那我们增加一列‘等待运维发布’（Waiting for Ops）吧，或者类似的名字。”Adam说道。“是的，我们先这么写吧。”Frank说道。
“但是也可以叫作‘已完成’（Done）或者‘超出控制范围’（Out of Our Hands），你们觉得呢？”Frank说道。
“为什么？”Marcus问道。
“这只是运维团队的工作，而且我们完全无能为力。”Daphne说道。
Frank接着说道：“是的，我们做不了什么。”
Joakim和Marcus交换了一下眼神，以确定“由你来还是我来”。显然，这次轮到Joakim了。Joakim问道：“你们的客户是谁？”
“你说的‘客户’是什么意思？”Frank接道。
“比如，谁对你们的工作成果感兴趣，或者你们完成的功能特性是为了谁。”。Joakim解释道。
“哦，就是那些书写系统需求的项目干系人吧。”Frank说道。
“真的吗？”Joakim追问道。
“嗯……那你重新定义一下‘客户’是什么意思。”Beth若有所思地说道。
当整个团队对于“谁是客户”这个问题进行了充分的思考之后，大家很快达成了一致并牢记于心：电子银行的用户是最重要的客户。
“‘已完成’对于他们而言意味着他们能够使用产品的功能，”Cesar说道。
“那么‘等待运维发布’这一列怎么样呢？”Joakim问道，“这会使最终用户高兴吗？”
“不，当然不，”Beth说道，“但这显然是目前的工作流程，那我们又能做些什么呢？”
“如果我们要把所有处于‘等待运维发布’的工作项贴出来，到底有多少呢？”Joakim对着整个团队问题。
“太多了，足够装一大卡车。”Eric抢在其他人之前说道。
“是的，有很多。上一个版本——”Frank停下来想了一会儿，“我想最近的发布是本周三。我猜应该有25～40个。”
“在项目处于‘等待运维发布’状态时，对于客户有什么好处呢？”Marcus一边看着Cesar，一边指着这一列问道。
“没有任何好处——我们期望将这些工作项移出这一列。”Cesar说道，“但是就如Beth说的，它完全脱离了我们的控制。”
“你能改变这一现状吗？”Joakim问道。
“不太容易。”Cesar叹息道。“他们拥有不同的预算，在不同的部门，甚至在另外一个办公场所，我的天哪。”
Daphne走上白板说道：“一旦我们有‘等待运维发布’这一列并把即时贴移进去，那么运维人员是唯一能完成这些事情的人员，但至少我们可以开始关注并讨论这个问题，不是吗？”
“是的，这可比只说‘认倒霉吧’强多了。”Frank一边说着，一边看着Eric，直把Eric被看得低下头看着桌子。
“我们甚至可以帮助他们做些简单的事情。”Daphne发现这是一个要回服务器管理员权限的好机会。
“是的，这至少值得一试。”Cesar回应道。
“太棒了，兄弟们。”Marcus说道，“当把工作中的痛点展示出来，并开始收集相关数据作为证据支持，这样就很容易获得项目干系人和其他团队的理解。毕竟这不是你的唠叨，而是确凿的事实。”Eric点头同意，看起来松了一口气。
“这是可视化之所以如此重要的另外一个绝佳的例子。”Marcus趁机插话道，“这些问题早就存在了，你们只是没有意识到。通过这个简单的可视化技巧，为每一个工作项创建一个即时贴，并将其贴在相应的列中，大家就能立刻看到工作流程中的问题。”
“是的——虽然我习惯称之为‘未意识到的改进机会’。”Joakim说道，冲Marcus笑了笑。“这是一件重要的事情。看板能够告诉大家很多事情，比如工作项移动缓慢，或者被卡在哪了，还有工作项没人负责处理等，这些都是看板能够提供的信息。通过这些改进机会，大家可以尝试改变工作的方式。大家一定要抓住这些机会，比如，跟运维人员讨论我们能做些什么来改变现状，很有可能他们之前根本不知道这对于大家是个问题。”Joakim意识到自己有些兴奋，所以在试着让自己慢慢冷静下来。
“我相信会的。”Cesar轻声说道。他也对目前取得的进展感到很高兴。
“好，在‘等待运维发布’之后是什么工作？”
“哦，那流程就结束了。”Adam说道，“我们的工作已经上线，可能会发现bug，但我们会把bug记录到JIRA里面，所以在白板上就应该在‘待办’这一列，对吗？”
“这是你们的工作流程，既然你这么说那就是这样的。”Joakim说道，“我们只需要加入最后一列，名字为‘已完成’或其他名字？”
“我们为什么需要‘已完成’这一列呢？”Daphne问道。
“为什么不呢？”Eric回答道。“我们想证明我们很棒，不是吗？”
Marcus表示同意说：“当然是的，所以我们就要想尽一切办法来证明。”他稍微停了一下，说：“我们把这些完成的工作展示在白板上，这样做是很好的办法。”
“是的。”Adam明白了Marcus的意思。“但为什么是‘已完成’呢？我说过有可能发现bug。用‘发布生产环境’（In Production）怎么样？我觉得这个名字表达得更加准确。”
团队的其他成员都认为这个名字更好，而且暂时没有即时贴放入“发布生产环境”这一列。
“我们再来看一下现在的白板——这就是你们现在的工作流程，对吗？”Joakim问道。“你们是否觉得现在比之前在电子系统中，更能够清楚地看到每个工作项的进展和状态？”同时Joakim又打开那张写满问题的白板纸。
“那么工作的优先级呢？这也是你们提到一项挑战。”Joakim一边说道，一边指着白板纸。“比如，当你们把工作按照优先级排列在每一列之后，是不是就很容易看到工作的优先级了？”
整个团队对着白板看了一会儿。Frank提到感觉这有些简化，而且如果不是大家一起尝试过，是无法知道这个方法有用与否的。
“那好吧。”Marcus说道，“有两件事情需要强调一下。第一，这还没完，这只是到目前为止最好的产出。这个白板和我们讨论的其他所有内容，日后都可能发生变化。在我们进行中，我们会持续不断地改进。”他停顿了一下，在谈到关于检视—适应—持续改进的好处时，他试图避免进入说教的模式。
“第二，接下来我们讨论一下你们提到的不同类型的工作，换句话说——白板上贴的是些什么类型的工作？”
“现在我们在白板上贴了很多即时贴，每一个都代表一个工作项。”Marcus说道，“每一个都有一个简短的标题描述这是什么工作。”
“每个工作项的状态通过其所在的列能够清楚地显示出来。”Joakim补充道，同时他用手示意着，从白板的左边向右边扫过每一列。
“这些信息对于你们和所有的项目干系人理解你们目前的工作，够了吗？”Marcus问道。
“哦，这些标题有时候太简短了。”Beth说道。
“你的意思是？”Marcus追问道。
“我想说的是其中有一些只能被负责的开发人员看懂。”
“也许你希望在代表工作项的即时贴上写一个简短的标题，既不要冗长，同时也不能太短以致无法记住这到底代表什么工作。”Marcus建议道。
“就像一个用户故事？”Beth笑着说。
“是的，你可以这么做。”Joakim回答道，“但你不是必须这么做。任何简短的描述都可以，只要能够提醒你这是什么工作就行。如果不用靠近白板仔细阅读就可以清楚地知道是什么工作，那就够好了。这个描述应该是明显易读的，只要眼一扫过，就可以把不同的工作项区分开。”Joakim在白板上画了一个大方块，然后在中间写上“描述”（Description）。
“这样做就可以了吗？”Marcus问道。
“不一定，有时候我想要知道JIRA的记录ID。”Eric很喜欢这个工具，从他的声音中就听出来了。
“为什么呢？”Joakim问道，一方面是因为他对JIRA并没有很深的印象，一方面是他觉得Eric可能有特别的原因。
“如果我们只有这样一个简短的描述，我们就需要引用回查JIRA，以便我们查看JIRA中的其他信息。有时候，那里有大量有用的信息。比如，深入的讨论、图片或者其他的信息。”Eric解释道。
“太棒了！”Joakim把JIRA的ID号写在方块的左上角。“还需要其他信息吗？”他问道。
“完成期限！”Frank站起身，几乎尖叫出来。
“是的，这看起来对你很重要？”Marcus问道，他看着整个团队，可是大家鸦雀无声。过了一会儿，Cesar打破沉默。“是的，这对我们很重要，但并非我们的每个工作项都有这个期限，那我们该怎么办呢？”他把这个问题抛向Joakim。
“大家觉得呢？”Joakim又把问题抛给了整个团队。
“我们在有完成期限的卡片上写下这个信息，就这么简单，不是吗？”Eric说道。
“是的，不过我们希望突出这个信息，以免我们忽视了。”Frank像是在自言自语。
“那我们用不同的颜色来突出一下如何？”Beth建议道。
“真是个好主意！”Joakim走上前，在方框的右上角写上完成期限。
“另外一个有用的小技巧就是总是在即时贴的同样位置写同样的信息，这样很容易形成一种关联。如果有完成期限，就写在卡片的右上角。”
“太棒了！”Marcus说道。
“不过还有其他有用的信息应该被写在卡片上，”Joakim说道，“大家猜一猜？”
这次没有人回答。
“那大家是怎么知道谁在进行哪项工作呢？”Joakim提示道。
在JIRA系统中，这个信息很明显，不过大家很快意识到需要把这个信息也加入到白板上。最初的建议是把名字直接写上去，但那样会占用即时贴的空间，而且有时候需要写很多名字，这使得即时贴上的信息很难读。
“一个简单的方法是用某种标记附着在工作项上，一块写有名字的磁铁或者其他的标记。”Beth说道。
“是的，一个简单又普遍的方法是创建一种称为‘头像’的标记，放在正在进行的工作项上。”Marcus解释道。
“一个头像？就像一个骑着飞马的忧郁王子？这有什么用呢？”Daphne看起来很吃惊。
“不，不是那种头像。”Marcus笑着说道。“一个小图片，或者代表你的某种占位符。就像你自己的图片，或者看起来像你的卡通形象，或者你随心所欲选择的头像。”
“卡通？但我们看起来一点也不像！”Frank反对道。
“使用某种看起来像你的头像，或者确保把名字加上。这样就能很容易在头像和你自己之间建立连接。”Joakim说道，他依然对上次使用狗作为头像的事情记忆犹新，大家当时根本无法把头像和人联系起来。Joakim开始在白板上描绘头像的草图，他的绘画技巧一般，引得大家咯咯直笑。
“你知道什么信息有用吗？”当Joakim画完草图后，Adam问道。“如果能知道这是一个bug还是不是会很有用。”
“为什么呢？”Joakim问道。
Adam解释说，bug一般比其他工作具有更高的优先级，而且在工作流程中可能不需要Analyze阶段。他们也希望跟踪bug是从哪条JIRA记录产生的。经过一阵讨论，团队决定使用其他颜色的即时贴来标明这是一个bug，大家决定使用红色即时贴来代表bug，而不是普通的黄色即时贴（这在看板社区是一个普遍的使用模式）。
“这太棒了！”Beth说道，她一直以为自己是一个善于隐藏自己想法的人，但这次她被深深地迷住了。“这样的话，即便从远处也很容易识别出bug的即时贴。”Joakim在一张红色即时贴上写下bug，又在一张黄色即时贴上写下“常规工作”（Normal），然后把它们一起贴在白板的一侧。
“大家快过来，看看白板上的即时贴是否需要换一下颜色。”他一边说着，一边把红色即时贴递给大家。
大家针对一些工作项展开了讨论，但对大部分工作项他们能快速地识别其工作类型。一会儿的工夫，他们就完成了。退后几步，他们凝视着白板。
“现在我们可以从白板上看到更多信息了。”Marcus说道，“而且，白板上一旦被红色即时贴充满，那就说明我们需要坐下来进行一次关于质量的严肃讨论了，不是吗？白板开始跟我们对话了，向我们发出信息，关于我们工作情况的信息。现在大家是否明白我们之前说的信息辐射源的意思了呢？”
大家都点了点头。从这里很容易看到可视化的威力，一些简单的措施，比如更改即时贴的颜色，就能帮助重要的信息凸显出来，像这种卡片代表的工作类型。
“太棒了！”Marcus鼓起掌来。“我们现在的白板上描述了整个工作流，而且还有一个简单的模板用来描述不同的工作项。下面让我们看看这些工作项如何在白板上移动，以及从中能有什么收获。”
“大家还记得我们从哪里开始这段可视化之旅吗？”Joakim打断道，“我们希望这个白板和白板上所有的东西向我们发出信息。这些信息能够告诉我们工作进展如何，以便我们能从中有所学习收获。真正的收获不是仅仅看到每个工作项的进展，虽然这很棒，但真正的收获是在学习如何使用的过程中帮助我们做出决定并进行改进。现在只是开始，而且永远不会结束。”
“这就是看板基本原则之一：工作可视化。”Marcus插话道。
“是的，根本的原因是如果你不能看到，你就不能改进。大家觉得呢？”Joakim问道。
注意
你无法对自己没有看到的进行改进。
大家都点点头，好像达成了一致。“完全同意。”Cesar说道，“我们已经知道了这样做的价值。但接下来我们该做什么呢？”
“我们再检查一遍之前提到的挑战。”Marcus建议道。“让我们看看能做些什么来解决大家感觉忙得不可开交的问题，怎么样？”
“这就把我们带到看板的另外一个重要原则，限制在制品。”Joakim开始介绍到，“也就是说，努力做到只有很少的工作在同时进行。”
他还没说完，Adam就怀疑的说道：“为什么？难道我不是该做尽可能多的工作吗？刚刚我们已经把正在进行的工作展示出来了，除了尽快完成这些工作，我们别无他法。”
“对此我一点都不怀疑，不过我认为大家可以做得更好。”Joakim说道。他脸上浮现出一种神秘的微笑。他看看Marcus，眨眨眼，说道：“我想我们需要一些便士。”同时，他拉过一张桌子和四把椅子。
“好的。”Marcus拿出一个小钱包。然后他把钱包里的硬币全都倒出来，将20个硬币在桌子的一边堆起来。
他转向Cesar问道：“我们还有多少时间？”
“我们已经讨论了45分钟，还有1小时零15分钟，请继续吧。”Cesar呆板地回答道，他想知道这些硬币到底有什么用。
“你们中4个人请围着桌子坐下来，”Joakim邀请大家坐下，“其他人分别选择一个坐下的同事站在其身后，并掏出手机打开计时器。Marcus和我会填补到剩余两个站着的空位。”
然后他向大家解释了游戏的目标。每个人要把所有硬币翻一遍，然后传递给下一个人。当所有人都翻过所有硬币之后，他们就完成了工作，并交付给了客户。解释到这里，大家似乎都能理解这个游戏要做什么了。
“站在‘工人’背后的人，”Joakim故意强调了“工人”这个词，“是负责给工人计时的经理，他们会记录每一项工作花多长时间。当你前面的工人开始工作时计时，当他完成工作时停止计时。明白了吗？你们是要为一个工人全部的工作时间计时。”
“最后，我们希望测量整个前置时间，这是指从工作开始到整个工作流结束的时间。”Joakim说道，“我来作为客户，为整个工作流计时。我会记录两个时间，一个是第一枚硬币到达我这里的时间，一个是所有20枚硬币到达我这里的时间。”
经过快速思考后，Daphne说道，“但是这样的工作方式，第一个硬币和最后一个硬币是同时到达的。”
“是的，这没错。”Marcus回答道，“至少在第一轮是这样的。在后面几轮，我们会看到变化。”
Marcus在介绍完这个游戏后总结道，“我们会玩三轮这个游戏，第一轮的规则是每个工人需要把所有20枚硬币翻完后传递给下一个工人。大家明白了吗？”
“大家准备好了吗？计时人员，记录你前面工人的工作时间。”Joakim又强调了一遍。“准备，开始！”
当Adam像个疯了一样翻硬币的时候，大家陷入了紧张的沉静之中。他把硬币交给Beth，然后回头对着背后的“经理”Frank说道：“我完成了，快停止计时！”
Beth也全神贯注地开始翻硬币，然后把硬币交给Cesar。Cesar在翻硬币的时候摒住了呼吸，直到把硬币交给Daphne才喘了一口大气。Daphne想要同时用两只手翻两枚硬币，但却更慢了。其他人抱怨道：“加油，Daphne——千万不要让我们失望！”
最终Daphne完成了，并把硬币交给Joakim，同时Joakim停止了计时器。在一张白板纸上，Marcus画了一个表格并把结果记录下来。
Joakim跟每一位“经理”询问了每个工人的工作时间。在把这些时间加起来之后，他转过头对大家说道：“就像Daphne预计的一样，第一枚硬币和最后一枚是同时到达客户这里的。”
“现在我们尝试着每次翻5枚硬币。”Marcus跟大家说道，“这意味着——每一批翻完5枚硬币就可以传递给下一个工人，然后再接着翻下一批5枚硬币，一直到全部翻完。这个规则明白了吗？”
工人们点点头，又开始集中精神到硬币上了。
“各位经理，请记住对各自工人翻硬币的全部时间进行计时。当第一枚硬币到达并开始翻时计时，当最后一枚硬币翻完传递给下一个工人时停止计时。”
“嗯——我想我知道这是怎么回事了。”Frank自言自语道。
“时不我待哦，”Joakim打断道，“准备，开始。”
这次硬币的声响很大，但大家还是全神贯注并保持安静。当Adam翻完他的最后一枚硬币后，他开始为其他人加油打气。“快！加把劲儿，Cesar！”
很快这一轮就全部结束了，大家把计时的结果记录到白板纸上。
“什么？这好像不太对，”Cesar看到结果后大叫道，“你们确认计时结果是对的吗？”他问道。他先看了看Marcus，然后又转向Joakim。
“我确认这个结果是正确的。在我们仔细讨论之前，我们需要再完成一轮。”Marcus回答道。“这次我们每一批次就翻一个硬币。就是每翻完一个硬币就传递给下一个人。明白了吗，工人们？”
“像刚才一样，各位经理，为你的工人的全部工作时间进行计时。准备，开始！”
大家立刻沉静了下来，除了硬币在传递过程中碰到桌子的声音，听不到其他任何声音。这一轮大家很快就完成了。Joakim把每个工人的工作时间收集上来，并在白板纸上也写下最终的加和结果。
“我简直不敢相信！”Frank非常怀疑地说道，就如同被欺骗了一样。“这到底是怎么回事儿？”其他人看上去对这个结果也感到很吃惊。
“这个结果没有问题，好了，下面我们来看看从中我们能够学到什么东西。”Joakim说道。
“首先，我们看一下第一枚硬币到达客户手中的时间。当我们把每一批翻的硬币数目减少后，有什么变化呢？”Marcus一边小心地为自己的提问措辞，一边指着白板纸上记录的结果。
“这个时间一直在下降，从50秒到4秒，这太神奇了！”Frank摇着头表示这真难以置信。
“那么总的完成时间呢？”
“当然，完成时间也下降了。”Daphne说道，但对这个结果不够印象深刻。
“但是，和首次交付时间的变化相比，这个变化不是那么引人注目。”Frank还是无法相信那个结果，他不停地看了又看。
“现在，看看每个工人的工作时间。”Joakim说完，又给了大家几秒钟思考时间。
“整体的趋势是怎么样的呢？不要特指某一个工人。”他干咳了一声，又对Daphne使了个眼色。Daphne立刻会意了这个玩笑，挥了挥手。
“哦，很奇怪的是，这些时间都在增加，这是怎么回事？”Cesar看着Marcus和Joakim，希望从他们那里得到答案。
“我们通过这个练习向大家证明了一点，当大家减少并行或者同时开展的工作时，前置时间也减少了。”Marcus解释道。“首先我们完成的总工作量并没有变，只是改变了工作方式——通过减少每一次批量工作的规模，使得同时进行的工作也减少了。”
“或者我们将它称为在制品，你们会经常听到看板社区的人们使用这个术语。”Joakim补充道。
注意
在制品（WIP）是同时进行中的工作数量。减少在制品使其快速流过整个工作流，即前置时间缩短。
“如果没有这种奇怪的三个字母形成的缩写，那么就很难称之为一个社区，不是吗？”Marcus说道，同时大笑了起来。
“就如同大家已经看到的，限制在制品对总完成时间产生了戏剧性效果，在这个例子中从最初的50秒下降到20秒。”Joakim指着白板说道，“同时还有另外一个效果。当我们以20枚硬币为批量规模工作时，第一枚硬币和最后一枚硬币同时交付。当我们以较少的硬币为批量规模时，我们在4秒后就交付了第一枚硬币，这连第一轮的十分之一都不到。”
“小批量，”Marcus用手臂摆出一个收缩动作，“较少的在制品，会给你更快的速度并使你更加敏捷，因为你总是可以优先交付小的重要的工作。大家明白这是个优势的原因了吗？”
“不仅如此，”Marcus继续道，“一旦我们翻硬币时犯了错误会怎么样呢？如果客户希望硬币沿其边缘立着翻转——对于不同的批量规模会有什么不同呢？”
因为“直到我们所有人都完成之前，我们没有交付，所以我们将不得不全部重新来过。”Daphne说道，“在第一轮中是这样的。”
“最后，我们不再关注是否每个工人的工作都是最有效率的。”Joakim说道，这是给Cesar的建议，“在第一轮中，在最后一个工人工作之前，有大量的等待时间，但每个工人都竭尽所能的完成整个批次，然后才交给下一个工人。另外，在最后一轮中，前置时间是最短的，但每个工人的工作时间都延长了，从个人来看工作效率下降了，但整个团队的效率最高。”
注意
优化工作流程以获得快速流动可能会导致资源利用效率的降低。
“我也不愿意扫你的兴，但是，”Adam靠在椅子上，双手在胸前交叉。他长舒一口气，“我们的工作，‘现实’是，比这个复杂多了。我希望你们能够意识到这一点。”Adam听起来有些疲惫。
“你的意思是？请解释一下。”Marcus试图展开一场讨论。
“首先，工作项不是像这样持续到来的，他们可能在我们之间来来回回多次。例如，我做一点测试，然后做一点编码，再之后又是测试，甚至有可能是需求变更。”
“第二，我们的工作项的大小各有不同，而游戏中的硬币大小和工作完全一样。”
“这一点很棒。”Joakim打断道，因为他看到Cesar在看时间。“你说的对，这个游戏是一个简化的模拟，用于展示一个基本原则：在制品越少，前置时间越短。现实工作中，有很多其他的影响因素，必须进行权衡，但这个基本原则仍然有效。”
“缩短前置时间和限制在制品还有很多其他好处，但现在我们没有时间进行讨论了。”Marcus试图结束讨论，总结陈词道，“这个游戏只是让大家拓展一下思路，不过目前最重要的是大家如何理解这个原则。现在大家围绕在白板周围，看看如何在工作中实际运用，并展现在白板上。”
他们又走到白板前面。
“我们的便士在哪里呢？”Adam夸张地说道，表明他还没有完全相信这个结果——至少目前还没有。
“在白板上，什么是便士硬币呢？”Joakim问大家，故意忽略了Adam的说法。
“就是这些即时贴吧。”Beth说道。
“他们怎么样呢？从游戏中你们学到了什么呢？”Marcus问道。
“好吧，让我们看看我的理解是否正确。”Frank开始说道，“如果我们希望这些工作在白板上快速流动，我们应该同时开展较少的工作。比如说，从20个硬币下降到5个。”他一边说，一边看着Joakim和Marcus。
“大家都同意这个说法吗？”Joakim回看着整个团队。他们看起来好像都同意了。
“但是我们在实践中怎么做呢？”Eric想要知道这个答案，“我们需要做什么改变呢？”
“嗯，如果我们都认为这是一个好主意，”Daphne回答道，他朝着Adam瞥了一眼，“那就足够了，对吗？我们都认为应该减少同时开展的工作。”
“是的，你们都同意要停止启动并聚焦完成。”Joakim对着白板沉思道，他号召着大家因为他太喜欢这个口号了，但是大家迷茫的眼神告诉他他需要详细解释一下。“与其开展一个新的工作，大家可以帮助团队中的其他人先完成已经开展的工作。”
“而且与其让你的工作处于被阻塞的状态，”Marcus补充道，“例如，等待外部的信息或者其他人的评审，你可以尝试着解决这个问题或者努力避免日后再次发生类似的问题。这些都是我们之前谈到的没有意识到的改进机会，对吗？”
“这个理论听起来很棒，”Eric说道，“但是在实际中，帮助别人完成工作并不容易。我的意思是说，我不希望打扰Daphne，让她给我解释她目前的工作以及我可以提供什么帮助。难道让她自己独立完成不是更好吗？”
“当然，有时候你会有这种感觉，特别是在刚刚开始这么做的时候。但你还是需要从某个地方开始这个改变，所以需要你自己判断最合适的时机。”Joakim解释道，“根据我们的经验，经常是开始新工作的时候遇到的阻力最少，所以我们必须有意识地设计工作使得彼此之间容易相互帮助完成工作。”
“这就引出了限制在制品的下一步工作，”Marcus故意打断道，他担心Joakim会扯太多题外话，“就是使用可视化技术把这些限制明确出来。我们需要选择一个最大值来限制能同时开展的工作数量。”
“这个限制将帮助我们将焦点放在工作的完成和帮助工作快速流动上。”Joakim又回到了主题。“限制在制品能够帮你应对最开始提出的一些挑战。首先，工作将开始流动，因此你不用时时监视大家的工作。”
Joakim走上前，指着白板纸说道：“当工作在整个系统中以稳定的速度进行时，根据我们的经验，准确地评估和预测就不再需要了。第二，你不会再有被工作淹没的感觉，因为现在已经有了你能同时开展工作的上限。如果谁希望增加一个新的工作进来，他还需要决定把某项工作替换掉。”
Joakim一边说着，一边在白板纸上打了几个点。
“这样的话，”Marcus插话道，他脸上洋溢着笑容，“反过来倒便于我们进行优先级排序。开展的工作项数目减少了，而且你现在有信息进行展示和思考，所以就容易进行优先级设定了。大家现在就可以做，就在白板上开始吧。”
“但我们怎么知道应该使用什么数字作为限制呢？”Beth说道。
“具体问题具体分析。”Marcus回答道，但是他马上意识到这是每个咨询师的标准答案，于是迅速尝试说一些更有针对性的建议。“通常，限制越低越好，但是有时候限制太低了也会有不良影响。想想看，如果大家都工作在一项工作中会是什么场景？这将有利于工作的流动性，一旦能够进入开发阶段，就会有开发人员领取这个开发任务并开始开发工作，而且当开发完成时，Adam也早已准备就绪开始测试了，但这个场景有什么问题吗？”
片刻之后，Frank打破了沉默。“在种情况下，看起来好像有很多等待，对吗？还是我漏掉了什么？”
“是的，你说得非常对。”Marcus给Frank竖起了大拇指。“在制品规模过低导致大量闲置，这对降低前置时间虽然有好处，但大多数公司可能不会愿意给无所事事的人员支付薪水。”
“你需要在这两者之间进行平衡：快速流动和每个人都有工作。你希望设置一个较低的在制品规模进行限制，但也许不应该是‘1’那么低。”Joakim总结道。
“但这依然没有解决我们的问题，我们应该设置的限制到底是多少呢？”Daphne说道。
“对不起，这一点我们也不知道。”Joakim耸耸肩，“这件事你们需要自己决定并且不断调整以便于达到持续向好的趋势和更快速的流动。”
“改变并行工作的限量。好的，我们懂了，但从什么开始变，变成什么呢？”Frank失去耐心了，“你总要告诉我们吧。”
“从最简单的开始。”Joakim说道。“从每人一个工作项开始，很快你就会发现某些地方堆积了一串问题。例如，开发人员无法持续下去。”
“你这到底是什么意思呢？”Daphne半开玩笑地说道，语气里也透露着不满。她的工作效率很快，她对此毫不怀疑。
“有些任务总是比其他工作需要更长的时间才能完成。”Joakim说道，“工作流到底在哪里减速或者停止，这不是重要的，重要的是你打算怎么解决它。”
“举个例子，”Marcus把白板上的即时贴清除干净，“我们合理地假设同时有2个工作项进入开发是合理的数量，因为我们有两个开发人员，对吗？”他跟Daphne确认道。
“当然。”她回答道，防御性的心态开始发挥作用，她非常谨慎，不知道会将讨论引向何方。
Marcus在白板的“开发”那一列上面写下数字2。
“我们已经有2个工作项在这里了。现在分析人员又准备好了新的工作，期望把这些新工作推到开发阶段，但这会打破我们设定的2个工作项的限制，对吗？”Marcus在白板上画了一个箭头，然后又打上了一个问号。
“我们现在该怎么做呢？”Joakim问道。
Frank急不可待地分享他的看法：“那就把新工作放进去吧，反正他们早晚都会被放进去。”
“其他人觉得‘把新工作直接放进去’，是个好点子吗？”Marcus问道。
“当然不！”Daphne反驳道，“这不同于我们从传递便士游戏中获得的启发啊，我们不是应该确保同时进行的工作是最少的吗？”
“是的——那么我们应该怎么做呢？”
“替换掉其他工作，如果新进来的工作确实很重要的话。”Eric建议道。
“什么也不做？等待？或者放慢工作的节奏？”Beth看着这个场景，却不知道该怎么抉择。
“大家看到了吗？我们正在进行一个讨论。”Joakim说道。“这就是在制品规模限制的意义所在：触发讨论。特别是关于改进工作流程的讨论，即限制在制品的规模以便于工作项的更快流动。这种讨论可以是某种具体措施的讨论，比如如何避免引入更多的工作到流程中。有时候这需要一个开发人员帮助其他人员完成某项工作，有时候需要替换掉进行中的工作，有时候需要开发人员停下开发工作来帮助测试——”
“先停一下！这决不会发生啊！”Daphne 大叫道，从她的声音和面部表情判断，她是在开玩笑。
“好像我愿意让你帮忙一样！”Adam也快速加入到玩笑当中。
注意
在制品限制不是一个严格的规定，它是用来引发讨论的。
“我们经常是在发布之前才进行大量的测试，”Eric插话道，“所以我觉得尽早测试以避免造成太大的影响是有道理的。你知道的，没什么，没什么，没什么，突然之间，砰！所有事情都集中爆发了。”
“有时我们需要打破在制品限制的原因是可以接受的。”Marcus试图把讨论拉回正轨，“但是如果你经常这样做，你可能需要检查一下这个限制，看看是否提高这个限制能有助于工作的快速流动。相反，如果很少或者从来没有达到这些限制，那么你就不会有这种有益的讨论，从而也就没有改进的紧迫感，那么这时你就应该降低这个限制。”
“现在大家对于找到一个数字来进行限制应该没有问题了吧？”Joakim看了看表，发现再不继续向下讨论就来不及了。
“嗯，找到一个很简单，但是否正确呢？”Frank问道。
“先把它当作一个限制，不要试图一开始就找到正确的答案。”Marcus说道，“就如同我们之前说的，随着时间的流逝，你们会逐步地检查和适应。如果大家决定每人一个工作项，该怎么简单地设置这个限制呢？”
“在每一列上面把工作人员的个数写上作为限制？”Adam建议道。
“是的，好主意！那看上去是什么样子呢？介意帮我们写下来吗？”Marcus递给Adam一支记号笔又退了回来。
“哦，我猜想因为我是目前唯一的测试人员，那么这里就是1。”Adam在“测试”这列的上面写下一个大大的1。
“等一下！”Beth走上前来，“有时我也会做一些测试工作，这对于我尽早跟踪需求的状态而言，是一种很好的方式。而且分析工作不会占满我所有的时间，因为我经常需要等着参加一些会议。所以我觉得这里写上2会更好。”
“是的，你说的没错，那我们就写2吧。”然后Adam就在白板上更新了数字。
“好的——那么开发人员呢？什么是比较合适的限制呢？”Adam把笔扔到Eric的电脑上，然后Eric又快速传给Daphne。
“对于我而言，只有2个工作项好像有点少。有时我们需要等着其他人，这时我们就无事可做了，但4个又有点多。Eric，你觉得呢？”
“要我说就是4个工作项。现在我们的工作比这个多多了，我们会管好的。”Eric信心满满地说道。
“嗯——我会写上3，然后我们会持续留意这个问题。”Daphne一边说着，一边把之前的数字擦掉，写上数字3。
“对于分析工作，我想限制2个工作项是合理的。”Beth说道，并把数字2快速写在她的那一列上。没有人对此有异议。
“其余的呢？”Frank一边说着，一边环顾四周。他发现Marcus和Joakim此时根本没有在白板附近。“对此我们该怎么办呢？”
“你这话是什么意思？”Joakim看上去很乐意站在团队的后面，让大家自己想解决办法。
“那么，剩下的这些列，‘待办’、‘验收’、‘等待运维发布’列和其他列，是否也要有相应的限制呢？”
“可以设置限制。”Marcus说道，“但是为什么呢？这么做有什么收益呢？”
“呃……我以为每一列都要有限制呢。”Frank坦白道。
“就像之前说的，大家可以给这些列设置限制，但没有明确的规则要求这么做。”Joakim解释道，“在那些能帮你实现快速流动的列上面设置限制。比如，在‘验收’列上面设置限制会怎么样呢？在这一列该设置一个什么样的限制呢？”
“让我看一看。”Cesar走上前，轻轻的自言自语道，“比如，设置这一列的限制为4，意味着一旦这一列充满了4个工作项，那么——”他停下来，并把数字4写在那一列上面。
“当测试人员希望增加一个新的工作项进来，他们会被阻塞住，这样的话，工作就会开始堆积，因而工作的流动就因为这个限制而冻结了。”Cesar一边说一边后退了几步。“这是怎么回事呢？”他自言自语道。
“那你该如何解决这种阻塞呢？”Marcus适时地提出问题。当Cesar继续思考这个问题时，其他人也陷入了沉默。
“那么，Beth或我可以检查一下这些工作项目，并接受这些工作成果……”
“是的——你会发现这个限制作为一种信号告诉你们需要来验收工作了。”Joakim按照他理解的Cesar的意思说道，不过顺便翻译成之前介绍看板时用的术语了。
“这样的话——我们为什么不设置为1呢？”Adam问道。
“因为——”Marcus还没来的及说完，Cesar就打断道。
“因为如果那样的话，一旦有工作准备就绪可以验收的话，我就不得不跑过来进行验收，否则整个工作流就会开始堆积。”一只思考的灯泡在Cesar头顶点亮了。“明白了，这很有趣。”
“那为什么是4呢？”Frank问道。
“我们不知道合适的限制是多少。但是“4”作为一个不错的开始，我们可以先使用一下，后续再进行调整并找到合适的限制。如果设置太低的限制，会要求我们经常出现，但因为出差或者频繁开会，我们经常很难做到。而太高的限制就会造成团队在没有得到我们反馈的情况下走得太远，这可能导致浪费，因为一旦有问题就需要大量返工。我们期望在他们进行得太过深入以致偏离方向之前解决掉这些问题。”
“但是为什么我们要为这一类等着人们做的工作建立一个单独的列呢？”Daphne问道，“我是说，你等着这一列先被填满，然后才开始验收这些工作。”
“好问题，Daphne。”Joakim回答道，“实际上这并不少见，我们一般称之为工作的队列或者缓冲区。它通常是放置在一个功能的前面并设置某种限制，就如同这里的‘验收’列。Beth和Cesar无法保证一直在我们身边，所以当他们在这里的时候我们想要确保他们有工作要完成。因而我们为他们创建了一个工作的缓冲区，而且只有当它填满的时候才叫他们过来。”
“Joakim，我不确定我是否明白了你的意思。”Cesar说道。
“让我们先把它可视化，看看是否能够变得更加清晰。”Marcus一边说着，一边向着白板走去。
在“验收”这一列中，Marcus将其一分为二，划出“就绪”列和“进行中”列。然后他转过身对着大家说道，“现在来看，什么处于等待状态，什么处于进行状态，就一清二楚了。当‘就绪’这一列开始有工作填充的时候，我们就可以叫Beth和Cesar过来。”
“这不是和‘测试’及‘等待运维发布’列很像？”Daphne说道。
“也许是这样的。你可以在觉得需要的地方加入这种队列。例如，只有有限资源的环节或者你希望将等待和进行中的区别可视化出来的地方。如果涉及工作的交接，比如从开发环节的某个人转给测试环节的另外一个人的时候，也可以通过设置一个队列来指示新工作已经准备就绪等待进入下一个阶段。”Joakim说的同时看了看时间。
Frank点点头，似乎他慢慢地理解了Cesar的解释。他对着白板注视了一会儿，“就这样吧，接下来呢？这个白板上写满了我们设置的限制，我们完成了吗？”
“是的，你们的白板就是这样的。”Joakim后退一步，双手在胸前交叉起来。“你们觉得怎么样？所有工作都在上面了吗？你们的工作流程就是这样的吗？”
Marcus又把白板纸上的挑战快速过了一遍，然后说道：“虽然现在我们还没有解决这个列表中的每一个挑战，但你们应该已经有相应的工具解决这里面的大部分问题了，大家觉得呢？”
大家先是陷入了片刻的沉默，接着Adam清了清嗓子，说道：“再说一次——这一切看上去都很美，但这只是一个简化。”他一边说着，一边叹了口气。
“并非所有工作都是新特性，都能一直向前流动。你也知道，”他继续说道，“有时候工作出了错误导致线上服务出现问题，此时不论你在做什么，也不管你已经有多少正在进行的工作，你就是必须要修复它！立刻、马上修复！”
“是这样的，”Daphne插话道，“我们当然不能为了遵守在制品限制而阻止紧急工作的插入，对吗？”
“嗯——你可以阻止，不过大多数团队都不会这么做，因为这样做业务会受到恶劣影响。在一天结束时，你们得到的最终结果比完美的流程更加重要。那么，你们现在如何处理紧急的工作呢？”Marcus转身面向整个团队。“如果你正在愉快地处理着又新又酷的特性时，突然收到线上服务器宕机的警告，你会怎么做呢？”
“我会放下一切，然后‘奔上山丘[3]’！”Eric说道，还用上了Iron-Maiden（铁娘子乐队）的唱腔。这引起了一阵笑声，因为之前没有人见过Eric这么快的反应。
“说正经的，我会停下手中的工作，然后看看到底是怎么回事。”Daphne说道，“啊，我明白了。我们应该在白板上对它进行可视化。从我们的现状开始可视化，然后把规则也显式化，诸如此类的工作，对吗？”
“太对了！”Marcus用他的右手潇洒地给了她一个手枪射击的动作。
Joakim转动着眼睛，快速跟着说道：“这是一个常见的情况。一种常用的方法是为这些紧急工作在白板上创建一条特殊的通道，通常我们会称之为快速通道。”
Marcus一边把虚构的手枪放进皮套，一边在Joakim解释时在白板的顶部加入了一条新的通道。
“Daphne，你所暗示的规则，比如应该放下其他工作来帮助解决问题，是比较标准的规则。但通常它们是隐式的，并且不一定所有人都理解或者同意。谁应该采取行动来解决问题通常也是不清楚的，或者，是否所有人都应该来解决这个问题？另外，新的项目是否应该纳入在制品限制之中？等等诸如此类的问题，这里有很多隐式的规则在发挥作用。”
“哦，我知道这是怎么回事了。”Eric把手臂甩到空中。“如果我们允许这个漏洞存在，我们坐在这里讨论这些限制的意义何在呢？”
“你什么意思呢？”Frank问道，同时很不友好地瞪视着他。
“你们几个人，”Eric朝Frank、Beth和Cesar三个人依次点点头，“你们几个人总是可以在这个通道中加入新工作，这就会为你们打开了进入开发队列的快速通道，因而你们就可能毫无节制的使用，这样你们的工作就可以最先完成。而这将导致我们从一个工作跳到另外一个，这样来回转换，就像去年春天开发Bank 2.0大版本的时候一样，还记得吗？”
大家陷入了一阵尴尬的沉默。
“好的，似乎之前在完成紧急工作时有些不太好的经历，那么大家该怎么做以避免再次发生类似的经历呢？”Joakim问道。
这引发了更多思考。Eric因为导致大家陷入尴尬的沉默而自觉有愧，所以针对这个挑战提出了更多的想法，于是建议道：“我猜，我们可以加入一个限制。”
通过简短的讨论，大家对于快速通道的规则达成一致。Joakim总结道：“我来总结一下大家讨论的规则，大家看看是否正确。只有真正紧急的工作才能使用快速通道，这个通道不能用来作为进入系统的作弊通道。大家会设置一个限制作为一个月内能接受的紧急工作的最大数量，对吗？”
“嗯，我个人对于这个设置很满意。我向大家承诺，我们会很谨慎地处理紧急工作，而不会用于作弊。”Cesar一边说着，一边握紧拳头并放到心口的位置，像是在发誓一样。大家一下子笑了，这也让大家从稍显紧张的气氛中解脱出来。
“让我们进一步确认大家对于这个规定的限制理解一致，如果我们把一项紧急工作放进来，会发生什么呢？”Marcus问道。
“它将被快速完成，这就是我们需要的结果。”Cesar说道，但他突然意识到自己似乎掉进了一个陷阱。一个巴掌拍不响，两个人就可以玩个游戏。想了一下，他又把问题抛了回去：“你为什么这么问呢？”
“嗯，我的意思是说对于其他进行中的工作该怎么办？会发生什么呢？Adam，如果你回想一下我们刚才玩的便士传递游戏，什么看起来像是一个紧急工作呢？”
Adam想了一会儿，然后大声说出推论出的结果：“我猜是新加入一枚硬币而且还必须在其他硬币之前先传递完成。”他顿了顿说道，“这对于流动而言是有害的，因为我们需要先停止翻其他的硬币，”突然之间，他醒悟过来，“这会使得其他硬币在系统中的流动变慢。”
“说得没错！”Marcus说道，“使用快速通道时要小心。它的确会使得紧急工作快速流经系统，但同时也增加了在制品，从而导致进行中的工作流动减慢。”
Joakim觉得这听起来是个坏兆头。“就是说，当使用紧急工作卡片时，要确保你知道这些影响并经过了充分的考虑。的确，有时候快速完成一件有价值的或者重要的工作是正确的抉择，但因为这是有成本的，所以你要知道你付出了什么。如果你愿意的话，这就像收税一样。”
“我们也会确保快速通道不会被滥用。”Eric看上去很高兴。
“对于在走廊里交待给你的任务，可以使用这种方式处理。”Marcus说道，同时他在白板纸上对应这一点的挑战旁边画了一个点作为记号。“没错，大家可以这么做，但这么做是否值得你付出的成本？这可以展开一场讨论，并使用真实的数据作为支持。”
Cesar走到白板前，注视了一会儿，然后转过身来。大家看出，他打算开启老板的总结发言模式了。
“我想代表在场的每一个人对你们今天的所做所为表达深深的谢意，并且——”
“哦，等一下。”Beth打断道。Cesar感到很奇怪，但是这次是Beth，根据之前的经验，她的话很值得一听。
“怎么了？”他问道，鼓励她继续说下去。“我知道我们就剩下20分钟了，但是还有一个方面没有进行过探讨。”Beth说道，“我们怎么基于此进行改进呢？”
“这是什么意思？”Frank有些吃惊，“这个方法对工作能提供比我们之前的方法更好的控制，我想这是一个不错的开始。”
“是的，没错！但是根据我的理解，这个方法是逐步演进的，对吗？”他看着Joakim寻求帮助。
“是的，不过……”Joakim回答道，“就像我们之前讨论的，我们在白板上画出这些列并设计工作项等等，白板上的所有内容都可能发生变化以便我们在进行的过程中进行改进。”
“太棒了！”Beth打断了他，“那我们怎么知道我们在朝正确的方向前进呢？”
Joakim说道：“当你们做出改变时，你们如何知道你们在改进？”
“嗯，如果我们比之前做得更好的话。”Adam说道。
“但是跟什么进行比较呢？”Frank问道，这是他擅长的领域。“‘变好’是什么意思呢？我们是如何判断的？我们需要一些度量指标来反映我们是否在变好。”
“那我们开始吧。”Eric和Adam异口同声地说道，同时其他人也或叹息或沮丧地加入到讨论中。Joakim和Marcus对视了一眼，他们都对大家这么强烈的反应感到吃惊。
这个团队明显在经历过全公司范围内引入关键绩效指标（KPI）[4]后发现这对他们毫无帮助。因为KPI必须实现，整个团队的生产力和团队士气都遭受了重创。不久之后，KPI就被废弃了。
“好吧，那么你们觉得跳过这一部分怎么样呢？”Joakim试图把大家带到积极的讨论中并获得大家的注意力。“我们不会这样讨论度量指标。这些指标是由大家定义的，为大家服务的，以帮助大家找到可以改进的地方。”
“是的，没错。”Marcus说道，“在白板上跟踪这些指标的数据，如果愿意也可以自己保留，或者只是对你选择的人展示这些数据。”
“但是获取和跟踪工作是个苦活儿，”Daphne痛苦的说道，“我只希望做真正的工作。”
“这不一定。”Joakim说道，“在建立好白板之后，你就可以轻松地跟踪两个既简单又强大的度量指标——前置时间和吞吐量了。”
他走到白板前面，拿了一沓即时贴。就在说话的同时，他在白板的底部画了一个大大的括号。“前置时间就是一个工作项从开始到结束用的时间，即从第一列到最后一列的时间。”
“真的吗？”Adam插话道，“我们完成工作的时间大相径庭，我们能从中学到什么呢？”
“我稍等一会儿再解释。”Marcus请求道，“开始跟踪前置时间可以很简单，在即时贴上写下进入‘待办’这一列时的日期和进入‘发布生产环境’这一列的日期，然后在白板上将这些信息绘制出一张简单的图，这样你就会对前置时间有个清楚的认识了。”Marcus快速在白板上绘制了一个示例图。
“通过这样一张图，你们能够很容易地看到不同工作项在时间上的区别。”Marcus解释道。“一如之前一样，我们在这里可以讨论很多东西，比你们问题的解决方案要多得多。”
“但这张图对我们有什么用呢？”Adam挠着头说道。
“让我们一起来看一看。”Joakim说道，“从这个图表上，你们第一眼看到的最显眼的是什么？”
大家注视着白板，过了一会儿Frank说道：“嗯，那三个点。”他指着那三个前置时间最长的点说道。“似乎它们用了很长的时间，为什么会这样呢？”
“那到底是为什么呢？”Joakim问道。“这也许值得深入分析一下。”
“可能因为这三个都和我们程序中的某个子系统相关。”Marcus提出了一个假设。
“或者是需求不清楚。”Adam一边说一边看了一眼Beth。
“或者是在定义需求时缺少测试人员的意见。”Beth不失时机地回击了一下。大家都轻声笑了起来。
“大家看，”Joakim说道，“我们又开始了一轮讨论，而且大家可以针对所有的常规工作进行讨论。比如，我们采取什么措施才能把平均前置时间缩短一半？”
“一半？”Frank说道，从他的声音可以听出来他认为这是不可能的。“现在不可能做到。我们花费在等待运维人员和其他团队的时间太多了。”
“没错，”Joakim打断道，“我们该通过什么办法来改变这一切呢？”他把这个问题抛出来但没有人回答。
Joakim看了一下时间，紧接着说道：“吞吐量，即你们完成工作的速率更加容易被跟踪记录。为一定时间段内你们完成的工作项计数，比如每隔两个星期或者四个星期，这取决于哪个更适合你们。”
“我们在每个月的第二个周三进行发布，”Frank说道，“所以如果你问我的话，我认为这会是一个不错的时间点。”
Marcus在白板上画了一个示例。“在每个月的第二个周三数一数‘发布生产环境’这一列中的工作项，然后就可以把它们从这里去除了。这样你就可以非常简便地跟踪吞吐量数据了。”
Adam有些迟疑：“还是那个问题——这怎么帮助我们改进呢？”
“还记得之前我们讨论通过降低在制品规模以得到快速的流动吗？”Joakim问道，“如果不跟踪数据，你怎么确信这一点呢？没错，你可以基于感受或者直觉进行，但你怎么知道呢？而且你的感觉是否足以说服别人呢？”
Joakim继续说道：“如果你对这个度量指标记录一段时间，并计算出平均的结果，你甚至可以基于这个结果进行预测，从而你就可以承诺在截止时间前完成。这是你们当前的挑战之一，对吗？”
“通过这些简单的度量，”Marcus补充道，“你们可以从你们的现状开始跟踪现有的流程。当你们改变后，你们可以轻易地看出来是否有所改进。”
“但这是不是有点太简单了？”Adam依然有些怀疑，“我们已经有一些复杂的系统来跟踪记录并进行度量——”
Eric打断他道：“而且我们不喜欢这些系统也没有使用它们，不是吗？我更愿意用一些简单的、对我们有用的指标，而不是那些愚蠢的度量指标——那都是管理层中的某些人想出来的。大多数形式的度量指标我都不再相信，但是这几个我觉得至少可以使用。”
大家再一次陷入了沉默。这一次不是因为尴尬，而只是安静。突然，Daphne转向Cesar：“现在的时间是？”
“还有很多时间——哦，不，等等，我们现在已经过了整整两个小时。”Cesar一边说，一边看着他的手表。
“我们还有很多内容可以讨论，”Joakim说道，“不过我们认为这对你们开始使用看板是个不错的开头。”
“在你们使用的过程中，如果希望了解更多内容，你们可以看看精益背后的原则，并将其应用到你们的工作中，”Marcus继续说道。“这可能比较困难，但你们可以从其他团队的经验中获得启示，看看他们如何把精益应用于他们的工作场景中。你们也可以访问kanbandev[5]邮件列表、Limited WIP社区[6]和研讨会来获得更多看板的信息。”
“基于现在的白板，你们可以从明天就开始使用，并继续进行改进。”Joakim试图结束这次讨论。
“我不会长篇大论，”Cesar一边说着一边站起来，其他人也跟着欢呼起来。当大家都重新安静下来，Cesar说道，“但我想说——谢谢你们。这正是我们所需要的一剂良药。你们说的没错，我们确实可以在两小时内建立好看板并运行起来。”说完，他满意笑了。
“当你们回到家之后，你们也许会想要了解更多细节和背景，而且或早或晚，你们也会想要了解一些高级技巧。”Marcus找到他的书包，“这时候这本书能够帮到你们。”
他递给Cesar一本他们即将出版的新书《看板实战》。
“最后一个问题，我们现在应该关注什么呢？”Frank问道。
“前置时间，”Marcus和Joakim异口同声地说，“将整个流程纳入考量，从而努力缩短前置时间。”
“而且还有一个小提示：试着想办法通过降低在制品规模来达到这一目标。”Marcus说道。
“谢谢你们。”Cesar看着他们的眼睛，又急忙转过身去。
在门口，他停下来，转过身。
“哦，对了，我们还没讨论给你们的酬金。”他一边说着，一边指向Marcus和Joakim背后的桌子。
他们两个人都转过身，乍看之下，他们没有发现什么东西。而他们走近桌子，发现了一个即时贴，上面潦草地写着一行数字。
“这是什么？”Marcus回头望向Cesar刚刚站的地方，只看到他出去的背影，门又关上了。
“看上去是一个银行的账户。”Joakim回答道，“但我们可以用它做什么呢……”
他们两个人又同时恍然大悟了。
“我们得到了酬金。我想我们最好登录一下那个网上银行，如何？”Joakim看着Marcus，笑了。
我们的英雄还在那里，而Kanbaneros团队已经在回家的路上，准备开始使用看板。这一整章是围绕一个虚构的故事展开的，为了增加故事的可读性，我们进行了适当的简化和调整，不过你还是能够通过本章看到如何简单的建立看板并把它运行起来。
也许你的工作、团队和环境与Kanbaneros团队并不一样，但你可以继续沿用这个推理逻辑并进行适当的裁剪。你不必采用他们使用的所有方法，只选用适合你需求的就好。
这一章的目标是帮你开始使用看板。在本书的后续章节中，你会学习到本章介绍的所有概念，包括更详细的描述、各种变型和对常见陷阱的预警。我们也会介绍概念提出的背景，以及如何应用到不同的上下文环境中。
非常欢迎你基于现在所学来尝试使用看板，你也可以继续本书下一部分的学习之旅。在下一章中，我们将简要介绍看板的起源，然后深入解读看板所基于的原则。同时我们也会提供一张建立并运行看板的步骤说明书。
[1]源于20世纪80年代日本丰田发明的精益生产（Lean Manufacturing）方式，属于管理学领域范畴，旨在以最小资源投入创造更多价值。——编者注
[2]一个吉他知识问答类网站。——编者注
[3]译自歌名《Run To The Hills》，英国重金属摇滚乐队Iron Maiden（铁娘子乐队）作品。歌中描述了对自由的追求。——编者注
[4]关键绩效指标（KPI）是一种衡量绩效的常用方式。
[5]http://groups.yahoo.com/neo/groups/kanbandev.
[6]http://limitedwipsociety.ning.com/.
在帮你快速了解看板之后，本书的第二部分将详细介绍看板背后的理论。不过不用担心——我们仍然会本着实用的原则一点一点地介绍理论。这一部分主要介绍看板所基于的原则，以及这些原则如何应用到你的团队之中。这一部分涵盖的主题广泛，从精益的理论基础到如何用正确的方式移除一张即时贴，都有所涉及。
本章涵盖的内容
在第1章中，我们通过一个小故事介绍了看板。通过这个故事，向读者展示了如何使用看板对实际工作进行改进。希望你现在可以有信心开始使用看板了，但也许你还有如下这些疑惑。
本书的后续章节将会解决上述问题和更多其他的疑惑。而本章将通过回顾在Kanbaneros的做法来介绍看板所基于的原则。
不用担心，本章并非想囊括看板的所有内容以形成冗长的理论篇幅。而且如果你愿意，可以直接跳过理论部分，开始阅读2.2节。我们会保持理论部分短小而实用，因为本书就是一本注重实用性的实战书籍。这就是我们将理论篇幅精简的原因，我们期望在你需要的时候再将理论一点一点地提供给你。本章还将提供一个快速的秘诀教你建立看板并使之快速运行起来。
还记得Kanbaneros吗？在本书中，他们将穿插进来提出问题，甚至挑战我们，并从你的角度提出实际中的困惑。
让我们再认识一下他们：
如果我们介绍的是另外一种流程，比如Scrum、极限编程、Rational统一软件开发过程，第1章将会是完全不同的风格。因为我们将集中精力介绍新流程如何工作、该做什么、不该做什么、迭代周期多长、产品负责人（Product Owner）的任务，等等。
看板与他们完全不同，它根本没有事先规定那么多内容。它更像是个“元流程”，可以适用于你现在使用的任何流程。这真是太棒了，因为这意味着你可以不用改变任何东西而直接基于自己现状开始使用看板进行改进。是的，不需要新的流程，不需要新的角色，更不需要恼人的组织架构重组。
看板方法，看板，看板系统？
如果你仔细阅读可能会发现，在本书中我们使用小写字母k表示看板（kanban）。然而看板社区正在蓬勃发展并进行持续优化，所以一些定义的表述会发生很多变化。我们先就目前的知识情况对他们做一下诠释。
- 看板方法（Kanban，大写K）——一种在组织中创建渐进变革的方法，由大卫·安德森（David Anderson）创立并完成著作《看板方法：科技企业渐进变革成功之道》（Blue Hole Press, 2010, http://amzn.com/B008H1APT0）。
- 看板（有时小写字母k，有时大写字母K）——有时指的是一种可视化流程管理系统，用以描述生产什么。何时生产以及生产多少，有时指的是实际的视觉信号。
- 看板系统——用以跟踪在制品的系统。举个例子来说，一面看板墙加上信号卡和工作中遵循的规则就是一个看板系统。
理论上来说，这些概念都具有不同的含义，但在实践中，人们在社区里面往往会不加区分地使用这些术语。通常情况下，当人们提到“使用看板”时，是指使用某种看板系统来管理和优化看板（信号卡）以取得渐进的改善。在本书中，当我们提到“看板”时，也是这个意思。
如果这使得你感到迷惑，不要紧，在通读本书时，你可以自行理解什么是看板，并且在本书最后也没有测试环节——这一点我们可以保证。
与日本的关联
你应该知道，仅仅知道看板这个词相关的知识，就可以让你的朋友对你的日语知识刮目相看。看板这个词是两个日语词组合在一起得到的：kan在日语中是可视的意思，ban是卡片的意思，组合在一起就是“可视化卡”或者“信号卡”的意思。
看板这个概念源于丰田，在丰田生产系统（TPS）中，看板的发明解决了准时制生产方式（just-in-time）的调度问题。当西方研究人员研究丰田生产系统时，他们把它称之为精益生产系统，后来称之为精益制造和精益思想a。看板源于丰田生产系统和精益生产，这就是为什么你会发现在本书中和其他同类的看板书籍中，有很多地方引用了上述概念。
aJohn F. Krafcik, “Triumph of the lean production system,” Sloan Management Review 30, no. 1 (1988): 41–52. James P.Womack, Daniel T. Jones, and Daniel Roos, The Machine That Changed the World (Scribner, 1990, http://amzn.com/B001D1SRRS).
虽然看板没有规定很多具体的规则或做法，你还是可以通过使用看板进行大幅改进。这是怎么做到的呢？看板的核心是几条原则，这几条原则可以指导你使用看板进行改进。下面让我们来仔细看看这几条原则。
看板基于三个简单的原则：
在Kanbaneros团队的案例中，我们是从可视化他们的工作开始的。通过创建代表工作项的即时贴，并在一个可视化的工作流白板上跟踪每个工作项的当前状态，就可以很容易地实现可视化。这是一个很棒的方式，可以帮你了解你的工作，反思你的工作是如何运作的[1]，并开始发现在工作流程中的改进机会。
对于我们辅导的很多团队，可视化能立刻产生巨大的影响。仅仅把之前隐藏的很多信息可视化，就可以帮你解决很多问题。
可视化还有其他方面的影响，因为你也可以开始针对工作项制定隐含的规则。比如，每个人可能都觉得他们知道你是如何处理一个特性需求的，然而通过将工作流在白板上按列展示出来，整个团队对实际的过程就一目了然了。通过这样的做法，你对于工作的处理规则一旦有所不同，就变得非常明显。这可能引发一场讨论，用来澄清工作的规则，而且你可以轻易地将这些规则记录在可视化白板上，以便所有团队成员按照同样的方式工作。
在Kanbaneros团队的例子中，我们经历了几种常见的可视化工作，如白板、工作项和快速通道。为了进一步了解这些内容，本书第3章和第4章将进行详细的介绍。
我们将继续通过Kanbaneros团队的案例进行一个便士传递游戏（关于这个游戏和其他游戏的细节见第13章），这个游戏说明了限制在制品的原理。简而言之，这个原则就是针对你能够同时进行的工作项人为地设置限制。这样做最明显的好处就是同时处理较少的工作项，使得每项工作更快地完成。第5章将深入解读限制在制品的作用。
因为其他一些微妙的原因，限制在制品也是很重要的。通过设置在制品限额，你将在工作流中创造些许紧张。这本身是个好事情，因为它能暴露系统中的问题，或者是Kanbaneros案例中的“未曾意识到的改善机会”。在第6章你将学习到限制在制品及背后的原因，还有如何将这些限制可视化。
限制在制品将把改进的机会呈现在表面。通过工作流观察，流动可能迟滞（即时贴在白板上的移动非常缓慢），可能积压（在某列中有很多即时贴），也可能完全停止（工作项一直等待）。这些都可以作为你改进整个系统的指标。你用于解决这些问题的做法，取决于是否带来了改善。
如果你想进行改进，就应该知道目标是什么。而这恰恰是看板最后一个原则发挥作用之处：管理工作流使之快速且毫无中断地流动起来。
这只是整个流程持续优化之旅的开始，而且你将永无完成的一天，这听起来是个坏消息。工作流程总是能找到改进点，因为流程中总是存在某个瓶颈会拖延你的工作[2]。庆幸的是，这些问题在白板上很容易显现出来。不仅如此，往往越严重的问题越早暴露，而且一旦解决掉，工作的流动就会明显改进。
你可能还记得，在第1章中Kanbaneros团队发现了几个改进的机会。
促使工作快速流动起来，这听起来并不困难，对吧？在第7章你能学到更多这方面的知识，所以你现在需要做的就是努力做到这一点。
你可以做很多事情来达到这个要求。当基于这一原则开展工作时，你能够从精益思想中找到灵感来消除过程中的浪费以便工作能够顺畅流动起来。你也可以浏览一下约束理论[3]，并尝试识别、拓宽和缓解系统中的瓶颈。从敏捷软件开发运动中产生的实践可以帮助你提升协作和质量，从而改进系统的流动。到底选择哪条路改进你的系统完全取决于你。最重要的一点是当你的工作向你发出改进信号时，你要响应并改善它。
在实际中，你会发现这三个原则是互相关联的。例如，为了取得工作的快速流动，你设置了限制，并且把它可视化在白板上。
通过可视化的工作流，限制在制品并重点关注工作的流动，你就建立了易于发现改进机会的机制。至于怎么做，其实完全取决于你，但我们不会让你孤立无援。在本书第3～7章，我们挑选了大量窍门、实践、模式和常见的解决方案来帮你促进工作的流动。
在发掘改进机会的时候，你很快就会跨越团队的工作范围。为了获得更快的流动，你需要和其他团队或者周围的其他职能角色以不同的方式进行交互协作。第一步就是将这些团队或者前后关联的职能角色加入到你的看板中。或者，你也许可以为部门的每个团队都建立一个白板，然后将所有团队的状态聚合起来。
这可能就是一场变革的开始，最终会渐进地影响整个公司。很快你就会发现自己在向其他人讲授看板，并且参与到整个组织级的变革管理中。关于这一点，你可以在第13章了解到更多细节。
三个原则？我以为是五个特性抑或是六个实践？
看板作为一种方法论应用到软件业务中的时间还比较短。看板社区是一个充满活力的社区，人们不断发现新的东西并应用于实践之中。这一点很棒，而且非常符合精益原则和持续改进思想。
本节介绍的三个基本原则是看板的基础。近期，大卫.安德森和其他人将这三个基本原则扩展为五个特性，后来又扩展为六大实践。这六大实践现在被称为看板的核心实践。a下面对这六大实践进行简单介绍。
（1）可视化——如前所述。
（2）限制在制品——如前所述。
（3）管理流动——如前所述。
（4）显式化流程规则——通过明确的规则，就可以开始对整个流程展开讨论，而且这种讨论是基于客观的数据而不是假想、感觉或是传闻。
（5）建立反馈环路——这个实践关注的是从你的流程中获得的反馈。例如，运营回顾就是对流程本身的回顾。
（6）协作式改进、试验中演进（使用模型和科学方法）——这个实践鼓励人们使用模型（如约束理论或者精益思想）来推动整个团队持续改进。
这就是在我们之前介绍过的三个基本原则之上又新加的三个实践。需要提醒的是，这同样适用于看板方法，即研发运营组织的渐进变革之道。而且，后面的三个实践在看板方法中是非常重要的。
你可能已经注意到，本书采用了一种务实的方法来介绍看板，而且后加的三个实践对三个基本原则的扩展非常适用。
- 显式化流程规则——显式化流程规则和工作可视化是一脉相承的。虽然把明确的规则公开写在白板上很重要，但这往往不是最重要的，反而是针对于即将落实到位的规则展开讨论并达成一致才是最重要的。虽然将规则明确出来是很棒的，但我们认为这本身就是工作可视化原则的一部分。
- 建立反馈环路——对于我们而言，这是管理流动基本原则的一部分。为了促进工作流动，反馈环路是必要的，所以应该在需要的地方建立反馈环路。
- 协作式改进、试验中演进（使用模型和科学方法）——我们完全同意这一实践的重要性。这一观念深植于看板所基于的精益原理之中，以至于我们觉得这并非看板本身的原则，而是看板发源的环境和生态。
后来，事情变得更加复杂了，因为大卫·安德森使用“原则”这一概念来描述如下内容。
- 从现状开始。
- 追求增量和渐进的改变。
- 初始时，尊重现有的角色、职责和头衔。
最近，又加入了第四条“原则”。
- 发挥组织中的各级领导力。
在我们实践看板的那个年代，我们谈论的看板原则现如今已变成了实践。这些实践从三个扩展到五个，后来是六个，而且重新定义了“原则”，并加入了新的“原则”。我们预测关于这些实践的讨论不会结束，但从这里开始，你就能够理解为什么我们谈论的是三个原则（可视化，限制在制品和管理流动），而其他人却在谈论五个实践或是六个实践。
如同Kanbaneros团队一样，你也能马上开始，因为看板本质上是轻量的。实际上，我们为什么不从现在开始呢？
使用看板并不费事，你可以轻易基于现状开始使用看板。你只需要开始关注如何将工作完成，注意是在其他新工作开始前将它彻底完成。建立你和团队的座右铭：停止启动，聚焦完成。这是一个限制在制品的简单方式，但非常有效。
如果你想要一个具体且实际的例子，你可以做一个练习，比如一个类似于我们在第一章中和Kanbaneros团队进行的练习。下面的简短描述可以帮你展开这个练习。
（1）从工作可视化开始。我们让Kanbaneros团队为每一个工作项创建一个即时贴，并贴在白板上。
（2）在白板上绘制工作流程。比较简单的方式是为工作流程的每个阶段在白板上创建一列。将处于不同阶段的即时贴移动到正确的列中。在这个时候，Kanbaneros团队谈论了很多有关工作如何进行的话题，这对于大家增加时整个流程的理解是有益的。但在看到整个流程如何运作之前，请不要急着去优化工作流程。在这个练习之后，你的白板可能如下图所示：
教练的忠告
确保和整个团队一起绘制白板。不要让单独一个人绘制，如果你是一个外部教练，特别注意不要自己一个人单干，因为这将严重影响整个团队的接受度。相信我们，这个错误我们犯过多次。
一个让整个团队参与这个练习的简单方法，是当你在白板上绘制的时候，把笔递给其他人让大家一起参与。
（3）用一些工作项来演练一下，看看它们如何流经工作流，是否与你的工作方式相吻合，需要的话可以改变工作流。在Kanbaneros我们没有时间来进行这一步骤，但是我们认为这是一个很好的实践。它可以快速告诉你是否设计了正确的工作流。记住，这一步只是跟踪和如实反映你是如何工作的。
（4）决定在制品限制——作为一个团队，同一时间可以并行多少个工作项。我们在这一步花了很长时间来帮助Kanbaneros，但是也别想的太多了。更好的方法是，先设定一个值，在需要的时候再改进。例如，从每个人两个工作项开始（例子中是6个），每个队列平均分配。或者是从本书第6章汲取一些好的想法。
（5）作为补充方法，你可以创建一些头像——代表你们自己的图片，把它们贴在正在工作的事情上。这会让你更简单地看到工作进展，知道如果有对某个工作项的问题应该找谁。
这样你就有了一个简单的白板来进行工作改进。即使很简单，这个工具也可以帮你发现问题并且一小步一小步地持续改进。本书其他章节将介绍如何进行这种改进。
看板是一种基于简单且有效的理念发展出的软件开发方法。它的目标是促进工作在整个价值链中快速流动，从最初的想法或概念到服务客户的生产系统。这个工具之所以能做到这一点是因为如下几个简单有效的原则：可视化工作和规则，限制在制品的数量，促进工作快速流动。
这些工具能引导你持续不断地改进工作流程，从而使得工作更快更顺畅地流动起来。这将是一场永无止境的探索之旅，每一天你和你的团队都能取得改进。
现在你的看板已经建立起来并投入运行。当工作取得进展，就可以把对应的即时粘贴在白板上进行移动。请好好关注影响工作流动的问题。一旦问题出现，停下来并讨论如何解决，这就是改进的机会。请好好处理它们，不要浪费这些机会。
本书其他部分提供了很多实用的建议，如与可视化相关的建议、如何限制在制品、促进工作快速流动的几种不同方法。我们把重点放在实用的建议上，以确保你可以应用这些实践、模式和工具。
现在就来看看可视化这一主题，这可是一个可以发挥你创造力的主题。
[1]参见JohnSeddon的Freedom from Command and Control : A Better Way to Make the Work Work (Vanguard Consulting Ltd,http://amzn.Com/0954618300)。
[2]好吧，当有一天只要你能够想出来，软件（或解决方案）就能立刻实现的时候，就不会再有瓶颈了。但在可预见的未来这并不会成真。
[3]参见http://en.wikipedia.org/wiki/Theory-of-constraints，阅读关于约束理论（TOC）的相关内容。
