在Scrum中用看板限制在制品(WIP)——什么/什么时候/谁/怎样

共同创建和教授新的Scrum.org带有看板的专业Scrum这门课让我有机会重新研究在制品限制、流量指标和所有看板的东西。这很有趣!

看板的一个关键实践是限制正在进行的工作。如果你想要变得迂腐，实际上这个实践的目的是减少和稳定正在进行的工作。这改善了流程，提供了可预测性，对于创建基于拉式看板的系统来说，实际上比使用看板板可视化您的工作流更重要。我曾与几个限制在制品数量但不使用看板的客户合作过。有人可能会说，也许这个实践应该排在看板实践的第一位，而不是可视化。

无论如何，当Scrum团队实现看板时，他们应该明确地弄清楚如何限制和减少他们的“正在进行的工作”。这是他们定义“工作流”的关键部分。现在，一个问题出现了:

谁应该定义在制品限制?

让我们假设团队正在使用看板，通过在Sprint Backlog中可视化和管理流程来改进Sprint流程。Sprint Backlog由开发人员拥有，因此他们拥有自己的工作流，特别是在这种情况下的在制品限制是有意义的。

如果团队从更全面的角度使用看板，从产品待办事项列表开始，包括改进工作，会怎样?在这种情况下，Scrum团队将拥有工作流，因此需要讨论在制品的限制。

现在，如果开发人员真的想让产品负责人参与到他们的Sprint流程中——例如，在Sprint过程中，在测试之前审查和接受一个故事。谁决定是否这样做?在这种情况下谁拥有Sprint Backlog ?我认为是Scrum团队。这通常是团队应该依靠的地方——尽管Scrum团队有具体的职责，但最重要的是，Scrum团队要对有效工作以交付价值负责。

好了，我们理解了谁定义了工作流以及在制品的限制。

是否应该改变在制品限制以处理sprint中期高优先级的工作?

现在让我们假设一个团队处于Sprint中期，产品负责人想要向Sprint Backlog中添加一个重要的有价值的项目。它与Sprint目标是一致的。该团队目前处于其WIP限制。他们可以增加这个项目吗?他们应该吗?在制品限制需要发生什么变化?

我对此的看法是，首先需要做出一个决定，是否将这个项目拉入Sprint Backlog。这个讨论与看板完全没有关系。这是一个核心的Scrum问题，答案是由团队决定是否将一个新项目添加到Sprint Backlog中。冲刺目标可以用来评估该项目与当前重点的一致程度。

如果项目被拉入Sprint Backlog，那么开发人员需要弄清楚他们是否可以立即启动它。这取决于在制品的限制和当前的在制品。如果团队达到了他们在制品的极限，他们就不应该引入新物品，直到有空间释放出来。如果他们的backlog项目非常小，空的WIP插槽将很快释放出来。如果物品比较大，可能需要一段时间。

准备一个正常的拉槽所需的时间越长，实际上加速这张卡的压力就越大。什么是加速?超出当前的在制品限制，并将此项目推至现有流程之上。做到这一点的典型方法是不改变在制品限制定义，而是在在制品之上并注意到一个在制品异常。这些例外可以成为回顾时检查和调整的主题。

在制品限制何时进行检查和调整?
一般来说，我不建议仅仅因为Sprint期间似乎有需要而心血来潮地更改在制品限制。我宁愿参见异常和讨论而不是用政策变化来掩盖问题。

大多数时候，Scrum团队应该在Sprint回顾期间调整在制品的限制，以尝试创建一个更好的流程策略，而不是在战术层面进行管理。这类似于Done的定义。我们不会仅仅因为在创建“完成增量”时遇到了问题，就更改“完成”的定义。我们注意到这个例外，甚至可能无法创建一个真正完成的增量，我们在回顾中讨论定义。

话虽如此，在整个Sprint过程中，没有什么能阻止他们调整在制品限制。
换句话说，CAN和SHOULD是有区别的

Scrum团队应该如何限制他们的在制品?

关于限制在制品，最后要注意的一点是，虽然我们通常将在制品限制为工作流中的每通道约束，但这实际上只是一种具体的方式。您可以限制每个人的工作进度，整个团队的工作流程，或者实际上，您可以通过时间限制在制品。如。“我们本周做的项目不会超过10个”。嘿，听起来很熟悉!# SprintForecast。

有兴趣了解更多关于在Scrum环境中限制工作进行中的内容吗?请查看带有看板类的专业Scrum以及看板指南而且应用专业看板类在ProKanban.org．