Scrum中的WIP限制和看板：好的做法与坏的做法对比
Scrum和看板通常被定位为替代品，但它们是兼容的。Scrum指南并不禁止团队在Scrum框架内应用看板实践——包括在制品（WIP）限制和流可视化。使用两者的团队有时被描述为实践"Scrumban"，尽管这是非正式标签而非正式方法论。WIP限制是对可以同时处于给定状态（或Scrum板阶段）的工作条目数量的约束。它们对抗人类开始新工作而非完成现有工作的自然倾向，并使瓶颈和队列可见。以下是在Scrum内应用WIP限制的好坏实践直接比较。
坏的WIP限制实施的样子
坏的：WIP限制在没有了解团队实际产能和工作通过Scrum板的自然流的情况下设置。设置太高的WIP限制没有效果——无论如何都在进行中的一切都适合限制内。设置太低的WIP限制会不必要地停止工作。正确的WIP限制需要观察团队的历史吞吐量并识别队列形成的位置。
坏的：WIP限制被视为可选的。如果WIP限制是"指导方针"而非硬约束，团队成员在感到繁忙时就会超过它，这意味着它对流没有影响。WIP限制要么在达到限制时阻止新工作开始，要么不阻止。如果不阻止，它不是WIP限制。
坏的：WIP限制适用于单个团队成员而非工作流阶段。个人WIP限制（你一次只能有两个条目在进行中）解决了个人多任务问题，但无法揭示系统级瓶颈。阶段级WIP限制（"审查中"列最多有四个条目）揭示了系统中工作在哪里排队。
坏的：当WIP限制被触及时，团队忽视它并继续。触及WIP限制应该触发团队响应：在开始新工作之前群策群力解决被阻塞的条目以清除队列。没有人响应的WIP限制是装饰品，不是管理工具。
好的WIP限制实施的样子
好的：WIP限制基于观察设置。团队审查历史吞吐量数据，识别工作最常排队的阶段，并专门为这些阶段设置WIP限制。随着吞吐量数据积累，限制会随时间调整。
好的：触及WIP限制触发团队对被阻塞阶段的群策群力。当"审查中"列触及其限制时，团队停止开始新开发并帮助在拉入新条目之前清除审查。这是预期的行为，它改善流。
好的：WIP限制在Sprint回顾会议中讨论和调整。团队反思他们的WIP限制是否正确校准、是否被遵守，以及什么变化会改善下一个Sprint的流。
XNM协助公共部门组织实施敏捷交付实践，包括流管理和WIP优化。欢迎联系XNM项目群与项目交付咨询团队，探讨贵团队的看板、WIP限制和敏捷流。