生成式AI领域的最新成果都在这里!抢 QCon 展区门票 了解详情
写点什么

与 Mike Burrows 聊他的新书 Kanban from the Inside

  • 2014-11-24
  • 本文字数:5786 字

    阅读完需:约 19 分钟

在他的新书 Kanban from the Inside 中,Mike Burrows 描述了看板方法,探讨了可以使用看板的多种模型,并为组织实施看板提供相关流程。

你可以在这里下载Kanban from the Inside 样章,其中包括书中不同章节的节选,可以大概了解本书。

InfoQ 今年已经发布过 Mike 的三篇系列文章: The Sustainability Agenda in Kanban Kanban’s Service Orientation Agenda 以及 The Kanban Survivability Agenda 。新书出版后,InfoQ 又访问了 Mike,请他谈谈看板的价值、流程和服务分类(classes of service),以及如何组合看板与敏捷、精益创业,并在组织中实施。(这三篇文章不久将发布中文版。)

InfoQ:为什么要写这本关于看板的书?读者从中能学到什么?

Mike: 首先,自从 David Anderson 的那本《看板方法 : 科技企业渐进变革成功之道》发布之后,已经过去四年半了。它经受了时间的考验,但是作为一个社区,那本书出版之后,我们已经经历了很多。因此,现在看来,我们对看板方法理解得更深入了,所以对其可以有更明确的表述。当然总有新故事的容身之处。 其次,我觉得,我们已经达到了某种成熟度和自信,让我们可以退一步,看看看板和其他知识体系之间的关系,特别是系统化思考、精益、敏捷和约束理论。认真实践的人们总是可以从中学到很多,我也一直希望跟他们每个人庆祝这一点(尽管他们的理论根基有共同之处,但我绝不认为他们都是完全一样的)。可能有些读者会对我失望,认为那些对他们很重要的领域,我只是浮于表面,但我觉得值得冒这个风险,因为可以扩大知识面。

我的第三个也是最强有力的动机,是很个人化的。我觉得自己的位置很独特,能够撰写这样一本基于深入的价值观的书,我在此前三篇文章中讲述了这 9 条价值观,大家可以阅读、了解。如果你打算写一本没人会去写的书,激励就不是问题了!

InfoQ:这本书的第一部分谈到了看板的价值观。为什么这些价值观特别重要?

Mike: 空洞、脆弱、画大饼,这可跟价值观半毛钱关系都没有。价值观可是令人意外地强壮、实用。无论我们意识到与否,价值观不仅能解释我们的渴望,更可以解释我们现在的行为。同时,价值观解释了我们期望从自己做事情的方式中得到的东西。透明、平衡、协作、以客户为中心、流、领导力、理解、同意、尊重;在这 9 条价值观中,我不仅可以说明看板方法的相关原则和实践如何发挥作用,同时可以解释成熟实现方法之特点背后的思考。这些价值观因此有助于我们很快记住一些东西。当团队为价值观排定优先级时(使用看板价值观练习看板知其然),他们也是在为实践中的改变排定优先级,当然,前提是他们希望得到相应的好处。当这些优先级在其他某些地方有了强劲的回响后,比如敏捷和协作、精益和、或是系统化思考和理解,你就可以知道应该从哪些其他领域获取灵感了。

反之(这条建议不仅适用于看板),如果某条价值观似乎与当前的主流文化冲突,要想实施其对应的实践,可就没那么容易。去尝试总是不会错,但一般来说,如果变革的动力可以导向其他方向,我们还是建议不要强行推进冲突价值观相关的变革,以避免引起不必要的抵抗。使用大卫·安德森最喜欢的一个比喻,要是能绕过石头,为什么还要试着从中穿过去呢?在这里,绕过石头意味着:要么开始时把其他价值观放在更重要的位置,要么接受对这种情形可能更适合的另一种方法。

InfoQ:平衡利益相关者的利益总是很困难。看板对此有何帮助?

Mike: 最直接来说,我曾不止一次发现:管理者必须确保,针对不同客户分配的精力和资源必须保证看上去平等。经验告诉我,以透明而积极的方式这么做,有助于把工作负载在当年摊平。一旦赢得信任之后,客户就会更愿意牺牲自己的短期利益,换取长期利益,或是更广泛的好处。 使用看板之后,不同需求的来源就能得到可视化,用专门的泳道或颜色展示。使用明显的最大和最小分配策略,系统就能实现每天的自我管理,这么一来,为了保证资源分配在中等时间长度中足够公平而要付出的格外管理成本,也就不那么有压力了。

持有否定权的内部利益相关者(比如不同形式的内部监管),他们可能不那么容易应付,但是识别并理解他们的关注点,这对于达成顺畅的流程至关重要。很多时候,通过这些人的流必须小心应对,为什么不能让他们的参与变得同样透明,就像我们针对外部服务提供者的依赖所做的事情一样?

也别忘了系统内部的人。我有一条原则:如果某项变革的受益方包括客户、更广泛的组织、团队,那么它应该是一项不错的改进措施,而且可以持续。让不同人之间互相呛火,这不可能持久,所以要努力尝试,反复思考。改进不是零和游戏。

InfoQ:你的书中谈到了服务分类,能不能详细说说它们是什么,看板又如何使用?

Mike: 邮政服务是个很好的类比。作为发信人,你要选择昂贵的一夜到达,或是更便宜但是更慢的服务,这要根据你对收件方的期望和需要的理解。对于同样的静载重量,不同收件人可能有完全不同的需要,他们应该会指导你做出正确的选择,或是让你自己做出最佳的抉择。 看板中的服务分类与此十分类似。即使工作在技术层面都是类似的,但客户对于延迟的敏感程度可能大不相同。我们会给常见的日程安排风险起名字,按照邮政惯例,包括:标准、加速、截止日期确定、不明。也可以起一些“本地特色”的名字,但要确保根据不同的服务分类能很快识别出不同工作项目,同时便于在系统中管理。再次强调,外部策略指导日常决策(对于特别敏感的东西,邮政系统应该允许人手投递),更长期的反馈循环要确保:我们对于不同服务分类在交付层面的表现理解深入。这就能帮助客户做出合理决策。

服务分类的更微妙之处在于:我们应该接受系统设计之中的多样性,不是所有的工作都是相似的!

InfoQ:我认为流是看板中很重要的因素。你能举一些例子,说明流在软件开发项目中的体现方式吗?你怎么知道工作是不是在流动?

Mike: 你说得对!“管理流(manage flow)”是一项长久以来建立起来的核心实践,很明显,是从中概括出来的价值观。 当我们看到延迟或是不可预期的事情时,或是人们背负太多工作,或是迫切想要工作,我们都看到了缺乏“流”造成的症状,也是背后真正问题根源的体现。当这些症状和原因产生于精心设计的系统时,也许我们不太愿意发现它们,但这很常见。批次处理(比如发布周期)看上去好像很有用,所以我们会拒绝认可它会带来延迟。把关注点放在利用率上,初看上去很有益,但是利用率特别高与表现特别差有关(更不要说给相关人带来多么严重的不适)。

在看板中,流既好看又好用。我们看到工作在看板中灵活穿越。工作不会在活跃状态之间等待太久,在这些活跃状态中,工作负载可以匹配系统能力,也不太可能不被处理或是遭到阻塞。在看板的右侧,我们能够欣慰地得到最重要的反馈:刚刚交付的工作是否满足了客户的需求,我们对此有了新的理解。

对于如何达成流,看板方法描述了一种屡试不爽的方式:

  • 将工作可视化,其方式要能放大流或缺乏流带来的体验。
  • 使用限制和其他策略机制,保持在制品与系统能力平衡,并进一步强化流以及阻止其流动的障碍带来的体验。
  • 识别、处理流的障碍,并一次推动进一步降低在制品数量。

这其中有一些正向反馈,鼓励可视化表达、限制在制品数量、工作大小,还有其他一些策略和因素会与流的改进共同演化。流更好,绩效表现更好。一切都好!

InfoQ:你在书中说:敏捷和看板是相关的。能不能举几个例子?

Mike:Scrumban 是敏捷与看板的经典组合,可以很方便地实施我前面提到的方法,但是专门用于实施 Scrum 的环境中。我在书中提到看板带来的常见变化,包括: - 手把手降低在制品数量,以更短时间让各种工作项真正“完成”。

  • 使用后面的验收、部署和客户验证状态,让工作的管理更为高效。
  • 将部署活动与 sprint 分开,因此规划起来更方便,以更快速度向实现持续交付进发。
  • 不同类型的工作和服务类别能够更自如匹配,注意力转向单个工作项以及各种工作混合起来的延迟成本。

能列出来的可不止这些,而且必须说明:不同团队走过的道路也不一样。我觉得:将一种流程实现“看板化”,绝不仅仅是处理 sprint 之内的活动,而是有助于将“以客户为中心”这样的理念注入到流程中。以前的焦点只是放在团队的工作效率上,那样产生的影响比起看板就小多了。 另一种方法,是将看板应用于看上去不那么敏捷的环境中,并逐渐有意识地引入敏捷实践,加速组织演化,看板系统可以让这些敏捷实践的效果更加明显。我对敏捷的初次体验(特别是书中第一部分提到的相对比较成形的体验),就是这么得到的,如果理性看待最后结果,称之为敏捷毫无问题。看板提倡“从你现在做的事情开始”,这是很人性化的方法,如果很多人对实施敏捷有疑问,这么做特别有帮助;不然就会带来“转型之痛”。

InfoQ:精益创业可以跟敏捷联合在一起。尽早获得客户需求的反馈,是使用精益创业能带来的好处之一。你能对此多说几句吗?

Mike: 我很荣幸,能代表某人讲一讲,他参与了英国政府两个具有典范意义的 IT 项目(要感谢 Valtech UK 允许这么做)。两个项目都高度重视深入的真实用户研究,而且坦然接受这样的事实:很多需求不过只是对于真实客户(平常的公民,而不仅仅是内部用户或者基于项目的代理人)真实表现的假设。我很喜欢这种态度! 说得更高深一点,我在书中提到:极限编程可以让反馈循环“向右移动”,这样可以确保系统按照他们宣称的方式运转,而不是被钉在某些历史模型上。这是一种解放。精益创业令我兴奋,因为它继续了这种向右的趋势,将反馈循环的中心放在系统与客户之间的交互上。在精益创业中,对这种交互不断深入的理解推动事情向前发展,做出的假设也在针对度量数据的严格实验中得到检验,得出其是否合理的结论。

埃里克·莱斯在 2011 年出版的《精益创业》【参考 1】中提到:看板非常适合在精益创业中管理实验。我的书是另一个方向,记录了我自己的第一手经验(2011 年之前),主要是在现有的看板交付系统中加入了“添加客户验证”作为最后一步,这就促进了大家针对特性开发过程的态度产生显著改变,而这个过程也向上游延伸,贯穿整个流程。现在我知道,很多人有我同样的经历,我也就有信心说:看板和精益创业是天生的好伙伴。

InfoQ:书中第三部分讲的是“向看板中引入系统化思考(Systems Thinking Approach to Introducing Kanban,简称 STATIK)”,说说这是什么,它又如何有助于实施看板?

Mike: “STATIK” 是我今年想出来的,而且希望“向看板中引入系统化思考”(这是大卫·安德森的成果,不是我的)能够得到更多应有的认可。我很高兴地说:它的新名字的确有助于树立这个理念。 STATIK 讲述了一个可以重复的过程,能够创建适当而且符合上下文的看板系统。其中包括六个主要步骤:

  1. 理解不满的来源
  2. 分析需求和能力
  3. 为知识发现过程建模
  4. 发现服务类别
  5. 设计看板系统
  6. 实施

在我们的看板基础培训班中,步骤 1—5 是第二天的重头戏。步骤 6 是更深入的话题,而且常常会带出额外的步骤——“理解系统的目的”,要么作为步骤 0 先期提出,要么集成在步骤 2-6 中。 我们也认可这样的做法:步骤 5 和步骤 6 可能包括一些系统变革,这些变革的幅度超越了看板系统刚开始提出时的最小幅度。不过,有一点毫无疑问:从步骤 1 到步骤 4,重点都是放在系统现有情形上。从你现在做的事情开始!

有件事情我们也理解了一段时间了(而且书里面也提到过):在已有的实施环境中,STATIK 同样有帮助,特别是需要让大家重新振作起来的时候。最近,我提出“反转 STATIK”【参考 2】的说法,就是从步骤 5 开始,然后从步骤 4 倒退回步骤 0,这样有助于识别出有意义的改进,然后改变就可以以正向推进。

InfoQ:有些组织对看板感兴趣,希望从中受益,你能给他们一些建议吗?他们应该怎么开始?

Mike: 要说书的画,我的书【参考 3】很明确地将看板方法视为管理手段,大卫·安德森的书【参考 4】将其在组织层面的影响说得十分透彻。Marcus Hammarberg 和 Joakim Sunden 最近那本 Kanban in Action 【参考 5】中有不少很有价值的团队层面的建议。 我已经基于 Creative Common 协议发布了两个资源:“看板价值观练习”【参考 6】介绍了价值观、原则和看板方法的实践,有助于大家思考;Featureban 【参考 7】是一个模拟游戏,展现出运行看板系统的好处。我们与 Luke Hohmann 一起,开发出了“看板知其然”【参考 8】,这是一个在线游戏,探索团队的结合情况。我的书还有一个副产品——基于价值观的评估工具,目前正在一些地方测试,如果想用,可以发请求。

有经验的培训师或教练总是可以让看板实施变得更有成效。在 LKU 的网站【参考 9】上列出了不少世界范围的提供商。我自己就是经过认证的看板培训师(Accredited Kanban Trainer,简称 AKT)和看板职业教练(Kanban Coaching Professional,简称 KCP),虽然现在不像以前那样天天参与这些计划,但我还是要负责培训课程。

要想得到帮助,交换想法,网上有一些在线论坛,主要是 kanbandev 雅虎讨论组和 Linkedin 上一些讨论组。同时也有很多面对面的机会,包括 Lean Coffeess、晚间会谈和相关大会。今年秋季的几个大会上【参考 10】,我会主持 Lean Kanban 英国大会(11 月 3 日和 4 日,伦敦)开幕,并且在 Lean Kanban Central Europe 大会(11 日和 12 日,汉堡)上发言。

参考资料

  1. 埃里克·莱斯,《精益创业:新创企业的成长思维
  2. Mike Burrows,《 Reinvigorating an existing Kanban implementation with STATIK
  3. Mike Burrows,《Kanban from the Inside》,Blue Hole 出版公司,2014 年
  4. 大卫·安德森,《看板方法 : 科技企业渐进变革成功之道
  5. Marcus Hammarberg & Joakim Sunden,Kanban in Action, Manning 出版公司,2014
  6. Mike Burrows, Kanban Values Exercise
  7. Mike Burrows, Featureban
  8. 看板知其然
  9. Lean Kanban University
  10. Lean Kanban Conferences

关于作者

Mike Burrows是 David J Anderson and Associates 公司的英国总监和首席咨询师。他服务的行业包括航空、银行、能源和政府部门。Mike 曾担任 IT 总监、全球研发经理和软件工程师。他是 Lean Kanban University (LKU)的董事会成员,同时也是经过认证的看板培训师(Accredited Kanban Trainer,简称 AKT)和看板职业教练(Kanban Coaching Professional,简称 KCP)。他在世界各地多个看板有关的活动中演讲,并在 positiveincline.com 上开博客,他的 twitter 账号是: @asplake @KanbanInside

查看英文原文: Q&A with Mike Burrows about the book Kanban from the Inside

2014-11-24 07:211072
用户头像

发布了 479 篇内容, 共 152.1 次阅读, 收获喜欢 47 次。

关注

评论

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

【Java 25周年有奖征文获奖名单公布!!!】关于Java,你最想赞扬、吐槽、期待的变化是什么?

InfoQ写作社区官方

写作平台 Java25周年 热门活动

patroni 通过服务启动报错

hobson

数据库 高可用 AntDB

Go语言分布式系统配置治理

田晓亮

微服务

Python 自动化办公之"你还在手动操作“文件”或“文件夹”吗?"

JackTian

Python 自动化

一个人,沿着童年的路究竟可以走多远?

zhoo299

童年 NASA 航天

互联网时代的界限管理

非著名程序员

程序员 职场 提升认知 界限管理

Redis持久化了解一波!

不才陈某

redis 程序员 后端

我的 Windows 利器

玄兴梦影

工具 Win

# LeetCode 215. Kth Largest Element in an Array

liu_liu

算法 LeetCode

奈学:传授“带权重的负载均衡实现算法”独家设计思路

奈学教育

分布式

Vue生态篇(二)

shirley

Vue

从 0 到 1 搭建技术中台之发布系统实践:集泳道、灰度、四端和多区域于一体的设计与权衡

伴鱼技术团队

架构 系统设计 系统架构 系统性思考 架构设计

# LeetCode 863. All Nodes Distance K in Binary Tree

liu_liu

算法 LeetCode

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (十三)编写测试-生命周期方法

编程道与术

Java 编程 TDD 单元测试 JUnit

我为什么开始技术写作?

架构精进之路

技术创作

ARTS 第二周打卡

陈文昕

情绪的力量:如何使用情绪来达成目标

董一凡

情绪

数据产品经理实战-数据门户搭建(上)

第519区

数据中台 开发数据

知识也会生宝宝?

史方远

个人成长 随笔杂谈

杂谈-JSONP探索

卡尔

Java jsonp

开源分布式文件系统大检阅

焱融科技

开源 sds 存储 焱融科技 文件存储

程序员修炼的务实哲学

博文视点Broadview

程序员 软件 编程思维 工程师 编程之路

Vue生态篇(一)

shirley

Java Vue

MySQL的各种日志

超超不会飞

MySQL

这是一个测试文档

Geek_073cad

ARTS - Week Two

shepherd

js algorithm

你不知道的SSD那些事

焱融科技

分布式 存储 SSD nvme

线程池续:你必须要知道的线程池submit()实现原理之FutureTask!

一枝花算不算浪漫

源码分析 并发编程

美团可能会强势涉足 ToB

罗小布

创业 互联网巨头 深度思考 互联网

每个人都是领导者的工程团队

hongfei

工程能力 项目实践

我常用的浏览器插件

彭宏豪95

chrome 效率工具 浏览器 插件

与 Mike Burrows 聊他的新书Kanban from the Inside_研发效能_Ben Linders_InfoQ精选文章