NVIDIA 初创加速计划,免费加速您的创业启动 了解详情
写点什么

看板如何奏效

  • 2014-09-01
  • 本文字数:4298 字

    阅读完需:约 14 分钟

最近,越来越多的人开始对看板产生兴趣,因为它是管理软件开发和持续改进的简单有效的方法。但是,看板如何(或者说为什么)奏效?是因为它暴露了系统,并对需求的可视化的追踪吗?还是因为限制了在线制品(work in progress)的数量,并且减少了浪费在任务切换上所消耗的精力?或许是因为通过简单的测量,例如周期时间(cycle time)和产能(Throughput)给经理们提供了频繁和有力度的反馈?本文依据排队理论和利特尔法则 1(Little’s Law1)深入研究看板的细节。并且通过案例分析,我们会阐述看板开发系统中,经理们所面临的三个典型的问题,并提出如何解决这些问题的方法。对于看板如何奏效,本文会揭露一些基本的概念和深入的见解。

软件系统中的利特尔法则

利特尔法则(根据 John Little 命名)是看板方法所建立的基础思想之一。在软件开发中,利特尔法则是这样描述的:

在线制品数量(WIP =产能( Th *周期时间( CT

在线制品数量Work in Process)= 在开发系统中,未完成条目的平均数量(缺陷,用户故事,变更请求,等等)

产能(Th= 团队在单位时间内的产出

周期时间( CT_)__=_ 团队完成一个条目所花费的平均时间

利特尔法则的动态性是令人惊奇的。它解释了软件开发的许多复杂性并激发我们做出决定。为了分析下一个案例的动态性,我们使用 _ 效应图 _2(Diagrams of Effects),它是一款非常好的工具,可以分析非线性系统,超过两个效应的系统或者分析影响系统行为。

案例 1:提高团队产能

Adam 是一个团队的教练,这个团队有 2 个开发和 1 个测试,负责维护公司大量的产品。在 2013 年,公司产品的市场宣传上提高了投入,并成功地将客户数目提高了一倍。现在,Adam 的团队收到越来越多的支持请求。然而,CEO 却不愿扩大团队的规模。

在这个例子中,为了满足客户需求的增长,团队必须提高产能。根据利特尔法则(Th = WIP / CT_),_ 为了提高团队产能,需要减少周期时间或者增加在线制品数量。因为团队的能力是固定的,不可能减少周期时间。所以,简单的解决方案就是增加在线制品数量。

可问题是:增加在线制品数量就真的能提高产能吗?答案是否定的。通过增加更多的在线制品数量提高的产能有一个极限,产能在到达极限之后会开始下降,如下图所示:

1:产能与在线制品数量的关系图

如下图所描述的,增加在线制品数量会刺激团队优化他们的工作,从他们的交付流程中减少某些浪费(黄色区域),直到团队可能达到的最大产能(绿色峰值)。在此之后,更多的在线制品数量不会带来任何改进;相反,由于工作压力和任务切换则会降低团队的产能(红色区域)。

2.根据在线制品数量的总和,团队对在线制品数量增加的响应图

在红色区域,由于外部因素和团队内部出现的一些问题,团队招架不住,从而导致生产率降低。下面的效应图分析了团队在红色区域的动态变化。

3.超越团队能力后增加在线制品数量会降低团队生产率和产能。

该图显示了在超出团队能力之上,增加在线制品数量的所产生的效应。这会增加与客户的沟通增多,增加任务的切换并增大团队的压力。在压力和任务频繁切换下工作会导致更多的缺陷,最终会降低生产率,因此,相应的产能就会降低。

为了理解这一决定的影响,下面的模型图显示了加强效应:增加在线制品数量会引起效率降低,因而堆积的需求就会上升,从而导致在线制品数量的上升,以此类推。这个系统会持续循环,因此产能会持续下降,直至团队崩溃。

4:超越团队能力后增加在线制品数量会引起2个增强回路,在这种动态下,在线制品数量会持续增加,直至开发系统崩溃。

说明:两个连续的负面效应 = 正面效应。

总结一下,如果你们团队的能力是固定的,想要增加产能,你可以选择同时增加团队规模以及在线制品数量。如果做不到这一点,那么你只有一个选择:降低周期时间,也就是发现和去除浪费。

案例 2:稳定周期时间

Ismail 是开发经理,负责在服务等级协议 SLA(Service Level Agreement)里所规定的时间内为客户交付变更的内容。Ismail 和他的团队收到的客户请求数量是波动的。有时候比平时的多,导致周期时间超出了 SLA 规定的时间,另外一些时候需求比例比较低,不能占满团队的工作量。下图解释了为什么高输入率会增加周期时间。

5.根据利特尔法则,高输入率导致周期时间延长。同样,低输入率导致周期时间缩短。

为了稳定周期时间,利特尔法则表明周期时间与在 _ 线制品数量 _ 成正比,与 _ 产能 _ 成反比。所以,如果 Ismail 能够稳定这两个参数,周期时间才可以相应地稳定。

为了做到这一点,Ismail 既要控制 _ 在线制品数量 _,也要控制 _ 团队能力 _(团队成员的数量或者专注于处理客户请求的团队时间百分比),从而可以响应过高或过低的输入率。这两个参数会同时影响周期时间,增加在线制品数量会延长周期时间,然而,增加团队能力会减少周期时间。所以两者效应会相互抵消。

6:如果经理可以增加/减少在线制品数量和团队能力,他们就可以稳定周期时间和优化团队利用率与绩效。

因此,总结如下,如果团队经历波动的输入率,他们需要控制两个参数,在线制品数量上限和团队能力。通过控制这两个参数,团队才可以稳定周期时间并优化团队利用率。

案例 3- 不要太多的快速通道

快速通道的工作方式(在看板的白板中使用高优先级的通道)也许可以简单的解决重复的问题报告和不确定的服务要求,特别是针对不满意的客户。在很多情况下,为了缓解特殊的案例或者对抱怨强烈的客户做出回应,很可能会无原则地使用快速通道。

快速通道会消耗团队的部分时间和工作,会使开发速度减慢,从而增加平均周期时间。根据利特尔法则,它会显著地降低团队的产出。

7:根据利特尔法则,如果在线制品数量固定,周期时间越长,产出就会越低。

然而,实际发生的情况是,在周期时间和产出之间的线性关系也会发生变化,如下图所示:

8:由于周期时间的延长和产出与周期时间的关系图的变换这两个因素,产出会极大地降低。

在更多严重的例子中 ,团队可能会把任务切换到快速通道的任务上去,然后开始立即处理这个请求,并把在进行中的其他任务搁置在一旁。应急式的上下文切换会对产出有更加严重的负面影响。下图解释了这个影响:

9:快速通道的任务延长了正在进行中的任务的周期时间,最终会负面的影响产出。

总结第三个例子,要意识到快速通道是一个陷阱,它可能会对整个团队的工作效率有负面的影响,而且可能导致降低平均周期时间。虽然快速通道可能在一些规模较小的紧急案例中有所帮助,但也可能会给计划外的负面的动态变化打开一道门。

结论

因此,在这三个案例中,我们根据排队理论阐述了看板如何奏效。它是非常简单而且有效的管理工具。作为一个经理或者主管,你需要控制几个参数:在线制品数量 _ 和 _ 团队能力。并且,你有衡量指标,例如周期时间和产出,因此对于流程的有效性,你可以简单的衡量并快速的得到反馈。在后三个例子中,我们指出了使用看板时要注意的三个基本问题:

  1. 试图研究团队能力,而不是压榨团队,让他们超出团队能力之上额外工作。绘制在线制品数量与产出的关系图可以让你知道团队可以承受的最大在线制品数量值。
  2. 可以通过对多个参数的控制实现稳定团队开发进度。就像在第二个例子中,你可以控制在线制品数量和团队能力,从而达到稳定的周期时间。
  3. 小心快速通道陷阱。实际上,他就是违反流程的一个后门。如果不小心使用,它会破坏团队的生产率。

  • 利特尔法则: 在一本书的章节中 解释了利特尔法则,该书由麻省理工学院发表,John Little 解释了这个法则并且把理论与实际结合起来。它是一本极好的书籍,非常简单并且深入到了利特尔法则的精髓。

    本书的这一章节非常好地解释了一个问题,是利特尔法则在原始的公式中(把到达率(Arrival Rate)作为公式的一个参数)和把它应用到生产系统中(用产能代替了到达率(Arrival Rate))的区别。解释如下:

    利特尔法则的陈述如下:

    L = λ W

    L = 在排队系统中的平均数量

    λ = 系统中的有效到达率

    W = 系统中一个条目的平均等待时间

    John Little 解释说这个法则是强大的,通用的并且精确的保留了排队理论中所给的必要条件:“对开始【当系统为空】和当系统为空站点有一个有限的观察窗口。”(第 88 页)。

    你可能会注意到,这个公式和文章中讨论的公式不同。实际上,对于原始的利特尔法则和在软件上下文中描述的公式 (WIP = Th*CT) 有两个基本的不同。原始的公式提到的是输入与到达率,后面的公式提到的是产出率和产能。第二个问题是在利特尔公式中陈述的条件:系统应该开始于 0 个条目,终止于 0 个条目。在软件中,我们很少看到一个系统没有任何维护的请求。

    为了解决这些不同,Little 对于这个法则保留了更加微妙的条件,那就是:在系统中没有条目进入并且丢失,或未完成。他称为“保守流动”(第 93 页)。如果我们把这个条件应用到系统中,我们可以轻易地得到输入率(Input Rate)= 产出率(Output Rate),因此,我们就可以将有效到达率(λ)和产能(th)关联起来。

    对于第二个条件(系统应该开始并终止于 0 个条目)。Little 解释说这个法则“仍然适用,至少是个近似值,只要我们选择的时间间隔足够长。”(第 93 页)

  • 效应图(Diagrams of Effects): 效应图第一次引入是在著名的 four-volume series 中:Gerald Weinberg 写的质量软件管理。它是一个很好的开启器,试图理解系统展现的非线性行为的动态性,它与软件开发团队的系统很相像。

    效应图与因果回路图 CLD(Causal Loop Diagrams)很像,但在记号上稍有不同,并且在系统中创建人为干预模型非常强大。一个效应图主要包括一些节点和箭头,每一个节点对应一个可测的量。简单的箭头对应一个效应(正面或负面的),从一个源头节点到一个目标节点。这里有一个全面的材料:如何绘画和使用效应图手册

关于作者

Amr Noaman Abdel-Hamid 是一名敏捷教练、培训师和实践者,他的生活愿景就是将敏捷和精益思想传播到埃及和中东地区。Amr 是 Agile Academy 的共同创始人,该产品能够帮助团队和组织以最大的潜能交付软件。Amr 还是埃及 Lean&Agile Network 的创始成员,并有幸发起了埃及的 GoAgile 项目,该项目是在埃及由埃及政府为了推广敏捷所发起的采用敏捷活动。从那时起,Amr 已经培训了超过 400 名的实践者,并且指导了很多团队。Amr 经常发表演讲、是几个行业报告的作者,并且在他的博客中分享他的思想:敏捷软件开发的故事。你可以通过 email Linked-in 或者 Twitter @amrnoaman 联系 Amr。

英文原文链接: http://www.infoq.com/articles/how-kanban-works


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

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

2014-09-01 03:443168
用户头像

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

关注

评论

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

一文来了解关于分布式锁的那些事儿

Linux服务器开发

redis 分布式 分布式锁 Linux服务器开发 Linux后台开发

译文《Java并发编程之volatile》

潘大壮

并发编程 volatile 后端 Java EE

OpenHarmony 3.1 Beta版本关键特性解析——探秘隐式查询

OpenHarmony开发者

OpenHarmony 隐式查询

洞见科技成为华东江苏大数据交易中心会员单位,创始人姚明获颁「年度数字经济卓越领袖奖」

洞见科技

数据中心 隐私计算 数据交易

Gartner发布中国IaaS PaaS市场服务报告,天翼云强势入选

天翼云开发者社区

信通院推出数字化赋能者新标准天翼云获评数字化转型赋能服务集体

天翼云开发者社区

内存之旅——如何提升CMA利用率?

OpenHarmony开发者

内存 OpenHarmony

中台和多云管理是伪问题?运维要集体下岗了吗?

火线安全

DevOps 云原生 云安全

公有云市场百舸争流!天翼云稳居第一梯队,进入领导者象限

天翼云开发者社区

VuePress 博客之 SEO 优化(六)站长工具

冴羽

Vue 前端 vuepress SEO 博客搭建

QoS 设计:车联网平台消息传输质量保障|车联网平台搭建从入门到精通 04

EMQ映云科技

物联网 IoT mqtt coap emq

2022年最热门的招聘技术技能是什么,您绝对想不到

禅道项目管理

项目管理 开发技能

融云直播 SDK 升级,让直播「PK」起来

融云 RongCloud

直播 IM 场景化

Linux云计算之linux grep命令详解

学神来啦

云计算 Linux 运维 grep

墨天轮访谈 | Pika数据库陈磊:云时代下,键值数据库是否会被替代?

墨天轮

数据库 KV存储引擎 国产数据库

OceanBase 社区 Webinar 首播官宣|社区版 RoadMap 和性能调优!周四见

OceanBase 数据库

OceanBase 社区版

天翼云成为首个加入openGauss社区的运营商云

天翼云开发者社区

企业在线产品宣传册应该如何设计?

小炮

产品宣传手册

Rust 用于移动开发的几种方式

非凸科技

Java c++ Python rust 量化

DevOps落地思考

火线安全

DevOps 云原生 云安全 DevOps认证

跑马灯带你深入浅出TextView的源码世界

vivo互联网技术

android 源码分析 TextView

长连接网关技术专题(七):小米小爱单机120万长连接接入层的架构演进

JackJiang

网络编程 websocket 即时通讯 网关 长连接

恒源云(GpuShare)_这个春天,GpuShare与你同行

恒源云

抗疫

龙蜥社区一周动态 | 3.14-3.18

OpenAnolis小助手

开源 操作系统 龙蜥社区 一周动态

跨境电商数据融合实践|OceanBase 助力致欧家居打造分布式跨境电商

OceanBase 数据库

oceanbase 致欧家居

雄安新区设立四周年,看天翼云以数字底座托起未来之城

天翼云开发者社区

以太坊的扩容革命:ETH2.0

不登山的小鲁

以太坊 扩容 Ethereum eth eth2.0

融云互联网通信安全揭秘之链路安全

融云 RongCloud

网络安全

Docker Build时的安全问题

火线安全

Docker 云原生 云安全 docker build

安全Linux 内核提权漏洞分析

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 漏洞挖掘

MASA Blazor入门这一篇就够了

MASA技术团队

C# .net 组件 组件库

看板如何奏效_文化 & 方法_Amr Noaman Abdel-Hamid_InfoQ精选文章