7000字讲解：什么是Scrumban（敏捷看板）

文章来源：Agile Alliance

原文作者：Corey Ladas

译者：Judy-朱迪

越来越多的人开始对精益思想及其在知识工作和项目管理中的应用感兴趣，这有助于人们找到一种更容易上手的方法，或者学习一些基本概念，从而获得更深入的见解。对于那些对工作环境中的看板感到好奇的人来说，他们经常有人正在使用Scrum，或者对作为敏捷思维的代表的Scrum方法有一些了解。不管怎样，Scrum的应用者是看板用户的重要组成部分。因为Scrum可以用描述看板系统的语言来描述，所以描述Scrum+看板的混合应用也相当容易。这对于希望提高Scrum团队的规模化或能力来说非常有用。对于那些对敏捷更保守的新人来说，看板也很有用，因为他们对约定俗成的方法感到舒适。(尽管事实上，看板的理念至少有40年之久。)

使用带有索引卡或便利贴的简单任务板的想法和敏捷本身一样历史悠久。这样一个任务板中，其中有一个简单的To Do→In Process→Complete（待办→正在进行→完成）工作流。板上的卡片表示当前工作范围内的工作项。名字可以与卡片联系起来，表明谁在做什么。敏捷团队已经使用这种方法很长一段时间了，一些人很早以前就指出，这与精益系统中的看板理念有一些相似之处。

任务板--显示工作流程和任务分配

当然，有各种各样的电子工具可以完成这些功能，但是这个简单的任务板代表了一些我认为非常有价值的精益原则:简单的技术和可视化管理。这种简单的工作流管理方法的优点是易于管理，更重要的是易于更改。蜷缩在电脑显示器前，即使是非常大的显示器，也无法取代操作大型任务板所带来的触觉刺激和社交互动，也许有一天在电脑前也会有这样好的互动效果，但不是现在。电子工具很适合管理事情列表，比如待办任务和缺陷，以及生成报告。简单的工具可能难以向技术狂热者解释，但价值也是如此。

任务过载

这种基本的索引卡任务板的问题之一是：没有什么可以阻止你积累一大堆正在进行的工作。从本质上讲，时间盒（time-boxing）设置了WIP（在制品）数量的界限，但它仍然可以允许比期望更多的WIP生成。如果看板是一个表示工作请求的令牌，而我们的任务板仍然可能失去控制，那么问题是什么?问题是看板不仅仅是一张卡片上的工作请求，在白板上放置便利贴不足以实现拉动式系统。

看板不仅仅是索引卡

在现代经济中，稀缺商品和服务的生产和分配受到货币和价格体系的调控。货币可以用没有什么内在价值的纸币来代表，但通过协议，它可以用来交换真正的商品和服务。中性交换媒介的存在使得一个经济体中商品供应相对稀缺性的经济计算体系成为可能。这样的价格体系就是市场。市场向其参与者传达经济生产和分配的价值。

如果一种货币或纸币可以用来交换具有实际价值的物品，那么就必须有一种与经济中实际价值的稀缺性相对应的方法来加强纸币的稀缺性。在实践中，必须有某种制度来强化这种稀缺性。市场经济的健康在很大程度上取决于其货币机构协调货币供应与商品和服务供应的能力。在不健康的经济中，不稳定的价格使经济计算变得困难，并破坏了有效生产和分配所需的生产者和消费者之间的沟通。

                 

              

看板代表了某个封闭的内部经济体生产能力的一部分。它是生产资源系统运作所提供商品和服务的交换媒介。看板在流通中的供应是由一些加强其价值的调节功能控制的。也就是说，看板是一种私人货币，车间经理是发行它的银行，目的是进行经济计算。

如果你把货币类比一下，就可能认识到看板和卡片根本不相关。就像钱不在于账单。看板是关于流通的数量的限制。如何在交易中表示它是偶然的。

理解这一切的简单规则是:

没有限制的任务卡不是看板，就像一美元钞票的复印件不是货币一样。

如果您使用像塑料卡作为持久令牌，那么这就很容易管理:控制流通中卡的数量。如果所有可用的卡片都已经在流通中，那么下一个寻求卡片的人就只能等到一张卡片收回。这正是看板系统的目的所在。然而，如果你使用的是一次性的媒介，如索引卡或便利贴，那么你就需要另一种机制来调节“货币供应”。在我们的例子中，我们简单地在任务板上写下流通中的看板数量，并根据这个数量分配新卡片。

这意味着看板服务于两种功能:它是做特定事情的请求，但它也是做一般事情的许可。第二个关于“许可”的概念是那些刚接触精益思想的人容易纠结的地方，但这正是我们“优化整体”或“服从约束”的方式。(约束理论是与精益毗邻的理论，软件开发中的看板运动自由地混合和匹配来自这些理论的思想。)

外 表简单 ， 内在技术不简单

就像软木板（cork board）上没有规则的索引卡不是看板一样，基于时间箱的迭代计划也不是拉式的。除非每个工作订单的周期也是一个月，否则对精益的合理解释不会涉及到一个月的预测。一个月的工作量肯定比3个月或18个月的工作量小得多，但是如果你的迭代计划安排包含20个工作项，那么这仍然比它需要的拉式系统多出19个工作项。

尽管如此，通过一些简单的实践来增强Scrum并不是一件困难的事情，这些实践将我们推向一个更容易识别的精益工作流。最明显的是减少了迭代长度，尽管这并不是没有问题。正如我们将看到的，可以用越来越多的拉式工作方式来增量地增强Scrum，直到原始过程的工作方式变成残余的脚手架。简单的方法是从类似scrum的迭代和迭代计划过程开始，并开始向团队的内部过程中添加拉式的工作实践。

一个简单的技术使我们更接近看板的定义，那就是为个人设定多任务处理的限制。比如设定一个简单的原则：完成工作胜过开始新的工作。或者你可以把它表达成一条规则：一次只做一件事。但如果你被阻碍了，那么你可以做第二件事，但是不能再多做了。在我们的例子中，该规则给了我们一个有效的WIP限制为6。

多任务限制

另一种常见的技术是推迟将任务绑定到所有者。一些团队会在迭代计划期间预先分配所有已知的任务。这通常不是一个好主意，因为它人为地创造了一个关键路径。等到“最后负责的时刻”再给别人分配任务，可以最大限度地获取知识并接近于拉动式工作。(最后负责时刻的理念与Poppendiecks（精益软件开发大师）、基于集合的设计和实物期权理论有关。)

任何人都可以有多个项目在处理中，并不意味着每个人都应该有多个项目在处理中。我们的多任务规则的一个问题是，它在不考虑整体的情况下进行局部优化。隐含的总在制品限制为6仍然比我们可能容忍的3个人的在制品更多。一次处理5个项目中的4个项目的限制仍然允许一些多任务的特例，但不允许每个人携带两个项目的明显特例行为。在这一步中，我们超越了关于个人的规则，并制定了关于任务卡本身的规则。也就是说，我们已经将我们的卡制作成看板。

在制品（WIP）的数量限制

我们可以对上一块板做的另一个增强是在to do列和in progress列之间添加一个就绪队列。就绪队列包含待定的待定项，但具有高优先级。我们仍然没有将个人绑定到这些任务中，但是一旦有人有赋予时间，他们应该接受其中一个任务，而不是从一般的待办事项列表中挑选一些东西。这使我们能够将工作分配过程与工作优先排序过程分离开来，从而简化了分配。就绪队列也有看板限制，它应该是一个小的限制，因为它的唯一目的是指示下一个应该启动的工作项。

现在我们可以开始看到拉式和流动的一些机制:

1. David完成一项任务并将其移到“完成”列

2. David从就绪队列中拉动了一个新的任务并开始工作

3.团队响应拉动卡片（pull event）并选择下一个进入就绪队列的优先项

此时，我们正在操作一个简单的看板拉动式系统。我们仍然有固定的迭代和计划周期，所以也许我们可以把这样的东西称为Scrumban系统!

既然我们有了产能和拉动的概念，就很自然地会想到流。将我们模糊的过程中的状态分解成更好定义的状态，可以让每个人对团队的优势、弱点和整体健康状况有更多的了解。即使是像极限编程这样的敏捷工作流，也有相对定义良好的角色和状态，这些状态之间的顺畅工作流程与整个流程的顺畅工作流程一样重要。

协调劳动分工

这里，我们将进程内状态分为两种状态:定义和执行。定义是定义全部任务必要的标准，以确定工作项何时可以被认为是完成的。执行是关于完成任务必要的工作，将工作项带入满足那些标准的状态。我们已经将之前的5个待办事项限制分散到这两个板块。在这种情况下，定义被认为花费更少的时间，所以它被赋予了2的限制。执行消耗剩下的限制3。随着时间的推移，我们可能会改变这个比例，我们的表现也会改变。

累积的流程图

由于我们现在更多地考虑工作流，额外的工作流细节需要使用累积流图来跟踪工作并度量我们的工作产出，一个简单的燃尽图告诉你是否正在交付工作，但不是为什么交付工作。累积流图传达了有关交付周期和库存的额外信息，这些信息可以诊断问题，甚至可以预防问题。

通过更好地定义我们的工作流，我们还可以考虑一些职能化。在这种情况下，它可能是一种软性的职能化，我们中的一些人更喜欢做一种类型的工作，而不是相反，即使我们有能力做所有的工作。理解这种拉式工作流系统允许职能化，但不强制职能化是很重要的。团队拥有工作和工作流，团队需要找出如何有效地完成工作。

工作流规则

如果我们让最擅长执行“定义”的人处理更多的工作，那么我们可能还需要协调我们自己之间的交接。添加指定完成列会向团队传达这样一个信息：一旦有合适的资源可用，以前在“完成”列中的工作现在就可以从“执行”列中提取工作了。在“定义”列中仍然处于活动状态的工作没有资格发出这样的请求。如果“定义”列中的任务所有者希望将其交给其他人，则可以将其放入完整的缓冲区中，该操作构成一个拉动（pull）请求。如果他不想把它交出来，只要有能力从队列中拉动，他就可以直接将其移动到“执行”列。“执行”列可能已满，唯一符合条件的工作是就绪队列从“定义”列中提取可用产能。

由于我们为交接缓冲区添加了一个新列，所以我们也将WIP限制略微增加了一些。权衡是，由于新库存而增加的周期时间会被职能化带来的优势而所抵消。我们还通过集中在前一个状态设定在制品限额来减轻对新库存的影响。这具有非常有益的结果，使“定义完成”缓冲成为前一个环节的可变节流阀。在“定义完成”缓冲列中堆积的工作越多，处于“定义”列处理的工作就越少。

如果我们要允许工作流职能化和其结果的移交，那么我们还需要对每次移交期望的结果达成某种协议。我们可以通过为每个状态定义一些简单的工作标准或标准程序来做到这一点。这些不需要很复杂或详尽。在这里，它们是直接画在任务板上的简单几条或清单。它们只需要避免生产者和消费者之间的误解就足够了。这些标准是团队自己制定和拥有的，并且他们可以根据改善的实践或者持续改进的需要来改变它们。将它们放在像白板或wiki这样的媒介中会强化团队所有权的概念。

高级 Scrumban

在到目前为止描述的Scrumban的基本版本中，迭代审查和计划周期就像在普通Scrum中一样。但是随着我们的生产过程的成熟，我们也给了自己一些工具，使计划过程更有效，响应更迅速，并更好地使其与它所服务的业务相结合。

随着拉动系统的到位以及过程能力的提高，我们的流程将变得更加顺畅。我们可以使用我们的过程步骤缓冲区和流程图来显示流程的弱点和改进的机会。当我们接近均衡生产时，我们将开始不那么关注任务燃尽，而更关注周期时间，因为周期时间是结果，任务燃尽是原因。平均前置=时间和周期时间值将成为绩效的主要焦点。如果前置时间得到控制，并且团队能力与需求相平衡，那么周期也将得到控制。如果周期时间得到控制，那么任务的燃尽是可预测的和没有意义的。如果任务的燃尽没有意义，那么目标设定和冒险的努力是不必要的。如果损耗是无趣的，那么迭代待办只是为了计划规律性和供给拉动系统的库存。因此，它们应该尽可能是最小的库存，以优化计划成本。

当工作产能变得可用，团队现在可以从一个小的就绪队列中选择。那么从团队的角度来看，迭代计划的价值在于它总是包含接下来值得做的事情。因此，我们应该使用浪费最少的机制来满足这个简单的条件。

待办事项列表限制

符合要求的一种简单机制是对迭代待办事项的大小进行限制。与其费劲地在每次迭代中估算工作范围，不如将待办事项设定为固定的规模，在计划间隔结束前偶尔会运行到零。这是一个简单的计算。这只是每次迭代发布的平均数量，而这又只是平均周期时间的倍数。所以如果你平均有5件事在处理中，平均需要5天才能完成一件事，那么你平均每天就能完成一件事。如果迭代间隔是两个工作周，或者10个工作日，那么迭代计划安排应该是10个工作日。如果您担心用完，可以添加一到两个填充。这可能是Scrum社区所忽略的一点:从来没有必要去估计待办事项列表的具体规模。只需要估计待办事项的平均大小。在Scrum中进行评估的大部分工作都是浪费。

在我们的Scrumban的最后一个版本中，迭代计划仍然是定期进行的，与评审和回顾保持同步，但是计划的目标是填补可用的空位，而不是填补所有的空位，当然也不是确定空位的数量。这大大减少了迭代计划的开销和仪式。在将工作拉动到就绪队列时，用于迭代规划估计的批处理所花费的时间可以替换为质量控制检查。如果一个工作项的不合格，那么它将被退回，并对重复发生进行其根本原因分析。

卸下训练轮

如果你已经在发展中走到了这一步，你可能会意识到Scrum最初的机制已经不再对你有什么帮助了。在你建立一个更优化的解决方案时，Scrum是一个很有用的支架，可以将团队凝聚在一起。在某些时候，你可以蜕去茧，让拉动式系统展开翅膀，飞起来。

超越Scrum的第一步是将计划和发布周期分离开来。可能会有一个合适的节奏来批量处理特性以便发布，也可能会有一个合适的节奏来让人们一起计划。如果我们有一个更精简、更拉动式的规划方法，那么这两个节奏就没有理由相同了。你的运维团队可能想要一个月发布一次，你的产品经理可能想要建立一个每周的排序节奏。没有理由不迁就他们。

一旦你打破了时间盒，对待办事项列表的构建就将变得更精简。敏捷意味着响应需求的能力。待办事项列表应该尽可能经常地反映当前对业务环境的理解，也就是说，待办事项列表应该是由事件驱动的。基于时间盒的待办事项计划就是这样，事件是一个计时器，但一旦我们这样看待它，我们就可以想象其他类型的事件，使我们能够更快地响应的优先级。因为我们的系统已经展示了拉动（pull）和工作流，所以提高的响应能力不会影响我们当前的效率。

我们要尝试解决的问题是:

理想的工作计划过程应该总是为团队开发提供接下来要做的最好的事情，不多也不少。

超出此范围的进一步规划不会增加价值，因此这是浪费。scrum风格的时间箱式计划通常提供了比挑选下一个工作项所必需的更多的待办事项，因此，它是不必要的清单，是不必要的浪费。

对于计划活动的调度，我们可能要考虑的下一个事件是订购点的概念。订购点是触发订购新材料流程的库存水平。当我们接受来自待办事项列表的项目进入流程时，待办事项列表将减少，直到剩余的工作数量下降到订单点以下。发生这种情况时，通知会被发出给到负责的各方，让他们组织下一次计划会议。如果我们当前的待办量是10，我们的吞吐量是1/天，我们将订单点设置为5，那么这个计划将大约每周进行一次。

如果人们很难安排或需要一些准备时间来区分优先级，那么一周做一次可能是合理的。然而，如果它们比这更容易获得，那么我们可以把订购点设得更低。如果计划人员能在一天内做出反应，那么也许我们可以把订货时间定在2。如果订单点是2，那么可能没有必要保持10个待办。也许我们可以把待办的数量减少到4个，并在这个过程中减少6天的交货时间。

这种进化的最终状态是拉动，或按需排序。如果计划者能够足够快地做出一个好的决策，并且在批量的优先级决策中没有规模经济，那么待办的规模只需要为1。当工作指令被开发团队授权时，计划团队就被告知开始选择下一个工作。这种工作授权和信号的循环是拉动的基本机制。如果计划团队的反应足够快，那么开发团队将永远不会停滞。如果响应中有一些变化或延迟，那么可能需要积压到2来防止延迟。但2仍然比10小得多，也更精简。或20，或者50，这是我经常看到的情况。

同样的逻辑也可以应用于发布节奏。对于发布有一个最佳的节奏，我们应该首先尝试找到这个节奏，然后尝试改进它。我们努力的结果最终将是功能按需交付。即使在这个层次上，我们仍然有一个相当基本的看板系统。从这里我们可以添加工作项泳道，或者结构依赖流以满足大规模项目的需求。我们相信，这使得精益展示了将敏捷扩展到企业的途径。