Kanban in Action 新书问答-InfoQ

Kanban in Action 是 Marcus Hammarberg 和 Joakim Sundén 的最新著作，介绍了如何用看板结合实际实施管理。其中提到如何使用看板将工作可视化、跟踪进度，限制在制品，以及使用哪些度量指标进行改进。书中同时介绍了一些游戏和练习，可供学习看板原则。

点击这里可以获取本书样章。

Manning 出版公司为 InfoQ 的读者准备了如下特别优惠：“当你购买 Kanban in Action 一书时，购物车中所有货品都享受 40% 优惠。下单结算时，只需在优惠码（Promotion Code）文本框中输入 ‘kanban40infoq’ 即可。只在 manning.com 才能享受此优惠。”

InfoQ：为什么要撰写这本书？它与其他看板书籍有何不同？

Marcus：实际上有个很有趣的故事。当时，Manning 让我给他们打电话，我那时有印象，他们在写一本看板的书。所以我也很放松，因为也不过就是参加个调查。他们的第一个问题是：“在你看来，看板的书中应该包括什么内容？”我是这么说的：《看板方法 : 科技企业渐进变革成功之道》这本书已经可以算是看板领域的圣经了。是它的作者 David J Andersson 将看板引入了软件开发的世界。无论什么新书也达不到这个高度，除非采取完全不同的途径。我希望看到的书，最好从实用的、常见的、每天都能碰到的问题开始，而且要把重点放在这些内容上，理论有一些基本的就可以了。如果要说，可以说是“我们的看板”之类的书。

跟 Manning 的人聊了 45 分钟之后，他们问我：所以，你愿意给我们写这样一本书吗？

我当时目瞪口呆，可能说了“我愿意”，但也拿不准。

（我现在还不知道他们为什么给我打电话。也许是弄错号码了，但我不会说出来的。：) ）

接下来，我想，我得跟 Joakim 一起写这本书，因为这些年来我们一直围绕看板展开工作。

Joakim：Marcus 太谦虚了。过去，我们已经完成了一个很深入的看板指南，在多个大会上做过演讲和展示，形式包括短演讲和整整一天的工作坊。我们已经准备了多年的材料，而且在几百个人身上得到验证。在他特别热门的博客上，Marcus 也写了很多与看板有关的内容。所以，Manning 找他也不奇怪。既然我们一起制定和交付了那么多内容，Marcus 一开始找我加入进来，我觉得也很自然。他这么做我很高兴，这本书能让我们总结过去的经验。我们觉得手上的材料能填充 200-250 页，结果写了 360 页……

InfoQ：你们的书一开始，讲述了一个面临困境的团队的故事。为什么要采取这种写法？

Marcus： 我和 Joakim 都是讲故事这种方法的粉丝，我们读过的很多好书也用了这种手法，比如艾利·高德拉特的《目标》。我们也想尝试那种写法。而且，这种手法也能让我们很好地贯彻我们的理念，保持实用性，只提供“基本”理论。书中一开始的教练课程中，有一个滴答作响的钟，就是这个原因。他们没有时间深入所有细节，但是足够开始动手，知道要解决什么问题。当团队开始解决“尚未意识到的改进机会”（又名：问题），以改进工作流程时，真正的学习也就开始了。 Joakim： 我们写那一章时特别开心，其中到处都是小笑话，某些只有我们两个人懂。我们常常担心，这种方法我们觉得很有趣，但读者不会欣赏我们的幽默和小说技巧。为了收集反馈，我们在多个审读环节加入了一个问题，也让朋友和同事读这本书。有些审读者不太喜欢，但是不少人还是很钟爱这种方法。最后，要保留这种写法也就很快定下来了，不过，我们还是可以保证：你不看这一章，对理解后续章节也没有影响；而且我们还在这一章前面放了免责声明。:)

InfoQ：书中多次提到精益。看板和精益之间是什么关系？

Joakim： 看板在用于精益生产中的日程安排系统。它是在丰田产生的，目的是为了改善生产，方法是鼓励人们持续改进“准时制（Just-in-Time）” 产品和服务生产流程，同时避免导致系统和工人负担过重。主要通过限制在制品、可视化和管理工作流实现。这与看板在软件开发中的使用很像。就像 Scrum 只是敏捷的一部分一样，看板只是精益的一个部分，但是其中容纳了一些精益最重要的原则。 Marcus： 嗯……我觉得这个问题不好回答。因为二者是并行的。看板是一种工具，很多精益实践者和团队都在使用。精益是一种业务战略，其重点关注流动中的工作，要保证其尽可能平滑和快速。你实施精益可以不用看板，也可以实施看板不用精益……但大部分都不这么做。它们还是并行的。

在我个人来说，看板让我开始阅读和学习精益。

InfoQ：你们能不能给 InfoQ 的读者说说，看板中的“板”长什么样子？

Marcus：这主要根据每个人的具体情况而定。这个板还是为了让你当前的、实际的工作流程一目了然。一般来说，它是一系列竖栏，表明当一项工作从左向右流动时，价值在哪些地方加入。假如说工作是从上流动到下，那就类似“泳道”。还有螺旋板，不同板之间有开关，可以切换到不同的泳道甚至是不同的板，等等等等。大多数还是使用竖栏方式。你需要展示真实的工作流程，而不是梦中看到的，或是要写在正式文档中的。要保证尽可能接近真实情况。

一般来说，尽可能把整个流程放到上面去，这样总没错。就算有些步骤是第三方团队或利益相关者完成，也没关系。在我们的故事中，Kanbaneros 团队与部署代码的团队不在一起。但 Kanbaneros 团队还是决定将其作为一栏展示在他们的板子上，展示出他们在等待的工作。也许这能引发一些讨论，看看是否有助于改进整体流程。

哦对了，最后还要提醒，要用马克笔在白板上画，这样很容易调整。而且要经常调整。因为这个板子也只是“目前的最佳状况”。我们的目标是要改进流程，并将其用可视化方式展示。

InfoQ：看板和 Scrum 中的板子有何区别？为什么存在这些区别？

Marcus：最主要的区别在于：Scrum 中的板子在每个 sprint 之前都会重置。在 sprint 开始，你会把所有打算在 sprint 中完成的工作放上去，放在第一栏（待办、Todo）中。在 sprint 之中，工作会在板子上流动，并在最终栏（Done、Completed、完成，或其他什么名字）中终结。然后，板子就会用于下个 sprint。看板不会主导 sprint，所以常见情况是，它更像是持续的工作流程，只要板子上还有地方，而且没有超过在制品 WIP 的限制，我们就会向第一栏中加入新工作。

还有一个可能存在的区别：

看板有可能存在更多竖栏，流程细化程度更高。很多 Scrum 团队使用 Todo、Doing、Done 三栏，详细的拆分放在将每个工作项拆分为具体任务上。

看板一般都有某种在制品 WIP 限制，用来限制某个竖栏或者整个板子中的工作数目。这在 Scrum 团队中也有，可能团队只会为下个 sprint 拉动合适数目的工作，如果他们觉得合适，而且没有其他情况的条件下。

我的经验中，看板变化更频繁，而 Scrum 板子则不是。这只是我的经验，当时不是说 Scrum 团队就不能这么做。我们曾经这么传授 Scrum。我有这么一些客户，他们在参加过 Scrum master 的课程之后，就会说：“Scrum 不适合我们。我们不能用 Todo、Doing 和 Done。我的老师说那是 Scrum 中板子的样子。”不！你要自己决定它长什么样子。

Joakim： 我想强调的是，这些区别是我们在所谓“我们实施 Scrum”和所谓“我们实施看板”两种团队之间发现的常见区别。我们将看板视为某种“元过程（meta-process）”，你可以将其应用到任何事情中，所以“正确的”描述方式可能是：“我们用看板实施 Scrum”，或者“我们从实施 Scrum 开始，同时是用看板，现在，我们已经转而使用持续的‘准时’规划来完成 Sprint 规划，所以我估计我们也不能说是在实施 Scrum 了”。把二者结合起来没有问题，不过我的经验是不太可能出现这样的情况：Scrum 团队已经拥抱了看板，但还是死抱着 Scrum 教条不放。看板内在的持续改进和实用主义，会引导他们定制自己的流程。

InfoQ：真实看板和数字化看板之间的主要区别是什么？是否有方式可以结合？

Marcus： 这个问题有点儿难啊。。。一个是真实的，另一个。。。实际上，说到看板，这是我们被人问得最多的问题。我觉得有两个重要差异：

真正的看板，你可以摸到它，比起浏览器里面的一个标签页，更有存在感。即便我们已经解决了大屏幕投影的问题，我还是对真实的、一整面墙的板子更“有感觉”。

每种工具都存在局限。说到看到什么，以及如何可视化，真实的看板局限更少。虽然现在有些比较新的看板工具还不错，可以做很多自定义（比如 LeanKit 的看板，网址 http://leankit.com/，良心推荐），但总是有限制。

话虽如此，数字化看板可以很快创建很多数据和统计，又不费力，还能保证大家遵守你提出的原则和方针（比如，如果违反了某项原则，就无法把一个卡片插入到某列中）。

我们经常这样建议：不妨先从真实看板开始，等适应差不多了，再切换到数字化看板。使用工具，而不是让工具使用你。

Joakim： 我都喜欢用。喜欢真实的，因为它们更容易持续改进，它们的信息更易于获取，而且鼓励协作；喜欢数字的，因为分布式团队和项目干系人可以参与进来，同时更容易产生度量数据。有人认为：同时维护真实看板和数字看板太麻烦了。我想这是因为开发人员太过坚持 DRY 原则（Don’t Repeat Yourself），而且过于执着于只能有一个数据来源。（也许，只是也许，因为他们面对“事务性”工作总是要羞羞地跑开……）但如果认真考虑各自的本质，以及你想要解决的问题，你大概会意识到：两者的目的不同。我觉得：真实看板可以用来促进协作，鼓励面对面沟通，在团队中培养责任感。每天花几分钟复制一些句子，这占用不了多少成本。而且也完全没必要一字一句地复制，只需要有用的信息，支持不同工具各自的目的即可。也许你只需要在一种工具上维护概要工作项信息，另一种工具才维护详细工作项信息？

InfoQ：对于限制在制品、增加产出，你们能列出一些做法吗？如何使用在制品支持这样的目标？

Marcus：这是一个常见问题，因此，我们用了整整一章——第六章——讨论它。我觉得，最重要的是：在制品限制没有永远正确的数字。在制品限制只是一种工具，你能用它来改进工作流。在制品限制越低，工作流动越快，因此，限制数字越小越好。但是，这个数字越小，你的流程中问题浮现得就越快。这就是某种希望的信息：你会遇到困难！或者我们称为“尚未意识到的改进机会”。之所以这么说，是因为如果你解决它们，你的流程就会更快、更流畅。接下来的问题就是，那你该做什么？

有些团队为整个看板设置了在制品限制，但是卡片可以位于板子上的任何位置。在制品限制越低，需要的协作就越多。5 人团队的在制品限制可以设置为 4，否则就会有人空闲。（当然不是说空闲就不好，有时候需要一些放松时间，这样才能有改进的余地。）

更常见的做法，是我们在流程中为一栏（或步骤）或多栏（步骤）设定在制品限制，这样就能保证不会导致某个步骤负担过重。也许是因为我们只有一个测试。为了确保工作流能稳定进入他的环节，我们为他设定了一个合适的在制品限制：3，也可能是 2。当他所在那一栏工作量饱满之后，工作就会堆积，其他人就能得到明确信号：出现瓶颈情况。他们就会过来帮助他，而不是继续往可怜的测试人员身上堆积过多工作。

另一个常见做法，是限制一个人的头像只能出现在特定数目的卡片上，而且不能存在没有头像的卡片。这可以保证没人选取了太多工作。 Joakim： 总而言之，你必须学着停止开始太多任务，开始完成更多任务。这很简单，但也很复杂，因为这就意味着你必须要说不，不仅对其他人，也是对自己。当人遇到障碍或者必须等待其他人时，有新任务跳出来就马上选走，这种事情很容易发生。不如多花时间想想如何避免未来被阻碍，甚至现在就试着搬走自己的障碍。

InfoQ： “蜂巢方法（swarming）”可以用来移除障碍。能详细介绍下吗？

Marcus： “蜂巢方法（swarming）”源于（非）著名的“安灯拉绳（Andon cord）”装置，世界上很多精益工厂中都有。基本上，就是说如果你遇到阻碍进度的问题，你拉下灯绳，人们就会过来帮你清除障碍。在绝大多数（其实就是所有的）软件开发团队中，我都没见过灯绳，而是遇到问题时，就找人来帮忙。没有灯绳，但是背后的理念是一样的。

本质上，我们十分重视阻碍我们流程的问题，我们会放下手中其他的一切，前来协助。这是很好的建议，因为受到阻碍的不仅是某个工作项，而是会造成一个瓶颈，导致流程中的工作堆积、停滞。要是仅仅傻傻地等，那就会创建更多在制品。

最后，如果你真心想要改进，所有这些阻碍事件都应该认真分析，事后还要反思，这样才能从中学习。为什么会发生这样的事情？我们如何防止再次发生？类似反思中，“五个为什么”是很好的工具。

InfoQ：你们的书中讲到看板中用到的多种估算技巧，能举几个吗？

Marcus： 我们在第九章中列出的技巧，都与相对估算相关。你可以将一个工作项需要的工作量与其他已完成的工作项比较。需要的工作量会给个名字或是数字，比如：S、M、L 或者 1、2、3、5、8、13。规划扑克最常见。这是一种依靠大众智慧的技术，你可以讨论某个工作项，然后每个人在心里估算，数到 3，大家把自己的估算亮出来。如果我们意见一致，就可以进入下一个工作项。如果有差别，我们就会再深入讨论，直到全部达成一致。

我们用过的最快的估算技术，称为“一行卡片”。你把要估算的一个工作项放在桌子上，然后拿出另一个，问团队：“这个更大，还是更小？”如果更大，就把它放在上面，更小，就放在桌子上那张下面。你会继续估算这些工作项，每个都问同样的问题。过一会儿，就能得到一行按照估算大小排序的卡片。现在就可以为不同组的卡片分配大熊啊，对于整体上需要多少工作量，也就知道差不多了。

“中庸法（Goldilocks）” 很有趣，因为它跟估算反着来。我们会将工作划分成我们希望的大小。具体做法是：创立三堆——“太大”、“正好”、“太小”。然后团队为所有工作项投票，决定它们属于哪一堆。所有进入“太大”的，最后会切分成“正好”。所有进入“太小”的，最后会合并到“正好”中。

InfoQ：你们曾经说过：“使用看板后，过上一段时间就不需要规划了”。能够说明原因？

Marcus：我们很骄傲，因为这是第一本写到“不需要估算”的书。在估算那个章节中，这也没啥奇怪的。不需要估算，背后的理念是试图找到某种软件开发方法，其中不需要估算。举个例子，如果你的交付周期很短（我指导过的某些团队，最多只需要几天），业务人员就会认为没必要估算了。只要说“大概就是我们上周完成的报表功能那么多”，也就够了。如果认真想想，会有哪个终端客户（不是业务需求人员或是项目经理，而是真正的终端客户）会打电话给公司，然后感谢你们的估算很准确吗？或者需求文档写得很棒？或者感谢你们所有的会议？

所有这些只是我们现在的工作流程。从客户角度来看，这些都是浪费（另外，如果它们不是浪费，那就有价值，要真这么想那就多做这些活动吧！），我们应该尽量扩大产出。也许可以少花些时间做估算？不妨试试看效果如何？

Joakim： 看板会驱动团队将工作项变小，而且大小趋于一致，这样它们才能在工作流中顺畅流动。看板社区中，大家都喜欢跟踪工作项交付周期，有些工具内置预测和模拟支撑，所以基于历史数据更容易得到出色的预测。

大型规划会议中，工作项会批量讨论，用持续的“准时制”讨论单个工作项取而代之，可以缩短规划时间。这种做法也使得计划的定制更容易，从而满足不同上下文和不同团队，规划活动也就没那么有破坏性了。

InfoQ：每种方法都有自己的问题或缺陷。那么看板呢？你们如何应对这些问题。

Marcus： 看板天衣无缝，完美无瑕！：) 真的，我们在一开始说了：看板是业务流程改进工具。其中只是一些很简单的原则。“缺陷”是：面对阻碍你改进的问题，你必须采取行动。下定决心改变当前的情形，很难，而且需要勇气和毅力。不是所有组织都愿意这么做。特别是当看板开始质疑最顽固的想法，或者是质疑“我们一直以来的工作方式”的时候。

无数次，我指导或是身处的团队开始停止反思，停止遵循在制品限制，甚至停止使用我们创建的可视化工具。这是因为一直处于改进状态需要努力工作。人们都需要足够好的理由才能这么做。 Joakim： 是的，有时候，看板似乎是团队的一条出路，因为他们不愿意花时间和经历去适应 Scrum 或是 XP 之类的方法。“咱们还是让即时贴都待在墙上，并称之为看板，然后就这样吧。”不结合其他优秀实践，看板会让你对于改进什么不知所措。所以，一定不要停止可视化，要确保执行在制品限制，也要了解其他方法和实践。这就是我们要在书中加入“看板进阶”部分的原因。

关于书籍作者

Marcus Hammarberg：让敏捷在实践中发挥作用，这是他的座右铭。一直以来，他也因此对下列东西感兴趣：精益、TDD、看板、实例化需求、Node、持续交付、NancyFx 和 Koa。现在，他已经离开软件开发领域一段时间，转而为印度尼西亚的慈善机构救世军工作，试图帮助他们的医院变得更加有效。