实施Kanban的目的除了上一篇文章中介绍的可视化以外，还有一个重要的目的：在制品限制，本文接下来会介绍什么是在制品限制以及为什么要做在制品限制。

1. 什么是在制品

在软件过程中，那些已经开始，但是还没有交付，没有产生客户价值的工作，例如已经开发的需求分析、正在研发的功能、等待测试的任务、待修复的缺陷等等，这些都是在制品。

2. 为什么限制在制品

• 过多的在制品任务会带来过多的工作上下文的切换，在多个工作间切换就会产生浪费
• 过多的在制品会造成任务的延迟，延迟就会带来额外的工作，例如一个工作早在一个月前就已经开发一半了，但是由于阻塞，没有及时处理，现在又回过头来继续开发时，你会发现你不得不重新编写代码和设计
• 质量下降，同时进行太多的任务，就会造成质量的下降，增加缺陷数量，从而进一步降低效率
• 缺乏动力，任务多了，总是堆在哪里，这样就减慢了你去解决问题和阻塞的动力了

我们可以借助利特尔法则再更加具体看下限制在制品能够带来的效率变化，利特尔法则使用下面的公式计算工作效率和周期：

周期=在制品数量/吞吐量

例如一个团队每个月可以完成的12个任务，那么吞吐量就是12，如果我们在制品数量是12那么可以得到：

周期=12个在制品/吞吐量12=1个月

而如果我们减少在制品，例如6个并行任务，那么：

周期=6个在制品/吞吐量12=0.5个月

可以看到通过降低在制品数量，就能很快的缩短交付周期，加快交付节奏。

3. 如何限制在制品

限制在制品通常有两种做法：按列限制在制品和按人员限制在制品。

3.1.1 基于列设定在制品

我们公司的做法，一般是限制“开发-待测试-测试”三列的故事数尽量维持在3个左右，最多不超过5个。

Kanban

我们做了在制品限制以后，经常会遇到一个问题：开发阶段人员出现了空闲，应该做什么呢？

空闲时间能做什么？

规模化敏捷框架SAFe中对研发、测试和交付的能力要求都比较高，SAFe的叫法是Build-In Quality（内建质量）：

Build-In Quality

所以在做了在制品限制以后，我们的工作流程可以变成这样：

在制品限制以后的工作方式

大家注意上图中红色的部分：

• 后台的同学在做完接口以后，前端（Web、APP、小程序等）同学做开发的时候，他们应该在这时候完成代码的自动化测试、单元测试、代码扫描结果优化等工作；
• 前端的同学可以在后台同学写接口的时候，同步将相关UI做完；
• 测试的同学在其他成员开发的时候，同步完成测试用例、UI自动化脚本的撰写、性能测试等工作；
• 如果开发团队里别的人需要帮助，那么空闲的开发人员应该给予帮助
• 如果开发者是个全职能人员，那么他应该去帮助测试人员，尽快完成测试任务
• 研发的同学需要注意，技术学习和代码优化的工作应该随时进行：例如项目框架的优化和升级、更加严格的测试代码、技术学习等

3.1.2 基于人设定在制品

我们公司采用的小团队敏捷方法是Scrum，团队里的研发和测试人员是不会属于多个团队的，所以只要限制了列的在制品个数，基本也就限制人的在制品，所以我们没有就这个限制做什么特殊的规定。

4. 限制在制品的具体做法

通常我们都是采用基于列的在制品限制，那么到底哪些列是需要限制在制品的？具体应该把数值设定为多少呢？可以告诉大家这没有一个统一的标准，要看具体情况。要通过对Kanban流转情况的一个动态观察，发现影响Kanban的瓶颈，从而通过限制在制品解决和避免瓶颈。这里没有固定的数字，Kanban开始的前期这个数字应该是经常变动的。一个比较快的确定一个限制数字的做法是：

如果某列经常同时有4-5个工作在做，你最初可以将在制品数量限定在8-10个，然后规律性的以20%的幅度将其递减，然后达到一个相对稳定的值，这也是持续改进的开始。

总归应该遵循两点：

• 要很容易的快速找到一个数字，不要因为这个花费太多的时间，上面的这个方法就可以借鉴
• 限制在制品的数值，是个持续调整的过程

好了，Kanban的在制品限制就说到这里吧，下一节主要说说Kanban中管理流动的原则！