专业的Scrum看板(PSK)——不要仅仅限制在制品——要优化它!(张贴1 / 3)

是什么?Scrum团队看板指南S(在//www.ertascelikyapi.com/resources/kanban-guide-scrum-teams)说一下工作进度限制?

看板(n):一种策略，通过使用可视化的、在制品的有限拉动式系统，优化涉众价值流。

…优化流程需要定义流程在Scrum环境中的含义。每个Scrum团队必须创建包含以下元素的“工作流”定义:

……工作流必须包含如何限制在制品(WIP)的定义。

……在制品(WIP)指的是Scrum团队已经开始但尚未完成的工作项。使用看板的Scrum团队必须明确地控制这些正在进行的工作项，从他们认为它们“开始”到他们认为它们“完成”。这种控制通常用看板上的一个或多个数字来表示。这些数字被称为“在制品限度”。WIP限制可以包括单个列、多个分组列或整个板中的工作项。一旦Scrum团队建立了WIP限制，它就不会将超过该数量的工作项拉入工作流的给定部分。Scrum团队控制限制是什么，以及如何应用这些限制。限制在制品的主要副作用是它创造了一个“拉动式系统”。它被称为拉式系统，因为Scrum团队只有在有明确的信号时才会开始做一个项目(即拉式)(注意，这与“推式”系统不同，后者要求无论何时都要开始做一个项目)。 When the WIP drops below a defined limit, that is the signal to start new work.

Sprint本身就是一种限制在制品的形式。根据定义，Sprint是一种控制开发团队在指定期间要尝试多少工作的方法。只有当开发团队选择这样做时，工作才会被拉入Sprint Backlog(通常，但并不总是，在Sprint计划期间)。无论有意还是无意，Scrum从一开始就接受了这种基本的流程实践。看板更细粒度和明确的在制品限制不仅有助于工作流程，而且可以进一步提高Scrum团队的关注点、承诺和协作。”

你的看板Scrum可能没有那么先进。也许，您只是可视化您的工作，而您的团队并不关心在制品的限制。只要可视化是新鲜的，它就是有用的，因为人们可以从设计良好的董事会接收到有关价值传递流在哪里受到阻碍的信号。

使用看板的Scrum团队需要跟踪的流程的四个基本指标如下:

•进行中的工作(Work in Progress, WIP):启动但未完成的工作项的数量(根据Scrum团队对“工作流”的定义)Scrum团队的看板指南）.

•周期时间:工作项“开始”和工作项“完成”之间所经过的时间。

•工作项年龄:从工作项“开始”到当前时间之间经过的时间。

•吞吐量:每单位时间内“完成”的工作项的数量。注意，吞吐量的度量是工作项的精确计数。

计算周期时间和工作项目年龄要求Scrum团队(至少)跟踪每个项目的开始日期和完成日期。这篇文章中的所有图表都是通过收集开始和结束日期而实现的。

这些指标应该在整个Sprint中进行监控——特别是在Scrum事件中(参见下面基于流程的事件部分)。与往常一样，Scrum团队可能想要检查其他流度量，但这些是最低要求。

虽然Sprint本身限制了在制品的数量，但是在制品的数量限制的增加推动了Scrum团队性能的显著提高。一个警告是，如果不让正在进行的工作老化，就会获得更好的结果。另一个警告是，通过监测统计性能和“感觉”，将在制品限制设置得过低是值得注意的;然而，对于知识工作来说，在制品限制过低很少是一个问题。为什么限制在制品可以缩短周期时间?因为当“等待时间”和“任务切换”时间被挤出后，循环时间减少了，所以驾驶在循环时间和估计工作量之间有更好的相关性。我们开始意识到也许不需要评估，因为完成项目意味着更多(让我们在另一篇文章中讨论)。

利特尔定律，当用离开而不是到达来表述时，需要一些假设(参见Daniel Vacanti的视频https://vimeo.com/52683659)。

在这个视频中(我强烈推荐他在https://vimeo.com/239539858上的泰坦尼克号视频)，丹尼尔提到了利特尔定律的缺陷，即假设利特尔定律在使其起作用的潜在假设不被满足时有效。在我看来，首要的假设是不允许正在进行的工作老化。也就是说，一旦开始，你应该尽快完成这个项目，而不是比其他正在进行的项目更老化。

团队通过在工作流程中制定明确的政策(包括观察/防止正在进行的工作老化)来消除Little’s flaws。这些“利特尔的缺陷杀手政策”使得利特尔定律得以完全生效。我们的团队变得更加可预测，即使是非常复杂的工作，依赖关系，以及(震惊:))以延迟成本排序功能(在这种情况下，功能是产品待办事项包)。避免老化的诀窍是，不管产品待办事项项(pbi)是如何排序的，一旦它们被选中(客户承诺)，我们应该尽快完成它们。

我使用了Mike Burrows的Featureban (https://www.agendashift.com/featureban)和Andy Carmichael的附加设计，并进行了一些调整。“每日”，团队成员抛硬币。正面还是反面，正面是美好的一天，反面就不那么美好了，人们学会了从反面的一个规则中获益，人们可以把一个项目从选择中移到构建中。在某一天，PBI可能会进入正面或反面的选择和构建阶段，然后在两个正面的情况下，从构建和测试阶段进入完成阶段。在这种情况下，我们知道如果没有等待，每个PBI需要两到三天。我们似乎以2天的周期时间接近尾声，这似乎是毫无意义的继续，因为从那一点来看，只要我们不改变政策，我们就会保持一致。

在美国和整个欧盟有大约90个先进的Featureban模拟，证据是明确的(在这一系列实验的限制下)。对于9个开发人员来说，限制6个正在进行的项目可以带来更多的协作。我注意到开发团队成员数量的2/3到3/4的WiP限制是“最佳点”。当通过有意识地先选择最老的正在进行的项目而不允许正在进行的工作老化时(或者甚至例如“如果任何项目超过4天，让我们移动它”)，循环时间的急剧减少是因果关系，而不仅仅是相关关系。当在制品数量限制产生更多的牵拉时，团队首先关注看板板最右边的部分，这样牵拉信号就会从右到左，在团队准备好之前，没有工作被推到第一个在制品栏(构建)。

我曾经有一个团队在这一点上删除了在制品限制，并且周期时间立即以与之前相同的趋势增加。我只有几个团队有“虚假的在制品限制”，这些限制非常高，以至于无法创造完成工作的紧张感，而且这些团队的趋势与推送系统相同，周期时间越来越长。

有些团队明白，一个真正节俭的产品负责人可以避免团队需要有纪律来限制他们自己的在制品。你可以看到，即使在辛辛那提这种情况下，在节约承诺不足的情况下，循环时间仍然越来越长。我只看到过一个案例(在英国的利兹)，产品负责人对工作太吝啬了，以至于开发团队没有看到在制品量限制的必要性(而且这种纪律的必要性似乎已经被产品负责人照顾到了，只有当她确信团队当天会把工作投入构建时，她才会把工作交给开发团队)。然而，这有几个问题:

• 开发团队不是自我管理的，因为它没有与产品负责人协商选择工作，以支持产品负责人和开发团队之间协商的Sprint目标。也就是说，产品负责人的行为更像是项目经理2.0，而Scrum中没有项目经理这个角色。
• 在某种程度上，它更像是及时补充，开发团队可能会为产品负责人提出更好的pbi建议顺序，特别是在多团队Scrum场景中。参考Barry Overeem的文章神话5——在Scrum中，产品待办事项列表是有优先级的(http://www.barryovereem.com/myth-5-in-scrum-the-product-backlog-is-prioritized/)。开发团队决定如何在存在依赖性的地方完成工作的能力，或者首先需要获得更多的知识/技能的能力，在某种程度上受到了阻碍。

在这篇文章的第二篇在第一部分系列中，我们将介绍PSK的复杂工作和复杂工作。在3 / 3，我们将讨论基于流的回顾的丰田改进和教练卡塔。

同时，请查看西门子健康服务公司Daniel Vacanti的看板案例研究(https://www.infoq.com/articles/kanban-siemens-health-services)，其中验证了复杂工作的端到端客户周期时间的缩短。

如果你不通过在制品限制来优化工作流程，你将错过一个技巧。不要被没有在制品限制的暂时增加的吞吐量所愚弄。在制品是周期时间的主要指标。周期时间可以作为吞吐量的主要指标，但也可以在周期时间和吞吐量之间进行权衡。例如，当你故意产生“流动债务”(从其他项目中借用工作时间来优先处理正在进行的项目，从而导致相对老化并破坏利特尔定律的假设-参见丹尼尔·瓦坎蒂的小缺陷视频https://vimeo.com/52683659)。

Andy Carmichael给我的另一个权衡例子是，当系统负荷过重时，减少在制品会增加吞吐量(通过减少开销任务和故障需求)并减少周期时间。当一个系统未被充分利用时，减少在制品会*减少*吞吐量，但对周期时间没有影响。在两者之间，可以选择通过减少在制品来保持较低的周期时间，或者允许更高的在制品，这样流程就不会缺少工作。理论上，这应该会提高吞吐量。

一定要把你的工作形象化，但要加倍努力优化价值流。它带来了一个更平静、更可持续的工作环境，如果它不能提高质量，我会感到惊讶。不要低估使用看板的专业Scrum，它会为你的专业Scrum增加马力。

我是《看板指南》的合著者https://kanbanguides.org。如果您有兴趣了解更多关于看板的知识，请访问KanbanGuides.org。