为什么限制正在进行的工作对Scrum很重要

Scrum的核心是Sprint，这是一个有时间限制的事件，在此期间，Scrum团队每个日历月至少交付一次有价值的增量。在Sprint计划活动期间，开发人员选择他们将在即将到来的Sprint中交付哪些产品Backlog项(pbi)，创建交付它们的计划，并确定为即将到来的Sprint提供焦点的Sprint目标。Sprint的目的是交付满足Sprint目标的有价值产品的已完成增量。听起来很简单，对吧?然而，许多团队都在努力交付满足Sprint目标的Done增量。

您知道添加限制在制品量(WIP)的补充看板实践会有所帮助吗?

这是一个常见的误区，如果你想早点完成一件事，就早点开始。在简单的环境中，或者只有一件事要做的时候，这可能会起作用，但是在复杂的环境中，许多团队成员一起工作来交付各种任务，这种做法实际上会延迟交付。

请看下图，它展示了一个Sprint Backlog的示例。左边是团队为Sprint选择的pbi列表。右边是我们可能为交付每个任务而创建的示例任务。

现在想象一下，在Sprint的第一天，我们立即开始处理产品待办事项列表中的所有项目和任务。

这可能看起来是个好主意，直到你意识到这是一项复杂的工作。如果我们在同一天开始所有的任务，我们就会减少团队协作，而如果我们限制在制品数量，就会减少团队协作。

假设开发人员A和开发人员B都有一个计划在Sprint期间完成的PBI。如果每个人都独立开始他们的PBI工作，他们可能能够完成它。但是，如果开发人员A和B不是单独工作，而是在第一个PBI上一起工作，完成它，然后在下一个PBI上一起工作，他们很可能能够通过协作更快地完成两个PBI。

协作帮助团队确定复杂问题的创造性或简化的解决方案。例如，几年前，我是一个专注于减少批处理作业运行时间的团队的Scrum Master。我们的目标是将运行时间从8小时减少到6小时，以使工作符合时间表。开发人员决定结对编程，在Sprint期间，他们提出了一个解决方案，将运行时间减少到15分钟，并消除了反复导致工作失败的质量问题。双方都承认，如果没有共同关注同一个问题，这种解决方案是不可能出现的。

即使团队不进行结对编程，减少在制品对团队也有好处，因为它增加了关注点，减少了任务切换，从而实现了更快的价值交付。

将其乘以团队的规模，即使在这个简单的示例中，您也会看到优势。当我们还考虑限制在制品所带来的质量提高时，我们发现尽早开始工作并不总是最好的途径。

下图显示了一个Sprint Backlog的示例，该示例用于限制一个团队正在进行的工作。这就是所谓的看板，一种允许团队成员可视化Scrum团队工作状态的工具。这个展板显示了团队已经在Sprint计划事件之后开始了部分(但不是全部)他们的工作。通过限制在制品，团队可以专注于那些正在进行的项目，并比他们试图将注意力分散并一次性集中在所有事情上更快地完成它们。

结论

这是一个常见的误区，如果你想早点完成某件事，就早点开始。虽然这可能适用于简单的环境，但并不总是适用于复杂的工作。

Scrum是一种在复杂环境中交付复杂产品的框架。虽然Scrum是最流行的敏捷框架，但许多团队都没有意识到可以实现看板常见的实践——比如限制在制品(WIP)——来提高团队效率。将看板与Scrum实践相结合并不需要替换事件、职责或工件。它是关于集成看板的一些补充实践，以帮助改进Sprint中的工作流程。

注册Rebel Scrum即将推出的游戏吧带有看板的专业Scrum类，学习更多关于如何使用看板实践(如WIP和可视化)来提高Scrum团队的效率。