最近…
小Q带领的NOBUG团队经常遇到迭代里研发或测试资源不足，导致需求延期交付的问题，开会时老被领导点名，这让他很苦恼…
在偷听工位隔壁，一直暗恋的女神小美聊天时，听到了一个词，好像能化解自己的当前的囧境。
数据看板？信息看板？
好学的小Q立刻进行了网上冲浪，映入眼帘的，是一张张符合自己心理预期的图片（如下）
小Q心里轻蔑一笑，“呵，不就是画个框，贴个任务卡片，然后再根据任务卡的完成状态移动卡片直到卡片上的任务完成，这不就是团队日常在用的“TAPD”故事墙嘛”
小Q脸一黑。。
继而盯着电脑屏幕又陷入了沉思
此时，端着茶杯的敏捷教练路过小Q的工位，看到了小Q的电脑屏幕
“哟，最近在了解KANBAN方法啊，这个方法很不错，在帮助团队聚焦消除阻塞，优化整体的生产效率方面表现很优秀”
小Q翻了个白眼，说道：“但我的团队一直在用看板方法啊，你看，我们每个迭代都在用TAPD故事墙管理需求，但还是会出现测试资源不够啊这些情况，导致我们迭代交付延期”
“嗯？TAPD里的故事墙吗？故事墙其实更像一个“物理板”，而不是真正意义上的KANBAN。”
萎靡不振的小Q听到敏捷教练这番话，忽然来了兴致。
敏捷教练继续说道：
“ “KANBAN” 一词源于丰田生产系统，它可不是汉语拼音哦，他来自日语“看板”，カンバン，是日语罗马拼写：
“KANBAN是实现拉动式生产的工具，目前也作为敏捷框架应该用在敏捷开发中，因为发音相似，在中文中也经常写作“看板”，但是看板很容易让人联想到信息板或者数据板。所以我们一般会把的信息板、数据板等称作“物理板”，就是在一些项目中供大家站会使用的那个大白板，比如你上面百度出来的那张图，或者TAPD的故事墙。”
“哦哦，这样啊，那可能我理解KANBAN方法的有问题，你刚刚说KANBAN在帮助团队聚焦消除阻塞，优化整体的生产效率方面表现很优秀，是什么意思啊”，小Q又问道。
敏捷教练搬来了小板凳，准备给小Q好好讲解一下KANBAN方法。
“KANBAN实现了拉动式生产，就是从下游拉取上游的半成品继续进行加工，他的最核心价值在于聚焦消除阻塞，优化整体的生产效率，而不是为了优化资源利用。”
“举个例子吧，我们国家建造高速公路的目的，是为了追求道路的通畅，缩短城市间的距离，而不是为了让高速公路的每一寸上都塞满汽车，对吧？”
“哦哦，好像有点明白了，那KANBAN到底应该怎么用，才能展现出“聚焦消除阻塞，优化整体的生产效率”的价值呢？？”小Q问道
“KANBAN作为一个敏捷开发框架的话，有3大核心实践，基本就学会了使用KANBAN。一是可视化价值流；二是显示化流程规则；三是限制在制品数量。下面这个图就是个基本完整的KANBAN管理流程：”
第一条：可视化价值流
这块，跟你平常用的“TAPD故事墙”很像。将功能性需求、bug、技术改进等写在卡片上，这个卡片就叫做KANBAN，用卡片代表需求在状态池中流转，卡片在不同泳道间的流动过程，也表示了对应价值加工的过程，同时团队可以直观的从状态池中发现和可视化问题，促使问题尽快解决，消除阻碍价值流程的因素，比如用红色卡片表示阻塞和问题，我们能一眼看到哪里有阻塞，可视化的价值流在我们平时使用的物理板中也能看到
第二条：显示化的流程规则
这是我们很多团队都欠缺，或容易忽略的地方。在不同泳道间设置流转规则，其实也是在设置需求状态流转的DOD，不过规则的制定应该基于团队情况，并通过团队全体成员的认可，这样才能保证后续执行的过程顺畅，无推卸；
这一点，更容易被我们团队日常运作忽略。限制各阶段的在制品（需求）最大数量（包含进行中和已完成的），在制品小于上限，可以从上游环节拉取新的工作，若在制品达到超过上限，则不能再从上游拉取工作，形成从下游向上游的拉动机制。你可以对照上面的图理解一下，你常见的物理板其实可以算作是简化了的KANBAN流，它只包含了可视化的价值流，显示化的流程规则和在制品数量没有做明确的规定。
“哦哦哦，明白了，我们平常用的TAPD故事墙，其实是需求在研发迭代的流转状态，可以说是部分满足了“可视化价值流”的实践，但却没有“显示化的流程规则”，我们也没有关注过“限制在制品数量”，所以说我们团队平常用的故事墙算是有表没有里”小Q兴奋道
“可以这么认为的，TAPD里的故事墙，是一个电子的看板，主要是作为信息雷达存在，方便每一个对项目感兴趣的人随时了解我们的进度和状态。”
“但是它相对我刚才说的物理板，其实有一点点小缺陷，目前，在TAPD里的故事墙，故事卡片主要展示了故事的优先级、主题、跟进人和预估规模、时间，我们没办法根据需要设置我们想要展示的字段，也没办法把我们的故事进行关联；但是对于异地的敏捷团队来说，他还是一个非常有用的工具。”
小Q：“那如果我想使用KANBAN流作为我们团队项目管理工具的话，有什么需要特别注意的地方吗？”
“在KANBAN管理流中，我们用不同颜色的卡片代表不同类型的价值来源，我们首先应该注意的是代表了阻塞点或者问题的卡片；当一条泳道发生堵塞时，我们应该集中团队的力量，去解决障碍，就比如上面那张图，明显看出测试的队列已经严重阻塞了，这时候我们团队应该一起去解决测试的问题，就不要再继续做其他泳道的需求了（防止过量生产）；”敏捷教练解答道
“另外，也不是说来一张KANBAN就要马上安排处理，团队应该有自己对应的规则，比如根据需求价值、优先级排序；最后，如果团队能形成一个稳定的输入输出节奏（需求产出和交付），就更好了。”敏捷教练继续说道。
小Q：那什么时候适合使用KANBAN流模式呢？
“嗯，如果我们团队的需求来源特别多，比如需要同时支持多个业务团队的时候，需要处理的需求没有特别大关联的时候，又或者产品基本完成，剩余维护类更新的时候，都可以使用KANBAN工作流；团队负责的产品不需要有固定发版节奏的时候，也可以使用KANBAN工作流。”
“那KANBAN和SCRUM有什么不同吗？哪一个框架用来做敏捷开发更好呢？”好学的小Q又问道
“是有一些不同的：
1.scrum明确定义了团队成员的角色，SM、PO、TEAM，而KANBAN中弱化角色的存在；
2.scrum中对迭代时间盒有明确约定，将项目周期拆分为固定时长的迭代周期，每个迭代完成一部分可交付的功能，迭代周期一般建议2-4周，KANBAN中没有固定的时间盒；
3.scrum将产品需求拆分为用户故事，根据优先级选择迭代范围，范围一旦确定，尽量不发生更改，KANBAN中采用拉动式生产，下游任务完成后，从上游拉取任务，生产力足够的情况下，可以随时插入新任务；
4.Scrum通过迭代容量间接限制在制品数量，而KANBAN方法则限制的更直接，对同一状态同一时间内的工作任务设置最大限制；
5.Scrum是以生产率作为计划和改进的依据，以迭代（sprint）数据作为依据，分析迭代的相关数据（包括生产率、完成率等），Kanban方法是使用生产周期作为计划和过程改进的依据。
scrum和kanban方法都是敏捷开发框架，都体现了持续改进的思想；也都关注尽早交付价值，频繁交付可以用软件；scrum中的物理板和kanban board都能直观反映团队的状态，方便团队找到问题和瓶颈，团队可以根据自己的实际情况选择。”
“搜嘎，明白了，那我按照你的方法去匹配一下我们团队的现状，争取快点解决目标交付延期的问题”，小Q心满意足道
“好，有问题多找我沟通，茶喝完了，我再去续一杯”
此时，坐在小Q身边的女神小美，崇拜地看着敏捷教练的身影，久久不能离开。小Q暗暗下决心，一定要多学敏捷知识，迷倒女神，成为人生赢家！！
[○･｀Д´･ ○]
想了解更多小Q的故事，请关注公众号
