Key Takeaways
WIP (Work-in-Progress) limits the number of tasks in each workflow stage, highlighting bottlenecks and improving workflow efficiency.
Limiting WIP encourages focus, reduces multitasking, and accelerates delivery by making blockers visible.
Teams should set, monitor, and adjust WIP limits to optimize throughput and maintain a sustainable pace.
Implement WIP limits on your kanban board to boost efficiency and foster a culture of completion.
什么是 WIP 限制？
在敏捷开发中，在制品 (WIP) 限制设定了工作流中每个状态所能允许的最大制品量。限制在制品数量更易于发现团队工作流中的低效率现象。
团队交付管道中的瓶颈能在情况变得严峻前清晰显现。通过专注完成现有任务再启动新任务，各类团队都能提升效率、减少上下文切换，并显著改善交付成果。
为什么 WIP 限制很重要？
现在，您肯定在想：“再详细说说吧！”
WIP 限制通过迫使团队专注于较小的任务集来提高吞吐量并减少“接近完成”的工作量。从根本上讲，WIP 限制鼓励一种“完成”文化。
更重要的是，WIP 限制让障碍和瓶颈显而易见。当有明确的迹象表明当前有些工作产生了瓶颈时，团队可以集中力量先去理解、实施和解决这些构成障碍的事务。待障碍消除后，团队工作便可继续进行。
这些优势保证了更快地向客户交付增加的价值，使 WIP 限制成为敏捷开发中的重要工具。
开发过程中，很容易会想“哦，这个事务先暂停一下，我先处理另一个事务。”有两个未解决的事务意味着要在两件事之间切换背景，或在队友之间转移工作。暂停一个事务而开始另一个事务并非毫无影响，需要花时间，而且会削弱注意力。
更好的办法应该是先解决原事务，而不是原事务还没完成，就开始新的工作。换句话说，WIP 限制希望我们不要在流中自设障碍。
最后，进行中的工作限制可指出长期闲置或长期超负荷的环节，继而可帮助团队看到整个流程中效率低下的领域，而非仅仅自己工作中的特定领域。
专业提示：
对于刚刚接触 WIP 限制的团队来说，他们会感觉无所适从。在最初的几次迭代中，花点时间跟讨论它们。了解团队何时以及为何达到 WIP 限制。不要一开始就武断做出调整。如果违反限制的情况持续发生，这就表明 WIP 限制过于严格，或者团队的流程效率低下。
对敏捷团队使用 WIP 限制
现在您对它们的价值已经心中有数了，我们来言归正传。
推出新工作流时，团队要决定每个状态的 WIP 限制。我们建议先监控几次冲刺中，每个状态下的平均工作项目数后再设置 WIP 限制。下面是一个典型软件开发团队使用的带有 WIP 限制的敏捷面板示例。
上图中，针对代码审核设定了 WIP 限制。因该列超出了限制，所以其背景变成了红色。
鉴于事务完成后就不需要采取任何行动了，所以那里不需要设定 WIP 限制。在上面的看板面板中，进入“待办”状态表明故事已经过产品负责人和团队的全面审查。开发团队开始处理工作项目时，会将相应工作从“待办”状态移至“进行中”状态。理想状况是在“待办”状态下保留足够多的工作量，以充分发挥开发团队中每个成员的作用。通过在“待办”状态下保留足够多的故事，产品负责人可确保在充实要求时不会过于超前，并且项目对变化的反应也会更加灵敏。
“进行中”状态列出了正处于开发状态的工作项目。这种情况下，在制品限制的目标是确保每个人都有工作要做，同时避免一人承担多项工作。在上面的看板中，“进行中”的项目数上限为 4，目前有 3 个项目处在这一状态。由此显示出该团队还有余力承担更多工作。为实现最佳效果，有些团队会将 WIP 限制的上限设置到团队成员数以下。这样做旨在为良好的敏捷实践留出空间。如果某个开发人员完成了某个项目，但该团队已达到其 WIP 限制，这个时候团队就知道该去掉几项代码审查工作，或者该增加一位开发人员做一些配对编程的工作了。
到达“代码审查”状态表明已充分完成故事编写，但还需要审查后才能并入代码库。及时进行代码审查是一项最佳实践，可以保障质量，可以加快向市场推出新的创新，可以通过减少开放分支简化合并，还可以在整个工程团队传播知识。处于这一状态的项目需要紧急处理，原因如下：
避免当团队成员签入新代码时，代码被破坏
避免开发人员失去其编写原代码时获得的背景信息
该功能可合并到主分支进行发布
WIP 限制可确保不会有未经审查代码堆积。
注意，在上述面板中，团队的代码审查项目太多了，所以该列显示为红色以示警告。
应留意的反模式：
根据需要提高 WIP 限制，以避免团队再次达到上限。（“债务上限”，有人吗？）
每个人都有大量的“后台任务”要做，以此来掩盖其原本空闲的时间。
团队成员空闲下来等待更多工作进入，而非共同去处理瓶颈。
与改进工程实践或团队流程相比，人们更愿意投入更多的工时来解决长期存在的瓶颈问题。
敏捷团队使用 WIP 限制的 4 个目标
与其他新事务一样，WIP 限制在刚引入时也会让人不知所措。其目标在于在中期优化团队，而短期的不知所措不是什么坏事。在此过程中，团队会有一些不适。在团队使用 WIP 限制几周后，根据需要做出调整。避免仅仅因为团队总是达到在制品限制，而提高限制上限。要抓住这样的机会来提高能力，最好是能够为团队提供指导，赋予每个团队成员以新的技能集，或提高开发过程的某些方面的效率。
目标 1：统一单项任务的大小。分解要求和用户故事时，一定要确保单项任务的工作时间不能超过 16 个小时。这样可以提高团队从容估算的能力，有助于防止瓶颈的产生。没有什么比一个大的工作项目阻塞管道更能减慢团队速度和加剧 WIP 限制的了。
专业提示：
当进行中的工作限制对团队起作用时，问题的周期时间就会缩短。周期时间是指完成一个事务所花费的时间。有关详情，请查阅我们的敏捷指标页面。
目标 2：将 WIP 限制与团队技能形成映射。以上示例假设团队成员具有相似的技能组合。如果您的团队中有专家，则当专家参与时，在制品限制可能会有所不同。为专家的工作创建专属状态。如果该状态出现瓶颈，则可以借此机会指导团队成员为专家的技能组合赋能，并提高整个团队的流动性。
目标 3：减少空闲。当一个团队成员有空闲时间时，鼓励其为上下游团队成员提供帮助。这样一来，他们不仅可以提高团队的整体生产力，还可以从中学到东西！
目标 4：保护可持续的工程文化。在制品限制并不意味着开发人员需要匆忙工作，以避免在特定状态下出现工作过载。这项限制旨在为强大的敏捷工程实践提供支持，以保障产品质量和代码库的运行状况。
如果您的团队已准备好实施 WIP 限制，请免费使用我们的看板面板模板以尽快上手。