看不到瓶颈在哪里？因为你的看板没有设置缓冲区

“ 看板追求的最高境界是用户故事的快速流动。要实现这一点，就需要识别瓶颈在哪里。在看板的每道工序间设置缓冲区，是识别瓶颈的重要手段。”

01

—

小明的迷思

小明最近负责一个新项目。刚学习了看板方法的他希望能在这个项目上运用这个新方法。在他看来，看板方法简单易用。

在他的团队里，有一个业务分析员（BA）小董，两个程序员小江和小杰，一个测试员小莫。表面上，这个分配很合理。他们的能力和经验都不错。团队规模也适中，沟通起来应该会很高效。这样的团队，应对这个新项目应该说是得心应手。

小明根据标准的软件交付流程以及团队成员的角色构成，在JIRA上建立了以下的电子看板（JIRA是澳大利亚的 Atlassian 公司推出的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域，如有兴趣，可参阅《敏捷利器 JIRA 和 Confluence，相得益彰》）：

在看板上，从左到右设置了以下的工序：

1. Backlog

2. 需求分析

3. 开发

4. 测试

5. 用户验收

6. 发布

其中，需求分析由BA负责，开发由程序员负责，测试由测试员负责，用户验收由用户负责。

小明也和团队成员讨论了每个人可以同时处理的用户故事数量，大家一致认为，每个人最多同时负责两个故事效率可能最高。

因此，根据这个原则以及团队各角色的人数，他们在需求分析、开发、测试这三道工序上设置了以下的限制在制品的数量：

万事俱备，小明的团队开始了这个项目的交付。

一个月过去了，程序员小江和小杰反映，他们完成开发后，由于测试员小莫没有及时拉走故事，导致那些已经完成开发的故事还停留在开发的工序里。如果这时他们再从需求分析那里拉入新的故事，就会导致开发的工序超过限制在制品的上限，违反限制在制品的原则。但明明这个时候他们是有空余时间去做新的故事的。

小明也百思不得其解，难道限制在制品错了吗？他感觉在整个交付过程中，测试是瓶颈，但为什么看板并没有反映出来呢？

02

—

缓冲区的重要性

在解答小明的问题之前，我们先来简单回顾一下看板方法。

熟悉看板方法的朋友都知道，看板有三个实践：

1. 进度可视化；

2. 限制在制品（Work-in-progress, WIP）；

3. 观察和改善流动。

在看板里，有一个重要的概念叫做“流”（Flow）。看板追求的最高境界是用户故事从左向右快速流动，不在任何一个环节出现滞留的情况。哪里出现了滞留或排队的情况，哪里就是瓶颈。

根据以色列物理学家、企业管理顾问戈德拉特博士（Dr．EliyahuM．Goldratt）提出的约束理论（Theory of Constraints, TOC），任何在瓶颈以外的改善都是徒劳的。

因此，根据“约束理论5步法”，我们应该：

• 步骤一：定义出系统的限制（瓶颈）；

• 步骤二：决定如何充分利用限制；

• 步骤三：依上述决定，让非限制资源充分配合；

• 步骤四：打破系统限制；

• 步骤五：若限制已打破，回到第一步骤。

要改善整体的交付流动情况，首先要做的就是识别瓶颈在哪里。

按照看板方法的第一个实践——进度可视化，由于所有用户故事都以卡片的形式展示在板上，我们应该可以很轻易地看到瓶颈在哪里——哪个环节或工序堆积的卡片最多，哪里就是瓶颈。

然而，别忘了看板方法的第二个实践——限制在制品，根据每个环节或工序最大可同时处理的用户故事的数量限制了可放置卡片的数量。这样也实现了拉动式的计划系统——只有下游有闲置产能才从上游拉入新的用户故事，避免在制品堆积。

但这样会产生一个有趣的现象。像上面小明的故事那样，如果开发和测试的产能不一致，整体上，开发做得比较快，测试做得比较慢。开发完成的卡片（故事），由于测试无法及时拉入，就会在看板上无处堆放。

那么为什么会出现这样的问题呢？

问题就在于，在看板的每道工序间，缺乏一个缓冲区——也就是上一道工序完成后，摆放故事以便下一道工序拉入的区域。

当有了缓冲区后，开发完成的故事就会放置在缓冲区中，如果测试的产能不足，无法及时从缓冲区中拉入故事，故事就会堆积在缓冲区。这样，哪个缓冲区堆积的卡片数量最多，其下游就是整个交付过程的瓶颈。

通过上面的看板，我们很容易看到测试就是整个交付过程的瓶颈。那么我们要提高整体的交付效率，就应该从提高测试的产能入手。很显然，在这种情况下再去提高需求分析或开发的产能（局部优化），是不会改善整体的交付效率的。

03

—

如何设置缓冲区

既然缓冲区对于看板如此重要，那么如何设置缓冲区呢。

答案很简单，就是像上图那样，要设置在每道重要工序之间。

为了实现缓冲区，整体的交付流程要包含一些过渡状态，这些过渡状态就是放在缓冲区里的状态。具体到小明的情况，交付流程应该包括：

1. Backlog

2. 需求分析

3. 开发就绪
   

4. 开发

5. 测试就绪
   

6. 测试

7. 验收就绪
   

8. 用户验收
   

9. 发布

其中，开发就绪、测试就绪、验收就绪这些状态就是过渡状态，应该设置在缓冲区里。如果使用JIRA的电子看板，设置好这些过渡状态在缓冲区中，用户故事便会根据其最新状态自动出现在各工序和缓冲区中。

04

—

总结

看板方法的第三实践是观察和改善流动。要实现这一点，就需要识别整体交付过程的瓶颈在哪里，否则观察和改善将无从下手。在看板的每道工序间设置缓冲区，是识别瓶颈的重要手段。要实现缓冲区，需要在交付流程中加入一些过渡状态。

看板说：

---

每天上百封邮件，看我用看板方法来瓦解

为什么我更推崇看板方法

凤凰沙盘体验——单件流的力量

关于作者

---

刘华（Kenneth）

• 就职于世界500强银行，负责基金服务业务软件开发与交付
  

• 敏捷、精益、DevOps专家

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会等论坛发表主题演讲

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书

购书通道

—

纸质书、电子书在京东、当当、亚马逊等渠道已全面上架，搜索“猎豹行动 硝烟中的敏捷转型之旅”。

当当自营购书码：

京东自营购书码：

有声书已登录喜马拉雅，适合路上听书的你

长按二维码识别收听：

关注公众号看其他原创作品

觉得好看，点个“在看”或转发给朋友们，欢迎你留言。