在敏捷团队持续改进的“看板方法Kanban Method”(或它的一些概念)被遵从。经常看到以下一些自适应性特征:
- 团队不再强调迭代、工作量估计和速度等作为过程的主要度量。
- 依靠度量交付时间(Lead Time)或周期时间来代替速度。
- 用更具可视化的“Kanban Board”代替“Task Board任务板”。
- 与“任务板”不同“Kanban Board”无需在每个迭代开始时重新设置。
- 它的每一栏代表“价值单元unit of value”的不同处理阶段,价值单元通常(但不总是)等同于用户故事。
- 另外,每一栏可以与“在制品限制WIP limit”相关,有数额限制。
- 团队首要任务是保持流Flow流畅,尽快处理在制品,当出现阻碍流出现时,团队协作解决使之流畅。
别名/又称 Also Know As
术语“Kanban”来自于日语,意为信号感觉,海报或广告,从词根来看翻译为“可视板Visual Board”。
其在敏捷情景下,是从丰田生产系统(Toyata Production System)中借用过来的,是指制定一个系统来控制各个部分的库存水平。它类似于(事实上启发)在超市货架产品缺货项目卡,触发及时补货的信号。
丰田系统提供一个存货或“在制品work in process”的精确核算,并为争取降低库存,并认为其是浪费和有害于性能。
“看板方法Kanban Method”也指种方法,依赖月可视化当前系统的工作调度,将管理“流Flow”作为主要效能度量工具以及整体优化当前系统——作为持续改进的方法,它并没有规定任何具体的特定做法。
常见误解
Kanban Board一般来说“仅仅”比“任务板Task Board”更为复杂而已。这本身不是错,然而,这种看法并不可取。以此为借口而将引入“瀑布”,系列线性活动构成软件开发过程。这可能导致产生信息孤岛或使得团队成员技能过度专业化/狭隘化。
特别是,团队应该警惕没有WIP限制的Kanban Board,不仅明确而且涉及到管理者、客户或其他利益攸关者要求执行。kanban趋法是从限制WIP中获得它的有效性的。
预期益处Expected Benefits
在某些情景中,度量交付时间(Lead Time)好于速度,解除有规律的迭代节奏,可能是更好的选择:比如,很少关注在特定的日期发布,或团队工作是自然持续和进展的,诸如增强或维护,尤其是多个产品时。
过于简单化的风险,“Kanban Board”的设置,可能会被认为涉及维护或不断持续演化发展的工作来考虑,而“Task Board任务板”的设置可能是一个被描述为“项目”的工作作为第一选择更为自然。
起源Origins
- 2001:May Poppendieck的一篇文章《精益程序设计Lean Programming》,提请注意敏捷与被称之为精益或“丰田生产系统”之间的相似之处,并引起了人们的关注。
- 2003:Mary 和Tom Poppendiek写了一本扩展自其关于精益程序设计(Lean Programing)的早期工作的书——《精益软件开发Lean Software Development》,其中描述了作为“软件看板系统Software Kanban system”的敏捷任务板(Agile task board)。
- 2007:最初几个以团队使用特定一组变化被称之为“kanban”(没有迭代、没有估计、带有WIP限制的持续任务板)的经验报告发布,包括来自Corbis(David Anderson)和BueTech(Arlo belshee)。
- 2007:Kanbandev邮件列表形成,提供了一个讨论Kanban风格敏捷规划实践的场所。
- 2009:致力于探索看板趋法(Kanban approach)两个实体(entity)形成,LSSS致力于解决企业问题,另外一个是限制在制品社团(Limit WIP Society),相对而言非正式一点,旨在让社区更为可视。