在敏捷开发中，进行中的工作（Working in progress: 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： 保护 可持续的工程文化。进行中的工作限制并不意味着开发人员需要匆忙完成工作，以避免在特定状态下工作超载。它们旨在支持可靠的敏捷工程实践，以保护产品质量和代码库的健康。
