速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

在实践中实施看板

  • 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:293466
用户头像

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

关注

评论

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

不爱跳槽的程序员集中在8-17k,揭晓中国开发者的真实现状

Java架构师迁哥

Github标星过万!能让面试官满意的Java面试笔记到底有多强?

Java 程序员 架构 面试

这可能是史上最易懂的计算机网络科普文

追谏

面试 大前端 网络协议 科普 TCP/IP

别再纠结“性能优化方案有哪些”了

追谏

面试 大前端

☕JVM技术之旅-带你认识GC回收的原理

洛神灬殇

Java JVM GC GC Root 5月日更

CPU战争40年,终于把Intel打趴下了

Java架构师迁哥

大米“绑上”区块链,江苏为农产品上“身份证”

CECBC

对Spring Cloud+Nginx架构的主要组件不清楚,看这个就好

小Q

Java 学习 架构 面试 微服务

你开25k?我给30k!能让面试官满意的Java面试笔记到底有多强?

Java 程序员 架构 面试

Boss直聘超90W次转发的Java面试题库!已超神

Java架构师迁哥

测试

bilibili

架构师实战营 模块三作业(基于自研集群 + MySQL存储的消息队列系统架构设计文档)

代廉洁

架构实战营

架构师实战营 模块三总结

代廉洁

架构实战营

4.1 Go语言从入门到精通:函数

xcbeyond

函数 Go 语言 5月日更

差点跳起来了!阿里首推22w字Java面试复盘宝典成功助我入职美团

Java架构之路

Java 程序员 架构 面试 编程语言

EOKEX交易所系统开发方案丨EOKEX交易所源码平台

系统开发咨询1357O98O718

从分层架构到微服务架构(一)

元闰子

学习 读书笔记 架构

网络攻防学习笔记 Day4

穿过生命散发芬芳

5月日更 网络攻防

牛客网亲测有效!牛客下载量近百万的Java程序员复盘秘籍真滴强

Java架构之路

Java 程序员 架构 面试 编程语言

卸载 Navicat!事实已证明,正版客户端,它更牛逼

比伯

Java 编程 架构 互联网 计算机

第八大洲环游记(二):中东云计算,异口同韵

脑极体

上线仅仅三小时,豆瓣评分均9.0的“四本程序员必刷书籍”火了

Java架构之路

Java 程序员 架构 面试 编程语言

教你写好技术文章

元闰子

技术人 写作技巧

从理论走向实践,金五银六Java线程池指南已上线,一次性教给你!

飞飞JAva

Java 线程池

【Vue3】起步

德育处主任

JavaScript Vue 大前端 Web Vue 3

GreenPlum数据库介绍

数据社

5月日更

一张漫画解读:程序员为什么会跑路?

Java架构师迁哥

Tomcat 中是怎么处理文件上传的?

AI乔治

Java tomcat 架构 HTTP

马特机器人系统开发具体详情丨马特现成源码开发

系统开发咨询1357O98O718

数字经济如何推动制造业高质量发展

CECBC

教你写好代码注释

元闰子

软件开发 代码注释

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