关于看板的思考与总结

看板活动是敏捷中非常常见的一项活动，它是用来发现组织内部流程瓶颈的一种高效方式。通过看板的流程和工作内容可视化，可以很快发现整个流程中可能存在的问题。因为工作上的需要，最近重读了《看板实战》一书。结合最近两年在工作过程中的使用，有了一些新的体会，也发现了过往在使用看板中的一些误区。本文通过总结和思考，为未来团队的敏捷化转型做一些指导。

NO.1

为什么优先使用看板来导入敏捷的理念

首先，内容相对轻量，核心只有三大原则：可视化、限制在制品、管理流动。

其次，不改变任何流程，只让流转规则可视化，让每个人的分工透明化，不会给团 队带来新的负担；

再次，通过看板的可视化，让团队决策的可视化，当我们关注看板反馈出来的“味道”时，很容易让成员理解团队的决策以及要解决的问题；

最后，看板活动不需要增加额外的角色。现有的团队成员就足够完成。

因为看板活动内容的轻量，很多人在给团队导入看板活动时，喜欢给出明确的信息，例如应该使用什么样的工作流，卡片应该怎么画，准入准出应该是什么样的。其实这样并不友好。每个团队当下的流程和所需要展示、处理的问题不一样，应该和团队一起共创属于当下团队最适合的内容，在逐步改进的过程中向一些最佳实践去靠拢。除非你对团队的掌控程度很高，否则容易引起团队的对抗性，导致效果不理想。

NO.2

关于在制品（WIP）的定义

书中关于在制品的定义如下：指你手头正在处理的所有事情，包括正在处理的任务、等着被验证或者部署的工作项、还有那些虽然还没开始处理，但已经等在你的收件箱里的事情。这里要注意的是“所有事情”，在实际的工作过程中，我们会额外处理一些非常规的工作项（大量的会议，迭代外的工作、沟通，流程任务等等），虽然不在迭代规划内，但会大量占用你的时间，最好也在建立一类工作项（卡片），让团队成员清楚你在做什么。

在之前的团队中，我差不多有40%的时间用于编码，还有60%的时间用于处理团队其它事务，这会导致在团队的看板中，每个迭代我只有20~30个估时（正常每个迭代成员的估时数在48左右），在观察看板给出的反馈时，好像我一直是“空闲”状态，这样不管对团队决策还是拉动卡片（解决阻塞或者处理时长过长的卡片）都是不利的。所以需要增加一类工作项，把我的所有工作都显示化，也有助于我自己安排优先级。

NO.3

在制品过多带来的影响

在制品过多，也就是你手上的任务过多时，会带来一系列的问题：

1）频繁的任务转换带来的资源消耗（上下文切换）：因为你需要记住当前任务的状态，以便下次回到这个任务时，能够知道处理到哪了（像不像CPU的工作形式），为什么多数程序员喜欢戴耳机？不是因为他们多么喜欢音乐，只是纯粹的不想让人打扰罢了。

2）延迟带来的额外工作：因为任务大部分是延续性的，如果不及时处理，时间一长，往往你自己都不知道当初的具体情况是怎么样的了，为什么要那么处理，导致很多延迟的决策会变的不清晰（例如BUG的解决）。

3）缺少动力：这个很明显，当你看到一堆的待办时，总不会自觉的告诉自己，反正还有那么多事，一时半会也做不完，那就不着急处理。而且会影响其他人的工作进度，因为研发活动会涉及到很多联调、依赖的事，如果某个卡片停滞了，会影响其它人的进度，导致更多的消极情绪蔓延。

4）书中还提到了其它的影响，如增加风险、质量下降等，个人认为影响最大的就是前面三点。

NO.4

限制在制品的活动

前面我们了解了在制品过多的影响，那我们是不是可以限制在制品的数量呢？是不是越少越好？在理想情况下，我们希望做到“单件流”，每个人只处理一件事，上下游顺利无缝对接。在实际的研发活动中，过少的在制品会引起人员的闲置，我们不太可能所有的研发员都投入到一个功能的研发中去（想象一下所有人都去做登录，每个人写几行代码？不可取），过程也会遇到小时间段的阻塞（前后端联调不顺利，后端有人开会去了等等），那就停下来？所以，在制品过少也不行。所以为团队选择合适的在制品数量就成为很大的挑战。书中给出的建议是：团队协商，一般情况是人数*1.5，在最开始的时候，可以选择一个数，试运行一段时间，找出合适团队的在制品数量，当团队成熟后，以20%的速度降低在制品数量，加速流动。

在团队实践过程中，我们更应该关注瓶颈处的在制品数量，所有的工作流程都会存在某个瓶颈，而瓶颈决定了整个工作流的步伐。如果提高瓶颈上游的吞吐率，工作就会在瓶颈处排起长队。在这种情况下，提高瓶颈下游的吞吐率毫无用处，因为这里不会有足够的工作输入。例如我们通常说在敏捷研发活动中，测试最容易成为瓶颈，那就优先提高测试活动的效率（引入自动化、测试左移等方案）

NO.5 关于利特尔法则的使用

在讨论WIP时，不可避免的会说的一个公式：

从这个公式可以看出来，在团队初期，我们很难改变吞吐量的情况下，可以通过减少在制品来的降低交付周期，我们一般会通过对需求端的优化来解决，比如拆分更细粒度的需求，每次交付较少的增量，增加交付频次，来提升团队的信心。

当团队逐渐成熟时，我们的交付周期也会相对固定下来（2周），这时候再降低交付项就不合适了，需要我们提升吞吐量，改进效率。这时候通过看板我们可以很清晰的发现流程的瓶颈点在哪，并加以改进。

NO.6 关于站会和流动

看板上的卡片只有流动起来，才能产生价值，所以我们要关注卡片在通道中停留的时间，限制在制品有利于流动，提高资源利用率。所以在每日的站会上，我们更应该关注右边的卡片，关注卡片是否流动到了最右边（价值现实，一般是待发布），如果卡片还没流动到最右侧，则需要关注原因是什么，是否形成了阻塞。这个和Scrum中的每日站会的三个问题（昨天，我做了什么？今天，我要做什么？我遇到了什么问题？）有些不同。从看板上我们可以很清晰的看到你做了什么。更关心的是遇到了什么问题，卡片为什么还不能流动。

在团队实际的实践过程中，对于每日的站会，我们还是遵循Scrum的玩法，回答三个问题，我们往往更关注的是人，这个有点不太对。我们是否更应该以故事为维度，关注卡片是否移动了。当我们聚焦于人的时候，往往发现不了看板反馈出来的“味道”。因为最终要交付的不是个人的工作量，而是故事。是否可以有新的尝试。期待后续的实践。

在每日站会时，我们还要可以思考以下几个问题，让站会的意义最大化：

1. 我所有的工作项都在看板上了么？

2. 我们在做正确的事么？（推进卡片流动，交付价值）

3. 我们还可以做哪些改进项呢？

NO.7 度量指导改进

最近研发效能的度量一度引发了各路大神的各种讨论，但在大方向上，还是比较一致的，就是关注团队指标，轻个人指标。书中给出了几个看板实践下的常用指标，我记下了团队几个常用的指标：

前置时间=完成整个流程所需要的时间

吞吐量=完成的卡片数量

准时率表现=是否遵守了承诺的发布时间

质量=能否保证质量的发布价值

我们可以根据一段时间内，这些指标的变化来评估团队是否在有序的前进。切记不要在不同的团队之间做比较。因为每个团队都是不一样的。我们需要评估的是我们的团队是否比之前做的更好了。

同时，度量本身不是改进，它只是让问题显示化，所以，我们不要以度量来考核人员，更不能因为度量数据的波动而惩罚成员。否则你将会受到来自度量的反噬（为了度量而度量）。度量的数据是用于过程的改进。

书中还提到了两种强大的可视化方式：变异理论和累积流图，有兴趣的同学可自行查看（我比较熟悉了，就不在这里展开）。

NO.8 看板陷阱

书中给出了几种使用看板的常见陷阱，很有意思，也是我们在实践看板中经常会遇到的问题，这里只列两种，有些需要额外的知识点，在这里不展开，有兴趣的同学自行查看。

第一种：看板最终会变成永不停止的工作流——只有工作，工作，工作。通过增加必要的评审、回顾和计划的节奏以保证这不会发生

我们之前的团队就陷入了这个陷阱之中，大家对于看板逐渐变成了事务记录器，不再反思，不再推进。我们需要有回顾，有庆祝，甚至于有惊喜。

第二种：因为看板只有三个简单原则，没有规定太多东西，这有时会成为停止尝试有益实践的借口，从而使你变得懒惰。

我们使用看板来显示化流程，更希望通过看板来推动问题的解决，在敏捷化的过程中，我们还会有很多有意义的实践可以融入进来，而不是说这不是看板的内容，我们就不玩了。

NO.9

未来团队规划

对于新团队的期待，总结起来其实就三个句话：

以看板为切入点，发现问题；

以Scrum为实践路线，解决问题，提升效率；

以DevOps为长远目标，真正实现敏捷转型

NO.10 停止启动，聚焦完成

最后谈一点，也是个人在这本书中学到的最核心的一点：停止启动，聚焦完成。不是“你开始的越多，就完成的更多”而是“你结束的越多，才完成的越多。”只有完成的事务才能产生价值，切记不要有太多的半成品停留在手上。

书中还有更多有价值的观点值得大家一起来讨论，在公众号中回复“看板实战”，可以下载电子版。期待你读完之后，可以一起进行更多关于看板的讨论。

END