看板方法系列3:限制在制品原则

今天介绍一下在看板方法中的限制在制品原则,这是看板的核心机制。

1、什么是在制品

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

2、为什么限制在制品

看法方法中强调限制在制品,因为过多的在制品会产生很多不利的影响,例如:

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

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

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

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

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

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

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

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

3、如何限制在制品

限制在制品通常有两种做法:基于列设定在制品和按人员限制在制品

基于列设定在制品我们通常是在列的上方写上这一列所能容纳的最大任务量,如下图

在这看板中,我们可以看到测试阶段已经有三个正在进行的任务和一个带测试的任务,出现了挤压现象,所以我们限制了开发阶段的最大任务项是3,那么当开发阶段的任务达到3之后,就不能再添加开发任务了,从而使得测试列不会再被拉入新的任务。那么如果这时候开发阶段人员出现了空闲,应该做什么呢?

  • 如果开发团队里别的人需要帮助,那么空闲的开发人员应该给予帮助
  • 如果开发者是个全职能人员,那么他应该去帮助测试人员,尽快完成测试任务
  • 另外偿还技术债务也是应该做的,例如项目框架的优化和升级、更加严格的测试代码、技术学习等

按照人员限制在制品的做法,通常要求人员都是全职能的人员,不会按照工作流分为不同的角色,这种限制在制品我们通常是为每个人准备一定数量的头像,例如每人3个,当领取一个任务后,就把头像贴到任务卡片上,头像如果用完了,就不能再开展新的任务了,这时候最重要的就是尽快解决掉未完成的任务。如下图:

可以看到小李和小王还可以再开展新的任务,但是小张由于三个头像都已经用完了,所以他的当务之急就是尽快完成手上的任务。

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

通常我们都是采用基于列的在制品限制,那么到底哪些列是需要限制在制品的?具体应该把数值设定为多少呢?可以告诉大家这没有一个统一的标准,要看具体情况。要通过对看板流转情况的一个动态观察,发现影响看板的瓶颈,从而通过限制在制品解决和避免瓶颈。例如上面的例子,通过观察我们发现测试节点总是出现任务的挤压,这时候测试就成了整个看板的瓶颈,那么有可能我们需要增加测试人员,或者是限制测试任务的输入。所以我们应该在开发阶段限制在制品,那么到底限制为多少呢?这里没有固定的数字,看板开始的前期这个数字应该是经常变动的。一个比较快的确定一个限制数字的做法是:

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

总归应该遵循两点:

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

好了,看板的在制品限制就说到这里把,下一节主要说说看板中管理流动的原则!

留下评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据