概览
前言
很多团队工作流程并不适合Scrum方法固定时间盒，期望更多开发工作能更快的完成，而不要缩减范围或牺牲质量，聚焦单个或少数工作并努力协作使得工作以持续价值流动的方式尽快完成
没有独立的开发团队和测试团队。当需要把全流程整合到一起，就很困难
因此引入Kanban
第一章 Kanbaneros团队开始看板之旅
以小故事的形式介绍看板，通过简单介绍，了解看板的所有工具和知识
原理和内容在后续章节也会讲解，略过
第二章 看板原则
概念诠释
看板方法：一种组织中创建渐进变革的方法，大卫.安德森（David Anderson）创立并完成《看板方法：科技企业渐进变革成功之道》
看板：一种可视化流程管理系统，描述生产什么。何时生产以及生产多少，有时指的是实际的视觉信号
看板系统：用以跟踪在制品的系统，如一面看板墙加上信号卡和工作中遵循的规则就是一个看板系统
与日本关联
kan 日语中可视的意思，ban是卡片的意思，组合一起就是“可视化卡”或“信号卡”
看板概念源于丰田，看板的发明解决了生产方式（just in time）调度问题，丰田生产系统被称西方之为精益生产系统，后称为精益制造和精益思想
2.1 看板原则
三个简单原则
可视化、限制在制品、管理流动
三个原则->六个实践
1 可视化
2 限制在制品
3 管理流动
4 显示化流程规则- 通过明确的规则，对整个流程展开讨论，讨论基于客观数据而不是假想、感觉、传闻（作者认为是可视化的一部分）
5 建立反馈环路- 关注从流程中获得的反馈（作者认为是管理流动的一部分）
6 协作式改进、试验中演进（使用模型和科学方法）- 鼓励人们使用模型（如约束理论、精益思想）来推动整个团队持续改进(作者认为这一观念深植于看板所基于的精益原理之中，而非看板本身的原则，是看板发源的环境和生态)
4个原则（大卫.安德森用原则来描述如下内容）
从现状开始
追求增量和渐进的改变
初始时，尊重现有的角色、职责和头衔
发挥组织中的各级领导力
2.2 马上开始
1 从工作可视化开始
2 在白板上绘制工作流程
- 确保和整个团队一起绘制白板，不要单独一个人绘制，会影响整个团队的接受度
3 用一些工作项来演练一下
4 决定在制品限制
- 一个团队，同一时间可以并行多少个工作项，可以先设定一个值，需要的适合再改进
5 作为补充方法，可以创建代表自己的头像
2.3 小结
基于简单有效的理念发展出软件开发方法，目标促进工作再整个价值链中的快速流动
简单有效的原则：可视化工作和规则、限制在制品的数量、促进工作快速流动
3 工作可视化
安灯拉绳（Andon cord）或称停止生产线拉绳（stop-the-line cord），哪台灯闪烁表明哪个工作台出现了问题，相关同事会得到告警
有时候透明化会让人感到威胁，大家有自己习惯的工作方式，可以一小步一小步的引入可视化手段，并让团队自行决定可视化什么信息以及如何做
3.1 规则显示化
规则清晰，避免误解导致低效的团队合作
规则不是法则，如有必要，团队商议后可以调整
信息辐射源：用来展示信息，需要放置再人们路过就能看到的地方，通常是形状巨大的显示器和可见的图表，只要看一眼就能看动
1 不要把信息隐藏到“信息冰箱”里
电子看板和物理看板
电子优势：处处可访问、数据不丢失、自动计算度量数据、保存每项信息和相关讨论
物理优势：大、自然的集会地点、更易于创建、易于根据特别需求进行变更和调整
2 坐一起？奢侈！
团队自己确定使用电子还是物理看板
3 无法处理
避免信息过载，不要再辐射源上放置太多图表、太多信息、太多细节
4 选大弃小
确保信息以足够大的方式呈现，一定距离也能很容易看到，文字要清晰
5 使用它或抛弃它
不要包含对团队或干系人没有价值的信息
6 1+1等于3
规则呈现在你面前，帮助你做正确的事；当同事看到你可视化的工作后，一旦它和团队达成共识的规则有所偏离，会施加正面压力
3.2 看板墙
共享信息促进高效协作，如谁在完成哪项工作、是否都有集中精力关注最高优先级的工作、阻塞事项是否悬而未决、瓶颈环节前工作是否堆积如山
3.2.1 看板墙
3.2.2 将工作流映射到看板墙上
团队成员设计看板墙，选择一个实际工作便于梳理流程
3.3 队列
明确合适队列以及准入准出标准，常检视标准
至少两个人同意这些标准都被满足了才能移动工作项
3.4 小结
工作可视化- 将工作及其相关的规则可视化
可视化有利于更好的理解工作流动和有效的合作建立信心透明和共享
可视化将不可见的信息可见，将隐含的知识和规则显示化，这样做后，需要解决随之浮出水面的不一致和冲突
看板墙是一个好方法，用来可视化工作流和共享信息
看板墙，将信息传递给每个感兴趣的人，避免了信息隐藏在人们的脑子里或难以访问的工具中
创建看板墙很容易：将工作项的流程所经历的步骤，映射到一张白板或者一面墙上刻画的不同列中
第四章 工作项
4.1 创建卡片的设计原则
1 促进决策制定
2 助力团队成员优化结果
- 如，一个工作项具有高风险，需要用某种方式展示给团队成员，避免冒险行为
- 如，有高优先级客户，要标识出来
- 够简单明了，确保团队成员清晰获得它所表达的目标
4.2 工作项卡片
4.2.1 工作项描述
1 用户故事
- 3C（card、conversation、confirmation）
2 标题
3 “就是那个。。。”
the one where 只是一个事情的引子，不需要写在卡片上
如（就是那个）名称字段允许太多字符
4.2.2 头像
团队成员头像，易于辨识，建议头像和本人相似
4.2.3 截止日期
突出在工作卡片上
4.2.4 跟踪标识
即时贴的有限工具无法包含为完成一个项目特性需要的所有信息，需要在电子系统中记录辅助信息，即时贴和电子系统记录项之间建立标识，便于查找、建立联系
避免把所有信息都放入电子系统，导致工作卡片退化为无法被理解的描述
避免双重工作（物理板+电子版），可以明确主要方式和辅助方式
4.2.5 阻塞事项
1 受阻的工作项
区分受阻事项和原因
2 阻塞事项进展
关注受阻事项进度而不是不闻不问，如标识受阻时间
将“味道”升级：发现味道、highlight味道、解决味道
4.3 工作类型
挑选一定数目的工作类型，选择合适颜色的便利贴
4.4 进度指示器
帮助记录工作进度
4.5 工作项的大小
4.6 收集工作流数据
4.6.1 收集工作流程的度量数据
4.6.2 收集情感数据
展示当时的感受
4.7 创建工作项卡片
需要知道什么信息才能处理这个工作项？
并不每日处理工作项的人会对什么信息产生兴趣？
是否有不同类型的工作？是否从区分不同工作的类型中获得收益？
是否需要阻塞事项？如需要规则是什么？对于标记受阻的工作项应该采取什么行动呢？谁来负责解决阻塞事项？
创建个人头像
4.8 小结
工作项应该包含所有团队需要知道的信息以便于处理：
描述- 从中可以知道工作内容
头像或其它标记- 从中可以知道谁在处理这个工作项
截止日期和其它重要的日期- 从中可以知道合适需要完成该项工作
跟踪标识或其它外部系统的索引- 从中可以知道哪里能找到更多信息
阻塞事项- 从中可以识别初无法进展的受阻工作项
工作类型- 从中可以知道工作类型，可以根据不同类型设置优先级
进度指示器- 从中可以知道目前未知以及完成了多少工作
大小- 从中可以看到工作项的大小于投入的区别
其它：流动数据、情感、当工作流经看板墙时累积的其它数据- 从中知道工作流动的表现和团队对此的感受
选择适合的特征，不要求全做
第五章 在制品
5.1 了解在制品
在制品（work in process，WIP），看板核心原则之一
进行中的工作 | 流程中的工作
5.1.1 什么是在制品
在制品指手头在正在处理的所有事情，包括正在处理的任务、等着被验证或者部署的工作项、虽然还没开始但已经等待被处理的事情
所有这些都需要完结，才能交付最终客户价值
1 在制品和前置时间
限制在制品并不意味着应该做更少的工作，而是指应该减少在同时处理的工作，帮助你更迅速的完成更多的任务
2 利特尔法则
约翰.利特尔（John Little）从数学上提出，同时做的事情越多，每件事情花费的时间就越长（前提其它条件，如工作项大小、团队成员等不变）
5.1.2 软件开发中的在制品是什么
尚未实现的需求规格说明、未被集成的代码、未测试的代码、尚未发布的代码
5.2 在制品过多的影响
5.2.1 上下文切换
在知识工作中做上下文切换，脑中要同时记住每件任务，不仅浪费时间还很难聚焦，研究表明会浪费10%的工作时间会用在每项工作的切换
5.2.2 延迟带来额外的工作
由于延迟，要处理更多（流程中的）工作，而且这个问题拖长了反馈环
如当时提缺陷和两个月后提缺陷，解决起来前者会更块，后者还需要回顾
反馈是敏捷的核心部分，是知识的创造者，及时的针对一个糟糕流程做些微小改进，让它变的更好
延迟反馈让修复问题更困难，或许更难找到根本原因
5.2.3 加风险
同时间更多工作进行，导致团队不能快速应对变化，容易被周遭环境变化所影响
5.2.4 更多开销
大量在制品的一个非常糟糕的地方是，它们需要被协调，因而会产生很多新工作
这是个恶性循环，很快就会失控，最后你只能做协调工作了
5.2.5 质量下降
如对于开发人员，被拖长的反馈环，长周期时间会牺牲代码质量；反馈环从写代码开始，到知道如何被验收，以及如何在生产环境中发挥作用
5.2.6 缺少动力
过长的前置时间会降低团队的动力
当A请B做问题反馈，该问题是B待办事项的最后一个，对于A来说也打击，当B给这个反馈时，A已经再做其它工作了，对于结果没那么在意了
5.3 小结
WIP，至少有两个含义，进行中的工作和流程中的工作，作者倾向于使用流程中的工作
利特尔法则，更多的在制品会让每个工作项的周期时间变长，应该约束在制品，获得更快速和更短的前置时间
在制品有多种表现形式（总结是待办但未完成的事项）
大量在制品会带来问题和负面影响（上下文切换、拖长反馈环）
过多在制品的几个表现（风险增加、消耗变多、质量下降、动力降低）
第六章 限制在制品
6.1 确定在制品限制
影响因素（包含但不限于）：
所在组织持续改进的动力有多大
团队的规模以及团队可投入工作的时间
正在处理的工作项的类型和规模
基本原则：
更低比更高好
人员闲置或者工作闲置
没有限制是不对的
6.1.1 更低比更高好
通常低比高好，尽可能限制并行工作项数目，缩短前置时间，提供更快反馈，强迫移除各种阻碍因素；有助于改善工作项的流动
但过低会让过程因为出现各种问题而陷入停滞
WIP过低暴露出的问题一般是流程中需要改进的问题，但快速暴露太多问题，可能使团队难以招架
6.1.2 人员闲置或工作闲置
6.1.3 没有限制是不对的
不限制的风险在于会得到一块堆满工作的看板，看板体现出你效率低下，无法推动工作取得进展
最终，看板会被放弃，因为你甚至无法看清板上的工作项
如果允许无线的工作项出现在看板上，就没有动力逼迫你在开始一项新工作之前完成旧的工作项
6.2 设置限制的原则
在制品限制数目并不重要，最关键的是将目前的在制品限制可视化，根据需要不断对它进行调整，拥抱变化
6.2.1 停止启动，聚焦完成
在新工作开始前，进来完成正在进行的工作，通过这种方式，限制了并行的工作项数量、缩短了前置时间，让工作快速通过整个价值链，帮助你获得反馈、加速过程
不是“你开始的越多，就完成的越多“而是”你结束的越多，才完成的越多“- David P.Joyce
6.2.2 "1"并不是答案
6.3 整块看板，整个团队
6.3.1 选择1！选择2！
每人一个还是每人两个，每人一个容易受到阻碍，每人两个对团队的驱动不够
人*1.5 ，平衡阻碍和驱动力问题、持续改进
6.3.2 一起来吧
每人同时间至少一个工作项在进行，若团队在结对编程，则WIP调得更低
如WIP小于团队人员数量，可促进团队成员共同合作，对于平时不太紧密的团队，开始别把WIP限制的太小，可以在之后逐步调低，同时对过程做出改进
6.3.3 降低在制品规模，以20%的速度
限定规模为团队成员*2，然后阶段性递减
可阶段性递增或递减WIP规模，保持观察
6.3.4 选一个数字，开始尝试
6.4 基于列的在制品限制
对于每列设置限制，利于更精细控制，更好了解工作的流动情况，并有机会消除瓶颈和流动不顺畅
6.4.1 从瓶颈处开始
瓶颈决定了整个工作流的步伐
瓶颈流程得不到解决，提高下游的吞吐量毫无作用
6.4.2 选择可以帮助你改进的列
关注你使用Kanban的出发点，先改进诉求点
6.4.3 请保持有限的故事
根据估算的工作流来限制在制品意味着只在可接受的限制范围内带入新工作
限制品数量结合故事点工作量
6.4.4 如何可视化在制品限制
6.5 按人员限制在制品
一些团队选择限制每个人的工作项数量，你关注的不在是优化整个流程的流动，而是在每个人都有工作的同时，不让某个人做太多的事情
限制个人在制品的通用方法
1 整个看板墙不足以放下所有这些头像
印三张头像，则每个人的在制品限制为3，可以很容易看出每个人在做什么，每个人手头有多少正在进行的工作项
2 请在你自己的泳道中游泳
还有一种限制个人在制品的通常做法是为每个人创建一条贯穿整个过程的泳道
这样可以确定每条泳道的在制品限制，有效的使泳道中存在一定数量的工作项，并且这些工作项可以分布在任何列上
这个方法也适用于多团队的看板墙上，从而限制每个团队或小分队（团队的一部分）的在制品
这些策略目的使侧重于确保每个人有足够多的工作可做，但对工作流动到完成的状态帮助不大，可以以此为起点，但效果值得商榷
客户并不关注你是否忙录，他们只希望你能交付成果
6.6 常见问题
6.6.1 工作项还是任务- 你限制的是什么
任务是工作项的拆解
许多团队采用对工作项进行在制品限制，任务只用于追踪为了完成工作项所需要做的事情，这些事情通常不交付客户价值
有时可能需要限制某些特定列里的任务数量
6.6.2 应当对等待队列设置在制品限制吗
如下在两个队列，则共同遵守开发队列的在制品限制
如果是独自一列，则无需遵守其它列的限制，有单独的在制品限制数量
6.7 练习：设置在制品，正确地设置在制品
没有最优的在制品限制可供选择，那只是一种用来帮助你改进工作的工具
需要考虑：
是否应该对整个看板墙设置单一的在制品限制？这对你有何益处？
开始的时候，是否可以从限制某些列中工作开始？应该是哪些列？为什么？
如果限制每个人的在制品，将给你带来什么？
如果每个泳道都设置在制品限制，是否对你的情况有帮助？
考虑这些政策将如何影响你们的日常工作：
你设置限制的方式，是在鼓励何种行为？
当你的在制品限制将要被打破时，你应该如何应对这种情况？
阻塞的等待队列中的工作项应该计入在制品限制吗？
6.8 小结
如何设置合适的在制品限制并将其可视化
1 对于你和你的团队，没有特定的在制品限制方式
2 限制在制品不是目的，改善流程才是；在制品限制只是一个工具，能够帮助你发现阻碍流动性被改善的问题
3 当开始设置在制品限制时，一切从简- 也许仅仅是一个口号”停止启动，聚焦完成“
4 可以为团队/工作流设置整体的在制品限制
这种方式可以帮助你改善合作
帮助你专注于在新工作开始之前，完成旧的工作项
5 可以按列设置在制品限制
这会让你聚焦到工作项的流动上
这能帮助你管理瓶颈
也许你已经认识到要从哪里改进，可以从给那一列设置在制品限制开始
可以通过估算的工作量来限制工作（如按故事点）
6 可以按人设置在制品限制
限制可分配的头像数量是这样做的一种简单方式
另一种方式是利用泳道
这样有利于防止多任务并行，避免某些人要参与到几乎所有的工作项中
7 绝大多数团队都会针对工作项而不是任务限制在制品数目
7 管理流动
7.1 流动为何重要
如果实现了单件流，就没有延期、没有队列、没有批量、没有库存、没有等待，不会有生产过剩，根据客户实际需求的产品，即时交付
流动能带来灵活性和快速反应能力，更好的风险管理，更快的反馈以带来更好的质量（构建正确的产品并使用正确的流程），提升可预测性以增强互信，减少加急请求和加速价值交付
流动还能暴露改进机会并提供改进努力的愿景：更快的流动
如何取得更快的流动：消除浪费
7.1.1 消除浪费
通过去除没有增加价值的浪费来缩短整个时间
7.1.2 软件开发的7种浪费
部分完成的工作：没有完全完成的工作就只是在制品
多余的特征：”没有比生产过剩更大的浪费“，构建正确的产品
重复学习：未能从之前的错误种学习，不得不重复失败
工作交接：需传递额外的必要信息，并丢失部分信息
延期：延期会造成额外的工作
任务切换：对关注力和能力造成浪费
缺陷：产生额外工作，并会减缓正在进行的工作
不过分执着消除浪费，看是否产生浪费和价值，以及投入产出比
7.2 帮助工作流动
7.2.1 限制在制品
当团队期望保持工作流动时，限制在制品是一项基本实践
在制品越少、流动越快、能发现改进的机会越多
到底时改进流程还是优化资源利用，这是一战略决策；但通过聚焦流动效率能减少大量不必要的工作和浪费，从而实际上优化了资源利用
7.2.2 缩短等待时间
第一步做到显示化，提醒别人等待状态可以被拉动，也易于跟踪和度量花费在等待中的时间，洞察其中的改进机会
1 确保工作就绪
可以计划和拆分工作以减少依赖，可以让外部或资源准备就位使得工作不被被阻塞，可以将工作设计的利于合作以致于完成工作的团队成员能协助你的工作而不必拉入新工作
实例化需求（Specification by example）是确保彼此理解的最好方式之一
将需求写成验收标准的形式或者特性如何被使用的具体实例（使用真实的数据），当实例被满足时就是特性开发完成之时，既不多也不少，刚好满足
2 确保工作项较小且尺寸相近
小工作项会缩短前置时间并降低在制品数量
尺寸相近，流动将更加平滑且可预测性提升，从而有助于建立互信并避免使用”特殊需求“的快速通道
7.2.3 消除阻塞
一名优秀的敏捷开发人员完成的每一步都为下一步工作做好了准备，用于不会阻塞自己的工作也不会阻塞其它人的工作
如果已经尝试了所有方法，但还是被阻塞，那么先不要开始新的工作
也许在等待阻塞被解决的过程中，可以完成其它一些事情
阻塞事项也是一个学习如何改进工作的机会，什么原因导致阻塞？是否可以做点什么来预见或通过变通的办法来应对？通过分析根本原因来学习和改进
跟踪阻塞事项
跟踪阻塞数目的变化和解决问题的平均时间
记录并跟踪阻塞，利用记录数据来理解阻塞时如何影响你以及该如何处理
当向阻塞你工作的人解释他们的工作对你帮助有多大时，这个数据也很有用
群体行动
有种行为在在很多看板团队都出现了，这种行为被称作群体行动
如在制品达到限制时，当阻塞事项发生时，或当一个工作项太大、太迟或太复杂以至于一个甚至多个人都无法处理时，团队对于限制的在制品和确保工作流动的关注驱动大家共同行动
可制定显式的规则，当遇到此类阻塞，所有人群集而上共同解决
群体行动可用来描述参与专业之外工作的一般行为，致力于帮助高风险或者高回报的工作快速完成，或者减少在制品总数
7.2.4 避免返工
返工对流程和周期时间都有重大影响
精益软件开发的关键原则之一”一开始就内建质量“，大力投入技术实践，如结对编程、测试驱动开发、持续集成、测试自动化
缩短缺陷被引入和解决的时间，并行的工作项越少且越小，就越容易缩短时间
价值需求和失败需求
失败需求（failure demand）”要求系统因失败而对客户做出某事或更正某事的需求“
进入工作流的所有需求并非全是新功能需求，有些因为某些工作并未达到预期而产生的需求，如需求太难理解、某些工件被遗漏了、设计失败、没获得用户反馈等
保证失败需求快速流程也没有多少收益，应尽可能消除失败需求以便容纳更多价值需求
开始跟踪并显示失败需求，做根本原因分析，避免以后发生类似问题
7.2.5 跨职能团队
当一个团队拥有满足需求的所有技能和资源时，就称为真正的跨职能
不依赖于跟其它团队的工作交接，也不会等待其它团队的工作
跨职能团队有助于减少等待、避免阻塞或易于消除阻塞，也有利于避免返工
特性团队和组件团队
特征团队对某个特性从开始到结束负全责
组件团队负责某个特性的一部分，可能会有团队间等待的风险
7.2.6 服务等级协议（SLA）或前置时间目标
设置目标（如timeboxing），促使工作快速流动
7.3 每日站会
每日站会是确保每个人获得团队进展并同步工作状态的好工具
7.3.1 站会的优秀实践
站会很短、站会准时开始（和结束）、站会聚焦重点、站会要有规律
7.3.2 每日站会的看板实践
1 关注事（接力棒）- 而不是人（运动员）
昨天做了什么，今天计划做什么，有什么困难阻碍完成工作
2 遍历看板墙（从右到左）
还需要做什么才能使工作接近于完成？
谁来做呢？
3 关注味道
没有遵顼规则的工作项- 味道
7.3.3 发挥站会的最大价值
1 扪心自问
你在处理的工作是否还有没在看板墙上的？
”手头小事“ 不但占用时间，也容易逐渐形成一种习惯，长远下去，看板墙就不在有意义
尽量保证看板墙能反映真实的情况
2 处理错误的工作
”我们现在是否都在处理最重要的工作？如何知道这一点呢？每个工作的优先级清晰明确吗？“
有价值的工作、紧急的工作、长期工作之间要进行平衡
3 不理解工作的原则
尽量找到更简单的方式描述你的工作
4 自发改进
成员主动关注看板上的味道项
提供帮助，并鼓励他们邀请需要的人一起解决问题或改进现状
7.3.4 规模化站会
1 为什么
确保很多人参与大规模会议既简短又专注且精力充沛，特别每天进行，使非常困难的
每日大会->每日同步->发布同步
2 多团队站会的技巧
每日大会在小组站会之前还是之后？
谁应该参加每日大会？（建议至少一人，感兴趣的都可以参见）
会议应该使用什么可视化方法来帮助决策？
是否在每日大会的看板墙上也展示每个小组的状态呢？还是每个小组一个看板墙？（避免重复信息在每个小组之间同步，聚合更好，同时注意大看板墙信息过载太细节）
3 自下而上还是自上而下
每个人经常沟通，同时促进大团队中所需要的合作
要知道谁在干什么、需求和谁讨论谁在等你进展等
常自问提供的会议价值是否值得投入？
7.4 我接下来该做什么
没有空闲就没有改进
空闲时间没有对客户产生价值，但对日后改进工作是很有益的
总结：接下来该做什么
1 你能帮助完成成已经在进行中的工作吗？完成它
2 你不具备1中的技能吗？查找瓶颈或减缓流动的其它事情，帮助解决它们
3 你不具备2中的技能吗？拉入新工作，只要不超过在制品限制
4 如果还没有工作可做，找一些有意思的并对团队有用的事情，完成它
7.5 管理瓶颈
队列和在制品限制共同构成了显示工作流程中问题的领先指标，它们揭示瓶颈在哪里，并能在阻塞发生之前提示哪里正在形成瓶颈
约束理论
系统的吞吐量至少受限于一个约束条件：减缓生产的瓶颈
没有约束的系统，吞吐量是即时和无限的
约束理论，关注于提升瓶颈的容量，充分利用瓶颈
1 发现瓶颈
瓶颈一般是前没堆积了大量待完成的工作，而后面环节却无事可做
2 充分利用瓶颈
持续改进系统吞吐量途径：
识别系统约束、充分利用约束、使用其它工作服务于充分利于约束这一步、打破约束、重复
充分利用瓶颈：
确保构成瓶颈资源的人或角色总是有工作可做（如拆分小的可独立测试的交付物）
内建质量确保最小化其工作负荷
消除或至少限制工作被打断
消除影响它们工作阻碍或迫使它们等待的事件
精心为瓶颈工作设置优先级以便团队人员总是在完成最重要的工作
通过平稳的工作到达速率使他们处于文档的工作节奏
7.6 小结
几种管理工作流动的方法：
流动（或持续流程）是描述一个流程的例行状态，其每一步都创造价值且没有中断和等待时间
对于这种理想状态的追求是永无止境的，不但帮你获得一个更顺畅、更快速的流动，也能发现流程中的问题
任何在客户眼中不是价值的事情都是浪费，消除浪费能获得更好的流动
管理流动时看板的基本原则，助力工作流程的实践：
限制在制品
减少流程中的等待时间
流程一开始，就内建质量避免返工
建立跨职能团队减少等待时间
明确目标
站会帮助更好的协作：
简短有活力、有规律、有纪律、聚焦
看板团队实践：
关注work而不是worker、便利看板墙工作项、关注偏离
充分利用站会，考虑：
是否所有工作都在看板墙上展示？
在处理正确的事情吗？
理解工作原则吗？
站会后团队鼓励自发改善会议，小的改善每天发生
多团队站会：
小组站会前开还是后开？
谁参加？
需要什么样的可视化手段？
小组看板墙和其它看板墙之间的同步状态？
第八章 服务类别
8.1 紧急情况
紧急情况：
有自己的泳道、即时贴颜色
不计入在制品限制
优先级高于正常工作，必要时每个人都应该放下手上的活来帮助解决这个问题
只做大致的估计：是否在特定期限前交付
当作例外处理：任何时刻紧急通道都只能有一个条目，每周最多两个条目
回顾：
什么样的流程导致了这一紧急条目的产生？
怎么防止它再次发生？
对这个条目是按计划处理的吗？
8.2 什么是服务类别
显示化工作项的价值、风险和处理策略
8.2.1 创建一个服务类别要考虑的因素
1 可视化
2 对在制品的影响
3 优先级设定
4 不同的工作流
8.2.2 常见的服务类别
1 固定交付日期类
卡片上明确表明到期日
优先于加急类之外的所有工作
当截止日期逼近时，考虑把它提升至加速/紧急类别
（不要滥用这个类别，让工作项变为计划驱动型的甘特图）
2 常规类
3 无形类
不具备有形和具体的业务价值，至少业务价值不易评估，但很重要
包括：低优先级缺陷、可用性改进、设计变更等
特征：
只有在没有其它类型的工作项时才被拉入
可以限制看板墙上此类工作项的数目, 同时最多两个、最多占迭代的20%故事点数、维持每个月3个工作项的速率
4 缺陷类
可以在正常的版本之外发布，不必等到下一个常规版本前就可以发布
8.2.3 服务类别的实践应用
8.3 管理服务类别
并非所有的工作都能规类上述规类
1 分割和再分类
细分工作后再做分类
2 工作项大小很重要
有时很难对大的工作项进一步分割，或者因为工作项的自然属性，或者因为相关的依赖关系
大的工作项更适用其它规则，可以考虑一个特殊的服务类别，允许再看板墙上停留很长一段时间，这段时间内总为它分配特定的工作流
3 一些客户比其它客户更重要
需定义新的服务类别
4 不同的分割方法
按需求的来源来区分服务类别
（注意，别搞得太复杂，不要超过5-7个服务分类，太多让人难以记忆、理解、决策）
5 放大、探索而后简化
放大（更多的列\分类），探索，然后简化
首先尽量的详细
8.4 练习：现在开始分类
我们要用紧急通道吗？适用怎样的规则？如何确保不被滥用？可以确保同一时刻只有一个紧急工作吗？
考虑你所作的不同种类的工作，使用特别颜色区分，让大家都清晰规则
是否有些工作总是容易被遗忘或者得不到优先级？为它们定义服务类别可以帮助完成这些”低优先级工作“吗？可以用简单的词语来描述这些规则吗？怎样可视化能帮助你记住这些规则，并不断总结提高？
哪些规则可以简化?
8.5 小结
服务类别围绕特定工作的服务登记显示化团队的规则
指定服务类别会对工作项产生影响，如可视化、优先级设定、对在制品影响
服务类别帮助自组织：
工作选择和日程安排
工作量分布
确保团队的产能按照团队达成一致性进行分布
常见类别：
紧急类- 优先级高于其它工作
固定交付日期类
常规类- 常规工作，先入先出，时间越久紧急程度提高
缺陷类
无形类
第九章 计划和估算
9.1 计划的安排：什么时候需要计划
计划是个事前活动，但又不能提前太久
9.1.1 即时计划
计划活动产出了待完成的工作项库存
事件驱动的计划方式：在流程中通过特定事件告诉你有能力进行更多工作了
与之对照的是定期计划，风险在于在计划的时间点有可能还没完成既定工作、或工作提前完成了，有空挡期没事可做
9.1.2 订货点
（order point）指当剩下的条目小于某个值时，就从利益相关人那里拉入更多的工作
如果协调成本高，则可设置高订货点，反之协调成本低，可以设置低订货点，再试验中改进
9.1.3 优先级过滤：可视化出”什么是重要的“
每列的在制品数据限制反应了团队的产能
从1-2-3，1做完了，2->1, 3->2
9.1.4 迪士尼乐园的等待时间
地铁不是火车，火车要提前预订、提前准备；而地铁发车频率高，到了一会就能做
限制在制品，更紧密的协作和更频繁的发布，对于流动有明显好处，有利于改善团队与利益相关人之间的协作和互信
交期绩效（due date performance）达成这一目标值的条目所占的百分比
- 为不同大小的条目设置不同的时间，如小条目平均耗时1~3天，中等的2~6天，大条目5~20天
- 使用交期绩效：根据对前置时间进行一段时间的度量，如”有80%的可能，这个条目会在x天内完成“
9.2 估算工作量- 相对而言
估算经常是错误的，但估算过程仍然是有用的
为了估算，需要深入研究工作，充分了解做的事，根据收益递减原理，不应再估算上花太多时间，可以做出一个快速但不那么准确的估计，可以再多花点时间做个更准确的估计
9.2.1 故事点
相对估算
斐波那契数列改良版
9.2.2 T恤尺码
T恤尺寸估算使用字母，故事点使用数字，除此之外，二者并没有大区别，意图是一致的
9.3 估算技术
以小组为单位来估算，小组最好包含不同水平、技能和角色的人
通过估算消除不确定性和发掘信息
9.3.1 卡片队列
9.3.2 计划扑克
基于斐波那契数列，给出估计点值；如果出入比较大，阐述原因，再次给出；还没办法完成一致，则取大值
9.3.3 金发女孩
《金发女孩与三只小熊》，不做大小估计，而是把工作项调整到合适的大小
9.4 节拍
（adence）固定节奏，设定目标、回顾目标
1 迭代和看板
基于timeboxing
2 基于迭代的流程开始迁移
3 看板中的节拍
看板只是三个基本原则（让工作可视化、限制在制品、帮助工作流动），没有对迭代和节拍做任何定义
但如果愿意，有可以在看板中使用迭代
基于迭代还是基于流动，如果有完整的产品待办事项且是唯一工作，基于迭代适合，保持专注；反之基于流动更合适
4 不要把看板作为偷懒的理由
如果开始从基于迭代的流程向基于流动的方法迁移
也可继续使用对你有益的实践，如有节拍的计划会议、回顾会、演示会等
9.5 用看板的方式做计划：痛苦少，收获更多
不要只是因为看板没有要求做计划而停止计划
很多看板团队在使用看板实践和原则后，发现计划和估算的需求变小了
9.5.1 计划和估算的必要性变小
估算和计划的需求是对风险和不确定性的管理驱动
为了做出值得信赖的计划，需要估算完成这些工作的工作量
同一时间做的事越多，就需要越大量的计划，这样导致更多的工作
看板，努力最小化在制品，让工作更快的流动起来
9.5.2 理性地归因：客户的诉求
客户在乎的不是计划和估算，是把业务更好、更快或以新的方式完成业务的能力
如果计划和估算能带来价值，就继续做，帮助工作更好的流动
9.5.3 #不做估算- 你可以完全抛弃它吗
1 什么是#不做估算
平均平均法则：平均来说，一个平均的工作项会花费平均的时间
只要需求足够平均，或团队学会了自发将工作分解至合适的大小，可以跳过估算
2 为什么要#不做估算
背后的驱动力是估算导致的负面行为，如估算变成了承诺、计划和最后期限
不做估算并非易事，需要纪律和能力，但带来的收益也是令人激动的
9.6 小结
1 什么时间计划，发现计划时机的不同方法：
不要太早也不要太迟，在需要时计划
事件驱动的计划，订货点
更频繁的计划让利益相关人更紧密的参与，建立更好的信任，但成本高，需要平衡
显示预期交付时间的方法
2 计划和估算经常是应团队周边的人要求才去做的，如何把工作流向上游和下游扩展
3 建议使用相对估算
4 估算技术：
卡片队列、计划扑克、金发女孩
5 节拍是所处流程的自然节律，在基于迭代的流程中，迭代的开始和结束就是自然节拍
6 应用看板方法，可以设置评审、计划、演示、回顾等活动节拍，不用把它们和工作流绑定在一起
7 计划和估算的必要性
使用看板的团队发现有了更紧密的反馈循环，计划的必要性降低了
客户要的是业务能力提升，而不是计划和估算
如果你在发现新的信息，那么计划和估算就算是有用的
”#不做估算“ 运动谈到了放弃估算，发现不依赖不算而高效工作的方法
第十章 流程改进
看板源于精益思想，持续改进（kaizen）和尊重人是它的一切之根本
可视化是个简单有效的方法，使自组织改进成为可能，限制在制品数量和帮助工作流动让瓶颈和改进的机会对团队可见
然而，看板并不直接解决这些问题，只是暴露改进机会，发现改进方法还是你自己的事
10.1 回顾会议
10.1.1 什么是回顾会议
一般1~4周要进行回顾，回顾的目的是得到有限的几个改进（最好不要多于3个）行动在洗一次回顾会议之前实施
要做的小改进，常改进，确保改进在可控的范围内
回顾会5部分：
1 做好准备
启动回顾，并定义好基调，让每个人都了解回顾会议的基础指导原则
2 收集数据
收集发生的事实和数据
3 产生洞察
分析收集到的数据，看看可以得出什么样的结论
4 决定怎么做
找到合适的行动列表，这些行动在下次回顾会议前完成
如果没产生行动项，在过程中就已经解决了，也可
5 结束回顾
对于本次回顾会议的简单回顾，比如了解本次回顾形式的看法，如何改进
为了保持专注，最好限定timeboxing
10.1.2 如何操作
1 启动回顾会议
展示回顾基本指导原则
收集数据（让团队写下自上次回顾后的重要事件）
重复之前的操作（写下需要改进的事情）
类似的想法，按不同主题分组
再做一遍练习，关注的是理想情况（期望团队的样子）
2 产生洞察
产生了许多想法
让团队选出1~3件希望下一阶段改变的事情
决定怎么做
结束回顾
每个人写下对回顾的建议
感谢大家的参与
应该在什么时间进行回顾
关注迭代的方法（如Scrum）有固定的节奏，看板基于工作流，没有固定的开始结束时间，可以定义个合适的时间节奏
10.2 根本原因分析
如何做
1 我们为什么要解决这个问题
自下而上分析问题带来的影响
2 找到问题的根本原因
自上而下挖掘根本原因
自我增强环路（self-enforcing loop），注意不要形成恶性循环
10.3 看板招式
10.3.1 什么是看板招式
1 每日招式
在每日站会上融入改进工作
2 改进和教练招式
改进流程的正式方法
关注改进学习者（团队中的人员），它属于教练技术
10.3.2 发生了什么
10.3.3 这为什么有效
通过每天组织和实施小小改进，创建习惯和思维方式
10.4 小结
持续改进和尊重人是看板的核心
看板帮助你发下改进的机会
回顾会议让团队回头监视流程，发下可改进的地方
根因分析帮助发现问题根源而不仅是解决症状
看板招式是一个持续改进的工作，源自丰田的改进方法
看板三个招式：
日常招式- 改进融入日常的工作中
改进招式- 流程改进的正式招式
教练招式- 改进学习者
看板的招式表示你为了实现目标遵循一套方法，直到这些方法变成一种本能的反应，改进成为常规工作的一部分
第十一章 用度量指导改进
11.1 常用度量指标
11.1.1 周期和前置时间
周期时间指的是工作项通过部分流程所用的时间，如开发或测试
前置时间则指的是完成整个流程的时间，即从创意到特性完成投产的时间
周期时间只关注局部，前置时间反映整个流程
关注周期只是局部优化（optimizing locally），要关注整个流程
1 获取度量数据
从看板看时间差
2 分析度量指标
如得到前置时间和开发测试周期时间数据，团队开始分析工作表现
周期时间占前置时间的比率？这个数据是在增加还是减少？应该占多少合理？其它时间花在哪了？需要跟踪其它部分的周期时间吗？
分析时间变化趋势
对于同类型和大小的工作项，周期时间正常吗？
根据前置时间做优先级设定，如中等大小需要5~8天完成，有个需要6天内完成的工作，就需要调整这个工作的优先级了
分解前置时间，看它究竟花在了什么地方？多长时间的等待和阻碍？多少返工？
发现瓶颈从而做出改善
3 可视化度量
线型图、柱状图、控制图、累积流图等
11.1.2 吞吐量
吞吐量：生产过程中输入和输出的移动，单位时间的产出，达成目标的速率
跟踪吞吐量帮助我们关注事情在过程中的流动，保证工作被完成，吞吐量越高越好（每个时间段完成更多的数目），但是不能以牺牲质量为代价
1 获取度量数据
每周（或其它时间单位）完成的工作项计数
2 可视化度量
散点图或堆积条形图
3 分析度量
根据吞吐量可以让我们关注需求的完成
11.1.3 问题和受阻工作项
度量阻碍流动的工作项
分析受阻工作项怎么影响前置时间/前置时间效率？解决和消除阻碍的过程如何？
跟踪问题是一个平衡指标，确保不至于过度关注周期时间跑的过快
1 获取度量数据
缺陷的数目、阻碍项的数目
2 可视化度量
散点图、堆积条形图
3 分析度量指标
阻碍项的数目很值得分析，让你慢下来，并降低前置时间效率
跟踪、记录、分析阻碍项，指导团队应对阻碍、设定工作优先级和改善流动
11.1.4 交期绩效
衡量承诺和期限被达成的程度
根据预测前置时间，到期期限是否能够得到满足，并建立跟踪记录表，让你变得可信任和可信赖，从而帮助你建立和利益相关人之间的信任
1 获取度量指标
记录预期完成时间和实际完成时间
2 可视化度量指标
3 分析度量指标
准时率的表现可以用于和团队以及利益相关人沟通，同时帮助你排定优先级以及激励团队
有了长时间和可靠的准时交付记录，能建立和关联团队以及利益相关人之间的信任
11.1.5 质量
度量工作的质量以及完成的特性是否为利益相关人和客户创造了价值
质量是其它改进（如前置时间）的重要平衡，可以帮你审查质量改进的努力是否取得预期的效果
1 获取度量指标
产品中每个版本的缺陷数，最好能显示随时间的变化
单位时间内，看板墙上的缺陷条目总数，显示有多少资源被用于解决缺陷
对于缺陷，可以单独跟踪之前提及的大部分度量（前置时间、吞吐量等）
2 可视化度量
很多种方式，尽量展示在看板上
3 分析度量指标
可以进行AB试验、分析某个问题导致的影响从而找出解决方案
11.1.6 价值需求和失效需求
度量有多少工作是由系统错误引发的，如不得不重复做的工作
如果系统减少失效需求，从而增加有价值交付的产能
失效需求：因为之前没有做某事或没有正确做某事而导致的对系统的需求
1 获取度量指标
失效需求分类很困难，获取度量也不容易
不用过分纠结，找个简单可行的分类方法即可
2 可视化度量
可视化数据趋势
3 分析度量指标
启发团队以及利益相关人，让他意识到时间都花在哪里了
面对这些度量，就能着手计划如何应对，为什么有这么多失效需求，根源是什么
11.1.7 被抛弃的想法
度量有多少条目被抛弃而没有进入开发流程，以及开发流程中的需求又有多少被抛弃
进入流程中的条目被抛弃的过多，意味着开始了太多不应该开始的工作
1 获取度量
设置回收篮，把被抛弃的需求放入其中，做好标记，每隔一段时间统计被丢弃的数量
2 分析度量指标
不应过多撤出，可能会让目标不清晰
但如果没有任何撤出，就应该怀疑是不是创新不足，为了保持不变的待办扼杀了探索渴望
11.2 两个强大的可视化方法
11.2.1 统计过程控制（Statistical process control，SPC）
质量控制方法及背后的变异理论（theory of variation）
1 变异理论
原则1：你应该预计到事情会变异（波动），他们总是这样
通过统计过程控制图，就能得知变异是可预测（在控制极限以内）还是不可预测（超出了控制极限）
原则2：理解变异，你就能知道可以预期什么
控制上下线告诉我们，团队的结果有时会低至下限，有时会高至上限，但更多时候是在均值附近
团队总是期望每次都能达到均值或更好，但这是不可能的
激励人们的并不是目标而是自治、精通、意义
原则3：找出变异的原因，它们总是存在于系统之中
大部分变异都可以从系统本身中找到原因，而不是系统的单个人的控制之内
导致自然变异的因素在团队的控制之外
原则4：理解变异，它能告诉你发生什么
在统计过程控制图中，可以看出单个点值是特殊原因导致或者共同原因导致
2 SPC图
一个SPC图显示了流程随时间的运行情况，通常用来跟踪周期或前置时间，也可以跟踪其他指标
统计分析能帮助你排除偶然的高点和低点（又称异常点），从而更好的把握和聚焦真实的趋势
3 为了画图你需要什么数据
工作项的编号或标题，区分工作项
开始和结束时间
工作项类别
4 怎么画一个控制图
5 如何解读控制图
不必过度关注第一个数据
如果差异不够大，表示工作项的前置时间比较精确
需要再等等，看样本空间增大会怎样
需要关注分布（控制上限和下限之间的距离）是否很大，意味着工作项的大小差异很大，前置时间很难预测，如何改进？
如果趋势不错或出现异常，分析原因
11.2.2 累计流图（cumulative flow diagram，CFD）
1 需要什么数据
看板每天每个步骤中的工作项数目，每天记录更新
2 怎么制作图表
堆积面积图（stacked area diagram）
解读信息：
在任何给定日期，前置时间都可以从图中着色区域水平长度看出
流程中特定阶段的周期时间也可以通过对应区域水平长度看出来
待办事项列表的大小可以通过上方区域的高度看出，也是输入对列中条目的个数
可以通过度量直至已部署（已完成）列的所有区域的总高度，得到总得在制品数目
11.3 用度量指导改进
1 使其可视化
可视化并不能直接改善流程，但是它针对为改善的讨论提供了数据基础，而不仅仅依靠直觉
2 是否产生了业务影响
应该选择哪些对业务来说重要的度量指标？希望实现的目标是什么？怎么知道是否朝着目标前进？
3 你将得到你度量的东西
建立一个目标或度量，很快就会看到人们为了实现这一目标而发生的行为改变
同时也是危险的，要避免度量驱使错误的行为
4 平衡度量指标
不要只关注单个度量，会让你忽略流程的其他重要方面
寻找几个相互平衡的度量指标
5 让数据易于获取
为了跟踪度量指标，要先收集数据，然后可视化显示给关心的人
要确保不花大力气可以获得这些数据，如果投入过多，就会不愿意改变，甚至忽视改变的需要了
6 优先使用真实数据而不是估算数据
真实数据是那些对工作的真实情况、工作的质量、产品的使用情况等的度量
但真实数据并不一定是精确的
跟踪我们的时间都花哪里了？
7 把数据用于改进，而不是惩罚
11.4 练习：开始度量吧
和团队一起讨论哪些度量指标可以帮助你了解流程状态
1 是否已经有了一些度量指标？它很好用吗？它能帮助你了解当前的状态吗？
2 在所建议的度量指标中，哪些值得尝试？会给你带来什么帮助？
3 还想引入其他度量指标吗？
4 希望鼓励什么样的行为？这些度量指标能在这一点上提供帮助吗？
从简单和容易开始，度量一旦开始就很难停下来，确保每个人都了解度量指标的目的
不要把他们强加给团队，最好的度量指标应该来自团队
11.5 小结
为了了解是否在改善，要度量流程表现并分析这些数据
度量指标就像是对你的流程健康状况的可视化
以下是常用的看板度量指标：
周期时间- 完成部分流程所需的时间
前置时间- 完成全部流程所需的时间
吞吐量- 每周（或每月等）所完成工作项的数目
看板墙上问题和阻碍的个数
交期绩效
价值需求和失效需求的对比
看板团队经常使用的图表：
统计过程控制图- 对前置和周期时间的可视化
累计流图- 展示了流程的许多信息，依据是每天每个阶段中工作项的数目
找到好的度量指标很难，记住：
你将要得到所度量的东西
不要仅仅关注单个度量指标- 要使用平衡指标
使用易于获取的度量指标，或者让它们变得易于获取
优先使用真实而不是估算数据
把度量用于改进而不是惩罚
第十二章 看板陷阱
12.1 只工作不玩耍，聪明孩子也变傻
看板是轻量级的方法，很容易运行起来，只有几条原则，可以使用基于Scrum或其他迭代的方法，也可以把迭代去掉，就可以获得持续的工作流动和“没有空闲去休息和创造”
但这不是必须的，看板并未规定不同的工作需要相同的节奏
看板提供足够的自由将不同的活动分离，比如计划、验收和回顾之间的分离
使用在制品驱动团队合作，有时要获得“空闲来休息和创造”
建立庆祝的节奏
1 航空积分里程
如基于故事点数作为庆祝的节点
2 设定蛋糕的限制
在已完成列设置数量限制，必须有所庆祝才能继续流动
12.2 时间盒对你有用
看板并未内建时间盒，有时需要时间盒，帮你设定优先级并在范围、时间和成本之间建立必要的平衡
迭代和时间盒鼓励你对能塞入一个迭代的工作进行修剪
12.3 必要的变革
看板使用渐进（evolution）的方法进行变革管理，从现状开始- 同意增量变化- 尊重当前的流程和角色
但如有变革需要，可以自行掌控改进的速度和目标，确保改进适合团队的处理能力
看板不是停止使用最佳实践的借口
12.4 不要让看板成为懒惰的借口
看板只有三个简单原则，没有规定太多东西，不要成为停止尝试有益实践的借口
坚持有益实践，除非证明它对团队没有价值
12.5 小结
陷阱1：看板最终会变为永不停止的工作流- 只有工作、工作、工作
方案1：通过增加必要的评审、回顾、计划的节奏以保证这不会发生
陷阱2：看板没有建议时间盒，消除了需要完成工作和进行取舍的限制因素
方案2：为单个工作项加入时间盒，通过截至期限或服务等级协议做到
陷阱3：看板可以从你的现状开始，可以不做任何改变的情况使用看板，但有时你需要一次变革
方案3：没有什么阻碍你引入新的角色或采用新的工作方式；通过限制在制品，控制改进节奏，低在制品意味着更多改进机会
陷阱4：看板是个元流程- 改进已有流程的流程
方案4：不要仅仅因为看板没有提就轻易去除今天尚能工作的事物
陷阱5：使用看板的第一个错误就是一开始时不设置在制品限制，意味着没有约束来推动你的改进
方案5：在制品是3个基本原则之一，要遵循基本原则，才能享受方法带来的益处
第十三章 通过游戏教授看板
13.1 传递硬币游戏
分三次迭代进行，1枚硬币、5枚硬币、20枚硬币，记录时间，讨论问题，分析结果
观察前置时间（从开始到结束）与周期时间（每个员工的工作时间）
客户对什么感兴趣？交付的价值还是资源的利用率? （灵魂拷问）
13.2 并行数字任务游戏
用不同颜色的笔，分别书写三种类型数字
游戏阐释了减少在制品可以缩短前置时间，帮助缓解紧张和压力
讨论了多任务并行和将工作“强推”给员工的不良影响
讨论并行和串行的整体结果？换笔代表了什么？对质量有什么影响？优先级如何？
13.3 打点游戏
模拟软件开发项目来展示限制在制品的好处
打点游戏展示出团队开始限制在制品时发生的有趣变化，思考如何改进以加速流动
第一次迭代：鼓励大家生成的越多越好，一次生产5个，贴对应颜色原点贴到/画到便利贴，然后传递下去，不要关心下游是否能够接纳承受，客户可以根据标准驳回，可以回答团队问题，但不要透漏标准
第二次迭代：每次只生产1个
第三次迭代：项目离场，团队自组织考虑改进流程，提高产能、减少浪费；谁对质量负责，如何做改进
收获：
批次减少可缩短前置时间，提高质量
通过迭代回顾并调整工作方式，可以改进结果，最后一次迭代问团队，如果在试一个迭代，是否能做得更好
团队需要多问客户问题，加深协作以了解客户愿望，完美的规格说明是不存在的
当系统过载后，向系统中压入更多的工作没有任何好处，第一次迭代就说明了这个问题
13.4 瓶颈游戏
展示了约束理论的5个核心步骤
约束理论把流程看做一个系统，认为任何系统都至少有一个拖慢生产的瓶颈（或约束）
5个核心步骤帮团队定位、评估和管理瓶颈，从而优化流程
瓶颈游戏目标：让每个团队制造尽量多的纸帽子和纸船组合，同时尽量避免浪费纸张，设定的过程将暴露出一些瓶颈，练习和演示帮助参与者使用约束理论的5个步骤来消除瓶颈
五个核心步骤：
建立在系统至少存在一个瓶颈的建设基础上，如果瓶颈不存在，系统内的流程就不受任何阻碍，系统吞吐能力是持续而不受限制的
跟踪管理瓶颈的5个步骤：
找出系统中减缓流速的约束因素
充分挖掘瓶颈的产能
让其他活动服从对瓶颈产能的挖掘
消除瓶颈的约束
重复上面的过程
13.5 getKanban
getkanban是一个完备的看板模拟游戏，完整的介绍了看板以及相关原则
可以从www.getkanban.com购买
主要收获：
通过实践体会看板方法
充分体现限制在制品的概念，以及拉动原则（以拉动方式在需要时才启动工作，而不是同时进行许多任务）
了解看板系统的运作方式以及如何设计看板
了解如何设计度量指标，以及如何使用累积流图、控制图等图表
了解如何使用游戏过程中获得的数据和信息来优化业务产出
13.6 看板比萨游戏
看板模拟游戏，可以从Agile42 http://mng.bz/kYN7 上免费获取
一个理想的团队建设游戏，让团队在时间过程中体会看板的作用
主要收获：
在游戏中体验看板系统和原则
理解并体验限制在制品的效果
审视流程，并以自组织的方式改进流程
创建看板系统来描述你自己的工作流程
这个游戏很容易让参与者觉得拉动系统是个很好的实践，但参与者也会体会到实现拉动系统并不容易
13.7 小结
通过一些模拟游戏来帮助你向不了解看板的人介绍看板的基本概念
是学习看板和看板原则的有效手段
尽管游戏过程非常重要，但更有价值的是游戏后的讨论，为团队准备好大量的问题，供他们反思并讨论
以及有些什么是可以带回到他们的实际工作中去
附录A 推荐阅读及其他资源
精益和看板
Kanban：Successfull Evolution Change for Technology Business
This Is Lean：Resolving the Efficiency Paradox
The Toyota Way to Continuous Improvement
Toyota Kata：Managing People for Improvement，Adaptiveness，and Superior Results
The Principle of Product Development Flow：Second Generation Lean Product Development
Lean from the Trenches：Managing Large-Scale Projects with Kanban
敏捷相关
Scrum and XP from the Trenches
Extreme Programming Explained：Embrace Change
The Agile Samurai：How Agile Masters Deliver Great Software
The Art of Agile Development
软件开发相关
Specification by Example：How Successful Teams Deliver the Right Software
Test-Driven Development：By Example
Growing Object-Oriented Systems Guided by Tests
Clean Code：A Handbook of Agile Software Craftmanship
The Clean Coder：A Code of Conduct for Professional Programmers
商业和变革管理
The Goal：A Process of Ongoing Improvement
Swith：How to Change Things When Change Is Hard
Made to Stick：Why Some Ideas Survive and Others Die
Fearless Change：Patterns for Introducing New Ideas
The Lean Startup：How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successfull Businesses
其他
http://mng.bz/61Zn
附录B 看板工具
LeanKit Kanban、AgileZen、Trello、KanbanFlow、Kanbanize、Kanbanery
Jira Agile、Kanban in Team Foundation Service、HuBoard
