写点什么

敏捷实施:看板能否实现规模化?

2015 年 3 月 23 日

当组织进行规模化敏捷,并想把看板作为一种敏捷方法应用的时候,问题就来了,可否规模化看板?Klaus Leopold 在 中欧2014 精益看板大会上演讲的规模化看板中进行了这样的解释:看板本身就具有规模化的能力,所以从严格意义上来说,这一问题的答案不可能是“否”,因为规模化看板仅仅是当前状态的一步改进。规模化看板意味着运行更多真正的看板,产生更多的改进。

在敏捷组织中,所有的团队都应该使用敏捷方法,这是一个误解。有许多不同的方法可以使用,团队必须应用对团队有效的方法,并且根据他们的情况进行调整。Klaus 表示,组织就是一个活生生的社会系统。团队在组织中并不是孤立的,他们互相连接,并通过交互产生价值。

InfoQ 采访了 Klaus,谈论了用看板管理项目集,在团队和项目集层面部署和连接看板板,在完整的交付周期中管理进行中的工作,以及看板带来的好处。

InfoQ:您谈到应当不断适应现实的工作环境,而不是去适应一个蓝图,您可否举一些例子呢?

Klaus: 在《爱丽丝梦游仙境》中有一个场景,兔子说,“为了能够站住,你必须跑的非常快。”我认为这个例子很好地解释了今天的商业现实。如果你不能不断地调整工作环境来适应一直变化的环境,那么这个世界就会把你遗忘。不幸的是,我没有那么聪明,可以提供一个包括多种实践的蓝图,能够适用于大千世界的所有组织,并让他们在市场上获得成功。我深深地相信,每一个组织必须自己找到答案。

这方面最好的一个例子可能就是日本丰田汽车,他们允许竞争对手进入他们的工厂,并演示给他们如何生产汽车。可以参看如 Mike Rother 编写的《丰田套路》一书。尽管很多公司照搬丰田公司的实践,但没有一家公司能够像丰田那样成功。所以,这完全不是采用别人的最佳实践和解决方案就可以成功的,实践仅仅是对包含多个改善步骤的学习循环的表现。如果你采用别人的解决方案来解决你的问题,那么这个解决方案不能解决你的问题也就不奇怪了。

InfoQ:在中欧精益看板大会上,你谈到在某个软件开发项目中使用了看板,他们为什么决定用看板?

Klaus我谈到的这个组织几乎在复杂的世界里迷失了。在这个项目中有大约 200 个人,他们想要完成共同的目标,但他们完全不知道该怎么做,也不知道他们的现状如何,以及他们是否可以达到目标。他们想保持尽可能的最小且无痛苦的变革,因为人们只是厌倦了正在进行的组织变革浪潮,这种浪潮冲击了他们的头脑。他们的想法就是保持团队的正常工作,并且不在变革方面对他们产生太多干扰。所以第一步我们只是想更好地协调团队意见,确保他们在正确的时间做正确的事情。

你可以把公司比喻成一个键盘,每一个按键代表了一个团队。如果你要给客户写一封信,你不会想对团队的有效性进行优化,从而让键盘上的按键按得更快。这几乎不会带来任何更多的产出。当在写一封信的时候,更重要的是你在正确的时间按下正确的按键。当你的公司创建的价值依赖于多个团队的时候是同样的道理。

当你在这个飞行水平(Flight Level)开始你的改进之旅时(参见看板和它的飞行水平为什么看板飞行水平),团队不需要在他们的工作方式上进行很大的改变。实际上,团队是用看板还是 Scrum,或是其他的方法都没关系。跨团队基本的建立流程是确保每个人在正确的时间做正确的事情。

InfoQ:您可否详细阐述一下看板是如何引入到这个项目中的?

Klaus这是一个很大的问题。我来尝试概括最重要的事情:在开始的时候,我们组建了一个跨功能和层级桥梁的变革团队,由他们引领变革。他们是有关变革疑问的主要联系人,并且主导引入变革的所有活动。变革团队所做的第一件事情就是识别干系人并理解真正的问题在哪里。有了这些信息,我们就可以准备系统设计的工作坊。团队提名代表来设计看板系统

在开始的时候,我们整个团队只有一个用于协调的看板系统。后来,越来越多的团队决定在团队层面使用看板。这是非常棒的,因为是团队拉动了变革 – 没有人告诉他们必须要用看板!当然,我们完全支持他们的决定。

InfoQ:为什么团队建立自己的看板板很重要,而不是建立一个标准板?

Klaus: 我认为很大一点原因是主人翁意识。当我建立了我的系统,我会理解它的意图以及如何工作。所以,如果有些地方没有预计那样有效果的时候,我就会有种内在的动机来改善我的系统。然而,如果一个聪明的人提出了一个板,然后告诉我这样工作应该最有效,那么我的目标就是告诉这个聪明的人他错了!如果人们不是自己设计这个系统,他们试图规避这个系统的概率就会变大,而不是出于对他们有利而使用他们。

InfoQ:在您的讲演中,您曾提到在团队中协调用项目站立会议,您可否解释一下是怎么做的吗?

Klaus那其实不是什么大问题。团队派出代表参加一周两次的协调会议。目的是协调跨团队的工作 – 谁需要谁的信息,谁可以帮助谁解决工作上的阻碍、我们有什么依赖等等。我真正喜欢的是团队轮流派代表的原则:每周有一名不同的人代表他的团队。相比于自己的小团队花园,这种方式对于理解整个项目的情况真是非常有帮助。情况就不再会是“只有我们团队的这几个家伙是很好的,而其他的人都是累赘。”, 而很可能是“我们可以一起做什么让项目成功?”另外,这也培养了团队之间的领导力。我并不是高地人原则(Highlander Principle)“无敌模式”的铁粉,我认为我们需要在不同层面上有更多的领导,而不是单点故障方式,就像看板 Master 等。

InfoQ**:您曾给出过一个例子,描述了在完整的交付周期将看板板与管理在制品数量(WIP)连接起来,您可否解释一下它是怎么工作的吗?**

Klaus连接系统是规模化看板的一种方式。然而,在看板的上下文中讨论规模化却有点困难,因为在规模化时,你真正所做的仅仅就是解决一个问题。我在现实中遇到过两种典型的问题,而规模化是一个解决方案:

1)聚合服务

我经常看到一种模式:服务 A 始终依赖于服务 B。例如看板系统中,前端开发的服务始终等待后端开发的服务,如下图所示:

(点击图像以放大)

这种依赖性必然会增加了大量的周期时间(Lead Time)。我看到的方案通常是只把这两个服务合并成一个服务,例如“前端和后端开发”。我曾看到过很多这样的实现。最简单的就是把两个团队合并成一个更大的团队。但是,这种方式只有在人数有限的情况下才是有意义的。我还经常看到的一种方式是,团队并不合并,但他们用共同的看板系统来进行协调工作。

2)连接服务

连接也类似。同样有两个服务彼此依赖,但现在的情况是,服务 B 要用服务 A 的输出作为输入。例如:想象一下有一个开发服务和一个整合服务。当开发完成的时候,他们把工作转给整合。当这两个服务不连接时,他们就把工作项放入到无限缓冲区中,例如“准备 2 整合”,这基本上就是这个板的完成栏。从开发的角度看这个工作可能已经完成了。然而,在客户的角度上这一任务并没有完成,因为它必须与整个系统整合并且还需要发布等等。看板在很大程度上就是通过客户的眼睛来看整个世界,因此把两个服务连接起来就变的有意义了。另外,减少无限缓冲意味着你有一个可预见的工作流。

(点击图像以放大)

为了解决这个问题,你只要把这两个服务连接起来,然后在“准备 2 整合”栏写上在制品数量限制。你实际要做的是,你通过下图中的方式连接两个单独的服务,以一种面向服务的方式实现规模化。这就是一个真正的 SAFE(规模化敏捷的一种方法)方式。规模化看板意思就是做更多的看板。你不需要用一个蓝图去做,因为这只是常识 – 这只是你的组织怎么工作的。你可以从 “看板规模化”这篇博客文章中查看更多内容。

(点击图像以放大)

InfoQ:您可否阐述一下应用看板给该项目带来的一些好处吗?

Klaus最大的好处肯定是,为了达到共同的目标:项目的成功,所有团队互相协调他们的工作。在开始的时候,让大家都关注在工作流上而不是使用上是非常困难的。不开始新的工作并不合适,因为我们已经达到了在线制品数量限制,并且还要专注于改进系统。然而,它完全得到了回报:仅仅两个星期之后,史诗(Epics)的周期时间减半,另一方面,我们看到了产出在上升,团队也减轻了很多压力。结果就是,我们能够做到在短期内交付更多的东西,团队成员们也会感到更加快乐。

关于被采访人

Klaus Leopold是一位具有多年经验的计算机科学家,帮助不同行业的组织用精益和看板开展他们的改进之旅。他是《德国IT 的看板》(2012 年由Hanser Verlag 在德国发布)的合著者,也是《看板改变领导》(将于2015 年5 月由Wiley 发布)英文翻译的合译者。Klaus 是第一批全球精益看板的培训师和教练。他在2014 年旧金山的看板社区得到了名为“杰出成就和领导”的Brickell Key 奖。Klaus 还是Stoos 管理网络的创始人之一。他主要的兴趣是在团队之上的敏捷性,尤其是针对30 到500 人规模的项目。他经常在自己的博客 www.klausleopold.com 中发表各种最新的见解,你也可以关注他的 Twitter 帐号 @klausleopold

查看英文原文: Can You Scale Kanban?


感谢邵思华对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

2015 年 3 月 23 日 11:051585
用户头像

发布了 55 篇内容, 共 10.5 次阅读, 收获喜欢 3 次。

关注

评论

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

深入浅出Vert.x架构

dinstone

netty案例,netty4.1源码分析篇三《Netty服务端初始化过程以及反射工厂的作用》

小傅哥

Java Netty 小傅哥

书摘之《堂吉诃德》—— 谁不曾想过仗剑走天涯?

Sicolas Flamel

读书笔记

一个实用的开源项目,可以快速将 Elasticsearch 数据导出到 csv

AlwaysBeta

Python 数据库 elasticsearch Kibana Lucene Elastic Search

netty案例,netty4.1源码分析篇一《NioEventLoopGroup源码分析》

小傅哥

Netty 小傅哥

大数据技术思想入门(二):分布式存储集群特点

抖码算法

Java 大数据 hadoop 分布式

netty案例,netty4.1源码分析篇六《Netty异步架构监听类Promise源码分析》

小傅哥

Netty 小傅哥

JDK8 日期 API 使用

HeGuang

JDK1.8

做职场里的“超级英雄”,需要怎样的盔甲与工具?

脑极体

Spring的Controller是单例还是多例?怎么保证并发的安全

简爱W

netty案例,netty4.1高级应用篇一,手写RPC框架第一章《自定义配置xml》

小傅哥

Java Netty

netty案例,netty4.1源码分析篇二《ServerBootstrap配置与绑定启动》

小傅哥

Java Netty 小傅哥

Week10--课后作业

Geek_165f3d

这么理解业务架构就对了!

周金根

BIZBOK 业务架构

Week10---课后总结

Geek_165f3d

阿里内部流传的Mybatis笔记终于流传出来了,赶紧收藏

简爱W

netty案例,netty4.1源码分析篇四《ByteBuf的数据结构在使用方式中的剖析》

小傅哥

Java Netty 小傅哥

世界正在重塑 加密货币将扮演什么角色

CECBC区块链专委会

数字货币 加密货币

8锁问题

HeGuang

synchronized

spring事务的这10种坑,你稍不注意可能就会踩中

简爱W

oeasy 教您玩转linux010101查看内核uname

o

netty案例,netty4.1中级拓展篇十三《Netty基于SSL实现信息传输过程中双向加密验证》

小傅哥

Netty 小傅哥

netty案例,netty4.1高级应用篇二,手写RPC框架第二章《netty通信》

小傅哥

Netty 小傅哥

netty案例,netty4.1高级应用篇三,手写RPC框架第三章《RPC中间件》

小傅哥

Netty 小傅哥

数字化背景下的经济社会发展的新特征 新趋势

CECBC区块链专委会

区块链 人工智能 大数据

区块链的共识机制有哪些好处优势?

CECBC区块链专委会

区块链 分布式 金融

牛逼操作,ThreadLocal还能当缓存用

简爱W

Java

大龄程序员的自我介绍 v 0.1

escray

学习 面试 自我介绍 面试现场

netty案例,netty4.1中级拓展篇十二《Netty流量整形数据流速率控制分析与实战》

小傅哥

Netty 小傅哥

netty案例,netty4.1源码分析篇五《一行简单的writeAndFlush都做了哪些事》

小傅哥

Java Netty 小傅哥

我,一个当代普通大学生的自述

有梦的咸鱼

个人成长 大学生日常 个人感悟 讨论写作

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

敏捷实施:看板能否实现规模化?-InfoQ