什么是看板方法?

看板方法是用于高效管理软件开发流程的新技术。看板方法源自丰田的“及时生产”(JIT=just-in-time)系统。尽管生产软件是一项创造性活动,与批量生产汽车有所不同,但是生产线管理背后所蕴含的原理仍然适用。

一个软件开发的流程可以看作是一段自来水管道,特性需求从一端进入,经过改进的软件从另一端涌现出来。

在管道内部,存在着各种各样的工序,有的是非正式的临时工序,有的是非常正式的阶段性流程。在本文中,我们假设一个简单的阶段性流程:(1)分析 需求,(2)开发 代码,(3)测试 软件运行正常。

瓶颈的影响

在管道中的瓶颈会限制工作的流动。管道的整体吞吐量被限制为瓶颈的吞吐量。

用我们的开发管道为例:如果测试人员每周只能测试5个特性,而开发人员和分析人员每周能够生产10个特性,整个管道的吞吐量就只有每周5个特性 ,因为测试人员扮演了瓶颈角色。

如果分析人员和开发人员不知道测试人员是瓶颈,那么测试人员的待办工作就会越堆积越多。

影响就是前置时间增加。并且,就如同库存一样,位于管道中的工作会套牢投入的资金、产生与市场的距离、以及随着时间逐渐失去价值。

最终,影响到质量。为了能够跟上进度,测试人员开始抄近路。最终bug被发布到产品中,导致给用户带来问题,从而影响未来的管道产能。

另一方面,如果我们知道哪里有瓶颈,我们就能够重新部署资源来解除它。例如,分析人员可以帮忙测试,开发人员开始进行自动化测试。

但是,我们怎样才能知道在已知流程中哪里是瓶颈呢?而当瓶颈移动后会发生什么呢?

看板方法可以动态显示瓶颈

看板方法难以想象的简单,但却难以想象的强大。最简单的形式的看板系统包括了一个挂在墙上的大白板,上面有许多卡片或即时贴,这些即时贴按列来放置,每列上方有一个数字。

你之所以能找到这些瓶颈,是因为限制了在制品(work-in-progress, WIP)的数量会显示出瓶颈。

卡片代表了工作项,列代表了开发工序,卡片会从第一步工序流动到最后一步。每一列顶部的数字用来限制每一列最多允许放置卡片的数量。

看板白板的限制大相径庭于其他任何可视化故事板。在流程中的每一步限制在制品(WIP)数量,可以预防生产过剩并动态显现出瓶颈,以便于你可以在达到不可收拾的程度之前找到它们。

样例

下面的白板展示了这样一种情况:开发人员和分析人员正被阻止开展任何新工作,这种情况会持续直到测试人员空出了一个卡片位置并将下一个工作项拉到测试步骤中。这时开发人员和分析人员就会开始寻找能够帮助测试人员减轻负担的方法。

注意,我们已经将一些列分割成了两列,这是为了用来说明正在进行中的项与哪些已经完成并准备好被下游工序拉走的项。你也可以用一些不同的方式来布局白板。这里用的是比较简单的方式。列顶部的限制包含了“doing”(进行中)和“done”(完成)两列。

一旦测试人员完成了一个特性的测试,就会将卡片移走,并且在“Test”列空闲出一个卡片位置。

现在,“Test”列中空出来的位置可以用开发“Done”列中的一个卡片补充进来。这时,“Development”列就会空闲出一个卡片位置,下一张卡片就可以从“Analysis”列中拉进来,其他列也是这样。

原文转载:http://www.cnblogs.com/lchrennew/p/what-is-kanban.html

时间: 2024-10-13 10:35:56

什么是看板方法?的相关文章

为什么我们关注看板方法?

反观近年,越来越多的企业开始重组组织结构.重定义角色和职能.为何为之? 答案是为了适应于新的商业环境.为了更加敏捷:为了减少官僚主义和成本.为了能够更加快速响应客户所需. 如今,无论敏捷与否的各种企业都在寻找更卓有成效的方法来管理优先级变化.提高生产率.改善工作能见度.提升团队士气.获得更快的市场投放时间,变得更加精益. 但是,Tower Watson的一项研究显示,只有25%的变革管理行为获得了长期的成功. 根据<敏捷状况>的第八版报告,53%的企业遇到了无法改变企业文化.42%的企业承认他

精益看板分析:吞吐率

基于PMBoK.Prince2.CMMI等传统项目管理的公司对吞吐率(Throughput) 的了解相对较少.但是,我确信随着精益概念的不断延伸,吞吐率将受到更多的关注. 吞吐率 是指在一段确定的时间内(如周.月.季度)已交付的工作项的数量. 我们所讲的已交付实际上指已经完成并可能已经交付给顾客.即,在这个过程之后收到了钱. 为了理解吞吐率的概念,我们假设在过去的五周中,某个团队在每周分别交付了4.6.4.2.3个故事.对于已经开始但尚未结束的故事不计入其中. 这五周的平均吞吐率约为 (4+6+

【CTO俱乐部研修班开课】看板先驱David J. Anderson:看板核心在于创造一种能力——提升敏捷性

看板开发方法是近年来最热门的敏捷和精益开发方法.看板之父David J. Anderson认为其核心在于帮助企业创造一种能力--提升敏捷性.CTO俱乐部看板研修班将通过理论.沙盘模拟.真实案例分享等阐释看板核心理论. 看板方法诞生于2006年前后,是近年来最热门和上升速度最快的敏捷方法,成为拉动互联网时代敏捷变革的主流方法,被互联网企业和追求互联网变革的传统企业普遍采用.一方面它有力支持了精益创业.持续交付和DevOps等实践的有效实施:另一方面作为渐进式变革方法,看板方法为敏捷转型提供了更加平

21天敏捷打卡--敏捷方法实现

常用的敏捷实践包含:精益.看板.Scrum.XP极限编程.水晶.DSDM动态系统开发.FDD功能驱动开发.AUP敏捷统一过程.OpenUP. <敏捷实践指南>将敏捷方法和看板方法是为精益方法的子集.因为他们都符合精益思想的具体实例,都反映了“关注价值”.“小批量”.“消除浪费”. 精益软件开发LSD TPS 面对场景 解说 原则 解说 过度 对员工和生产/研发过程施加不必要的额外压力 消除浪费 无法带来价值的事务就是浪费 违规 不切实际的需求导致过生产/研发程中的不均匀 尽快交付 短期迭代或小

精益软件开发与精益管理:从一家关闭的汽车厂重焕青春说起

“把工厂搞砸的是系统,不是人!” 弗里蒙特汽车装配厂是通用汽车于1982年关闭的工厂,当时劳资关系几近崩溃,工人们边工作边酗酒和赌博.1984年通用与丰田成立了合资企业:NUMMI,启动了弗里蒙特的工厂并重新雇用了原来的工人.这些工人被送到日本的丰田城学习丰田生产系统(TPS),之后短短三个月内,NUMMI就生产出了质量近乎完美的汽车,而且成本比以前工厂时期低很多. 持续改善 当你倾听那些从弗里蒙特装配工厂开始一直坚持到NUMMI结束的工人们谈话时,一个反复被提及的主题就是团队协作.这也许有些老

瓶颈法则

瓶颈法则源于约束理论(Theory of Constraints, ToC),由Dr Eliyahu Goldratt提出并于1984年发表于他的著作<The Goal>中. 法则指出:每个系统,无论运转优劣,都有至少一个约束(即瓶颈)限制其产能. 这个法则使我们可以推断出一个流程中响应时间和性能的限制,这是IT服务和软件开发项目的重要信息. 专注于通过解决瓶颈改善成效是提升盈利能力最快和最卓有成效的途径.瓶颈可以包括组织内部或外部的人.信息.工具.过程. 瓶颈是指在一个流程中限制或阻碍流动的

Github 新的项目管理模式——Projects

Github 新的项目管理模式--Projects Issues Github 中传统的项目管理是使用 issue 和 pull request 进行的,这部分内容不是本文重点,不再赘述. 但有一些功能需要提及: Tag: 每个 issue 可以添加不同的 tag,可以用于标记 issue 的种类和 issue 的处理进度: MileStone:每个 issue 只属于一个 milestone,用于显示 issue 的处理进度. Projects 概述 这是Github 2016年9月份新的功能

[转载]持续交付和DevOps的前世今生

作者/分享人:乔梁,20年IT老兵,腾讯公司高级管理顾问,敏捷和精益开发专家,持续交付领域先行者.曾就职于百度,国内多个知名互联网公司的企业教练. 历年QCon技术大会的讲师和专题出品人. 这是一个新概念风起云勇的时代. 就让我们从云端抓它几个名词下来,一起玩耍吧!!! “敏捷软件开发”,“增长黑客”,“持续集成”,“DevOps”,“精益创业”,“持续交付”,“大数据”... ... OK,就这四个啦: “敏捷软件开发”,“持续集成”,“DevOps”,“持续交付”. 先让我们在Wikiped

第2章 传统与敏捷方法论

2.1  传统泛瀑布软件开发模式 2.1.1  瀑布模式 1.瀑布模式简介 2.瀑布模式特色 3.瀑布模式缺点 2.1.2  渐增模式 1.渐增模式简介 2.渐增模式特色 3.渐增模式缺点 2.1.3  雏形模式 1.雏形模式简介 2.雏形模式特色 3.雏形模式缺点 2.1.4  螺旋模式 1.螺旋模式简介 2.螺旋模式特色 3.螺旋模式缺点 2.1.5  统一开发过程模式 1.RUP模式简介 2.RUP模式特色 3.RUP模式缺点 2.2  敏捷方法论 2.2.1  Scrum 1.Scrum