高品质的音视频能力是怎样的? | Qcon 全球软件开发大会·上海站邀请函 了解详情
写点什么

Sandvik IT 实施看板三年:改进之旅的故事

  • 2014-08-07
  • 本文字数:5960 字

    阅读完需:约 20 分钟

2009 年 10 月,瑞典:新成立的“系统开发办公室(System Development Office,缩写为 SDO)”——一个有三名成员的小型支持小组——刚刚分到了一项令人兴奋的任务,提升 Sandvik IT 所有开发团队的交付能力(生产能力、质量、提前期)。四年之后,Sandvik IT 已经在超过 60 个团队中实施了看板方法。

这是一个在企业范围内实施看板的故事。不仅如此,它说的是如何将持续改进的文化注入企业。

我们将会看到:为什么 Sandvik IT 选择了看板方法;如何使用“快速启动(kick-start)”的概念进行推广;如何使用“看板深度(depth-of-kanban)”评估进行跟进;目前为止的效果。关于如何一步步地快速启动和评估,读者可以找到链接,它们指向非常具体的信息。

这是“Sandvik IT 的看板”系列的第一篇文章,它有两个目标:一是鼓励读者踏上自己的改进之旅;二是就如何解决可能会遇到的问题提供一些思路,尤其是扩展看板的时候。长远来看,如何最大化看板的效果?第二篇文章将探讨我们从这个问题中汲取的经验教训。

Sandvik IT 的系统开发办公室

Sandvik AB 是瑞典的一家公司,成立于 150 多年前。这个故事就是关于它的。它是一家世界领先的企业,在 130 个国家有超过 49000 名员工,供应采矿和建筑机械、特种合金、高级钢产品和钢切削工具。

在 Sandvik IT,系统开发办公室(SDO)起一个支持作用,目的是为实现卓越的 IT 交付提供方法、流程和工具。

为什么是看板?

SDO 分到一项任务:提升 Sandvik IT 的交付能力。SDO 的团队成员非常熟悉敏捷,同样地,他们本身对如何成功地使用敏捷技术已经有许多想法。当时,那在很大程度上是关于持续集成、持续交付和自动化测试。

尽管 Sandvik IT 有着重量级的流程(同所有企业一样),但管理层希望通过指定和推广一个标准开发流程来提升交付能力。实际上,对于可以在 ITIL 中找到的不同流程,如事件、变更等,这项工作已经做了,并且发挥作用了。为什么不能把它用于系统开发呢?

因此,SDO 只需要指定一个通用的标准开发流程——为了符合管理层的要求——然后将精力集中在真正关键的部分,如持续集成 / 交付和自动化测试,就是这样!那什么可能会出问题呢?

改进的推动方法问题

在快速开始敏捷体验之后,SDO 的团队成员很快就感觉到,这种基于“推动”一个标准流程的改进方法不会成功。主要有以下不利因素:

  • 团队及他们的环境相差很大,所以不可能创建一个对所有团队都有用的足够详细的标准开发流程。事实上,对于客户、技术、职责、需求、产品更新频率、事件数量和严重程度等,每个团队都有一个特定的组合。甚至是每个团队的人数、他们的性格和经历也相差较大。
  • 当推动变革的时候,有一个风险是,SDO 最终成了管理每个团队交付能力的中心。这似乎不可持续。团队之间的巨大差异将使事情变得非常复杂,那根本不可能做到,更别说有效了。感觉上,分散管理更合适。
  • SDO 很快就发现,没有人真正有时间听他们讲:每个团队都太忙了,忙于交付、评估、处理事件以及响应客户的日常需求。见鬼,有些团队甚至都认为自己根本不属于 IT,因此为什么还要听一些关于“IT”流程的演讲呢?

事实如此,SDO 能做什么呢?

知识型工作的痛

首先,SDO 设法了解开发团队的现状。什么让他们痛苦?通过与不同的团队举行价值流映射研讨会,他们开始搜集信息。在 26 场研讨会过后,事情变得明朗——与团队的环境无关——对于所有团队,那些反复出现的重点问题都是相同的。这些问题包括:任务切换、技术债务以及计划和里程碑得不到保证。而且,这些问题在一个强化负面反馈回路的错综复杂的网络中相互关联。

(点击图片可以查看大图)

图一:知识型工作的痛

流程控制是关键

基于这种理解,SDO 认识到了三件事:

  • 不只是开发团队,所有团队都有相同的问题。事实上,即使是 HR、通讯和管理团队也都经历过恰恰相同的问题。因此,这对所有知识型团队都是成立的,而不仅仅是 IT 开发团队。也就是说,找到消除这些问题的方法将惠及任何团队。
  • 这些症状反复出现的根本原因似乎是源于缺乏流程控制:太多的在制品。因此,减少在制品数量也就应该可以减少——或者甚至消除——其中的大部分问题。这是个好消息!
  • 因此,将会对团队交付能力(生产能力、提前期、质量等)产生最重大影响的最重要的一件事是获得对工作流程的控制并限制在制品。那不是说要有一个通用的流程,或者一种更好的方法应对需求、开发或测试。这些事情今后可能很重要,但现在做不是最明智的。

看板方法:最佳投资回报

对于 SDO 而言,认识到这三件事意味着他们不得不放弃让每个人都开始自动化测试和持续交付的宏伟计划,取而代之以一种可以获得最佳投资回报的行为,就是“简单地”给予每个团队控制他们自己的工作流程的手段(知识和权力)。

在这一点上,看板方法——注重通过限制在制品进行流程控制——是一个显而易见的选择。此外,它的原则和做法非常合适:从自身实际情况出发,建立关于现状的共识,并在团队内部培养改进的愿望。

创造认知

现在,SDO 知道该做什么了:让团队为了控制他们的工作流程而开始看板方法。但是,该怎么做呢?团队有太多的工作要做,无论如何,他们还是没有时间听 SDO 演讲!

当与团队管理人员讨论的时候,SDO 开始图解“知识型工作的痛”。它成了一个创造现状认知的完美工具。当它与高层管理人员的改进期望相结合的时候,这种认知很快就引发了变革的愿望。团队管理人员开始考虑:“如果现在我不做些相关的事,那么以后别人必然会迫使我做;那就不漂亮了……”。

看板快速启动

这样,SDO 终于第一次引起了管理人员的兴趣。在这一点上,讨论是像下面这样进行的:

管理人员:不错,我认识到了团队的问题,而且我完全同意,为了获得成功,我们现在就需要解决这些问题。你已经说服了我,有些事情可以使用这种看板方法来做。那么,让我们干吧!你需要多长时间?

Johan(SDO 教练):好的,那有不少事要做,所以两三天怎么样?

管理人员:什么?我以为那只会花两三个小时!这不可能,我不会把我下面的人在一个讲习班里锁三天!我们这会儿有若干具体的工作要做……我可以给你一天,不能再多了!

Johan:……那就一天!

就是这样,SDO 不得不将看板方法的基础知识打包,以便在为期一天的讲习班中讲完。这被称为“看板快速启动”。

一天用于开始已经足够了,但不足以创建一个可持续的看板系统。因此,还需要做一些事,涉及调整、确认或引入无法在开始时就设定的概念。这些事称为“强化(boosts)”,采用一种两小时会议的形式。

回想一下,一小步一小步地引入看板方法,长远来看是非常好的:它使得看板方法 “富有吸引力(sticky)”且更有弹性,对于组织变革而言,尤其如此。另一种方法是一次性将所有的概念灌输给团队,团队会因此负担过重,而看板系统也必然会在产生任何良好的效果之前因为自身的重量而崩溃。第二篇文章将会在这一点上展开。

快速启动的构成

自 2010 年以来,看板快速启动一直在不断发展。如今,它由以下三个部分构成:

  1. 建立有关团队目标的共识。一旦所有的团队成员都共享相同的团队目标,真正的改进就会发生。这一部分确定了团队向谁交付以及如何交付价值。换句话说:团队提供什么服务以及它们属于什么业务。这与管理顾问要做的事非常类似,不过是在团队层面。真是让人惊讶,讨论过该问题的团队竟如此之少。
  2. 制定有意义的、与团队目标一致的策略(工作类型、工作说明、审核清单、就绪 / 完工定义、工作优先级、工作步骤 / 流程定义、如何进行工作可视化等)。
  3. 如何使用策略。为了更聪明地工作,在每日会议中使用可视化板和策略。
  4. 快速启动看板研讨会的准备工作和后续的强化形式在《看板快速启动实战手册》中有描述。该手册由 Johan Nordin 和我共同编写,遵循“知识共享(Creative Common)”许可协议发布。它源于在 Sandvik 公司内部普及 SDO 的知识这样一个需求;使企业中的任何人都能以一种类似和一致的方式举行快速启动研讨会。

扩展看板实施

第一次看板快速启动研讨会在 2010 年 9 月完成,从那以后,SDO 已经在 Sandvik IT 内部 60 多个各种各样的团队中进行了快速启动:应用程序管理、项目、支持 / 协作、管理、客户等。

有趣的是,举行所有这些快速启动和后续的研讨会,SDO 都是设法用两名,有时候是三名,教练来完成的。这部分是由于快速启动的组织方式,但主要是由于引入了一个额外的角色:流程经理。实际上,流程经理的角色在看板方法中并不存在(看板方法没有规定任何角色),但是——在 Sandvik IT 的环境里——我们发现,团队内部需要有人负责使看板实施为大家所保持。该角色与 Scrum Master 角色有相似之处,一度从项目管理方面取消,而它常常承担了这方面的重任。

流程经理的目标是使团队认真思考和采取行动:遵循它制定的策略、需要时创建新的策略、针对异常情况(问题和机会)进行讨论并采取行动、试验找出创造性的解决方案等。流程经理负责对团队成员进行激励、鞭策和指导。事实上,该角色是教练的一个扩展,应该在教练逐步撤出的过程中接管其任务。

评估看板

最终,SDO 在许多团队快速启动了看板,每个团队有它自己的流程经理。实际上,团队可以沿着任何对他们有意义的方向自由发展,变成为了获得成功所必须的样子。那么,SDO 如何知道一个团队是否真正地在“做”看板呢?它又如何评价怎么才能最好地帮助团队更进一步呢?

看板社区关于看板深度的讨论ⅰ启发,并基于 David Anderson 的工作ⅱ,SDO 设计了一款评估看板系统深度——或成熟度——的工具。简而言之,就是可以通过使用一组问题绘制出一张图,反映团队目前的看板实践“做”了多少。做的越多,则“越深”,体现在图上就是离中心最远。该工具及其用法在博文《看板深度——一款优秀的指导工具》中有更详细地描述。

(点击图片可以查看大图)

图二:看板深度评估——问题

(点击图片可以查看大图)

图三:看板深度评估——示例

当使用这种方法评估一个团队时,SDO 教练可以:

  • 了解团队实施的不同的看板实践已经有多“深”。
  • 为团队下一步改进推荐最显而易见的——或者投资回报最佳的——可改进之处(比如,在一个已经高度可视化的方案里更“深入”而不是开始明确策略,可能成本会更高)。
  • 基于评估(“是的,那可以帮助我们!让我们试一下!”)给出改进思路,激励已经停止改进(比如,已经到达了一个舒适的、“足够好的”深度)的团队继续改进。
  • 为了达到一定的深度,通过奖励激励团队。比如,当达到足够的深度时,就在他们的看板图上做一个非常醒目的“卓越的绝地武士学徒奖(Excellence Padawan Award)”标记,接下来是“卓越的绝地武士奖(Excellence Jedi Award)”, 以及最高奖项“卓越的伟大的绝地武士忍者奖(Excellence Grand Jedi Ninja Award)”(或者其它类似的东西)。

在许多团队使用了评估后,有一点变得非常清楚:评估不能用于比较团队!两种看板实施会产生两个密切适应各自环境的有极大差异的系统。因此,评估应该由团队使用,而且是为了团队,而不是管理人员用来安排加薪。

看板对团队的影响

到 2011 年,在帮助了 20 个团队后,SDO 开始从团队、他们的管理人员及客户那里获得良好的反馈。客户对于该方法所带来的透明度的提高尤其满意。但是,由于并不是所有的团队都已经调整了他们的流程,所以 SDO 想更好地了解看板和快速启动概念对团队的影响。他们感受到了什么具体的改进?

因此,对于 Sandvik 内部那些已经完成快速启动的团队,SDO 让大学生分析了看板对他们的影响。报告ⅲ显示,使用快速启动的概念,团队在团队精神、注意力、质量和提前期方面感受到了显著的改进。部分影响在快速启动之后马上就出现了,而其它的需要几周甚至上月的时间——这取决于团队的成熟度:

  • 团队行为像个团队。团队成员知道其他人正在干什么,共同分担正在进行中的工作,互相帮助(即使那意味着走出自己的舒适区),了解每个人的技能和特长,并建立一种知识分享策略(在适当的时间和地点)。
  • 团队专注于“正确的事”。每日会议确保只做相关的工作(根据工作类型、服务类别、截止日期)。即将到来的工作是可见的,并且不断地调整它们的优先级。团队成员互相帮助完成紧急的工作。
  • 团队工作与其能力相符,而不会超出。团队成员拉动工作(而不是把工作推到他们身上),使用明确的 WIP 限制限制在制品。
  • 工作是可行的,因为它是按照团队的“就绪定义”(适当的规模、正确的信息)进行准备的。阻塞的工作项(由于与其他团队、专家或客户的依赖关系)得到了积极的管理。
  • 团队有一种通用的、标准的工作方式。这可以确保团队成员都知道成功的原因(标准),并在未来的工作中采用该标准,不再为失败创造条件,进而可以避免失败。
  • 流程明确且众所周知。团队现在与客户的讨论更周到了,因为除其它事情外,为了及时交付,团队可以说出什么时候——最晚什么时候——开始一项特定类型、规模和服务类别的工作。

(点击图片可以查看大图)

图四:使用快速启动的概念引入看板以后,Sandvik IT 的团队多快感受到看板方法的影响。

继续旅程

时至今日,SDO 已经在超过60 个团队使用快速启动概念开始了看板方法。但是,SDO 仍然在以看板方法作为基础学习如何创建一种持续改进的文化。在Sandvik 的环境里,考虑到经历过的主要问题,SDO 的体验是,看板方法快速提高了开发团队的交付能力。

实际上,Sandvik 使用看板方法实现的其实是创建了一个环境,在这个环境里,必要的变革(比如:更好的需求方法、自动化测试等等)能够保持。确实,看板方法使得团队能够有时间有能力来处理变革,同时有按他们的工作方式构建这些变革所需的精力。相反,在团队没有办法承受时(开始时就是这种情况)推动变革将很快使变革失败,这浪费了团队的时间和精力,对推动变革的人而言,也是如此。

轮到你了!

像所有工具一样,如果你对看板方法感兴趣,那么务必弄清楚它为什么适合你的环境及你的目标。这对企业而言尤其重要,因为经常有许多倡议是为了争夺注意力。一旦定调,则务必将其打包成一个可以简便快速推广的形式iv,而又不失目的性。最后,找出方法跟进和评估v 为了在实施过程中保持一致所做的设定。

关于Sandvik IT 改进之旅的第二篇文章将更深入的介绍我们在企业里推广看板的过程中所汲取的经验教训,尤其是如何最大化它的影响。敬请期待!

i Håkan Forss 在 2012 年看板领导培训营的博文

ii David Anderson 的博文《我们是否是在做看板》

iii 《看板在软件开发团队中的效果——Sandvik 看板实施研究》,R.Ericsson & A.Granlöf 2011

iv C.Achouiantz 的博文《看板快速启动实战指南》

v C.Achouiantz 的博文《看板深度——一款优秀的指导工具》

关于作者

Christophe Achouiantz是一名精益 / 敏捷顾问。他是法国人,为瑞典的 Sogeti 公司工作。他以一种更加高效更加有效的知识型工作为使命,志在使它更有意义,并最终更有用。他的博客在这里,Twitter 账号为@ChrisAch。

查看英文原文:**** 3 years of Kanban at Sandvik IT: The Story of an Improvement Journey

2014-08-07 02:152065
用户头像

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

关注

评论

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

下载超过10万次?阿里大佬的《高并发、性能调优笔记》一战封神

Java架构师迁哥

每天学习10个实用Javascript代码片段(五)

devpoint

定时器 JavaScrip 8月日更

本科毕业六年,裸辞备战三个月,四面阿里巴巴定级P7

编程susu

Java 编程 程序员 面试 计算机

从λ演算到函数式编程聊闭包(1):闭包概念在Java/PHP/JS中形式

zhoulujun

闭包 闭包函数

微信业务架构和学生管理系统架构设计

Geek_db27b5

微信业务架构 学生管理系统架构

模块(一)什么是架构

我是一只小小鸟

客户需求难以推进和实现?企业如何有效管理项目需求?

优秀

项目管理

特斯拉依旧头铁坚持视觉路线,激光雷达会笑到最后吗?

脑极体

从λ演算到函数式编程聊闭包(2):彻底理解JavaScript闭包规则

zhoulujun

闭包 闭包函数

百度地图开发-显示实时位置信息 04

Andy阿辉

android Android 小菜鸟 Android端 8月日更

网络上数据通信过程

一个大红包

8月日更

JS遍历循环方法性能对比:for/while/for in/for of/map/foreach/every

zhoulujun

foreach map for for in

Linux之nc命令

入门小站

Linux

混合模型与期望最大化算法(三)

数据与智能

算法 混合模型

模块一

树建

架构实战营

ShardingSphere Proxy 初步体验

ShardingSphere-Proxy

微信业务架构图 & 学生管理系统方案

缘分呐

架构 设计

微信业务架构

一叶知秋

架构实战营

在线JSON转YAML工具

入门小站

工具

LeetCode刷题09-简单 回文数

ベ布小禅

8月日更

JavaScript 有关数组的 slice 截断函数

HoneyMoose

Go- 函数执行时间

HelloBug

Go 语言 函数执行时间

3 分钟了解 JSON Schema

程序员鱼皮

Java json 数据库 大前端 后端

数据挖掘经典算法之K-邻近算法(超详细附代码)

Python研究者

8月日更

实时数据引擎系列(二): 批流一体的数据

tapdata

太厉害了!腾讯T4大牛把《数据结构与算法》讲透了,带源码笔记

编程susu

Java 编程 程序员 计算机 技术宅

正经人一辈子都用不到的 JavaScript 方法总结 (一)

编程三昧

JavaScript 大前端 8月日更 模板字符串 String.raw

网络攻防学习笔记 Day115

穿过生命散发芬芳

网络安全 8月日更

JIT-动态编译与AOT-静态编译:java/ java/ JavaScript/Dart乱谈

zhoulujun

dart JIT AOT 动态编译 静态编译

使用明道云搭建电梯维修与保养系统

明道云

Go,一文搞懂 defer 实现原理

微客鸟窝

Go 语言 8月日更

Sandvik IT实施看板三年:改进之旅的故事_治理_Christophe Achouiantz_InfoQ精选文章