wip 敏捷开发：看板中的WIP限制思想

WIP限制并不是真的限制你的进度，事实上恰恰相反。

什么是在制品限额？

在敏捷开发中，在制品限额决定了在每种情况下工作流中可以存在的最大工作量。限制正在进行的工作的数量可以更容易地识别团队工作流中的无效工作。在情况变得更糟之前，很容易识别出一个团队在持续交付渠道中的瓶颈。

为什么WIP限制很重要？

所以现在你一定在想，“快点告诉我！”嗯，我希望你这样认为。)

在制品限制通过迫使团队专注于更小的任务集来提高吞吐量并减少“待完成”的工作量。从根本上说，在制品限制鼓励“完成”文化。更重要的是，在制品限制会使障碍和瓶颈变得明显。当有明确的迹象表明现有工作遇到瓶颈时，团队可以专注于尽快理解、实现和解决阻塞问题。一旦堵塞被清除，团队中的工作将再次开始流动。这些优势可以保证在最短的时间内将有价值的增量交付给用户，从而使得在制品限制成为敏捷开发中非常有价值的工具。

“此外，多任务处理只是看似时间安排紧密。”

在开发过程中，很容易让人产生“等我开始另一份工作，我就暂停这份工作”的想法。同时打开两个问题意味着在两个事务之间来回切换或者在团队成员之间转移工作。减少一个人的投资，增加另一个人的投资，并不意味着自由——这需要时间，削弱了重点。解决一个原来的问题总比开始一个新的工作而不完成好。换句话说，在制品限制防止我们阻塞自己的流程。

最后，在制品限额表示长期闲置或超载的区域。他们帮助团队在整个过程中看到低效的事件，而不仅仅是特定的领域。

专家提示：对于刚刚使用WIP限制的团队，会觉得并不方便。只需要花点时间在最开始的几次迭代中进行讨论。了解团队何时以及为何达到了WIP限制。起初，要抵制随意调整WIP限制的诱惑。如果违规行为接连不断，那就表明WIP的限制过于严格或者团队的流程效率太低。

在敏捷团队中使用在制品限制

既然你已经认识到了它们的价值，让我们回到实际问题上来。

每当一个新的工作流被推出时，团队应该在每个案例中判断和决定在制品限制。我们建议在监控几次迭代后设置在制品限制，以确定每种情况下工作项的平均数量。

要注意的反面模式：•根据需要调高WIP限制，以便团队不再打击它们。（例如“债务上限”，还有其他的吗？）•每个人都有一个很大的专属“后台任务”用来隐藏他们的闲置时间。•团队成员闲着等待更多的工作进入，而不是集中在瓶颈上。•在工程实践或团队流程中，投入更多的人时在持续的瓶颈上要优于过度改进。

敏捷团队使用在制品限制的四个目标

与任何新活动一样，在制品限制最初很难使用。WIP限制的目标是让团队在中期达到最佳状态，所以短期尴尬其实是好事。这会迫使团队触及他们过程中的一些痛点。

在使用WIP限制几周后，团队可以根据需要进行调整。仅仅因为团队已经受挫，就能抵挡住提高WIP限额的诱惑。而且还要抓住机会提高团队的整体能力——理论上讲，每个成员都可以通过对团队的教育，在某些方面获得新的技能或者提高开发过程的效率。

目标1:不断调整单个任务的大小。

在分解需求和用户故事时，确保单个任务的工作量不超过16小时是非常重要的。这样既能提高团队准确估算的能力，又能避免瓶颈。没有什么比用大的工作项堵塞渠道更能减缓团队速度，加重WIP限制了。

专家提示：当WIP限制有效时，一个事件的循环时间就会降低。循环时间就是完成一个事件需要的时间。

目标2:将在制品限额作为团队技能进行规划。

上面的例子假设团队成员的技术能力是相似的。如果您的团队有技术专家，当专家参与时，在制品限制应该不同。此时，有必要创建一个特定于专家工作的状态。如果在这种状态下出现瓶颈，那么对于其他团队成员来说，学习一些额外专家所具备的技能是一个很好的机会，从而提升整个团队的流量。

目标3:减少懒惰。

当一个团队成员停机时，鼓励他们帮助上游或下游的团队成员。他们不仅可以为团队的整体生产力做出贡献，还可以在这个过程中学到一些东西。

目标4:保护可持续的工程文化。

在制品限制并不意味着开发人员在某些情况下需要匆忙工作以避免过载。它旨在确保产品质量和代码库健康的前提下，保护坚实的敏捷工作实践。

原作者:丹·拉迪根

翻译:吴倩倩