看板中的WIP限制

最近在看有关看板的资料，之前我对看板的认识觉得只是一个任务展示工具，作用等同于to do list 看了这篇文章，对看板有了一些新的认识，以下是我翻译的文章，如有不准确的地方，欢迎交流，enjoy~~

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

什么是WIP限制？

在敏捷开发中，WIP限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队在持续交付通道中的瓶颈是非常容易辨别的。

为什么说WIP限制很重要？

所以现在你一定在想“赶快告诉我更多吧！”（好吧，我希望你是这么想的。）

WIP限制通过强制让团队聚焦在更小的一套任务中来改善吞吐量和减少“将要完成”的工作量。从根本上来讲，WIP限制鼓励的是“完成”的文化。更重要的是，WIP限制可以让阻碍和瓶颈显而易见。当有明确指示现有工作遇到瓶颈时，团队可以聚焦在阻塞问题上尽快的理解、实施和解决。一旦消除阻塞，团队中的工作将再次开始流动。这些优势可以确保在最短的时间内向用户交付有价值的增量，从而使得WIP限制成为敏捷开发中一个非常有价值的工具。

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

开发期间，大家很容易会想“当我开始另一项工作的时候，我会暂停这项工作”。同时打开两个问题意味着在两个事务之间前后切换或者在团队成员之间转移工作。降低一件事的投入加大另一件事的投入并不意味着自由-因为它会花费时间并且削弱焦点。解决一件原始问题总是好过开始并且未完成一项新工作。换句话说，WIP限制防止我们阻碍自己的流。最后，WIP限制指出了长期闲置或过载的区域。它们帮助团队看到整个流程中的低效事件而不仅仅是某些特定区域。

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

在敏捷团队中使用WIP限制

现在你已经认可它们的价值了，那我们回归实际问题。每当铺开一条新的工作流时，团队都要判断并决定每种情况下的WIP限制。我们建议在监控几次迭代确定每种情况下平均数量的工作项后再设置WIP限制。

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

敏捷团队使用WIP限制的4个目标

与任何新活动一样，WIP限制最初使用起来比较尴尬。而WIP限制的目标是在中期使团队达到最优状态，所以短期的尴尬实际上是好事。它会迫使团队触碰到他们流程中的一些痛点。团队在使用WIP 限制几周后，就可以根据需要进行调整。正因为团队一直在受挫，因此可以抵制调高WIP限制的诱惑。而且还能抓住机会，提高团队整体能力-理论上，可以通过教育团队让每个成员获得新技能或在某些方面提高开发过程的效率。

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

在分解需求和用户故事时，保证单个任务的工作量不超过16个小时是非常重要的。这么不仅可以提高团队确切预估的能力，还能有避免瓶颈。没有什么能比大工作项阻塞通道更能降低团队速度加剧WIP限制了。

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

目标2：将WIP限制规划为团队的技能。

上面的例子是假设团队成员的技术能力相似。如果你的团队有技术专家，那么当专家牵涉其中时WIP限制应该有所不同。这个时候需要创建特定于专家工作的状态。如果在该状态下出现瓶颈，正好可以趁机让团队其他成员学习一些额外的专家具备的技能，以此来增强整个团队的流。

目标3：减少闲置。

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

目标4：保护一种可持续的工程文化。

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

文章来自 Worktile官方博客 ，想了解更多有关敏捷开发/项目管理/团队协作等方面的内容可前往查看。

原文作者：Dan Radigan

翻译/校对：吴倩倩