什么是 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 限制，请免费使用我们的看板面板模板以尽快上手。
