深入浅出 Kanban 系列 (1) - 看板和流程可视化

什么是 Kanban (看板)

看板，可以理解为一个具备约束条件，使用拉动方式来改变工作任务状态的流程可视化系统。

有点抽象是不是？请看下面的看板样例，然后我会逐个解释上面几个关键字是什么意思。

工作流和状态变更

这个应该不难理解。当你要完成某个任务的时候，通常都会涉及状态变更。最简单，就只有两个状态，"正在进行"和"完成"，对吧？

在软件开发领域，一个产品或者新功能面世前，通常都要经历几个阶段: 需求提出，需求分析，设计，开发，测试 和 部署实施。这些不同的阶段，其实就是工作项从开始到结束要经历的各个状态的变更。那我们其实可以把它们映射为上面的看板样例中的每一列里。

可视化

工作流程在软件开发领域是非常复杂的，通常要牵涉不同部门的协作。如果在流程中还设置了不少的监管程序，或者管理混乱的情况下，那更是一团糟。

要通过言语来描述整个流程，可能会很罗嗦也未必能说清楚。但是通过像上面的一个那样的板子，其实就可以很清晰的帮助我们看到整个流程是怎么样的，不同的工作任务各自的状态，是否被阻碍，从而看出流程上是否存在瓶颈。

约束

约束在看板里面被称为在制品 (WIP)。这个特点，是看板区别于其它 "卡片墙" 形式的任务管理系统的最大不同点。约束在看板上面就是体现在每一个阶段下的那个数字，它代表了同一时间最多有几个任务可以处于当前阶段。从上面的例子来看，就同时最多只能开展6个开发任务。

对于这个约束，一开始我们可以先简单理解为负责这个阶段的部门里的人数。虽然说很少会限制一个人只能做一件事情，但是先这样来类比的话，比较容易理解。

拉动

其实这是一个很有趣的动词。它是另一个动词推动的反面。我想大多数的开发人员能很清楚的感受到这两个词背后的含义。通常情况下，所有的开发任务都是从上层指派下来的。

但是在看板里面，它强调工作项是必须从下游拉动的。一旦某个阶段的约束条件已经达到，也就是说人员已经满负载在工作了，就不能再接受任何新的任务了。直到手上的工作项已经做完，而且这个工作项被它的更下游接收了，那么当前这个阶段才可以承接上游来的任务。

所以说，这是一个拉动式的系统。不难想象，通常处在最上游的人员更倾向喜欢推动的模式多一些。但是下游肯定是更喜欢拉动的方式。目前大多数的企业和团队应该都是推动式管理的，这主要由于沿袭了过时的管理模式和普遍的上下游的信任问题。这些问题，其实是看板希望能够解决和改善的地方。

如何可视化流程

应该没有人会质疑流程的重要性，但是同时也有很多人讨厌流程。因为那些被人厌恶的流程其实是官僚式的做事方式，它们只会带来低效和扼杀公司的敏捷和创新能力。

通常，因为某些事故的发生，很容易就会在现有的流程上再添加一些所谓的监管性的措施。但是，如果想移除一些既定的流程，那就不是那么一件容易的事情了。 大部分的原因，是基本没有人可以很清楚说明当初添加某个流程的历史缘由，而且也不一定够胆量提这样的建议。一方面，很难证明某个流程在移除后能带来多少好处。再说，作为提议者，一般都会担忧移除后可能带来的后果。所以，请神容易，送神难。

流程的可视化是看板里面首要且最重要的的事情。 通过充分的可视化，任何阻碍项目运行的流程，和可改进的领域更显而易见。同时，流程中耗费的沟通成本，是可以通过可视化去除掉的。你想想，如果看板上面已经把最重要的，各方沟通所需要的信息都反映出来，我们还需要发各种邮件去问一大圈的人吗？

案例

让我们来看看一间公司目前的开发流程:

1. 业务分析人员收集需求，确定优先级和特定的发布日期后，他们再对开发和测试人员进行需求描述。

2. 开发和测试人员根据需求，估算开发和测试要用的时间，并回馈给业务人员，确定哪些需求可以包含在当次发布里。

3. 当开发任务完成，开发人员需要向发布组提出一个发布项目申请。这个申请其实只是一些类似证明文件的东西，来表示这个发布项目已经经过必要的开发测试，安排测试人员，并且让系统和数据库管理团队审批了开发人员要求做的一些系统级变更。

4. 当发布组确认发布项可以纳入当次的发布版本后，开发人员可以申请测试环境的部署。

5. 当测试环境部署完毕，开发小组需要在上面先做集成测试，然后再通知测试人员入场测试。

6. 当测试完成后，如果没有什么重大的问题的话，测试人员就可以通知发布组把项目部署到预生产环境。

7. 测试人员在预生产环境做回归测试看有没有什么问题。
   

8. 当回归测试也完成后，发布组就会做最后的生产环境的上线准备。

注意：整个流程里面，每天或者每周，都会有不同的组发不同的报告出来，统计项目进度和遇到的问题。

先不管这个流程好还是不好，我们可以看到中间牵涉到多少环节和多少部门在里面。每一个环节都通过某种信号来表示当前环节已经完成，然后通知下一个环节的部门和人继续处理下去。我们可以想象，如果中间的沟通是以来各种即时通讯软件或者邮件来达成的话，是多么低效，尤其是一些问题需要涉及多部门来解决的时候。

但是，如果我们把整个流程通过下面的看板可视化出来，所有的部门都通过项目在板子上面的状态来了解它的进度和决定下一步应该是哪个部门要接手处理的话，多少额外的沟通成本可以节省下来啊？

可视化



让我们看看怎么把上面的流程和看板结合起来。看板上面的一张卡片，可以认为是一个需求项或者工作项。

1. 在工作项的优先级确定前，它们全部放在Backlog阶段下。一但确认优先级，就可以把工作项挪到Prioritized阶段。最重要的工作项，应该列在最顶层。这样，不同业务单元之间的任务优先级问题就可以解决了。由于这个公司的流程里，学要求开发和测试做时间的估算，那么，可以在工作项时面加 一些任务，或者把它们包括在Prioritized阶段的拉动前提条件里面。

2. 当工作项的开发完成后，就可以被标记为完成的状态 (卡片的绿色边框)。这其实是一个信号，让下一个阶段的负责人，在有空闲的情况下，拉进下一个阶段进一步处理。

3. 一但发布组审核通过工作项，并部署到测试环境，他们同样可以在RC Request的阶段把工作项标记为完成的状态。

4. 如果开发的集成测试做完了，开发就在Dev-Int Test队段把工作项标记为完成的状态。

5. 同样的做法可以用在QA Test, PP Deploy和PP Regression阶段。

6. 如果说任何一个工作项遇到阻碍，我们可以很容易从卡片的红色边框看出来，并且还可以标记上原因是什么。这样还方便日后流程效率和阻碍项时间占比的分析。
   

所以说，通过看板的流程可视化，我们可以清楚的知道工作项的运行状态。后续处理，阻碍项，负责人都可以很清楚的体现出来。一张图胜过千言万语。

最后，要注意的是，流程的可视化是看板实践里最核心的一步。我们必须反映团队目前的流程，而不是从书本上，或别人的团队那复制一个过来，更不应该是设计一个理想化的流程出来。

结语

到这里，大家应该已经有了看板的基本概念了，如果你还有兴趣更深入了解它，可以读读看板创始人 David J Anderson 的: Kanban: Successful Evolutionary Change for Your Technology Business。为什么上面用了樱花这幅图？看过这本书你就知道了。

想了解更多内容，请持续关注我们的微信公众号：互联网plus管理新范式。点击原文链接，可阅读英文原文。

版权所有，转载请在文章开头注明作者及"转载自公众号：互联网plus管理新范式"，谢谢。