看板的原意为日语中的“广告版”,“招牌”。丰田汽车公司的工程师大野耐一发明了“看板”,以提升制造效率。
尽管看板的初衷是帮助制造业,但是软件开发中同样有类似的目标,包括提高流量、吞吐量等。使用看板的指导原则,开发团队可以提高他们的效率及交付质量,更快得为客户带来价值。
采用看板需要适应如下基本概念。
由于通常是客户要求更多的功能,以至于软件开发者一直以来都是被推动着进行工作。这些工作经常伴随着紧张的时间限制。这种模式带来的副作用是,团队经常为了在时限内交付,采用快捷的措施,导致交付质量的下降。
看板帮助团队专注于维持质量水平。在可以完成一项工作之前,必须对质量标准达成共识。为了实现此模型,客户不能推动已经满负荷工作的团队。相反,他们讲需求添加到Backlog中,一共团队在有符合时“拉取”到工作流中。
想要充分理解软件开发团队目前的流程和进展是很困难的。但是当进展被可视化而不是以工作项、文档的形式展示之后,便可以更容易掌握当前情况。
工作的可视化是看板的一个关键原则,主要通过 看板 来实现。这些“板”通过进度来组织排布,以传达项目的整体状态。
将需要完成的工作可视化为看板上的卡片,处于不同的状态,可以让你轻松地看到项目目前的 “全局”,以及识别可能影响生产力的潜在瓶颈。
试图做太多事情的团队往往由于频繁和高负载的上下文切换而导致生产力下降。团队很忙,但工作看上去并没有进展,导致不可接受的高周转时间。为了解决这个问题,限制一个团队在任何特定时间内正在处理的积压项目的数量,有助于提高注意力,同时减少上下文切换。团队目前正在处理的项目被称为进展中的工作(WIP)。
一个团队在任何时间点决定工作的最大项目数被称为WIP限制。一个纪律严明的团队将努力确保他们不超过他们的WIP限制。如果发生这种情况,团队将调查原因,并努力解决问题的根本原因。
对于软件开发团队来说,要想持续改进,他们需要有方法来衡量他们团队的效率和产量。看板提供了一个工作流程中工作状态的动态视图。这使得团队可以尝试不同的流程,并更容易评估对工作流程的影响。实践看板的团队经常利用诸如提前期和周期时间的测量,为持续改进提供方法。
看板只是团队用于在团队中实施看板实践的众多工具之一。看板可以是一个实体的看板,也可以是一个软件应用程序,显示排列成列的卡片。典型的列名包括To-do、Doing和Done,但团队可以根据他们工作流程中的状态进行定制。例如,一个团队可能使用新的需求,开发中,测试中,UAT中,和完成的看板排列。
基于软件的看板显示对应于产品积压项目的卡片。它们包括与其他项目的链接,如任务和测试用例。团队通常定制卡片,在其中包含与他们的流程相关的信息。
在看板上,WIP限制应用在"正在进行 "的列。看板上的第一列和最后一列没有WIP限制,因为它们代表尚未开始或已经完成的工作。看板通过提请注意超过WIP限制的列,帮助团队保持在WIP限制之内。一旦发现,团队就可以确定适当的行动方案来消除瓶颈。
基于软件的看板的一个常见补充是被称为累积流程图(CFD)的图表。这个图表说明了每个状态下的项目数量随着时间的推移,通常是跨越多个月。横轴显示时间线,纵轴显示产品积压项目的数量。颜色被用来表示卡片目前所处的状态(或列)。
这个图表对于识别一段时间内的趋势特别有用,包括瓶颈和其他对进展速度的干扰。一个好的CFD会显示在团队进行项目工作时有一个持续上升的趋势。如果团队在他们的WIP限制内工作,图表区域顶部的各种 "条纹 "应该是大致平行的。
如果有一条或多条条纹出现凸起,这通常是团队流程中出现瓶颈或障碍的明确指标。在下图所示的CFD中,已完成的工作(绿色)是平坦的,而之前的状态,即测试,由于可能存在的瓶颈而在增长。