作者：David J.Anderson
出版社：华中科技大学出版社有限责任公司
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
看板方法：科技企业渐进变革成功之道试读：
对本书的赞誉
大卫•安德森在看板系统上所做的工作，对我的软件开发方法产生了重大影响，改变了我对软件过程的思考方式。以往，我以“用户故事”“点数”和“时间盒”等看待软件开发工作；现在，我则会从“在制品”“流动”和“节奏”的视角出发看待软件开发工作。作为一本里程碑著作，本书将向更多读者传递此种视角。如果你希望创建可持续发展的开发团队，本书不可错过。——卡尔•斯科特兰德（Karl Scotland）EMC咨询公司，资深实践顾问
看板是一个有难度的写作主题，因为每个人在实施看板时，都要根据自身具体的工作流程和瓶颈进行调整。但是，大卫•安德森确实做到了这一点，他在提供坚实理论框架的同时，又切实确保了其中的可操作性。通过实施书中介绍的这些方法，读者将取得实实在在的成果。——克里斯•西蒙斯（Chris Simmons）;Sophos公司，开发经理
大卫•安德森的《看板方法：科技企业渐进变革成功之道》一书没有停留在诸如“看板是如何驱动变革的”这种介绍性层面上。在书中，他不但清晰地解释了其中的细节，还给出了丰富的实例和具体的实践精要。企业工作场所中涌现的“自治(autonomy)”，是现代管理领域中最令人兴奋的一个新的发展趋势，面向知识工作的看板方法对此提供了强大的支持。——克里斯蒂娜•斯卡斯芙（Christina Skaskiw）敏捷教练
最近十年间，这是我在软件行业中所看到的最好的变革管理方法。——大卫•巴尔金（David A. Bulkin）Lithespeed有限责任公司，副总裁推 荐 序
看板在软件开发领域已获得越来越多的应用，而大卫•安德森是这个领域当之无愧的领导者，《看板方法：科技企业渐进变革成功之道》是他系统深入阐述看板方法的重要著作，是了解和实践看板的必备读物。
看板将软件开发带入到队列管理与流动的世界，它与其他敏捷方法的显著区别在于它是一种变革管理方法，在组织级渐进变革方面尤其具有优势。看板基于现状对现有方法做系统的渐进改良，阻力小，具有很强的暴露问题和提示改进机会的能力，能有效提高组织在完整价值流上的关注程度和绩效表现。在看板带来的渐进变革中可以结合其他敏捷方法，从而发展出更为适合企业自身特点的独特方法。
翻译是一项非常辛苦的工作，译者章显洲的辛勤工作加上他在看板方面的扎实实践确保了本书翻译的质量。我有幸审校本书的译稿，这对我来说更像是个学习的机会。本书非常容易阅读，读者可以从中找到许多实用的技巧。大卫对看板体系的搭建和使用极具洞察力，甚至一些不起眼的选择背后也饱含实践者的智慧，值得细细体会。如果你已经是敏捷的实践者，无论是在应用Scrum或是XP，并在实践中遇到困惑，本书的不少内容会给你启发和指导。
我自认为在看板方面有颇多实践和思考，但参加大卫•安德森的培训，接触他本人，再认真审校《看板方法：科技企业渐进变革成功之道》译稿后我发现自己还远没有发挥出看板方法的威力。看板方法比大部分人想象的要系统和深入，这是一个值得深入学习的领域。审校本书对我来说是个转折点，我开始在已经应用看板的团队中对其做深入改造，并尝试在新团队和新项目中使用深入的看板方法。我利用看板建模过程分析团队信息，发掘真实流程。通过刨根问底式的沟通挖掘团队规则，借助工作项分类、服务分类以及队列的拉入条件将规则显示出来。我和团队一起识别看板系统的范围（可以为队列设置约束的那部分流程），针对看板系统建立推迟承诺的工作项拉入机制，并度量工作项在看板系统的前置时间，让每个人都看到自己的努力如何改善整个系统的表现。有了对现状的深入洞察，通过本书介绍的方法发现改进机会，我们开启了渐进式的变良过程。
团队追求前置时间的可预测性，这需要综合的努力和强大的问题解决能力，据此形成可信的服务承诺。我发现这会降低对时间盒迭代的依赖，避免追求迭代承诺时的一些副作用。团队追求看板系统的范围向下游扩展，按用户期望的频率部署，向上游扩展，利用看板的承诺方式改变用户与团队互动的方法，增进信任关系，利用推迟承诺为用户带来选择和灵活性。
我在组织层面开始尝试利用电子系统呈现和度量完整的价值流，价值流经团队所代表的服务。度量各个服务以前置时间反映的服务水平，评价通过前置时间分布反映的可预测性，以及以控制图反映的内部协作水平。组织内价值流的视角能够帮我们发现最值得改进的杠杆点，避免局部优化，也更容易把用户、团队、中层和高层管理者协调到同一个目标上来。
看板实践让我收获颇丰，也让我更加坚信看板方法将会给软件开发领域，特别是大型组织带来真正意义上的变革。相信读者在认真阅读、实践和思考后一定会获得与我类似的感受。
大卫•安德森对我说，经过最近几年的探索，他对看板方法有了进一步的理解，也对本书中的很多主题有了新的认识，现在的看板体系比以往更深入、更具体，这些从他最新的培训和演讲中便能看得出来。我很期待新版的《看板方法》能尽早面世。路宁2013年11月于深圳Agilean联合创始人，咨询师，Lean-Kanban University认证讲师译 序
自有软件开发活动以来，在软件工程界和软件开发社区中，一直有不少先行者和实践者在积极探索如何更高效地组织团队进行高质量的软件开发活动。敏捷方法和精益方法正是近十几年来，从这波潮流中涌现的最精彩夺目的两项成果。敏捷方法和精益方法的大伞，覆盖多种软件开发方法学，其中最具代表性的有Scrum、极限编程等，它们以《敏捷宣言》定义的价值观为基石，构成了这张大伞的一半幅面，另外一半幅面则由以精益价值观为基石的方法学组成，其中最具代表性的是由Poppendieck夫妇共同创立的精益软件开发方法（lean software devleopment）。本书所介绍的看板方法，则是精益阵营中涌现的一种不可忽视的新方法。
看板方法，由David Anderson创立，它脱胎于大野耐一所创立的丰田生产方式（TPS），以及埃利亚胡•高德拉特（Eli Goldratt）的约束理论（TOC），并结合统计质量控制（SQC）、排队论（QT）、工业工程（IE）、软件成熟度模型（CMMI）等多个领域的知识，在软件开发社区中获得了极高的关注度，并迅速传播开来。
David在从事软件开发管理的实践经历中，发现商业组织中的软件开发团队经常产生过载现象。这对软件开发者带来了深深的伤害，反过来也伤害了商业组织，因此他期望找到一种双赢的软件开发模式，寻找到一种系统性的途径，能够带来可持续的步调，既有利于软件从业者，也有利于商业组织。同时，作为变革推动者，David还发现，在团队中导入新技术总是不可避免地会遭遇到阻力。他领悟到，必须寻找到一种能够使变革阻力最小化的方法才行，最好的策略便是从团队当前状况出发，采取逐步改善的变革引导方式。这两个方面，是David创立看板方法的两个基本动机。
看板方法采用了精益的思维范式，将软件开发视为一个价值流（value stream），并且基于拉模式来驱动其流动。“价值流”是精益思想和看板方法的基础隐喻，基于这个隐喻，引申出来的是一系列其他元素，例如，拉动（pull）、在制品（WIP）、批量规模（batch size）、前置时间（lead time）、阻塞（block）、瓶颈（bottleneck）、缓冲区（buffer）、吞吐量（throughput）、改善（kaizen）等。改善是精益和看板方法的精髓，它旨在通过持续性地实施系统性变更来优化生产系统。
看板方法的各种设计元素，为质量和过程中的问题提供了可见性，能够迅速暴露价值流中影响效能的问题，从而引导团队专注于解决问题以维持稳定的流动。通过帮助软件团队建立稳定的工作节奏，实现始终如一的可靠交付，看板方法能够在开发团队与客户、相关部门、供应商、价值流下游合作伙伴之间建立信任关系，从而建立具有高度协作、高度信任、高度授权和持续改进特征的组织文化。
软件开发中的看板方法本身还在不断发展过程中。作为本书的中文版译者，我非常荣幸能够把这本奠基之作介绍给中国的敏捷和精益软件开发社区。期待本书能够给社区带来新的视角和启迪，更期待国内社区对看板方法的实践能够反过来促进看板方法的进一步发展。
祝大家都能够精通保持平衡和持续改善的艺术！章显洲支付宝高级技术专家2013年11月5日于杭州古荡序
我一直关注大卫•安德森的工作。第一次与他接触是在2003年10月，那次他送给我一本他的书《软件工程的敏捷管理：应用约束理论获得商业成功》。正如书名所示，这本书受到了艾利•高德拉特（Eli Goldratt）“约束理论（theory of constraints ,TOC）”的深刻影响。后来，在2005年3月，我造访微软公司和他见面，那时他正在进行的研究工作给我留下了深刻印象，在其中他使用了累积流图 （cumulative flow diagrams）的概念。再以后，2007年4月，我有机会考察了他在Corbis公司实施的看板系统，深叹其突破性。
这里之所以罗列这些，是因为要说明一点，大卫的管理思想一直在不断发展，没有停歇。他不是停留在某个单一的理念上，然后试图迫使外部世界来适应这一理念。相反，他高度重视正在试图解决的问题的整体，对各种可能的不同解决方案保持开放的态度，通过实践不断地对它们进行检验，并反思其中的有效机制。在他的这本新书中，读者可以看见他经由这种方法所取得的成果。
显而易见，只有当方向正确了，速度才是最有用的。我相信大卫正在正确的方向上前进。这本关于看板系统的最新著作，令我特别激动。我在研究中也屡屡发现，较之TOC，精益制造中的诸多理念对于产品开发更为直接有效。事实上，在2003年10月，我写信给大卫时就曾提及，“TOC一个最大的不足之处，便是它忽略了‘批量规模（batch-size）’的重要性。如果第一优先级是找到和减少约束，那么一般而言，你正在解决的是一个错误的问题。”现在，我仍然相信这个判断是正确的。
2005年我们见面时，我再次鼓励大卫超越TOC中“关注瓶颈”的思想。我向他解释说，“丰田生产方式 （Toyota production system，TPS）”所取得的巨大成功，与发现和消除瓶颈无关。丰田是通过降低批量规模和变异性（variability） ，进而降低在制品库存（work-in-process inventory）来实现效能提升的。降低了库存，便可释放资金占用，带来经济效益，而正是看板这样的“在制品约束系统（WIP-constraining system）”，使其成为可能。
2007年参观Corbis公司时，我看到了看板系统的一个具体实例，令人印象深刻。我向大卫指出，这已经远远超越了丰田式的看板方法。为什么这么说？虽然丰田生产系统经历过反复优化，几近完美，但它用于处理的是那些重复（repetitive）和可预测（predictable）的任务，这些任务的工期和延迟成本（delay cost）是类似的。在这种情况下，使用像“先进先出（first-in-first-out , FIFO）”这样的排程方法是正确的。当在制品达到限额时，在入口处阻挡新工作进入处理流也是正确的做法。但是，当要处理的工作非重复、不可预测、具有不同的延迟成本和任务工期时，这些方法就不是最优的了，这些情况恰恰是在产品开发中必须应对的。我们需要更先进的系统，本书正是在实践细节层面上对这些系统进行描述的第一本著作。
我想先简要提醒读者几点。
第一，如果你认为自己已经理解看板系统的工作方式，那么你理解的很可能就是和精益制造中使用的看板系统一样的那种方式。本书中的理念，远远超出了使用像静态的“在制品限制”、“先进先出调度（FIFO scheduling）”、单一的“服务分类（classes of service）”这样的简单系统。请仔细留意这些差别。
第二，不要认为这种方法只是一个可视化控制系统。使用一块看板（kanban board）的方式，确实能够显著提升在制品的可见性，但这只是看板方法中很小的一个方面。仔细阅读本书，你会找到更多深层的内容。真正的洞见，寓含在诸如“到达和离开过程（arrival and departure processes）”的设计、“不可替代（non-fungible）资源”的管理，以及“服务分类”的使用等方面。千万不要受“可视化”部分的干扰而错过了其中诸多微妙之处。
第三，不要因为这些方法看上去十分简易便生轻慢之心。看板方法的易用性，来自大卫对“什么能以最小的成本创建最大的效益”的深刻洞见。他已经敏锐地意识到实践者的需求，对方法中真正有效的部分给予了高度重视。最简单的方法最不容易遭到破坏，并且几乎总能产生最大的持续性收益（sustained benefits）。
这是一本令人振奋的重要著作，值得细细参读。读者从中的收获，将取决于阅读时的认真程度。对于这些先进理念，本书给出了最好的阐释。祝读者诸君如我一般深享书中的思想和乐趣！唐•雷纳特森（Don Reinertsen）2010年2月7日于加州雷东多海滩（Redondo Beach），《产品开发流的原则（The Principles of Product Development Flow）》作者第一部分导 论第1章解决敏捷管理者的困境
2002年，我是摩托罗拉公司个人通信产品事业部（PCS）手机部门的一名开发经理，公司位于美国华盛顿州西雅图市的一个偏远小镇。我所在的部门原本属于一家创业公司，后被摩托罗拉公司收购。我们开发的是网络服务器软件，面向无线数据服务如空中（over-the-air）数据下载和空中设备管理服务等。这些网络服务器应用软件，和手机上的客户端应用紧密协同工作，是整个集成化系统的一部分；另外需要一起协同工作的，还包括电信运营商的网络以及后台基础设施中的其他组成要素，如计费系统等。公司管理人员无视工程复杂性、风险和项目的规模，为我们的项目完成时间定死了最后期限。我们写的代码是从原创业公司写的代码演变过来的，为了图快，开发人员走了许多捷径。一位资深开发人员坚持认为我们的产品只能算是一个“原型”。为了满足业务的需求，提高生产力和质量对于我们而言已迫在眉睫。
2002年，我在日常工作中和写作前一本书时，一直在思考我所面临的两个主要挑战。第一，如何实现现在敏捷社区所称的可持续步调（sustainable pace），保护团队免受业务部门提出的无穷无尽的需求的困扰？第二，如何克服其中不可避免的变革阻力，将敏捷方法成功推广到整个企业内？1.1 我对可持续步调的探索
2002年，敏捷社区将可持续步调简单解释为“每周工作40小时”。《敏捷宣言的原则》告诉我们：“敏捷过程倡导可持续开发。出资人、开发者和用户应共同维持一个长期稳定的步调”。两年前，Sprint PCS公司的团队已经普遍认同了我的观点，“大型软件开发是一场马拉松，不是短跑冲刺”。如果要求项目成员在持续18个月之久的长期项目中保持步调，那么绝不能让他们在头一两个月就精疲力竭。必须为项目制订计划、预算成本、进行调度和估算，以确保团队成员每天合理的工作时间，避免他们过度疲劳。作为经理的我，所面临的挑战是，在实现这一目标的同时，还要能够确保满足所有的业务需求。
1991年，我首次在一家成立已经5年的创业公司里从事管理工作，该公司主要制造面向个人计算机与其他小型计算机的视频采集卡。我从CEO那里获得的反馈信息是，领导认为我“非常消极”。我们的开发能力已经达到极限，而领导却仍然要求增加更多的产品特性，这时我总是以“不行”断然拒绝他们。2002年以前，我形成了一种明显的模式：一直以“不行”这种拒绝的方式，抵挡来自业务方持续不断和善变的需求。
软件团队和IT部门似乎总会遭遇被其他组织任意摆布的悲惨命运。即使计划已经做得无懈可击、公正客观，这些组织仍然会对他们极尽软磨硬泡、恐吓威逼之能事。即使是基于深入分析、有多年历史数据支持的计划，在这些组织面前也会变得脆弱不堪。大多数团队则是既没有透彻的分析方法，又没有任何历史数据支持，在那些想要迫使他们承诺未知的（通常是完全不合理的）交付期限的权术手腕下，他们无疑势单力薄而只能任其摆布。
与此同时，软件工程师也已经基本上接受了疯狂的进度表和献身工作的荒谬言论，并对此司空见惯。软件工程师好像本不该拥有社交活动和家庭生活似的，这真是莫大的羞辱！我知道有太多人因献身工作而影响了和家庭成员的关系，并因此蒙受了不可弥补的损失。但要人们对那些身处主流的软件开发极客（geek）表示同情却很难。在我居住的美国华盛顿州，软件工程师的年收入仅次于牙医。就像20世纪20年代福特汽车装配线上的那些工人一样，其收入是美国平均工资的五倍，由于他们的报酬丰厚，没有人会考虑他们工作的单调性或身心的幸福感。很难想象，在诸如软件开发这样的知识工作领域会涌现出劳工组织；没人会从根本上去解决软件开发者日常遭遇的生理和心理方面疾病的问题。有些雇主很聪明地增加了额外的医疗保健福利，例如，按摩和心理治疗，偶尔还提供“心理健康”方面的病假，但他们不会去寻找这个问题的根本原因。一位供职于一家知名软件公司的技术作家，曾给出如是评论：“服用抗抑郁药并不涉耻辱，因为每个人都在这么做！”对于此种局面，软件工程师倾向于忍气吞声地接受命令，一边领取令人艳羡的高薪，一边默默承受身心之痛。
我想打破这种模式，想找到一种双赢（win-win）的方法，让我在说“好的”的同时，又能通过促进形成可持续步调来保护团队成员。我想回馈我的团队成员，让他们能够重返社交活动和家庭生活；通过改善环境，让那些开发人员不至于在年纪轻轻时，就因压力过大产生健康方面的问题。所以我坚定决心，尝试做些能改善这些问题的事情。1.2 我对成功变革管理的探索
我思考的第二件事情是，在大型组织中引领变革这一挑战。在Sprint PCS公司以及后来的摩托罗拉公司，我均担任开发经理之职。在这两家公司中，确实都需要创建一种更为敏捷的工作方式。但在这两家公司中，当我努力想将敏捷方法扩展到其他团队中时，却都感到颇为艰辛。
在这两个案例中，我并没有强势要求团队进行变革的权力。我都是应高级领导层的要求，试图去影响和推动变革，但我并没有任何行政职务上的权力。领导要求我在团队中对工作伙伴施加影响，就像我以前在自己的团队中所实施的那些变革一样。但是，那些在我的团队中明显奏效的方法，在其他团队中却遭遇抵制。存在这种阻力的原因，可能有很多方面，但最常见的原因是，其他每个团队的具体情况有所不同，在我的团队中使用的方法，必须根据其他团队特有的需求进行修改和裁剪。到2002年年中的时候，我得出了这样的结论：将某种软件开发过程强行施加在一个开发团队上，是无法奏效的。
一个过程需要根据每种具体情况进行适配调整。要做到这一点，需要每个团队拥有积极的领导者，而这点往往是团队所缺乏的。即使有了正确的领导者，如果没有框架指引裁剪过程来适应不同的环境，我依然怀疑能否发生什么重大的有益变革。如果领导者、教练或过程改进工程师缺乏这种引导，就很可能会基于自己盲目的信仰，主观地将变化强加给团队。这与因强行施加不适宜的流程模板而招致更大的愤怒和反对，是同样的道理。
在我写作《软件工程的敏捷管理》（Agile Management for Software Engineering）一书时，就已经开始着手解决这个问题。那时候我思考，“为什么敏捷开发方法能比传统方法产生更好的经济效益呢？”我试图用约束理论的框架对此进行研究。
在研究和写作那本书时我明白了，在某种程度上，每种情况都是独一无二的。怎么可能每个团队的每个项目会在同一时间同一地点遇到瓶颈呢？每个团队都是不同的：不同的技能要求、不同的团队能力和不同的经验。每个项目也都是不同的：不同的成本预算、进度、规模和风险状况。每一个组织也是不同的：不同的市场、不同的价值链环节。如图1.1所示，对我而言，这可能为研究变革阻力提供了一条线索。如果所倡导的工作实践和行为的变革，并没有带来能够被感知到的实际益处，人们就会抵制它。如果这些变化并没有改善团队成员感知到的约束或限制因素，那么他们一定会抵制这些变化。简而言之，脱离具体情境的变革建议，将会遭到身在其中、了解项目具体状况的工作者的拒绝和抵制。图1.1 为什么“一刀切”的开发方法学是无法奏效的
由此可知，由消除一个又一个瓶颈来不断演化发展出一个新过程，是最好的做法。这是艾利•高德拉特的约束理论（Theory of Constraints）的核心主题。尽管我认识到其中有很多东西可以学习，也感觉到约束理论的那些材料很有价值，但我还是按原定计划继续埋首于我的书稿写作之中。我十分清楚，那本书中并没有提供如何在更大规模上扩展实施这些理念的方法，因为关于变革管理的具体建议，书中几乎没有涉及。
本书第16章，将会解释艾利•高德拉特提出的方法。该方法的主旨是：识别并设法减少瓶颈因素，直到瓶颈因素不再对效能产生约束；消除一个瓶颈之后，又会涌现出另外一个新的瓶颈，如此循环不已。这种方法以迭代方式，通过识别和消除瓶颈，系统性地提升效能。
我认识到，可以将这项技术和精益方法中的一些理念合成（synthesize）在一起。首先以价值流（value stream）对软件开发生命周期的工作流程进行建模，然后建立一个可视化跟踪系统，此后，当新工作“流”经该系统时，通过跟踪其状态的变化，便可识别出瓶颈。在约束理论的基本模型中，具备识别瓶颈的能力是第一步。艾利•高德拉特已经针对“流”的问题（flow problems）开发出了约束理论的一种应用方法，并很别扭地将之称为鼓-缓冲-绳（drum-buffer-rope）。尽管名字有些别扭，但我意识到，也可将一种简化的鼓-缓冲-绳方案应用于软件开发中。
鼓-缓冲-绳一般被看成是拉动系统（pull system）这类解决方案的一个具体实例。正如将在第2章中看到的，看板系统是拉动系统的另外一个实例。拉动系统的一个有趣副效应是，它们通过将在制品限制在一定的数量范围内，来防止工作者的工作量过载。此外，只有瓶颈区域的工作者会维持满负荷，其他人则应该会有富余时间（slack time）。我意识到，拉动系统也许可以解决我面临的两个挑战。拉动系统可以让我逐步实施过程变革，（我希望）它能够显著减小阻力，同时有利于形成可持续步调。我决定尽早建立一个“鼓-缓冲-绳”拉动系统。我想去尝试增量式的过程演化，看它是否既能形成可持续步调又能减小对变革的抵制。
2004年秋，我在微软公司工作的时候，机会来了。第4章的案例分析中将对此进行详细介绍。1.3 从“鼓-缓冲-绳”转向“看板”
在微软公司实施的“鼓-缓冲-绳”解决方案行之有效。变革阻力很小，生产力提高了两倍多，前置时间（lead time）下降了90%，而可预测性则提高了98%。2005年秋，我在巴塞罗那的一次会议上汇报了数据结果；还有一次是在2006年的冬天。我的工作引起了唐纳德•赖纳特森的注意，他专程造访我位于华盛顿雷蒙德的办公室。他想说服我，实施一个完整看板系统的各项条件已经成熟。
看板（kan-ban）是一个日语词汇，英文字面意思是“信号卡”。在生产制造环境中，这种卡片作为一种信号，通知生产过程中的上游工序继续生产。在这种生产过程中，除非从下游工序中获得看板信号，否则每个工序中的工人不准进行额外生产。虽然我了解这种机制，但是不确信将之应用在知识工作领域，尤其是在软件工程中，是否有用或可行。我明白，看板系统可以促成可持续步调。但是，我未曾注意到它作为一种能促进增量式过程改进的方法已享有盛誉。我也没留意到丰田生产方式（Toyota Production System）的创建者之一大野耐一（Taiichi Ohno）曾说过：“丰田生产方式的两大支柱，是及时生产（just-in-time）和有人工介入的自动化（autonomation）。驱动这个体系运转的工具，便是看板。”换言之，看板是丰田公司所使用的改善（kaizen，持续改进）过程的基础。正是这种机制，使得丰田生产方式可以运行起来。据我近五年的经验，现在对此已经确信无疑。
幸运的是，唐纳德取得了令人信服的论据，表明我应该从“鼓-缓冲-绳”实施方法转向看板系统，因为有一个深奥的理由：相比“鼓-缓冲-绳”系统，看板系统可以更为优雅地从一个瓶颈区域中恢复中断。但是，能否理解这点，对读者能否读懂本书来说并不重要。
回顾我在微软公司实施的最后一种解决方案，我意识到，如果一开始将之作为看板系统来看待，其结果也将是相同的。两种不同的方法产生同样的结果，这令我感到非常惊讶。既然过程的最终结果是一样的，就没有必要将之专门看成是“鼓-缓冲-绳”的具体实施。
于是我倾向于使用“看板”这个术语，而不是“鼓-缓冲-绳”。看板已经应用于精益制造（或丰田生产方式）中。相比约束理论，看板的知识体系已经被广泛采纳和接受。虽然看板是一个日语词汇，相比“鼓-缓冲-绳”，其含义也不够明显，但是看板更容易发音，更容易解释，而且事实也证明它更便于传授和实施，因此最终确定使用“看板”这一术语。1.4 看板方法的出现
2006年9月，我离开微软公司接管Corbis公司的软件工程部门。Corbis公司位于西雅图市中心，是一家私人持股公司，主营业务是图像和知识产权。受到在微软公司实施改进所取得的结果的鼓舞，我决定在Corbis公司实施一个看板拉动系统。结果令人鼓舞，由此也产生了本书中所展示的大部分理念。正是这些理念的扩展，包括可视化工作流程、工作项类型、节奏、服务类别、专门的管理报告和运营回顾等，共同定义了看板方法（kanban method）。
本书其余部分将要描述的看板（Kanban）（大写字母“K”开头）方法，是一种渐进式的变革方法，其中采用了看板（小写字母“k”开头）拉动系统、可视化和其他工具，促成将精益思想引入技术开发和IT运营中。这是一个渐进的（evolutionary）和增量式的（incremental）过程。采用看板方法，你可以根据具体情况实施过程优化流程，将变革的阻力降至最低，同时让参与者在工作中能够维持可持续的步调。1.5 看板方法被社区采纳的过程
2007年5月，瑞克•嘉伯（Rick Garber）和我在芝加哥召开的“精益新产品开发大会”上，向55名听众展示了来自Corbis公司的早期成果。同年夏天，在华盛顿特区召开的2007年敏捷大会上，我组织了一次开放空间会谈（open-space session）来讨论看板系统，大约有25人参与。两天后，与会者阿罗•贝尔斯（Arlo Belshee）在一次闪电演讲（lightning talk）中分享了他的“Naked Planning”规划技术。显然已经有其他人在实施拉动系统了。后来，我们组建了一个雅虎讨论小组，小组成员很快就增长到100多人。至写作本书时，讨论组已经有1000多名成员。开放空间会谈的数位参与者承诺，他们会在自己的工作中尝试应用看板方法，且他们的团队基本上都使用过Scrum。那些早期采纳者中，最值得称道的是卡尔•斯科特兰德（Karl Scotland）、亚伦•桑德斯（Aaron Sanders）和乔•阿诺德（Joe Arnold），他们都来自雅虎公司。很快地，他们便把看板方法带到了分处三大洲的十多个团队中。开放空间汇谈中另一位需要提及的参与者是平谷贤治（Kenji Hiranabe），此前他已在日本着手开发看板解决方案。不久之后，他为InfoQ就此主题写了两篇文章，受到了高度关注和重视。2007年秋天，《敏捷项目管理》的作者和敏捷项目领导力网络（APLN）的创始人圣杰夫•奥古斯丁（Sanjiv Augustine）到西雅图访问Corbis公司时，称我们的看板系统是“近五年内见到的第一种新型敏捷方法”。
2008年，在多伦多召开的2008年敏捷大会共计有六场在不同环境中应用看板解决方案的演讲。其中一位是约书亚•克里夫斯基（Joshua Kerievsky），他来自Industrial Logic（一家极限编程的咨询和培训公司），在演讲中他展示了如何根据业务环境来以类似的理念对极限编程进行调整和改善。那年，敏捷联盟提名将戈登•帕斯克奖（Gordon Pask Award）颁发给阿罗•贝尔斯（Arlo Belshee）和平谷贤治，以肯定他们对敏捷社区所作出的贡献。他们俩对看板方法都作出了有目共睹的贡献。1.6 看板的价值是反直觉的
在许多方面，知识性工作是和重复性的生产活动对立的。软件开发和制造业之间的差异在很多方面都表现出很大的不同。制造业具有低变异性（variability）；而软件开发极其易变，它利用变异性，通过设计上的创新来产生价值。软件天然是“软”的，一般能够很容易地以低成本进行变化，而制造业则围绕着很难变化的“硬”件开展工作。
人们怀疑看板系统在软件开发和其他IT工作中的价值，这是十分自然的。在过去这些年中，整个社区已经深切体会到看板方法是一种反直觉的（counter-intuitive）方法。无人预见，在Corbis公司，看板方法能够对企业文化和改善跨职能协作产生很大的作用（参见第5章）。
我希望能够展示“看板确实有效！”我希望能够说服读者，通过采用看板的简单规则，可以提高生产力、可预测性和客户满意度，同时还可以缩短交货时间。与此同时，随着协作性工作的增加，将有助于在整个组织中建立更多更好的跨职能协作关系，从而带来组织文化上的变化。总 结
• 看板系统来自一系列称为拉动系统的实践方法。
• 埃利亚胡•高德拉特的“鼓-缓冲-绳”作为约束理论的一种应用，是拉动系统的实施方法之一。
• 我之所以探索拉动系统，来自两方面的动机：一方面是寻找一种系统性的途径，使团队在工作中实现可持续的步调；另一方面是寻找一种方法，能够以最小的阻力引入过程变革。
• 看板是丰田生产方式及其改善方法的支撑机制，能够带来持续改进。
• 第一个虚拟的软件工程看板系统，是从2004年开始在微软公司实施的。
• 从早期的看板实施来看，结果令人鼓舞。看板确实可以实现可持续步调，通过渐进增量的方式，最大限度地降低变革阻力，并产生显著的经济效益。
• 作为一种变革技术的看板方法，自2007年8月在华盛顿特区召开的2007年敏捷大会展示之后，开始广受社区关注。
• 在本书中，看板（kanban）（小写字母“k”开头）指的是信号卡，看板系统（kanban system）（小写字母“k”开头）指的是使用（虚拟）信号卡实施的拉动系统。
• 看板（Kanban）（大写字母“K”开头）方法指的是自2006—2008年间在Corbis公司涌现的渐进增量式的过程改进方法学。这些年来，看板方法在更为广泛的精益软件开发社区中得到了持续深入的发展。第2章什么是看板方法
2005年4月初的时候，我在日本东京度假，恰逢春天樱花盛开之季。为了欣赏美景，我打算和家人第二次游览位于东京市区的皇居东御苑公园。正是在这里，我受到启发——看板并不只供制造业使用。
2005年4月9日，周六，我和家人走过位于竹桥（Takebashi）地铁站附近的护城河桥，经由北面入口进入公园。周六的早晨阳光明媚，许多东京市民正尽情享受公园的宁静与樱花之美。
所谓花见（hanami），指的是坐在樱花树下一边野餐一边欣赏落英缤纷。在日本，这是一种古老的传统，也是一种感悟生命的美丽、柔弱与短暂的机缘。樱花短暂的生命，也是我们自身生命的某种写照，在浩瀚的宇宙中，我们的生命亦显短暂、柔弱和美丽。
盛开的樱花，与东京市区灰色的建筑形成鲜明的对比。东京市区十分喧嚣，人群熙熙攘攘，声音嘈杂，而公园却宛如水泥森林中心的绿洲。当我和家人跨过护城河桥准备入园时，一位肩上挎着包的日本老人走到我们身边。他从包中掏出一把塑料卡片，给我们每人发了一张。当看见我胸前兜着3个月大的女儿时，他迟疑了下，想是否也要给她发一张卡片。最后老人认为我女儿也需要，于是递给了我两张卡片。老人没有说什么，而我的日语也有限，所以我们没有交谈。走进公园后，我们找了一块地方开始享用家庭野餐。
在阳光的照耀下我们度过了一个愉快的上午，两小时后，我们收拾起野餐的东西，朝位于大手町的东门口走去。近出口时，我们加入了一列在小亭子前排队通行的队伍中。随着队伍前移，我看到人们正在交还塑料入园卡。于是我在口袋里摸索了一会，找到了入园时发给我的塑料入园卡。走近亭子，我看见里面有一位穿着整齐制服的日本女士。我们之间隔着一面玻璃，在台面位置上有一个半圆形的洞，类似于影院或游乐场的入场处。我把塑料入园卡通过柜台上的洞口递给了这位女士。她手上戴着白手套，把我的塑料入园卡接过去后与其他入园卡一起放在了货架上并向我低头微笑致谢。没有收费，也没有解释为什么两小时前进来时要带塑料入园卡在身边。
这些入园卡是怎么回事？如果不是为了收费，何必发一张入园卡？我的第一直觉是，这肯定是一种安防方案（security scheme）。当傍晚公园闭园的时候，只需通过计算所有返回的入园卡，管理员就能够确知是否还有游客在园内逗留。转瞬间，我感觉如果真是这样，那这将是一个非常糟糕的安全系统。如果只给我一张而不是两张入园卡，似乎也可以。那么我那三个月大的女儿是作为行李看待还是作为游客看待呢？在这个系统中，似乎有太多变异性（variability）。有太多种出错的机会了！
如果这是一种安防方案，那么肯定起不到作用，每天都会误报有走失的游客。（顺便说一句，这样的系统不会轻易产生假阴性，因为那样还要生产额外的入园卡才行。这是看板系统很有用的一个基本属性。）与此同时，安防人员可能需要每晚出动，在灌木丛中搜寻走失的游客。不，这种做法肯定另有意图。随后，我明白了，皇居东御苑公园正在使用的是一个看板系统！
这次顿悟极大地启发我跳出制造业来看待看板系统。看起来，在各种管理场景中，看板令牌（kanban token）可能都有用处。2.1 什么是看板系统？
看板（或卡片）的数量，等价于系统设置（核定）的流通能力。一张卡片与一个工作项关联。每张卡片都充当一种信号机制。只有获得一张自由卡片（free card）后，才可以开始新的工作项。这张卡片与该工作项关联在一起，跟随工作项在整个系统中一起流转。当自由卡片没有剩余时，就不能开始额外的工作。任何新到达的工作项必须在队列中等待，直到可以获得新的自由卡片。在某项工作完成后，和它关联在一起的卡片就与之分离而被回收。有了自由卡片，队列中的新工作项就又可以启动。
这种机制就是所谓的拉动系统（pull system），这是因为系统只有具备了处理的能力才能拉入新工作项，而不是基于需求将工作项推入系统中。由于流通中的信号卡数量表征了系统能力，所以只要恰当地设置能力阈值，拉动系统就不会出现过载（overloaded）现象。
在皇居东御苑公园案例中，公园本身就是一个拉动系统，游客便是在制品（work-in-progress），由流通中的入园卡数量限定系统能力。仅当有入园卡可供发放时，新到的游客才能入园。普通的日子，公园接待游客没有一点问题。然而，在繁忙的日子，如假日或樱花盛开季节的某个周六，公园就很受游客青睐。当所有的入园卡发放完时，新到的游客必须在园外的桥上排队等候，等待其他游客离园后回收的入园卡。看板系统提供一种简单、成本低廉和易于实施的方法，通过限制入园人数，来控制园内人数。这种技术可以让公园一直保持良好状态，避免因游客过多或拥挤对公园造成破坏。2.2 把看板应用于软件开发中
在软件开发中，使用虚拟看板系统来限制在制品数量。尽管“看板”的原意为信号卡（signal card），而且在大多数软件开发的看板实施中使用的也是卡片，但这些卡片实际上并没有作为一种信号起到拉入更多工作的作用。相反，它们仅起到代表工作项的作用。之所以称为虚拟的（virtual），是因为并没有使用物理的信号卡。拉入新工作的指示信号，是通过在制品限制指标（或系统能力上限）与以可视化方式表示的在制品数量之差推算出来的。有些实践者通过使用诸如便事贴或位于一块板上的物理插槽来实现物理看板。更多时候，信号是从工作跟踪软件系统中产生出来的。在第6章中，将描述一个把看板机制应用于IT工作的案例。
卡片墙已经成为敏捷软件开发中流行的可视化控制机制，如图2.1所示。无论是使用在软木公告板上钉索引卡片（index card）的方式，还是通过在白板上贴便事贴的方式来跟踪进行中的工作（WIP），都已经是司空见惯的事情了。值得留意的是，这些卡片墙本身并不是看板系统。它们仅仅是可视化控制系统（visual control system）。它们让团队以可视化的方式观察在制品并进行自组织（self-organize），无需项目经理或产品经理的指令，便可自行分派任务，将工作从待办项列表中移向完成状态。但是，如果其中并没有明确限制在制品数量，也不能在系统中发送信号拉动新工作项，那么这个系统并不能算是一个看板系统。第7章中会对此有更详细的介绍。图2.1 一个看板卡片墙2.3 为什么使用看板系统？
后续章节将逐渐说明，通过使用看板系统，我们将团队的在制品工作项限制在一个设定的能力阈值内，根据已交付工作的交付速率来平衡提交给团队的工作需求（demand on the team）。这样做可以获得可持续开发的步调，让所有人都可以实现工作与生活之间的平衡。正如你将看到的，看板能迅速暴露那些影响效能的问题，因此，目前团队所面临的挑战是专注于解决问题以维持稳定的工作流。看板为质量和过程中出现的问题提供了可见性，使得缺陷、瓶颈、变异性以及经济成本等因素对流动与交付速率的影响变得更明显。单就使用看板来限制在制品工作项这一做法，就能促成更高的质量和更高的效能。流程改进和更好的质量结合在一起，有助于缩短前置时间（lead time），提高可预测性和准时交付能力。通过建立稳定的发布节奏，实现始终如一的可靠交付，看板能够帮助团队与客户、依赖的相关部门、供应商、价值流下游合作伙伴建立信任关系。
看板有助于实现组织文化的演进。通过暴露问题，引导组织聚焦于解决这些问题并消除其对未来的影响，看板能促进高度协作、高度信任、高度授权和持续改进的组织文化的形成。
事实表明，通过定期、可信赖、高质量地发布有价值的软件，看板能够提升客户满意度。事实还表明，看板能够提高生产率、质量，缩短前置时间。此外，有证据显示，在演进式文化变革中将涌现出更为敏捷的组织，看板在其中起到了关键的催化剂作用。
本书将致力于帮助读者了解如何在软件开发中使用看板系统，以及介绍如何和团队一起来实施这样的系统，以获得其带来的各项益处。2.4 看板方法模型
为了能够在书中以文档方式记录看板方法（kanban method），我发现有必要正式地介绍模型。自看板出来至今，过去4年中虽然一直在不断演化，但我从来没有想过要进行这样的定义，直到今天。我担心它可能会因此变得僵化，也担心人们将之作为看板过程的真髓而教条式地引用，或者将之作为一种检验“我们在做看板吗”的测试方法，从而形成教条主义的思维模式。我希望，当试图定义看板方法的时候，也能够鼓励大家保持开放性思维，同时我们自己的认识仍将继续深化。我还会在Limited WIP Society（http://www.limitedwipsociety.org）站点上维护看板方法最新的定义。2.5 识别看板方法的应用实施
遵循看板方法的团队，会展现出5项核心特性。迄今为止，这5项特性已经在所有成功的实施实例中展现出来，包括我2004年在微软公司实施的“鼓-缓冲-绳”案例。
1. 可视化工作流程。
2. 限制进行中的工作（work-in-progress）。
3. 度量和管理流动。
4. 明确过程策略。
5. 使用模型来识别改进机会。
看板方法还有5个附加的特性，我们期待能够在看板实施案例中发现它们。所有这些特性已在Corbis公司的实施案例中展现出来，过去2年内，在技术大会上曾展示过的和社区内有文档记录的大部分实施案例中，也已经展现出其中若干特性。
1. 根据延迟（机会）成本进行工作项的优先级排序。
2. 通过服务分类来优化价值。
3. 通过产能分配（capacity allocation）来管理风险。
4. 鼓励工艺和过程创新。
5. 定量化管理。2.6 作为权限授予者的看板
看板并不是一种软件开发生命周期的方法学，也不是一种项目管理的方法。实施看板时，需要当前已经有一些在运行的过程，这样便可应用看板来逐步改变当前运行的过程。
在敏捷软件开发社区中，对于这种提倡增量变化的渐进式方法一直存有争议。争议在于，看板方法建议开发团队不要采用一组预定义的方法或流程模板。但是，围绕两种流行的敏捷开发方法的一部分实践集合，相关的服务与工具行业已经发展起来。现在由于有了看板，个人和团队便具有开发自己独特的过程解决方案的权限，这便有可能削弱对这类服务的需求，产生对另外一套新工具的需求。事实上，看板也确实推动了一波新的工具厂商的兴起，它们迫切地想以一些新工具来代替现有的敏捷项目管理工具。相比较而言，新工具具备更强的可视化功能和可编程能力，可以随时根据特定的工作流进行调整配置。
在敏捷软件开发方法发展初期，各种方法为何有效，社区的领导者们也常常不甚明了。大家提出了生态系统（ecosystems）的说法，并建议实施者遵循全部的实践，否则该解决方案有可能会失败。最近几年，出现了进一步鼓吹这种思维的负面倾向。一些公司已经发布了敏捷成熟度模型（agile maturity models），以设法评估实践的采纳状况。在Scrum社区有一种基于实践的测试，通常称之为诺基亚测试（Nokia test）。这些基于实践的评估方法的设计，旨在推动一致性和遵循度，而否认根据具体情境进行适应性变化的需要。看板方法则允许市场忽略这些基于实践的评估方案，它鼓励多样性（persity）。
2007年，有人到我在Corbis公司的办公室参观看板的具体实施情况。其中和敏捷软件开发社区关系密切的参观者都问及一个具有代表性的问题，“大卫，我们在这里转了一圈，已经看了7个看板，每个看板都不一样，每个团队遵循的是不同的过程，这么复杂，你怎么应付得过来？”对这种问题我一直是不屑回答的：“每个看板当然会不一样，每个团队的情况不同。他们必须演化过程，以适应自己的具体情境。”但我知道，这些过程均派生自同样的原则，由于团队成员都理解这些基本的原则，因此，即使将他们从一个团队转派到另外一个团队，他们也能够适应性地进行调整。
随着越来越多的人尝试看板，他们意识到，看板有助于解决在组织中推行变革管理时所遭遇的问题。看板可让团队、项目和组织展现出更好的敏捷性。我们认识到，在行业中，看板授予了一种权力，允许你创建根据具体的情境进行裁剪与适配的更优化的过程。看板授予了人们联系自身具体实际进行思考的权力。看板授予了人们保持与众不同的权力：你的团队可以不同于同一楼层的团队，可以不同于隔壁楼层的团队，可以不同于旁边建筑里的团队，可以不同于隔壁公司里的团队。看板也授予了人们不死守教科书里那些条条框框的权力。看板方法最大的好处是，提供了一种工具，让我们可以解释（和辩护）为什么与众不同更好，为什么在那种情境下某种与众不同的选择才是正确的选择。受到谢帕德•费尔雷（Shepard Fairey）设计的奥巴马（Obama）竞选海报的灵感激发，为了强调这种选择策略，在为Limited WIP Society设计T恤衫的时候，我选用了丰田看板系统的创建者大野耐一（Taiichi Ohno）的头像作为图案。而设计“Yes We Kanban”的口号，是为了强调人们拥有这些权力。你有尝试看板的权力，你有修改自身过程的权力，你有保持与众不同的权力。你的具体环境是独特的，因此你应该根据自己的业务领域、价值流、需要管理的风险、团队技能和客户需求，进行剪裁、适配和优化，开发一种独特的过程定义。总 结
• 任何情况下，都可以使用看板来限制系统内的某些事物的数量。
• 东京皇居东御苑公园使用了看板系统来控制公园内的游客数量。
• 可供流通的“看板”信号卡数量为在制品（进行中的工作项）设置了限额。
• 当前工作项或任务完成时，信号卡便被收回，用于将新的工作项拉入流程中。
• 在IT工作中，由于没有实际的物理卡片用于传递和定义在制品限额，所以我们（通常）使用虚拟的看板系统。
• 在敏捷软件开发中，常见的卡片墙并不是看板系统。
• 看板系统在工作场所中创建了一种积极张力，驱动大家去讨论问题。
• 看板方法（大写字母“K”开头的“Kanban”）利用看板系统（kanban system）作为改进的催化剂。
• 看板方法要求对过程中的规则进行明确的定义。
• 看板使用来自不同知识领域的工具，鼓励分析问题和探索解决方案。
• 通过不断探索发现影响过程效能的问题，看板方法可以实现增量式的过程改进。
• 可以通过Limited WIP Society的在线站点http://www.limitedwipsociety.org/获取关于看板方法的最新定义。
• 在软件开发行业，看板起到权限授予者（permission giver）的作用，鼓励团队根据具体情境制订过程解决方案，而不是教条式地遵循某种软件开发生命周期过程定义或模板。第二部分看板方法的益处第3章一种成功秘诀
过去10年间，我曾被要求回答这样的问题：“作为一名经理，当你接手一个现有的团队，尤其当这个团队并非以敏捷的方式进行工作，成员能力也参差不齐，甚至已经彻底陷入瘫痪时，应该采取什么样的行动？”通常，我被放在变革推动者（change agent）的管理职位上，因此，我只有面对挑战，发起积极的变革并迅速在两三个月内就取得成效。
作为大型组织中的管理者，我一直没能招聘属于自己的团队。我总是被要求接手已有的团队，以最小的人事变动启动一场变革，来提升组织效能。我认为，对于管理者而言，相比招聘一个全新的团队，这种情况更为常见。
在这个过程中，我逐渐形成了一种管理变革的方法。这种方法基于经验而来，其中包括从失败中汲取的诸多经验教训。这些失败教训，主要是指借助职权强制推行某些过程和工作流程。强制推行的管理方法往往会失败。当我要求团队成员改变他们的行为，去使用某种敏捷方法如特征驱动开发（feature driven development）时，我遇到了阻力。我回应说，大家都无需害怕，因为我会提供必要的培训和辅导。然而，这样做，即使是最好的情况下，我也只能得到些默然的接受而已，而非取得真正深刻的制度化的变革成果。要求团队成员改变行为会令他们产生恐惧，降低他们的自信心，因为其中传达出的信息表明，现有技能的价值已经不再被看重。
我琢磨出了一种用来解决这些问题的方法，我将之称为成功秘诀（recipse for success）。成功秘诀中包含新任管理者对现有团队可以采取的若干行动指南。遵循这些秘诀，能够快速改善团队现状，而来自团队成员的阻力会很小。在这里，我要感谢唐纳德• 赖纳特森（Donald Reinertsen）对我的直接影响，他贡献了秘诀里前面两步和最后一步，以及来自艾利•高德拉特（Eli Goldratt）的间接影响，他关于约束理论的相关著作和五步聚焦法（Five Focusing Steps）极大地影响了秘诀中的第四步和第五步。
秘诀中包含的六个步骤如下：
•专注于质量；
•减少进行中的工作（work-in-progress）；
•频繁交付；
•根据交付速率来平衡需求（demand）请求量；
•进行优先级排序；
•消除变异性的根源，提升可预测性。3.1 使用秘诀
秘诀中的各项内容，是按照技术职能经理能够依之操作的顺序排列的。“专注于质量”列在第一步，因为这是像开发经理或测试经理这样的管理者，或者其上司如拥有类似“工程总监”头衔的管理者，所能单方面控制和施加影响的。沿着列表向下，到“进行优先级排序”这一步，可控制性将逐步降低，而和其他上下游群体进行合作的要求则会逐步加强。优先级排序是业务部门的本职工作，而不是技术组织的工作，因此，不应该是技术经理职责范围内要考虑的事情。不幸的是，业务管理人员没能承担起这一责任，而把工作优先级排序扔给技术经理来做，然后反过来又责备技术经理做出糟糕的选择，这样的事情也相当常见。“消除变异性的根源，提升可预测性”之所以处在列表的末尾，是为了减少某些类型的变异性，必须进行行为改变。而要求人们改变行为是很困难的。因此，最好把消除变异性留在后面，等前面的步骤成功实施且组织氛围有所改变之后再行实施。如同第4章中将会看到的，为了促成那些先期步骤的成功实施，有时候需要先消除一些变异性的根源。其中的诀窍在于，要挑选那些几乎不需要行为改变而能为人们所欣然接受的变异性根源，须从它们开始入手。
试读结束[说明：试读内容隐藏了图片]