产品战略专家梁宁确认出席AICon北京站,分享AI时代下的商业逻辑与产品需求 了解详情
写点什么

在实践中实施看板

  • 2014-02-25
  • 本文字数:6230 字

    阅读完需:约 20 分钟

在芝加哥精益看板大会上与看板先驱 David J.Anderson 交谈的过程中,我们问他,是否有任何可以深入浅出地描绘看板的快速入门指南。David 建议我们与来自 IT-Agile 的 Arne Roock 博士进行交流。在本次会议上,他是“扩展看板(Scaling Kanban)”议题的演讲者和主持人。他在德国从事敏捷顾问和培训师的工作,著有 30 页的看板手册“停止启动,开始整理(Stop Starting,Start Finishing)”。

InfoQ:根据目前的著作,看板似乎有一些哲学意味。团队如何开始评估它是否是正确的工具,以及需要具备什么条件才能开始实施?

Dr.Roock:最重要的是,要在究竟是否想要改革的问题上达成一致。如果不想改革,那么看板就不适用,因为看板首先是一种改革方法。人们经常把它与项目管理方法或者开发方法混为一谈,但它不是;它是一种改革方法。改革的先决条件只有一个,那就是要有领导力权威 John Kotter 在他的同名著作中所描述的“紧迫感”。

第二件事是,如果大家一致认为要改革,主要有两种策略。第一个是进行革命性改革。那意味着对组织进行颠覆性的巨大改革,这会导致很大的痛苦,但我们希望在改革之后比之前好得多。那不是看板的做法。看板是一种渐进式改革方法。

InfoQ:假设我们一致认为已经做好了改革的准备。我们想做正确的事,如果真需要一场革命性的改革,我们也已经做好了准备,但如果可以通过渐进式改革实现显著改善的话,我们更喜欢这样做。我们希望在改善交付、提高可预见性和透明度方面看到成果。

Dr.Roock:以我的经验来看,在开始引入看板之前,需要在主要目标上达成一致。那意味着需要得到管理层的支持。

也可以尝试采用一种基层“隐形”的方式,只在一个团队中实施,而不让管理层知道。这样做可以获得的成功比较有限,很快就会达到上限。如果想在企业范围内获得真正的成功,就需要管理层的支持了。与管理层进行交流,了解他们试图实现什么,痛点是什么,以及他们想要达到的目标,这一点很重要。

在你的例子里,目标是“获得可预见性和改善交付。”那么,首先要做的是可视化端到端的流程。知识工作有一个大问题,就是看不到也摸不着。如果到一家工厂,可以看到大量的原材料和未完工的产品堆在车间的地板上。但到任何一间办公室看看,看起来都一样;有桌子,有键盘、电话、电脑和许多纸,就是那样。我们看不到自己的工作,那也就意味着很难进行改善。

因此,开始看板首先要做的是工作可视化。有多少工作已经开始,它们都处于什么阶段?有多少开发工作,有多少分析、测试工作等等。

上述过程要非常深入。在许多情况下,人们并不会注意到正在进行中的工作有如此之多,(这意味着工作已经开始,但没有结束。)

下一步要创建意见反馈循环。定期观察流程和工作,在想做的事情上达成一致,以便改善流程。

现在,透明度有了。看到事情堆积在测试栏里,就说明开发速度比测试和部署的速度要快。因此,大家聚到一起,开一个改善研讨会,看看做什么可以理顺流程。

做什么能够消除这一瓶颈呢?首先想到的事情可能是雇佣额外的测试人员。但那通常不是正确的解决方案。也许可以提高进入测试阶段的工作的质量,或者自动化一些事情,或者抽调开发人员做测试,因为开发人员经常能够做这项工作。

因此,透明度是第一位的。意见反馈循环非常重要。大部分看板团队在看板图前召开每日站立会议,他们可以从看板图上看到他们的工作。他们还召开改善研讨会,或者通常称为“回顾”或“改善(Kaizen)会议”。

接下来将是定义某种指标,用于确定前进方向是否正确。

如果目标是提高可预见性以及更快更频繁的交付,那么测量周期时间也许是个好主意。周期时间是从任务开始到结束的时间。之后,观察一下,如果抽调开发团队的一员来做测试会发生什么。或者改变工作划分会发生什么。或者商定一项策略,使正在进行的开发工作不超过两项,测试工作不超过三项。

我们可能还会有其它若干想要尝试的事情。因此,既然有了意见反馈循环和指标,就可以观察一下,如果这是件好事就应该加强,或者如果它不能正常工作,就需要对其进行遏制。

InfoQ:您谈到了看板图,这似乎是核心。我想了解一下看板图的粒度应该多大。是包含从头至尾的整个过程呢,还是仅仅包含开发步骤?

Dr.Roock:从价值流的可控部分开始。如果发起人是开发总监,那么起点应该是开发。看板图将会从某种任务分解分析开始,之后是开发、测试,再之后是与上游流程如产品管理和下游流程如部署的一些接口。

当然,长远看来,我们希望扩展这一界限。我们不想要局部最优,我们想要跨越部门界限的协作。如果上下游的合作伙伴不同意协作,那么把所有这些都列在看板图上也会因为无法控制而没有意义。这一点很重要。

从可控部分开始。不要试图传福音,那不会起作用。起作用的是,如果获得了较好的结果并使之透明化,那么人们就会好奇,而好奇是一个非常强大的工具。人们连续不断地会过来问,“如此频繁的交付,你们是如何做到的?”或者“为什么你们几乎没有 Bug 呢?”然后,我们通常可以看到,看板已经传遍所有团队了。

我们听过 Jimdo 的一次演讲,有一家德国公司,其在线营销团队有看板,其新闻团队、视频团队和合作伙伴团队都分别有看板。当然,每个团队的看板图各有不同,但都遵循相同的原则。那意味着一小步一小步地持续改善。

InfoQ:如何在分散的地区之间扩展看板图?

Dr.Roock:那是一个棘手的问题,但非常有意义,因为当今的许多团队都是分散的。市场上有许多好的看板工具,但是电子工具都各有其优缺点。我会尽可能地设法保持其物理存在。即使有两个地点,也可以使用物理看板图。当然,那样就不得不在团队中同步信息,可以使用摄像头、即时消息和伙伴系统。在伙伴系统中,每个地区都在其它地区有一个联系人。

InfoQ:您所说的联系人是什么意思?

Dr.Roock:在伙伴系统中,每个团队都在其它地点有一个永久联系人。每次改变看板图的时候,比如说将一个标签从开发移到测试,就要通知联系人更新他那边的看板图。现在,可以使用电话或视频会议或即时消息,这听上去是个很大的开销,也确实是。但是,这种交流是必要的。另一方面,可以看到,联系人之间现在开始交流了,并且内容不局限于标签移动,而是跟这样一些事情有关,如“我下周会外出度假,因此请提醒团队其他成员做这做那。”或者“我看到你正忙于这部分代码。我知道它有一些棘手的部分,所以让我给你一些提示。”这样,人们现在可以跨越团队界限进行交流,那真的很有价值。

InfoQ:如果有超过两个团队,他们所在的地区时差非常大,如纽约和新加坡的时差可达 12 小时,那该怎么办?

Dr.Roock:在两个地区可以奏效,但三个不行;我从来没有见过在三个地区还奏效的情况。另一个问题是时差,这会使看板的实施非常困难。

我想指出的是,看板就像一位刻薄的继母;她总是告诉你什么做错了,却不帮你改善。如果在这种情况下应用看板,就会发现,团队分散各处非常痛苦,在这些团队间进行信息同步非常费力。但那就是现实,不管是否有看板。因此,看板只是使这些问题透明化而已。对于地点多于两处的情况,无疑需要一款电子工具。此外还需要大量的带宽用于交流。我已经多次见到这种情况。鉴于人们只通过工具交流,你做到了!人们需要保持交流。当然,面对面的交流好过视频会议,而视频会议要好于电话,电话则好于电子邮件。因此,要确保人们尽可能经常地交流。那意味着要把人一次又一次地送到另一个地方,即使是在新加坡。因此,团队需要有非常好的视频会议设备和好的看板工具。对于组织改革(那是看板设计的初衷)而言,很重要的一点是建立信任。当人们彼此了解时,更容易建立信任。当人们可以看到彼此,互相面对面的交谈,一起喝啤酒,了解一点他们私下的生活,他们是否有孩子,或者他们喜欢哪类电影,那会建立信任,那真的真的很重要。

站立会议是创建此类讨论会的一种方式,那样人们可以定期聚到一起并互相交谈。当然,如果存在时差,那会是个问题,但在任何情况下,这个问题都得解决,这就与看板无关了。

InfoQ:对于跨地区进行站立会议,有标准的解决方案吗?

Dr.Roock:即使存在时差,通常也会有 1 个或 2 个小时的时间重叠。

InfoQ:嗯,不过新加坡的时差是 12 小时,因此,即使他们工作到很晚,也很难每天都做到这一点。

Dr.Roock:是这样的,即使能做到,但由于所处时点不同,精力水平也就不同。这是个棘手的问题。但即使有人得在晚上工作,也需要定期地交流。可以使用轮循机制,使一个人与另外一个团队交谈。

另外,我们要打破界限。我们经常会看到,一个团队在美国,一个在新加坡,在美国的团队说“唉,来自新加坡的家伙妨碍了构建”,反过来也一样。通常,这是一个玩笑的开头,但背后也是有原因的。派代表到其它地点呆几个月,然后使其它地点的代表到这边来,这可能是一个有效的联系手段。

InfoQ:那么现在,假设我们获得了管理层的支持,而为了降低风险,从小处着手是不是更好呢?

Dr.Roock:是的,那是看板的基本思想。从现有条件开始,然后逐步发展。如果要对工作进行可视化,那么可视化现有工作;不要试图可视化目标状态。

我们听了 Daniel Vacanti 的介绍,他是西门子医疗部门看板实施的负责人。他们的做法不同;他们上线了一块遍及整个企业的巨大看板。

但通常,我们从小处着手,然后它会像病毒一样传播,或者一个团队接一个团队地传播。

看板有一个非常重要的原则是这样说的,尊重当前角色、流程和职责。那很重要,它直接关系到我正在谈的渐进式方法。

因此,如果组织内部部门间不协作,或者有确定的管理结构或角色,那么所有这些都需要保留。尊重现状。如果已经有测试经理、架构师、业务经理等角色,则需要保持不变。经验表明,人们并不喜欢我们改变他们的职责、头衔和角色。他们有很多自尊源于其专业角色。如果我在过去的二十年里都从事业务分析师的工作,而现在我们在制定一套新的流程,其中没有了业务分析师的位置,那么我不得不将新头衔打印到新名片上,对此我会很生气。这就是看板起初不这么做的原因。但是,当我们继续我们的旅程,信任开始建立,就可以开始引入那种改革了。

InfoQ:关于看板图上的列,它们的粒度应该多大?

Dr.Roock:看板图上的列应该能够反映团队目前的工作方式。通常,通过听人谈话就很容易发现。他们会说“开发完成了吗;开始测试了吗?”那表明,看板图上应该有一列针对开发和一列针对测试,总之,反映人们的工作方式。我们要有工作流的真实情况。

另一方面,如果粒度太小,就会有太多列,太多泳道,那么看板图就不再清晰了。看板有一条称为“三乘三(three-by-three)”的规则;如果站在看板图前三米的位置,那么需要在三秒钟内就可以知道正在进行的任务。不用阅读每一张卡片,就可以看到事情在哪里扎堆,哪些人没有事做。但是,如果看板图上列太多或者泳道太多,那么团队会开始迷失。(编者注:“列”是指看板图的垂直列;“泳道”是指水平行。)

InfoQ:关于“在制品”(WIP);在 Scrum 过程中,我们有一定数量的故事,我们忙于这些故事,如果不能完成,就把它们带到下一个冲刺,但是,要密切关注还剩多少时间,那样可以根据自己的速度决定停下多少故事。因此,WIP 实际上已经是一个 Scrum 概念。

Dr.Roock:是的,它是。Scrum 是通过冲刺概念限制 WIP。这与看板的做法不同,即便如此,两者的主旨是一致的。在看板中,每一栏或每个泳道或者每个人有 WIP 限制。关键是要平衡需求与能力。我们不希望接受的工作比我们能够完成的工作更多。

InfoQ:假设一个项目中有 10 名开发人员。我的能力是 1,其他人也是如此。那么,我们的 WIP 限制为 10。某个人卡在某件事上后可能会开始另外一件事。如果生产环境有问题,那么我就可能不得不承接另外一件事。

Dr.Roock:你在问两件不同的事。让我解释一下。在看板领域,生产环境问题称为“快速问题”。如果不马上处理这些问题,那么就会付出很高的代价。在这样一种情况下,快速问题会需要打破 WIP 限制,而且会应用一定的策略。例如,面对问题,大家集体应对,并立即作为一个团队处理它们。之后,必须反省,为什们会有如此多的快速问题。可以做些什么来减少那种问题呢?这才是看板方法。

你提到的另一件事是一项工作阻塞了,但那不是快速问题。我会等待另一个团队,因为我需要从他们那里获得信息或什么东西。我可以开始另外一项工作,并打破 WIP 限制,或者我可以使用已获得的“冗余能力”来改善系统。这就是看板背后的理念。WIP 限制是创造冗余的有效方式。冗余能力让人可以做个深呼吸,看一看正在发生什么事,并评估一下,可以做些什么来利用冗余和去除病根。

例如,如果反复遇到同样的阻碍,那么也许需要在那边安排一个人,或者那边的人到这边工作一段时间以便进行知识的转移。看板并不会说明如何处理这些阻碍;它只是说“使用 WIP 限制创造冗余,不要把人用到 100%。”传统的项目管理就是那样做的。总是试图把人完全利用起来,因此浪费了本可以用于流程改善的冗余能力。

InfoQ**:假如我是组织的一名项目经理,我对看板稍微有些了解,并且决定要试一试。而组织并不会投入数千美元来对我进行培训。最低限度,我需要具备什么条件才能开始看板?**

Dr.Roock:我见过使用看板非常成功的企业,他们没有接受任何外部辅导或培训,而只是读了一本书,或者一篇博客,以及订阅了一个邮件列表。那是些小公司,但我认为,如果至少有一个真正有经验的人,那会增加成功的机会。如果这些人来自公司内部,那最好,但如果公司没有这样的人,那么那就是要请顾问的原因了。

通常,我们会以管理研讨会为起点,探讨这样一些问题,诸如究竟为什么要实施看板?是否一致同意采取增量改革?目标是什么?之后,对团队进行培训,从而使每个人都讲同一种语言。什么是列,什么是泳道,如何处理快速问题标签等等。在此之后,我会定期帮助团队仔细反省系统并对其进行改善。现在,那不再是一周五天的全职工作。在开始的时候,它差不多是以两三天为单位的一系列工作,但之后会逐步减少,因为我们正设法积累内部辅导经验。所以,辅导的量不是很大,但会增加成功的机会。

InfoQ:教练应该有多少时间在组织中度过?

Dr.Roock:这个问题通常很难回答,那取决于教练与多少个团队一起工作。如果教练同时与三个或者四个团队一起工作,那么那会是全职工作。但是,如果只有一个团队,最好的策略是每次辅导的量小一些而辅导频率大一些。例如,每周一天比每六个月五天更好。

InfoQ:最后,您还有其它建议吗?

Dr.Roock:我认为有件事很重要。我们使用看板努力实现的目标是了解我们的工作方式,并了解我们的工作。那是看板的一项基本价值。如果一名顾问来到公司,并说必须要做这个和这个,那么他很可能错了。一名好的改革管理人员会为看板实施过程提供便利,使公司里的每个人,尤其是领导者,了解他们的工作方式,因为除此之外非常难以改善。因此,不要只按照教科书应用看板,要设法弄清楚为什么要有 WIP 限制,为什么想要有透明度等等所有这些事。如果做了这些事,那么就会有一个不错的成功机会。

关于受访者

Arne Roock**** 博士是一名精益看板培训师兼教练,他为德国的 IT-Agile 公司工作。他致力于帮助企业使用看板建立看板文化。他写了数篇关于精益 / 看板的论文,并将 _Kanban-Successful Evolutionary Change for Your Technology Business_ 一书译成德文。他是德国第一个 Limited WIP Society 社区的创始人,同时也是“中欧精益看板”大会的董事会成员和组织者。2012 年,他获得了精益系统学会授予的 Brickell Key 大奖。读者可以通过 Twitter 博客或者电子邮件与Dr. Roock 取得联系。

查看英文原文: Implementing Kanban in Practice

2014-02-25 07:293418
用户头像

发布了 256 篇内容, 共 85.6 次阅读, 收获喜欢 12 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营第 1 期第 10 周作业

owl

极客大学架构师训练营

2020双11,Dubbo3.0 在考拉的超大规模实践

阿里巴巴云原生

阿里云 开源 云原生 dubbo

C++语言中std::array的神奇用法总结,你需要知道!

华为云开发者联盟

容器 数组 函数

第十周学习总结

饭桶

Canal 组件简介与 vivo 帐号实践

vivo互联网技术

数据库 分布式 数据存储

CAP理论

DL

什么是物联网?常见IoT 物联网协议最全讲解

华章IT

物联网 IoT

一线大厂欺负程序员?京东单方面辞退38岁P7员工三次败诉

Java架构师迁哥

架构师训练营第十周作业

文智

极客大学架构师训练营

不懂源码?来看看阿里P8亲自手码的Spring源码解析整套笔记,高薪offer唾手可得!

比伯

Java 编程 架构 面试 计算机

架构师训练营第 1 期第 10 周总结

owl

极客大学架构师训练营

Linux 笔记(三): 软件安装

Leo

Linux 学习 大前端

Mac下Docker Desktop配置阿里云镜像加速器

jiangling500

Docker 阿里云镜像加速器

深度剖析,为何C语言在开发领域的地位如此稳固

Philips

Python .net rust C语言 Go 语言

排查指南 | mPaaS 小程序提示“网络不给力”时该如何排查?

蚂蚁集团移动开发平台 mPaaS

小程序 网络 小程序生态 mPaaS

我是如何使计算时间提速25.6倍的

白日梦想家

Python 代码优化 Numpy 代码加速

第十周课后练习

饭桶

揭秘11.11监控排障利器 京东高稳定日志服务深度解析

京东科技开发者

云计算 DevOps 日志监控

《我想进大厂》之Spring夺命连环10问

艾小仙

Java spring 程序员 面试 大厂

源码 | 浅谈Webpack原理,以及loader和plugin实现。

梁龙先森

大前端 webpack

接口测试如何在json中引用mock变量

测试人生路

json 接口测试 Mock

薇娅携手中国航天基金会与我们的太空 带你“益起探月,共舞九天“

智慧公安大数据可视化分析系统搭建

t13823115967

智慧公安二维码定位报警系统开发

t13823115967

shell脚本的使用该熟练起来了,你说呢?(篇一)

良知犹存

Linux shell脚本编写

云算力矿机系统开发,区块链挖矿平台搭建

薇電13242772558

区块链 云算力

身为程序员还记得C语言经典算法(附带答案)吗?

ShenDu_Linux

c c++ 算法 编程语言

Kubernetes初体验--用Kubernetes部署一个Web服务

网管

Kubernetes k8s Web 服务 Go 语言

Mysql数据备份与恢复

张攀钦

MySQL

解密智联招聘的大前端架构Ada

智联大前端

Serverless 大前端 开发工具

「面试必备」最新整理出的腾讯C++后台开发面试笔记

linux大本营

c++ Linux 后台开发 架构师

在实践中实施看板_研发效能_Vikram Gupta_InfoQ精选文章