如何理解并应用精益敏捷Kanban看板

我引入看板系统的目标是：防止过载、控制工作流的波动性，以及触发渐进式变革。

–大卫.安德森

看板的基础知识

看板是一种用于管理产品创造的方法，该方法强调持续交付，同时又不增加开发团队的负担。 像Scrum一样，看板是旨在帮助团队更有效地协作的流程。它是一种可视化工作流程的方法。为了在需求与可用产能和瓶颈之间取得平衡，该框架在下面的工作中具有很高的生产率和效率。

• 临时请求(按需的任务)
• 计划外工作
• 生产支持

简要历史

在1940年代后期，丰田公司从超级市场那里找到了更好的工程流程。 他们注意到商店的店员通过商店的库存而不是供应商的库存来补充货品。

只有当一个货品接近售罄时，店员才能进行订购。 超市的“实时”交付流程激发了丰田工程师重新考虑他们的方法，并开创了一种新方法-看板系统-该方法可以使库存与需求匹配，并实现更高的质量和产量水平。

看板，拼写为Kanban，是日语中的“信号板”，表示“可用产能（工作）”。 看板是与精益生产和实时生产（JIT）有关的概念，它被用作排产系统，告诉你要生产什么，何时生产以及要生产多少。看板成为支持整个生产系统运行的有效工具，也是促进改进的很好的方法。

原则

在看板方法上实施软件增量是一个基于拉动的系统，它可以帮助团队以可持续的速度和产能进行交付，减少了工作和时间的浪费。 保证这一点，就需要遵循以下看板的基本原则。

1. 可视化工作

看板工作面板的可视化模型及其工作流程使范围和功能透明化，有助于观察和检查从待办事项到完成的工作流程。 这样会让工作可见，也包括阻塞，瓶颈和队列以及即将进行的工作，这有助于团队制定策略，是继续进行现有的工作或将新工作带入。

2. 限制在制品WIP

团队为看板面板中的所有“进行中”的列共同定义了一个限制，例如分析，开发，测试等。此WIP限制实现了基于拉动的系统，因为只有在该列下的工作总数少于其上限的情况下才可以将工作从上一列拉至当前列。

这有助于平衡基于流的方法，团队不会开始并承担过多的工作。 它减少了浪费，并帮助团队专注于先完成后开始。

3. 聚焦在工作流

要完成一项工作并增加价值，它必须经历其开发过程的多个阶段。 如分析，开发，测试，评审等。为了获得看板的价值，团队需要专注于从启动到完成的工作流程。 通过遵循上面2条原则，可以帮助你专注于流程。

专注于工作流会使团队可视化即将到来的的瓶颈并对其采取行动。 以便保持流动。 团队经常制定工作的策略以优化流程。

把看板和现实生活相关联

我们已经学习了看板的基础知识及其原理，让我们尝试将看板流程与现实生活联系起来。 假设你已经知道并正在实践Scrum，我们将在其中执行定义的时间框的迭代。 我们提交一堆故事，对其进行处理2到3周，然后完成迭代，并再次计划新的一堆故事以进行下一次迭代。 在看板中，我们不会为迭代，时间框或冲刺提交故事。 我们做的有些不同。

在下面的示例中，我们将Scum和看板与现实生活联系起来。 假设人们是故事，放映厅是一次迭代，放映时间是迭代时间。

关联Scrum流程和现实生活

这个案例说明了放映厅中的人员流动，一次是一群人。 如果我们假设人是用户故事，并且将时间显示为迭代或时间框。 然后，你可能会注意到一群人一起在放映厅里走来走去。 我们有明确的座位容量和放映时间。 为每次放映安排的人在放映开始之前已预先计划好了。

关联看板流程和现实生活

这个案例说明了门卫允许公园中的人流是一个接一个的。 如果我们假设人是用户故事，那么公园就是看板面板。 然后，你可能会注意到没有定义的公园放映时间，因为它是24小时开放的。 进入公园或在公园内漫游并出来的人不在同一个人群中。 我们没有容量和演出时间。 但是，公园的管理层决定一次不允许在公园内同时容纳6人以上，以提高公园内人们的舒适度。

在此图中，让我们尝试用Scrum术语关联场景。 如果我们假设人是用户故事，那么在大厅外面等待下次放映的人就是Backlog中的用户故事列表。当前的放映厅放映就是当前Sprint或迭代。观众是冲刺的故事。 显示时间是冲刺持续时间。 放映厅容纳人数是团队对冲刺的产能。 已经看过电影的人是以前冲刺中的“完成”故事，可能已经确定已发布或已部署。

在这里，让我们尝试用上面的图片来映射看板术语。 假设人员是用户故事或任务，公园是可视看板面板。 排队等候在外面的人是当前的看板Backlog。 放映时间没有定义，“最大容量”没有限制，但是管理层决定不允许面板中的故事超过6个。 已经从公园出来的人就是已经可以部署的用户故事。 管理层正在统计出来的故事，以便允许进入新的故事。看板面板(公园)内的故事(人)没有确定的开始或结束日期。

上面图片中进行解释，以解释Scrum流程。

上面图片中进行说明，以解释看板流程。

看板面板

现在，了解了看板及规则和原则。 让我们开始讨论如何真正实现流程可视化原则，实现WIP限制等。要使工作对所有人可见且透明，我们需要有一个工作面板，可以是物理的（对于在同一地点的团队来说更好）。 如今大多数团队位于分散位置的日子，我们可以有一个数字面板。 你可以使用在线工具来配置这样的板。

一个典型的看板面板有三个主要部分

1. Todo (待办事项)
2. In Progress (进行中的工作)
3. Done (完成的用户故事)

实现多个在制品WIP列

如何进行工作分配，我们通常会将进行中的工作分配到多个列中，例如，我们可以进行分析，开发，测试等。在右图中，我们将进行中的工作分为两个部分：开发和测试。你可以根据需要进行分配，团队则可以进行更好的控制。 分布到多个列会有助于实现针对不同技能组的在制品限制。

实现在制品WIP限制

限制在建案例的数量是看板的核心原则之一。通过实施WIP限制，会强制团队专注于从左到右的故事流动。

在此示例中，我们将“开发”中的最大故事数限制为4个，“测试”的最大故事数为3个。这意味着团队可以在“开发”列中最多处理4个故事，在“测试”列中最多处理3个故事。这种局限性会帮助团队首先集中精力完成故事，然后考虑的引入新故事。

从图中，我们可以看到已经有4个故事的开发（限制为4个）和3个故事的测试（限制为3个）。因此，在这种情况下，即使开发人员完成了1个或多个故事的开发，也无法选择待办事项中的新的故事，因为在“开发”中暂时没有新的故事或任务的空间。

为了在“开发”列中腾出空间，测试人员需要从“开发”提取故事或任务进行测试。只有完成对某些现有故事/任务的测试并将其移至完成状态时，测试人员才能执行前面的操作。

在这种情况下，开发人员将无法进入理想状态。意愿驱使他们会贡献力量给测试人员，加快测试速度，以便团队可以从“开发”中获取故事，而开发人员可以从待办事项中引入新故事。

团队成员可以在开始时根据团队规模和可用技能组共同决定WIP限制。此限制会在一段时间后进行修改。

分解在制品WIP列

将每列的在制品限额分为两个部分总是一个好习惯

1. 进行中doing
2. 完成done

这种分解将使在制品的状态更加明显和突出。能帮助团队制定策略。左边一列的“完成”部分就是右边列的待办事项。

例如，处于开发完成状态的故事是测试的待办事项。

理解基于拉动的系统

如前所述，看板是基于拉的系统。 实施WIP限制，激活基于拉动的系统。 这意味着团队根据其当前任务和限制将新任务拖到其WIP列中。

即使当前列中有空间，团队可以决定去拉进来新故事/任务或完成该列中的现有故事/任务。

下面的三幅图演示了三种情况，开发人员或测试人员有机会提出新的故事或任务。

不受控的在制品WIP

到目前为止，我们已经讨论了在制品WIP，例如分析，开发，测试等。列下工作的执行始终由看板团队控制。

有时团队希望将一列用于其他目的，然后再移至“完成”，例如UAT。“UAT”列下的工作可能不受团队控制，因为任务或故事必须由最终客户或用户执行。

如果我们对此“UAT”列实施WIP限制，它将成为团队的瓶颈，因为从“UAT”到下一列的故事可能会花费时间，具体取决于客户的其他工作重点和可用时间。为了克服这种瓶颈情况，我们将UAT之类的列数限制设置为无限。 使故事/任务可以自由流动到此列。

退出标准

如果你之前从事过Scrum的工作，则必须熟悉DoD(完成的定义)。这是一个清单，我们在将故事标记为“完成”之前，用于对其进行评审。

对于看板，我们使用类似的概念，我们称之为退出标准。我们为每个进行中的工作准备好所有状态的退出标准。

由于每个在制品WIP列都有“进行中”和“完成”两个部分。我们为每个故事从“进行中”到“完成”提供了通道。因此，我们将有一个完成“分析”的标准，一个完成“开发”的标准，一个完成“测试”的标准。

开发“完成”的示例可能是

1. 必须检查所有代码，并且应该将注释评论上传到某个存储库中

2. 必须提交所有代码并与测试分支合并

3. 最新代码应已部署到测试环境。

4. n个人应已通过电子邮件通知。

5. 单元测试结果应已更新到某处。

6. 其他

团队成员共同决定优化工作方式，并在一定时间后进行修改。

加速通道

在我们的日常工作和优先级工作中，我们通常负责解决不同严重程度的生产支持问题。从管理层过来许多高优先的活动，要求立即采取措施解决。

为了忽略在制品WIP限制来处理那些高优先级的工作，我们为所有这类工作保留了一个泳道。我们将其称为加速通道或优先通道。并在每列顶部为该通道保留一些任务空间。

在此示例中，我们的加速通道可以在每列的WIP限制的顶部添加另外2个故事/任务。因此，即使开发限制为4，并且开发人员已经在处理4个故事，如果任何故事可以归类为“高优先级”，他们仍然可以选择另外两个故事。

取决于这些高优先级故障单，问题，任务，故事的频率，团队成员可以定义快速通道的附加限制。并且该限制会在将来再次修改。

团队可以事先准备一份定义，关于将工作项视为高优先工作的条件。根据定义，将相应工作归为高优先项目。

制定策略（服务等级）

到目前为止，你已经了解了如何使用看板来保持故事和工作项的可持续和优化的流程。团队始终坚守首先完成并随后开始的策略，这意味着除任何快速工作外，团队专注于已经开始的工作，然后计划开始新的工作。

要开始一项新工作，请查看待办事项列表，上面有许多可用的工作项。 因此，你需要在工作期间每天制定策略，开始哪个项目，以及需要集中精力更快地完成哪些项目，并及时确保WIP限制。为了简化策略，我们将工作项分为4个不同领域或服务等级，如下所示。

服务等级

普通	加急	时间限制	无形的
常规的故事或工作项目	高优先级工作项，例如，严重性为一个生产问题。这在“优先”或“加速”车道上进行。	具有固定完成日期的故事。有时，惩罚条款与此类故事关联。如果业务在某个特定日期或之前需要某些东西。团队可以择机引入相应的工作项。	这些是工作项，它们不会立即为业务增加价值，但会带来长期利益。大多数维护工作都属于此类。例如，从服务器A到服务器B的数据库迁移，重新索引数据库。获取生产数据备份以测试环境。

通过对以上四个领域的工作进行分类，你就能够优化流程并根据最适合你的业务需求，将工作项拉入正在进行的工作中。

如果你的在线工具支持创建单独的泳道，就可以相应地创建它，即使它不支持，或者你使用的是物理看板，也可以对不同类别的故事或任务进行颜色分类。

看板的收益

如果你使用看板来管理适合这个方法的工作内容，那么它是有用且有益的。 如生产支持，临时请求，计划外工作，项目组合或项目集级别的工作等。以下提到的几个重要优势。

规划灵活

看板团队只专注于当前正在进行的工作。 一旦团队完成了一个工作项目，就将下一个工作项目从待办事项的顶部移入WIP。 负责人/利益相关者可以随意在待办事项中重新安排工作的优先级，而不会干扰团队。当前工作项之外的任何变更都不会影响团队。 只要将最重要的工作项目放在待办事项列表顶部，开发团队就可以确保他们正在为企业带来最大的价值。

缩短周期时间

周期时间是看板团队的关键指标之一。 周期时间是故事/工作单元在团队工作流程中移动的时间，即从工作开始到完成的整个过程。 通过优化周期时间，团队可以自信地预测未来的工作交付。

减少障碍

多任务处理会降低效率，这就是为什么看板的一个主要原则是限制在制品(WIP)数量。 WIP限制有助于可视化瓶颈。 然后，团队团结一致地解决障碍，以实现流程畅通。

持续交付

持续交付是一种经常向客户（甚至每天或每小时）产出工作结果的实践。看板和持续交付相辅相成，因为这两种技术都专注于及时交付价值。

可见的指标

看板系统以其可视化的工作流程而闻名，因此，诸如“周期时间”，“吞吐量”等指标可以使当前流程，性能和改进机会得以更透明并对其采取行动。 我们将在本文下面讨论不同的指标。

Scrum与Kanban

假设你已经熟悉Scrum，以下是Scum和看板之间的一些区别

	SCRUM	看板
节奏/交付	Sprint中的“常规时间”框	连续流
释放频率	在每个时间框的末尾或之后	根据实际的需要，或每个工作项完成后
角色	Scrum Master，产品负责人，开发团队	除开发团队外，没有定义角色，某些团队向敏捷教练咨询
关键指标	速度	循环时间，吞吐量，累积流量
范围	范围在Sprint计划里规划，按批次包含多项工作	工作想被逐一拉入系统
变更机制	范围在Sprint计划里规划，Sprint中期不允许变更	可以随时进行变更
适用性	更合适在工作可以按批次进行优先级排序的情况下	更适合优先级高度可变的操作环境

看板的指标

周期时间

当故事或工作项以看板流程移动时，从第一阶段到最后阶段，它都会经历多个阶段。 它停留在一段更长或更短的时间里。

计算故事的周期时间是根据从它进入第一个受控的WIP列到离开最后一个WIP列之间的时间间隔（UAT被视为失控WIP）。 根据在此项目上团队的实际投入时间来计算，而不是根据工作项放在面板上的时间来计算。

在下图示例中，故事或工作项在“开发和测试”中投入的总时间就是故事的周期时间。对于仍在进行中或尚未开始的故事，我们不会计算周期时间。通常，我们会取所有符合条件的故事的周期时间的平均值，以计算团队在给定期间的周期时间。

前置时间

这类似于周期时间，但是唯一的区别是，它计算的是从创建工作项/故事或由客户请求，到将其交付给客户为止之间的时间。 也称为客户交货时间。

示例中，可以计算出故事进入面板并离开UAT列之间的时间（完成意味着交付给客户）。通常，我们会取所有符合条件的故事的前置时间的平均值，以计算团队在给定期间的前置时间。

响应时间

故事/工作项在待办事项列表上等待的时间再次被计算。计算是根据它被创建的时刻与将其移至“进行中”的时刻（获得了第一次响应）之间的时间长度。

吞吐量

吞吐量不是已知的度量指标。 此指标是在给定的时间范围（周，月等）内完成的故事数。已完成是指已完成或交付给客户的故事/工作项目。 它是真实数据，而不是假设或预测。

吞吐量是团队在给定时间段内能够交付的故事或工作项目的数量。 每周，每月，前提是他们保持可以承受的工作量。

它不是速度（速度是根据每个冲刺的Story Point计算的，通常是在Scrum或XP框架上测量的）吞吐量是根据数量计算的。 看板系统不会将其用于估算或计划。 虽然，它对于衡量团队绩效和看板利用率从而进行改进很有用。

切记：吞吐量越高，交付时间越短

累积流量图

累积流程图是可视化看板流程健康状况的重要指标之一。它提供了周期时间，前置时间和响应时间的视图，还体现了WIP限制的好处。

累积流程图是一个多层面积图，不同颜色代表看板中各个阶段。X轴表示时间（最近一周，一个月等的图）。 Y轴表示每个阶段的故事数量。

看板的CFD（累积流程图）在项目开始时显示了一个或两个阶段（面板中最左边的阶段），几天后，它显示了相对右侧阶段的故事计数。这很自然，因为先从分析开始，然后是开发，然后是评审，然后是测试。

CFD图始终从左到右上升。因为它总是将当前日期在任何阶段的工作项计数与该阶段的前一天计数相加。所以叫“累积”。你会注意到，没有WIP限制的阶段的颜色会不断增加其宽度，而具有WIP限制的阶段的颜色在宽度上是相对一致的。

从下面提到的图片中，你可以看到，如何计算周期，前置时间和在制品WIP数量。

—

END

感谢你阅读本文，希望能在评论区学习到大家的经验和想法~

如果对相关内容感兴趣可以关注我的公众号：捷伴行Agile。会有更多更及时的内容与君分享。

• agile methodology
• agile project managememt
• agile software development
• Kanban
• lean startup
• Scrum
• 敏捷方法
• 敏捷框架
• 敏捷软件开发
• 敏捷项目管理
• 看板
• 精益
• 累积流图