正确认识看板系统并运用“看板方法”

2022-06-09 11:16:00
乐思行
转贴:
微信公众号
970

自敏捷开发的兴起以来,我们软件开发这个行当就没少听说“看板”这个概念,看板系统之于敏捷开发的使用程度绝对不亚于WBS之于项目管理。如果说我们做软件开发的还有人没用听过看板,那是让人无法接受的;如果说做软件开发的还有人没用过看板,那是让人难以置信的;但如果说这些人都会用看板,那也是妥妥的不可能的。为什么?因为看板太简单太直接了,大家压根就懒得去学,一边看着就用起来。今天我要说的是,看板用好了,它就是一把“牛刀”,它不杀鸡不砍狗,但专治研发流程的协作问题。那么关于Kanban,我们下面一一道来:


一、看板、看板系统、看板方法傻傻分不清楚

为了方便后续的介绍,我们首先来做一个定义上的解释。通常地,大家会下意识地把看板理解成“可视化的板”,又或者把看板理解为看板系统,这都是不够准确的。所以,这里再次澄清一下4个概念,下文也是基于这些概念进行阐述:

看板:看板的原始定义是“信号卡”,对就是信号卡!譬如制造业中还区分为“取货看板”和“生产看板”等信息卡,不过在软件开发中一般就是需求/故事卡片。所以在软件行业中,我们一般直接说需求/故事卡片,或称之为价值项;

看板方法:David J. Anderson 首次在软件开发中借鉴和应用制造业中的看板实践,并总结成为完整的方法体系 – “看板方法”,是一套运用于高效管理软件开发流程的新技术;

看板墙:在看板方法中用到的“可视化的板”,国外称之为Kanban board,我们称之为看板墙;

看板系统:通过看板及其配套运作机制形成了的拉动式生产系统,我们称之为看板系统。

1、看板/Kanban的来源

虽然看板实践广泛应用于当下的软件开发过程当中,但是看板这个概念并不是来自软件行业,而是来自于制造业。在1940年代,丰田汽车公司发明了看板系统,它是鼎鼎大名的丰田精益生产系统 /Toyota Production System的关键组成部分。到了2006年,一位叫David J. Anderson的人首次在软件开发中借鉴和应用制造业的看板实践,并改良总结成为完整的方法体系 – “看板方法”,这才把看板实践引入到我们这个行业来。丰田生产方式的奠基人大野耐一就曾说过:“看板和自动化是丰田生产方式的两个核心工具”,可见看板在精益生产中的重要地位。

2、看板的原理是什么

看板系统被丰田汽车公司主要用来实现订单拉动生产,即有了汽车订单后再启动生产线进行生产,当预计的生产计划完成后,每一步骤的看板上需要标注相关的生产信息,其中包括预计目标、产品数量,这样管理者只需随时观察看板,便可以掌握汽车的生产情况。看板管理最终需要实现零库存的最终目标,所以每一个生产步骤完成之后,需要立即停止生产,汽车生产过程中的各个零件生产环节不同,节奏也就有快有慢,所以这个过程可以使生产快的环节等待生产慢的环节,通过不断改进,优化各道工序的资源配比,就能很大程度上消除等待时间,每一个环节齐头并进,提高生产效率并且消除浪费,达到近乎”零库存“的目标。所以看板系统的原理是根据订单来拉动生产,看板系统本质上就是一个拉动系统。

3、看板解决的问题是什么

知道了这个原理,那看板解决的问题就很明确了,可以说看板就是为了解决准时制生产方式(Just-In-Time)的协调调度问题,针对生产/软件研发过程和资源投入进行全局的系统优化,避免材料和人力的浪费。

4、软件研发下的看板/Kanban方法

然而,产品开发和生产制造有本质的区别。我们可以从精益制造中借鉴思想,但实践上我们却不能照搬,产品开发需要独立的方法体系,而这就是产品开发中的看板方法。上面提到,2006年,David J. Anderson 首次在软件开发中借鉴和应用看板实践,并总结形成“看板方法”这个方法体系。这个就是我们这个行业最熟知的看板方。


二、实践的3个要点

TPS(Toyota Production System-丰田生产系统)是丰田取得成功的关键,而看板就是TPS实现精益生产能力的关键。同样地,看板方法也是实现敏捷开发的极为重要的关键实践,它使得我们的研发过程和完成规则可视化透明化,让我们专注于高业务价值的工作内容,与此同时还在全局的层面上呈现出研发过程中的堵塞并提醒我们对此进行协作管理。下面给大家分享在研发过程中使用看板方法的3个实践和具体经验:

1、流程和规则的可视化管理

设计好研发过程的边界,即起点和终点,以及中间的每一个环节。每一个环节我们用一个纵列来表示。譬如一般的研发过程里,首先,我们会定义为需求-开发-测试-障碍-完成等5个纵列,其中除了障碍纵列之外,其他看板墙上的任务卡片之只能从需求到开发,从开发到测试,从测试到完成,不能跨纵列移动。其次,它定义了一个价值项从一个阶段进入下一阶段所必须达到的标准,譬如我们可以标记开发环节的完成标准是通过了单元测试以及开发评审。通过做到这两点,这样我们就完成了研发过程的标准化并可视化了出来。

2、看板系统的优先级管理

在需求纵列的左边,我们往往会设置一个需求等待区,我们只会把优先级最高的几个需求放到需求纵列,或者为看板卡片本身设置优先级。这样可以团队明确优先级,并让团队专注于完成最有价值的工作,同时避免了团队过早承诺造成了过多返工和无用投入。


3、流程的流动管理/在制品管理

在第一和第二点的基础之上,我们可以通过观察和流动的数据分析,找到当下这个看板系统的瓶颈/堵塞,并不断地优化它。譬如如果是测试环节产生了拥堵,那么一位的提需求和做开发并不是最好的决策,最佳的决策是通过自动化实践优化测试环节慢的问题,或者把开发一部分人力投身于测试中,做更好的资源配置。这时,限制在制品/WIP-Work In Process数目的实践可以对价值流动进行十分有效的管理。这样我们就可以通过限制某一个环节的在制品数目,使得团队更专注于当前目标的价值流动,同时暴露协作过程中的问题,譬如让过去被隐藏的问题,如团队协作不良、需求定义错误、开发环境低效、资源分配不均衡等得以显现。

文末总结

最后,通过《看板和Scrum--相得益彰》中的一幅经典插图,来对照和回顾下上面三个实践。大家也可以动起手来,对照下自己开发过程中用到的看板实践,找找是否存在优化的空间呢? 


文章分类
联系我们
联系人: 阿道
电话: 17762006160
地址: 青岛市黄岛区长江西路118号青铁广场18楼