BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

看板如何奏效

| 作者 Amr Noaman Abdel-Hamid 关注 0 他的粉丝 ,译者 李清玉 关注 0 他的粉丝 发布于 2014年9月2日. 估计阅读时间: 13 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

最近,越来越多的人开始对看板产生兴趣,因为它是管理软件开发和持续改进的简单有效的方法。但是,看板如何(或者说为什么)奏效?是因为它暴露了系统,并对需求的可视化的追踪吗?还是因为限制了在线制品(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经常发表演讲、是几个行业报告的作者,并且在他的博客中分享他的思想:敏捷软件开发的故事。你可以通过 emailLinked-in或者Twitter @amrnoaman联系Amr。

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


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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT