看板Kanban方法起源简介
看板Kanban 方法起源于20世纪40年代的丰田生产系统（TPS），是精益制造的核心工具之一。他是一位名叫大野耐一（Taiichi Ohno）的丰田工程师受到超市补货机制的启发（货架仅补充被购买的商品），提出了“拉动式生产（Pull System）”，即根据需求触发生产流程。大野耐一说：“丰田生产方式的两大支柱是 ‘准时化’ 和 ‘自动化’，看板是运营这一系统的工具”
1990 年麻省理工的 James P. Womack 等几位教授提炼总结了丰田生产系统的实践，出版了《改变世界的机器》一书，从此以后，精益制造的概念开始为世人所认识和运用。后来 James P. Womack 等人对精益生产方式做进一步的总结，写出了包括精益理论、方法和工具等内容的一本书 《精益思想》。
2004年，David J. Anderson 将看板方法应用于微软的软件开发项目，并于2010年出版《看板方法》一书，正式将其系统化为敏捷开发方法。
什么是看板Kanban
看板方法源于丰田生产系统，实现拉动式生产的有效工具。
如果按照中文字面意思理解 “看板Kanban” 这个词，以为是 “信息板” “展示板”，其实不是，在丰田生产中，Kanban 是一种传递物料的卡片，一种生产触发信号，以实现及时生产，拉动生产的方式，为了实现连续流的生产，而不是各部门隔离式的生产。
在开发中，Kanban 是 “视觉符号” 或 “卡 Card”。带有卡片的物理或电子看板，推动和实现整个系统工作流的可视化。
看板的核心思想是通过可视化工作流、限制在制品的数量以及持续交付与改进，来优化需求任务开发和提高团队的协作效率，实现信息共享，提高沟通效率。
看板方法的五大核心实践
软件产品是一种虚拟产品，在软件产品开发中，工作（需求、编写代码、测试代码等）一般普通人是看不见的，除非是一个软件成品。那更不要说它的多个工作步骤可以被看见。为了使软件产品开发变成有步骤、能可视化、更有效率，从精益制造中借鉴了看板kanban管理方法。
1、可视化工作（价值）流
使用看板（物理或电子板）将工作任务流的各个阶段用卡片的形式可视化展示出来，使团队成员或任何人能直观看到各种工作任务的进展情况。
比如卡片列：“待办 To Do”、“进行中 In Process”、“完成 Done”、“测试 Testing” 等列清晰展示开发中、已完成的任务。
（来自：精益产品开发一书，作者：何勉）
上图展示了一个产品开发，端到端的流程步骤，也就是产品价值交付的整个过程。
通过这张图不仅可以看见用户价值，也可以看见工作流程中的瓶颈问题，也就是及时发现瓶颈并解决。
2、限制在制品数量 WIP
WIP 的上限决定了开发资源的利用率，也决定了任务的交付速度。
对每个工作阶段的任务数量进行限制，防止团队成员同时处理过多的任务导致效率下降，应集中精力干少量的重要任务，保证任务高质量完成。
确保任务快速交付，缩短从工作任务进入到看板系统到完成交付的时间。
（来自：精益产品开发一书，作者：何勉）
控制在制品数量，还可以暴露开发过程中遇到的瓶颈和问题，如下图：
（来自：精益产品开发一书，作者：何勉）
如上图，在测试环节的在制品数量达到了上限，可以看到这个测试环节积压了很多工作任务，在拉入新的工作任务就被禁止了，团队应该聚焦处理出现的堵塞中的任务，及时处理瓶颈问题，让工作流能顺畅快速流动，快速交付用户价值。
3、显示化流程规则
为了让看板能规范化、顺利的运转起来，需要制定一些规则。
- 任务卡片的书写规则
- 需求评审规则
- 需求进入开发的条件是什么
- DoD（Definition of Done）完成的定义，每个阶段需明确定义任务完成标准
- 优先级规则，高优先级任务可以插队处理，但要确保不违反 WIP 限制
- 阻塞处理规则，阻塞任务标记并优先解决，必要时分配专人处理
- 流转的规则，工作任务从看板列的一列进入下一列所必须达到的标准
等等一些规则，显示化定义这些流程规则，目的是让团队成员对做事的规则有一致的理解和承诺，为决策提供一些依据。
4、管理和度量工作流
为了让看板中的工作任务能顺畅流动，团队需要管理好各阶段的工作任务流动的情况。因此对看板中的工作任务的跟踪，工作任务流动情况的跟踪，都需要不断的进行了解。
- 1、需求评审进入开发阶段：哪些需求是有价值的，就进入开发阶段。
- 2、看板站会：一般由一名主持人带领团队成员，在每个工作日，同一时间同一地点，对着看板来检视工作任务的完成情况。主持人带着大家从右到左审查看板，这个审查方向体现了看板方法价值拉动的方向。重点是关注价值流动过程中的问题和阻碍，然后处理这些问题。我们无需检视每一个工作任务，重点检视影响价值流动的工作任务。
- 3、发布计划：这是工作任务开发完成后准备发布给用户使用前的计划活动，决定发布哪些完成的功能和发布的策略。
度量为改善价值流动提供了参考的方向。
通过持续的监控任务在流程中的移动效率，通过数据分析，比如开发周期时间、吞吐量、任务完成率（每天完成的任务）、阻塞的数量、每周发布的功能数量、在制品数量等度量指标来发现瓶颈，优化价值流动的效率。
还可以通过累积流量图来查看改进的方向。
5、持续改进
第一：用户反馈：
在敏捷开发中，通过短周期迭代，小批量的发布功能，然后不断收集用户对产品的反馈，从而进行产品改进与迭代。
可以通过PDCA方法来进行不断改进：
- Plan 规划：在一个开发周期中制定一个可发布工作成果的计划，计划内容为工作任务完成后产生预期的结果，以及完成的验收标准。
- Do 执行：执行上面制定的工作计划。
- Check 检查：对上一步的执行工作进行检查，和预期结果进行对比，看看有没有偏差，有没有做错的地方。
- Action 处理：对上一步的结果进行处理，有偏差就进行修正；没有就继续保持。对于需要改进的方面提出改进方案，在下一个 PDCA 循环中解决。
第二：工作流阻塞反馈
看板可视化工作流中，是否出现工作流阻塞的问题，对阻塞问题的原因进行分析，然后改进。
第三：开发过程问题反馈
在开发阶段或测试阶段发现的问题，进行反馈，然后改进。
第四：回顾会议反馈
通过回顾会议，分析流程中遇到的问题并制定改进措施，形成持续优化的闭环。
看板方法的工作流程
1、定义工作流程
根据团队需要划分各个流程阶段。比如待办、开发中、测试、完成等等，并在看板上可视化展示.
2、创建看板卡片
为每个任务创建卡片。卡片的内容包括任务描述、负责人、优先级、截止日期等关键信息。
3、设置WIP限制
为每个阶段设置并行的任务上限，比如开发阶段 WIP = 8，避免资源过载。
4、管理任务流动
-
拉动机制：下游阶段有空闲资源时，从上游“拉取”新任务，避免任务堆积。
-
阻塞处理：标记阻塞任务（如依赖未解决），优先解决以恢复流动。
4、持续监控与改进
-
定期分析数据（如周期时间、吞吐量）识别瓶颈。
-
通过用户反馈、开发过程问题反馈、回顾会议等调整流程规则，改进工作流程。
参考
- 《看板方法》 https://book.douban.com/subject/25788807/
- 《改变世界的机器》 https://book.douban.com/subject/1135841/
- 《精益思想》 https://book.douban.com/subject/6307924/
- 《精益产品开发：原则、方法与实施》https://book.douban.com/subject/27116921/ 何勉
2632
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
