第一次接触到看板这个词，还是在今年8月2日敏捷开发模式交流的技术沙龙上。听质量团队的同事在台上侃侃而谈，我觉得看板应该是一个比较不错的敏捷开发模式；虽然有心学而应用之，但苦于目前的项目并不适用于敏捷，因此听完也就完了，并没有打算立刻进行深入的研究。但是没过几天，在读《软技能:代码之外的生存指南》（Sonmez，2014）这本书时，又看到作者在”我的私房‘生产力提升计划’”（My personal productivity plan）这一章中又提到了Kanban（即看板¹），于是下决心打算仔细学习一下看板方法。即使现在暂时用不到项目上，但是没准可以应用到自己的工作学习中；而且谁知道以后有没有可能带敏捷的项目呢？知识嘛，达时可兼济天下，穷时可独善己身，就是这个道理。

很快找到相关书籍，一读之下才发现自己对看板方法的很多理解都是错的。就拿看板这个名字来说吧，看板中的板居然不是我们一直认为的白板……惊讶之余，不禁好奇：难道只是自己对看板方法理解有误吗？在中文互联网中搜索了一下，发现与我犯同样望文生义错误的人还不在少数。于是打算就看板方法写两句，以复看板本义。

1. 引入看板方法的是与非

未深入研究之前，我原来一直以为看板方法是为了让软件开发更加敏捷、快速、高效而设计出来的。但是，在看板方法的圣经——大卫•J•安德森²所著的《看板方法:科技企业渐进变革成功之道》——的第一章”解决敏捷项目经理的困境”中就赫然写到，安德森将看板方法引入软件开发行业，是为了：

• 保护团队免受无穷尽需求的困扰（protect team from the incessant demands）
• 实现一种可持续发展的节奏（achieve a sustainable pace）

没错，这就是大卫•安德森将看板方法引入软件开发的初衷，也是看板方法的终极目标。

要理解这个目标，我们还需要回到看板方法的起点。

2. 看板方法原则的是与非

2.1 看板非板 —— 看板方法的缘起

看板方法源于日本制造业，目的是降低不必要的库存、实现按需制造。为了让读者理解看板的含义同时避免过多使用制造业术语，安德森在书中用他在日本游览皇居东御苑公园的经历给看板方法最核心的思想做了一个简单的类比介绍。

那是一年的樱花季，去御苑公园的人很多。安德森与众人一起排队入园。在入园的时候，工作人员交给他一张小塑料卡片；待安德森离开时，又有工作人员管他收走了那张卡片。没有人向安德森解释这张卡片是干什么的。这肯定不是为了查票，因为公园是免费的。安德森忽然意识到，这是一个简单的看板系统。这个小卡片，是用来限制公园接待游人数量的。当游人数未达预先设定的接待能力上限（即卡片数量）时，游人可以随来随进；但达上限后，只有当一个游人离开公园归还卡片后，下一个等待入园的游人才能持此卡片入园。

安德森原来就了解制造业的看板方法，但从来没想过在软件行业进行应用。御苑公园的游览经历让安德森看到了看板方法在其他行业中应用的可能。所以，就有了我们现在讨论的看板方法。

至此，我们可知：所谓看板（Kanban）³，是源于日语的一个词汇，在这里指的是那个塑料卡片。从此不难看出，看板更接近于计算机术语中的令牌，而不是我们一般理解的白板（board）。

所以我们说”看板非板”。

那为什么我们又说”看板有板”呢？这里，我们要从看板方法的实现说起。

2.2 看板有板 —— 看板方法的实现

在使用看板方法前，需要先构建适用于本项目的看板系统⁴：

1）定义看板方法所控制的范围，定出起点与终点
在我们一般软件开发工作中，一般以接到需求为起点，投产上线为重点

2）按照工序，画出各工序的泳道图
这里给大家画一个简单的示意图：

3）定义各工序的在制品上限
“在制品”是从制造业中借用的词汇，其英文为Work In Process（WIP），也主旨就是我们上文介绍的看板令牌。

我们按最简单的每人WIP为1计算，那么当需求分析有1人、开发有4人、测试有2人时，需求分析、开发、测试的WIP分别就为1、4、2。

好了，最简单的看板系统已经构建好了，那么我们可以让该看板系统流转起来了：

1）业务人员提了6个业务需求，每一个需求分配了一个看板令牌：

2）需求分析人员看到自己的WIP未达上限，从需求队列中取一个需求（看板令牌）过来，其他工序人员由于前序工序的产出队列中没有交付品，因此暂且等待：

3）需求分析人员分析完成后，将看板令牌从”分析中”队列放到”完成”队列中，开发员看到后，立刻将其拉入其”开发中”队列；需求分析人员见自己的WIP又低于上限了，就又从需求队列拉进来一个需求：

4）上述工作不断循环直到如下场景：

需求分析员将第五个需求分析完了，放入其”完成”队列。但这时开发员还都未能完成开发工作，其WIP已达上限4，因此不会从需求分析-完成队列中再拉走需求了。所以需求分析人员的WIP因此也不会归零。所以呢，虽然还有一个需求待处理，但是需求分析人员先不用去接该需求，可以享受一点点闲暇了（slack）…

虽然我们并没有将此看板系统流转完，但是聪明的读者朋友应该已经可以从上面的介绍中了解其构建、运转的大致方式了。

我们可以看出：承载上述泳道图的白板是看板方法的流转核心。因此，我们说”看板有板”。

至此，聪明的读者还会有一个疑问：这样处理，确实可以保护开发人员不受过度需求的困扰，但是，这样做（限制WIP，自我管理，产生闲暇）真的好吗？开发员不会偷懒吗？你没在骗我吧？

看板方法确实如上所述，让我们仔细看一下看板方法的原则——“看板限板”。

2.3 看板限板 —— 看板方法的原则

在《看板方法:科技企业渐进变革成功之道》中，大卫•安德森提出了看板方法的五条原则⁵。但作为一篇简介文章，我更喜欢引用《看板实战》（马库斯•哈马伯格，2014）中提到的三条原则（毕竟更精简些，且其本质与安德森的原则完全一致）：

1. 可视化（Visualize）
2. 限制在制品数量（Limit Work-In-Process）
3. 管理流程（Manage Flow）

其中：”可视化”指的就是”看板有板”；”管理流程”是看板方法实施中的一些具体措施，我们在此篇简介中并不赘述；而”限制在制品数量”，即”看板限板”，在我看来才是看板方法的最核心最精髓的本质。

安德森在其著作中承认”看板的价值是反直觉的”（the value of Kanban is counter-intuitive），但在书中他并没有解释清楚为什么这种反直觉的处理（限制WIP，自我管理，产生闲暇）反而能起到激励开发员，促进生产效率的原因。通过仔细拜读安德森的这本《看板方法》、查询相关资料，也通过我几十年从事软件开发业的切身体会，我觉得这要从程序员这一特殊群体本身出发寻找原因。

程序员群体基本符合管理学开创者、”现代管理学之父”彼得 • 德鲁克在其著作《明天的里程碑》（Landmarks of Tomorrow）中对”知识型员工”的定义：”那些掌握和运用符号和概念，利用知识或信息工作的人”（Drucker, P. F. 2011）。

在诸多论著中，管理学家及相关从业者都认为”高自主性”是知识型员工最具代表性的特征之一。

中国人民大学工商管理学院市场营销系系主任江林在其论文《知识型员工的特点与管理》就指出：”知识型员工更倾向于拥有宽松的、高度自主的工作环境，注重强调工作中的自我引导和自我管理，而不愿如流水线上的操作工人一样被动地适应机器设备的运转，受制于物化条件的约束”（江林，2002）。

在中文互联网技术圈影响力颇大的丁香园前CTO冯大辉也在其最近一篇文章中写道：”程序员们希望拥有自主的工作环境…不喜欢条条框框和各种流程制度。程序员们不希望工作过程被监控，也不希望工作环境里有个监工。程序员们需要信任。管理者应该对有想法的技术人员做足够的授权，让他们自己去决定一些事情，多数情况下，他们会做的很棒。公司在进行重大决策的时候，有必要邀请资深工程师参与”（冯大辉，2016）。

此文读者应该都是IT技术从业人员吧？在此，请大家做代入式设想：

作为一个开发员⁶，谁不喜欢自己可以在一定程度上掌控工作内容，自己可以决定去”拉”哪个需求⁷，而不是被业务部门硬”推/堆”一脸的需求呢？

作为一个开发员，谁不喜欢限制WIP所带来的节奏感呢？有了WIP限制的保护，开发员还能较清晰地预知后续的工作内容与工作压力并做好调整。试想，如果没有WIP的保护，在你刚刚拼了老命加班加点几个月搞完一个政治任务时，领导一脸歉然或一脸正气地对你说，”刚才行办会上行长定下来了，XXX需求今年11月一定要投产，咱们再加加油，争取一下”。你会不会陷入一种深渊般的无力感而不由自主地懈怠下去呢？

作为一个开发员，谁又没有点小自尊小骄傲呢？项目组所有人都能从看板墙上一眼看出自己是当前瓶颈所在，别人都因为自己不能及时完成工作而无所事事。那么，用不着领导发话，你自己怎么可能不去拼一拼呢？

等等……

所以，我认为看板方法能在软件开发业中起到神奇的反直觉的作用，恰恰是因为看板方法暗合程序员的”自主管理”的需求。

3. 看板方法实践的是与非

看板方法能在什么样的项目中应用呢？我们这篇文章的最后一个”是与非”就来介绍一下实践看板方法的前提条件。

3.1 敏捷不是实施看板方法的前提

安德森在《看板方法》中”什么是看板方法”章节直接写道，”看板方法并不是一种软件开发生命周期的方法学，也不是一种项目管理的方法”（Kanban is not a software development lifecycle methodology or an approach to project management）。

所以，敏捷不是实施看板方法的前提。

在安德森看来，只要项目实施中遵循了前面提到的看板诸原则，那么这个项目就实施了看板方法。为此，安德森特意提出了”Yes We Kanban”的口号，并以丰田汽车看板系统创建者大野耐一的头像设计了相关海报。在这里，安德森想强调：”你有尝试看板的权力，你有修改自身过程的权力，你有保持与众不同的权力；你的环境是独特的，因此你应该根据自己的业务领域、价值流、需要管理的风险、团队技能和客户需求，进行裁剪、适配和优化，开发一种独特的过程定义”（Anderson, D. J.，2010）。只要你遵循了看板原则，无论你将开发过程定义得多么独特，那你都可以骄傲地宣称：”Yes We Kanban”！

3.2 成熟的员工是实施看板方法的前提

但是，同样的，我也不认为看板方法适用于任何一个项目。看板方法也有其适用前提。在我看来，项目组由成熟的员工构成，是看板方法在该项目中得以完美开展的前提。我这里所谓的”成熟”指什么呢？年纪大？技术能力强？项目经验丰富？情商高？在进一步解释这个”成熟”的含义前，我先给大家讲一个真实的故事。

在我近期带的一个项目中有一个合作公司的员工，70后，计算机系科班出身，毕业后一直从事软件开发工作。要说他，开发经验非常丰富，行里的各种软件知识考试轻易就能拿到高分，私下里无论对软件设计、项目管理工作的见解都比较到位；但是在其实际工作中，经常看到完全有悖于其能力的现象：遇到问题先琢磨怎么凑合怎么糊弄，编个工作计划则紧张得完全不合理。有一次，实在忍不住了，我生气的质问他，为什么要制定这样的计划；这样的计划推行下去，要么不断延期根本实现不了，要么累死几个开发员。他无奈的回答我：”我知道，但是公司就这么要求的，我胳膊拧不过大腿呀”。我继续追问他：”那你就应该把这个人力资源安排和项目时间表扔到你们领导脸上，说爱谁干谁干，反正我干不了。你作为项目经理的职业素养到哪里去了？你作为程序员的骄傲到哪里去了？”。他痛苦地看着我说：”我首先得活着呀”……事后了解到，他因为上大学时未能通过英语4级考试而没有大本文凭，找工作相当困难；所以，无论公司提出什么样的不合理要求，他只能默默接受，难说一个”不”字。

这个员工是一个很好的开发员，但在这个公司工作的他绝不适合采用看板方法。

我们从前面阐述中可以看出来，程序员”自我管理自我实现”的需求是看板方法起作用的核心原因。

那么，好了，管理者们，让我们复习一下马洛斯的需求层级理论吧。

上面提到的那个开发员虽然要知识有知识、要经验有经验，但如果他当前最迫切的需求还是”生理需求”与”安全需求”时，他肯定无法将”被解雇”的顾虑放到一边，而去追求”自我管理自我实现”的。那些对他放弃”职业素养”与”程序员骄傲”的指责，无疑于”何不食肉糜”。

所以，我们说，只有当一个已经”成熟”到不再为底层需求所困扰的程序员，才能去”自我管理自我实现”，才能在外界压力下保持专业态度，才能将看板方法贯彻下去。而一个企业想要实现看板方法，则必须帮助其员工解决其生存、安全的后顾之忧，保护其员工使之不要面对“保证质量与进度而被累死”VS“放弃质量或进度而活下来”的两难选择的时候，才能使其员工”成熟”到看板方法所需的层次。

4. 结语

看板墙/白板确实是看板方法中必不可少的组成部分，但看板方法的核心在于限制WIP（看板令牌）以实现技术人员在一定条件限制下的自我管理。

看板方法的应用，对技术人员，特别技术人员所在的企业提出了更加成熟的要求。

---

尾注

1. Kanban是看板的英文单词，不是汉语拼音。其源后文有述。


2. 大卫•J•安德森（David J. Anderson），是公认的将看板方法引入软件开发行业的第一人。他的相关论著指导着后续看板方法的实施与演进（Wikipedia Kanban (development)）。


3. 看板，在日文中就是”看板”两字（Wikipedia Kanban）。


4. 这里指的不是电子化系统，而是一套工作方式。


5. 安德森在其最新论述中，将其扩充为6条。


6. 这里虽然为了文章通顺仅写了开发员，但实际上这里描述的是一切IT技术从业人员，包括需求分析人员、测试员、应用管理员、系统管理员、项目经理、架构师等，的共同需求。


7. 看板方法有相关class of service机制来保障不同工作的优先级；开发员一定程度上的自主，不会导致业务需求不能按照优先级来处理。本简介文章不展开讲解看板方法的细节。感兴趣的同学可以参阅《看板方法:科技企业渐进变革成功之道》（Kanban: successful evolutionary change for your technology business）或《看板实战》（Kanban in action）等书。

---

参考文献

1. Anderson, D. J. (2010). Kanban: successful evolutionary change for your technology business. Blue Hole Press.
2. Drucker, P. F. (2011). Landmarks of Tomorrow: A Report on the New. Transaction Publishers.
3. Hammarberg, M., & Sunden, J. (2014). Kanban in action. Manning Publications Co..
4. Sonmez, J. Z. (2014). Soft Skills.
5. Wikipedia. Kanban. https://en.m.wikipedia.org/wiki/Kanban
6. Wikipedia. Kanban (development). https://en.m.wikipedia.org/wiki/Kanban_ (development).
7. 冯大辉. (2016). 程序员们希望怎样被管理? 微信公众号-小道消息.
8. 江林. (2002). 知识型员工的特点与管理. 经济理论与经济管理, (9), 58-62.