写点什么

看板如何奏效

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

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

关注

评论

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

代码作业

Geek_4c1353

极客大学架构师训练营

架构师训练营 第一课作业

文江

学习总结

TONNY

架构师训练营第五周作业——一致性哈希算法

文智

极客大学架构师训练营

关于Java面试必备的Java集合知识,终于有大佬总结整理出来了!

Java架构之路

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

【高并发】面试官问我:为什么局部变量是线程安全的?

冰河

多线程 高并发 高性能 线程安全 签约计划第二季

架构师训练营 - 第五周 - 作业一

行者

Netty源码解析 -- ChannelPipeline机制与读写过程

binecy

Netty nio 源码剖析

ping TCP端口的实用小工具tcping

网络 ping tcping

一个大型的互联网应用系统使用了哪些技术手段

kawayi

架构师1期-技术选型(一)作业

ltl3884

极客大学架构师训练营

2020年的Java程序员面试三件套:多线程+算法+微服务

Java架构师迁哥

食堂就餐卡系统设计

菜青虫

golang实现一致性 hash 算法

Jacky.Chen

第五周 实现一致性 hash 算法

Geek_fabd84

架构师训练营第1周学习总结

菜青虫

极客大学架构师训练营

SQL优化-分治思想

李印

MySQL SQL优化

Git:使用Git之前的配置

bobo

git

架构师训练营 - 第五周 - 作业二

行者

二十二、 深入Python的进程和线程(上篇)

刘润森

Python

架构师训练营第五周作业

我是谁

极客大学架构师训练营

第13周总结

Vincent

极客时间 极客大学

架构师训练营 -week05-总结

大刘

极客大学架构师训练营

1024|推荐一个开源免费的Spring Boot教程

Java旅途

Java 开源 Spring Boot

并发环境下,先操作数据库还是先操作缓存?

捡田螺的小男孩

数据库 缓存 后端 并发

周练习 5

何毅曦

一个程序猿应该具备哪些能力?

锐哥

程序员 1024讲话 1024

架构师训练营第一周作业

TONNY

第13周作业

Vincent

极客时间 极客大学

介绍几种微商常见的引流方式

boshi

营销 电商

架构师训练营 1 期第 5 周:技术选型(一) - 总结

piercebn

极客大学架构师训练营

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