限制工作进展(在制品)Scrum和看板- /什么/谁/

营造和教学新的Scrum.org专业的Scrum和看板课给了我一个机会回到android系统在制品的数量限制,看板流指标和所有的事。这是有趣的!

看板实践的一个关键是限制工作进展。如果你想成为迂腐,实际上这种做法目的是降低和稳定工作的进步。这提高了流程,提供可预测性,其实更重要的是创建一个基于看板系统比使用看板图可视化您的工作流。我曾与几个客户限制在制品的数量,但没有使用看板。也许有人会说,这种做法应该在列表中第一个看板的实践、可视化。

总之,当一个Scrum团队实现看板他们应该找出如何限制和减少他们的工作进展。这是一个关键的一部分“工作流”的定义。现在,一个问题出现了:

谁应该定义在制品的数量限制?

假设团队使用看板来改进短跑流可视化和Sprint Backlog的管理流程。Sprint Backlog是属于开发人员会使他们自己的工作流程和具体WIP限制在这种情况下。

如果团队使用看板从更全面的角度来看,从产品待办事项列表,包括细化工作吗?在这种情况下,它将Scrum团队,将自己的工作流程,因此需要讨论限制在制品的数量。

现在,如果开发商真的想涉及产品所有者在Sprint流——例如在Sprint审查和接受一个故事之前经过测试。谁来决定是否做这个?在这种情况下谁拥有Sprint Backlog吗?我认为这是Scrum团队。这通常是团队应该瘦——虽然有具体的岗位职责Scrum团队,最重要的是Scrum团队负责工作有效地交付价值。

好的,我们了解定义工作流,因此在制品的数量限制。

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

现在假设一个团队Sprint当中,有一个重要的有价值的商品,产品所有者想要添加到Sprint Backlog。这是与Sprint目标。团队目前在制品的数量限制。他们能添加这个项目吗?他们应该吗?WIP限制需要发生什么?

我的观点是,首先需要做出决定是否要把这个项目到Sprint Backlog。这个讨论并不相关的看板。Scrum是一个核心问题,答案是,这取决于团队同意把一个新的项目到Sprint Backlog。Sprint目标可以用来评估这个项目是与当前的焦点对齐。

以防拖入Sprint Backlog条目,那么开发人员需要弄清楚他们是否可以马上开始。这取决于WIP限制和当前在制品的数量。如果团队在他们的在制品数量限制他们不应该引入新项目,直到腾出一些空间。如果他们的待办事项列表中的待办项都很小,一个空WIP槽将很快释放。如果项目是大,它可能需要一段时间。

时间越长可能需要准备一个正常的拉槽,更大的压力可能有真正加快这张卡片。加速是什么?超越当前限制在制品的数量和推动这个项目的现有的流。典型的方法就是不要改变WIP极限定义但要高于在制品的数量,注意在制品数量异常。这些异常可以检验和适应时间来回顾一个话题了。

当WIP限制应该检查和调整?
一般来说,我不建议改变在制品的数量限制突发奇想仅仅因为在Sprint中似乎有一种需要。我宁愿看到一个异常和讨论而不是隐藏在政策变化的问题。

大多数时候,Scrum团队应该调整在制品的数量限制在Sprint回顾的试图创建一个更好的流策略,而不是在战术级别的方法来管理。这是类似于“完成”的定义。我们不改变“完成”的定义在一个sprint只是因为我们有一个问题创建一个增量。我们注意例外,甚至无法创建一个真正做增量,我们讨论了定义在我们回顾。

已经说过,没有什么阻止他们调整整个Sprint在制品的数量限制在任何时候。
换句话说,可以而且应该有区别

Scrum团队应该如何限制在制品的数量吗?

最后一件事需要注意限制在制品的数量是,尽管我们通常讨论限制在制品的数量每道限制您的工作流,这实际上是一个特定的方法。你可以限制每个人的工作进展,每整个团队在他们的工作流程,或者,你可以通过时间限制在制品的数量。如。“我们不会超过10项本周工作”。嘿,这听起来很熟悉!# SprintForecast。

有兴趣了解更多关于限制在Scrum进展的背景下工作?检查专业类Scrum和看板以及看板指南和运用专业的看板类在ProKanban.org。