微软、雅虎都在用的看板工作法,日事清轻松实现
在一个阳光明媚的春天,有个人带着三月大的孩子去公园游玩,在入园口处,公园的工作人员从包中掏出一把塑料卡片,给每个人发了一张卡片。包括他兜中三月大的女儿。
他不知道这卡片用来干嘛,但也没问。在公园阳光的照耀下,度过愉快的两小时之后,他决定带着孩子回家。在出口处,他发现前面排着长队。出园的游客正在交还入园时发的塑料入园卡。工作人员收回了这张卡片,放在货架上。既没有收费,也没有解释为什么两小时前进来要带这张卡片。
那么问题来了,既然不收费,公园发一张塑料卡让游客随身带着出园时又把它收回去为哪般?
难道是为了安保吗?闭园时根据计算返还的卡片,来确定有没有游客逗留?这未免带麻烦,而且出错的几率太大了。难道发现了卡片差额还要返回公园把人从草丛里一个一个揪出来吗。
百思不得其解的他后来想明白了,
这个公园正在使用的,是一个看板系统!
公园发放的塑料卡片有一个固定的数量。仅有当入园卡的数量充足可以发放的时候,新到的游客才能入园。在人满为患的节日或周末,当所有的入园卡被发放完的时候,新到的游客必须在园外的桥上排队等候,等其他游客离园后回收入园卡才能入园。
在公园这个故事就符合了看板工作方法的其中两个重要特点:公园代表了一个拉动系统,而每一名游客都是系统中的在建项目(work- in-progress,WIP)流通中的入园卡的固定数量限定了公园这个系统的包容能力。
这个故事的主角,就是看板方法的创立者David J.Anderson。
Kanban方法脱胎于日本丰田公司的大野耐一所创立的丰田生产方式。不只微软雅虎这样的知名互联网大型公司,甚至从柬埔寨全员仅五人的新创公司到大型的巴西石油公司,阿根廷外包服务商,伦敦、洛杉矶和纽约的传媒公司,以及世界各地其他许许多多公司,每个地方都有团队在使用看板工作法。
要了解看板方法,就需要了解日本的丰田公司生产方式:“及时生产”(JIT:just-in-time)。
及时生产的定义是:
“只在必要的时间以必要的数量生产必要的物料。”
看板方法因为其能够以可视化的方式展示浪费的活动,有助于启动全面的精益变革,成为实施及时生产的的工具载体和支撑机制。
看板工作法是敏捷开发的一种,因此它具有敏捷开发所具有的一切特性:
敏捷宣言
例如敏捷团队要求相互信赖,高度团结。遵循看板方法进行工作的人,整个团队需团结一致保持长期合作关系。团队中每个人都要关注看板系统的整体效能。关注所交付软件的质量和数量、交付频率及交付的前置时间。
而它与其他敏捷软件不同的地方在于,它是基于现状对现有方法做系统的渐进改良,变更阻力小。不需要公司做大的变更。
还记得敏捷开发的当家花旦SCRUM吗?(复习一下:来敏捷一下 | 如何在日事清上实践scrum3.0?)SCRUM方式严格规定了各种角色以及角色的职责分配,而看板并没有这样的要求。看板要求变化越少越好。除了要求团队成员接受看板工作法所追求的理念:限制在制品额度并进行拉式的工作之外,其他所有流程如团队人员、工作内容、工作流程次序均不变。
开始实施看板工作法是一件非常简单快速的事情,只需以下步骤:
稀松平常地找一块大白板,
从左到右把工作流程按顺序画出来,
每个人都选一种颜色的便签,把工作内容写在便签上,
把自己的工作贴在相对应的列里边,表示自己所处的工作流程。
基本的看板就建好啦,是不是非常清楚直观:
很多团队最初都采用如上图的物理看板,但是,也会出现一些问题。例如:
团队中有人远程办公
团队地理上分布多地
允许成员每周有一两天在家工作的团队
这时,物理看板显然无法满足需求。
不仅如此,对于那些期待达到更高级别组织成熟度的团队,使用软件来开展看板工作法是必需的。
利用软件可以更好地进行定量化管理、对多个看板系统、团队或项目进行对比,或者基于可靠的统计数据进行分析,如果想要达到这样的效果,团队一开始就要用软件进行看板工作法。
在日事清的看板里,可以根据需要自由的创建卡片清单,可以自定义你的工作流程、自由添加团队成员。
看板系统采用“拉动”的实践方法。
在看板中,每一张卡片上的任务都代表了一项工作内容。也就是在制品(WIP)。而这些卡片的总数是有限制的,在看板管理中,我们希望它越少越好。
只有获得自由卡片后,才可以开始新的工作。在获得新的自由卡片之前,新的工作需要停留在队列中。
而当一个工作被完成了,与之绑定的卡边被回收,成为自由卡片,队列中因此有新的工作项被启动。
前面的页面截图也可以看出来,通过看板可以直率地看到团队工作流程、每个人的工作任务,以及任务分布,使得信息实现可视化。看板方法还能够以可视化的方式展示浪费的活动,具有很强的暴露问题和提示改进机会的能力让价值产出最优化。
而在日事清中,在这种经典的看板模式基础上,还提供了列表度两种视图,适合多维度查看任务:
在制品指已经开始实施,但是还没有交付,没有产生价值的所有工作项目。
在看板工作法中,要限制WIP的数量。过多的在制品会造成不利的后果,如果开发团队的开发人员平均每人都需要并行处理七八项工作任务,这么多并行任务会带来过多的切换。会延长工作周期。
那么在具体操作中,应该把在制品的数量设定为多少呢?这没有一个统一的标准,要看团队和项目的具体情况,通过团队成员和利益相关者沟通来协商。因为毕竟每个团队的能力、经验不同,每个项目也不同,不同的成本预算、规模和风险等等,因此需视具体情况而定。
如果团队有10名成员,大家都希望同时并行2项任务,那就意味着大家约定好了开发团队的WIP限额为20。
在日事清中,每一个卡片都明确了在列的任务数目,直观地反应了在制品的数量,方便团队把控。
满足规则后才可流转。一个工作项当它满足什么样的条件时,才能被移动到下一个流程节点呢?这个规则需要团队提前讨论确定下来,并进行可视化。而在日事清中,这个规则可以在任务的描述里进行设定:
要策量看板系统有没有被很好地流转,需要策略看板的可预测性。为了体现可预测性,需展示各个工作项是否得到了处理?是否按照目标时间完成了工作?准时交付率如何?应此需要通过数据分析以便发现问题。
日事清在数据度量统计方面提供了强大的功能,团队可以通过数据分析有依据地指导团队的持续改进工作,促进看板的流畅的流转。