深入解读主流的敏捷方法之一“看板方法”

前言


看板方法,作为,最近几年异军突起,广受业界推崇,并且大有赶超Scrum的趋势。我们也能经常看到敏捷爱好者在各类社区里火热的讨论看板方法论。可以说,无论是提问,还是交流分享,关于看板的讨论就一直没有停歇过。


由于篇幅有限,这里也仅介绍了看板方法的一些重要特性,无法覆盖看板理论的方方面面,还请读者见谅。



看板方法,一般认为是由大卫安德森(David J. Anderson)发明创造的,于2004年诞生在微软的XIT项目,并于06年至07年之间在Corbis公司得到大规模运用,紧接着在全球迅速推广。


大卫在发明看板方法之初,便深受了大野耐一的丰田生产方法(TPS),高德拉特的约束理论(TOC),戴明的质量管理,以及敏捷开发的影响。因此,看板方法中的很多概念,都可以从上述理论中找到影子。下面我们就来详细的谈一谈:


拉动(Pull),瓶颈(Bottleneck)

(源于高德拉特(Eli Goldratt)的约束理论(TOC))



约束理论诞生于上世纪八十年代,曾大量应用于耐克,福特,英特尔,宝洁等大型企业。其理念是,通过对产品在企业各生产环节之间流动的长期观察,建立拉动系统,进一步识别并消除生产过程的瓶颈,并通过后续的持续改进,消除一个又一个新出现的瓶颈,从而让企业的各个生产环节协同一致,提高生产效率。


这里不得不提一个经典的“鼓-缓冲-绳(D-B-R)”的拉动系统:




  1. 在上图中,我们把每一个生产环节比作一个纸片人,那么产品在每个生产环节的流动速度,就相当于每个纸片人的前进速度。

  2. 现在,我们给一条绳子,一端由走在最前面的纸片人牵着,另外一端由走在最后的纸片人牵着,并且由前面的纸片人通过绳子,“拉动”后面的纸片人前进。

  3. 在所有纸片人前进的过程中,我们可以通过观察绳子是否“紧绷”来判断后面一个纸片人是否为“瓶颈”。如果绳子没有“紧绷”,那么将绳子的一端,由最后一个纸片人,交给倒数第二个纸片人,再次观察绳子的状态。以此类推。




上图中,我们发现到了第四个纸片人的时候,绳子变得“紧绷”了,那么我们断定这第四人就是我们要找的“瓶颈”,是进行重点改进的对象。

当然,当改进结束以后,我们会再次运用这一拉动系统,去发现和解决系统中新的瓶颈,以达到持续改进的目的。


批量规模(Batch size),在制品(WIP)

( 源于大野耐一(Taiichi Ohno)的丰田生产方法(TPS))




丰田生产方法的产生要追溯到上世纪70年代,大野耐一及其团队通过长达20多年的探索和完善,形成了丰田公司独有的生产体系,通过对物流,库存,组织等一系列管理的强化控制,极大的提高了丰田汽车的竞争力。


凭借这套生产方法,丰田汽车在进入美国市场后,仅仅通过短短几年时间,便迅速的击败了美国三大汽车公司,在美国本土的汽车占有率上独占鳖头。


与高德拉特的约束理论相比,丰田生产方法更强调了“批量规模(Batch size)”的重要性。丰田正是通过降低批量规模,进而降低在制品库存,达到节约成本的目的,实现了效能的飞跃。另一方面,小规模的生产方式,也让企业能够更加聚焦于减少浪费,通过降低协调成本和事务成本来提高交付效率。


(2012年冬,拍摄于美国麻省的Wrentham Village Premium Outlets的Coach工厂店。该店为了保证服务质量,提高成交率,对店内购物人数进行了限制,因此在店外排起了长龙。)


看板方法借鉴丰田生产方法的另一个重要思想就是对在制品数量(WIP)的限制。通过对每一个生产环节在制品数量的限制,一方面,减少了产品在各个生产环节之间的排队等待,缩短了产品从开始生产到交付的时间,加速了价值流动;另一方面,由此产生湖水岩石效应,暴露了生产环节中的团队协作,资源分配等各类问题,为进一步改进提供了着力点。



看板方法对于WIP的最佳实践是对每一个生产环节都分别定义一个最大在制品数,以充分发挥看板在挖掘问题,协同改进方面的作用。

对于WIP,通常有两类错误的应用:


1待看板运用成熟后逐步加入WIP

一个典型的例子就是 雅虎公司。早期的时候,他们选择不设置WIP限制,理由是因为他们认为团队对于看板应用还不够成熟,希望首先利用看板的可视化来提升组织的成熟度,然后再引入WIP。然而,事实证明这种方法是有问题的。离开了WIP这一看板的核心方法,团队在协同改进上进展缓慢,最终在还没看到改善之前,团队就被解散,或者放弃了看板方法。


2设置整体WIP,取代各个环节的WIP

即使是看板方法的发源地,Corbis公司,也在这一问题上栽过跟头。为简化WIP,几个重点项目团队选择了粗粒度的整体WIP限制。结果因为无法识别具体环节上的瓶颈来加以改进,实际效果大打折扣。


(上图中,我们以典型的软件开发流程为例,根据实际产能,对每个开发阶段都分别设置了WIP,这是一种比较推荐的做法。)


质量(Quality)

(源于戴明(W. Edwards Deming)的质量管理)




作为质量管理之父,戴明提出了“质量是一种以最经济的手段,制造出市场上最有用的产品。一旦改进了产品质量,生产率就会自动提高。” 其思想更是对二战后迅速崛起的日本起了重大作用,并且在随后的几十年中影响了许多世界上最具创新精神的经理人。


因此,大卫在看板方法的推广过程中,也极其强调了內建质量的重要性。经过研究发现,专注质量,能够让高缺陷率团队的生产力和交付速率获得2-4倍的提升。


在软件生产过程中,提高质量通常有以下几种实践:

  • 代码检查(Code Review)

  • 单元测试(UT)

  • 测试驱动开发(TDD)

  • 验收测试驱动开发(ATDD)

  • 使用设计模式(Design pattern)


前置时间(Lead Time)

(源于敏捷开发Agile)


众所周知,敏捷开发非常重视对用户反馈的快速响应,强调以最短的时间,交付最大的用户价值,以获得市场竞争力。

因此,任务完成的“前置时间”,是衡量敏捷团队成熟度的一个重要标志,而看板方法也将这个“前置时间”看作是度量与改进的一项非常重要的指标。




服务分类(Class of Service)


在看板的实际应用中,对于不同的任务类型,往往需要区别处理,因此看板方法引入了服务分类(CoS)这一重要机制。常见的服务分类有:


1加急类(Expedite)

常见于一些时效性特别强的需求,或者对产品重大缺陷的修复。

这一类任务将被视为最高优先级,因此可以无视最大在制品数(WIP)的限制,直接进行作业。

然而这样的任务,很容易对看板的正常工作造成冲击,因此加急类的任务个数,通常都仅设置为1。


2固定交付日期类(Fixed Delivery Date)

看板方法推荐安排一定的产能,来处理一些固定交付日期的任务。

对于这一类的任务,需要在开发之前对任务的工作量进行估算,并在开发过程中定期的确认进度。一旦发现进度落后到有可能无法完成的情况,则需要对任务重新进行评估。如有必要,这类任务可以升级为加急类。


3标准类(Standard)

顾名思义,就是最普通的任务。看板方法推荐大部分的产能都应用于此类任务。无需对任务的工作量进行估算,直接按照先进先出的顺序进行处理。但对于超过两周工作量的任务,建议先进行拆分。


4无形类(Intangible)

主要针对一些用户价值有限的附加功能。看板方法推荐安排在此类任务上的产能应该低于标准类。




上图为软件开发看板中,针对不同服务类型的产能分配。值得注意的是,该产能分配在实际过程中,可根据具体的情况,适当的动态调整。比如,由于业务季节性的原因,预计后续一段时间的固定交付日期任务会比较少,这个时候可以将一部分的产能暂时交给标准类的任务。


需要强调的是,看板的服务分类是一项非常强大的机制。它能够确保团队在合适的时间做着合适的事情,即使在整体按时交付率比较低的情况下,团队依然能够获得较高的客户满意度。


看板仪式(Ceremony)

下面简单介绍一下Kanban实施的几项重要会议:


1每日站会

必开。在每日固定时间召开,全员参加,每人1-3分钟各自介绍任务状态,计划,以及障碍。此外,每日站会还可能需要根据实际情况,对看板输入队列(To Do List)进行填充。


2回顾会

建议两周开一次。用于讨论上一阶段的工作成果,检视上一期行动方案的落实情况,以及集体思考如何改进,并制定下一期的行动方案。


3发布计划会

根据实际情况,在版本发布前召开。主要用来明确即将发布的内容,以及部署计划等等。具体内容和瀑布流程的Release notes内容非常类似。


4需求讨论会

可选会议。如果需求可以在日常工作交流中完成,

其他