您的团队需要最低在制品限制吗？

我采访了一位敏捷教练，他的团队在工作中与董事会类似。 他们不使用迭代，而是按需计划。

左侧的“车间的故事”列是其积压工作细化列。

最近，团队决定他们需要“最小”在制品数量。 特别是在Workshop栏上。 为什么？ 他们的产品所有者没有在团队中花费足够的时间。 PO需要团队信号。

PO不使用各种最低要求中的信息 。 PO太忙了，PO只能从路线图中获取已经存在的想法/故事。

这种方法使用“多少”思考，而不是“ 多少 ”思考。 敏捷方法让我们在完成工作时就完成工作，而不是在完成所有工作后完成工作。

为什么最低WIP限制会导致组织问题

当我们可以更改排名的待办事项时，就可以创建组织敏捷性。 如果我们假设路线图永远不会改变，那么我们就不会敏捷地思考。 并且，我们为自己制造问题：

• PO正在根据旧的路线图或产品的战略视图进行设计。 采购订单未利用新信息。 我们没有敏捷的路线图。
• 组织没有利用停止一种产品（或功能集）并启动另一种产品的优势。

当团队表示需要更多信息时，他们也表示可以使用此功能集或此产品来完成。

他们可能没有完成。 而且，如果不是这样，为什么采购订单不与团队一起查看每天完成的工作？

借助变化创造业务敏捷性

您的产品需要比交货更多的发现吗？ 如果是这样，采购订单和产品经理需要定期重新评估当前的路线图。

当我们更改计划和交付的内容时，我们可以获得业务敏捷性。

对于程序，程序产品负责人（通常是产品经理）会发出信号，与产品价值团队一起决定下一步要做什么。

对于项目，也许团队可以使用不同的功能集。

而且，对于项目组合，也许团队可以暂时停止使用该产品 ，然后开始开发其他产品？

如果产品负责人仅从战略角度看待工作，那么他们就不会像产品负责人那样行事。 他们是产品经理。 （请参阅PO角色系列。）

我们需要产品经理。 我们需要从客户和更大的市场中获取信息的战略观点。

而且，如果我们的团队中没有产品负责人，我们会得到什么？ 我们得到更快的瀑布。 当然，我们没有业务敏捷性。

最低在制品限制是一种反模式

如果您的团队需要最低在制品限制，那么团队的流程可能有问题。 与我合作的每个组织等待团队的工作量远远超过团队可能完成的工作。 最低WIP限制意味着像PO这样的人对团队的关注不足。

如果团队表示他们需要更多工作，那么该工作应该在其他产品上进行。 拥有真正的产品所有者。

翻译自: https://www.javacodegeeks.com/2019/10/does-your-team-need-minimum-wip-limits.html