通过限制正在进行的工作，更快地交付

软件开发团队一直难以在企业和客户期望的时间范围内提供功能。BCG 最近的一项研究发现，超过三分之一的受访者的内部软件开发项目被推迟。延迟交付会延迟投资回报率，并使所有相关人员感到沮丧。

组织在加速软件交付时面临着许多挑战，但其中一个挑战因其巨大的影响力和相对简单的解决方法而脱颖而出：一次处理太多事情。

多任务陷阱

一个团队有三个为期六周的项目：

• 项目 A：面向客户的移动应用程序更新
• 项目 B：一项重要的安全增强措施
• 项目 C：用于合作伙伴整合的新 API

如果团队环境在项目之间切换，他们就会陷入困境。你可能去过那里，经常参加会议，管理不同的利益相关者的期望。该团队最终大约在同一时间完成了所有三个项目：

• 项目 A：16 周
• 项目 B：17 周
• 项目 C：18 周

其影响是灾难性的。该移动应用程序在购物旺季结束很久之后启动。延迟的安全更新使利益相关者感到焦虑，而延迟的 API 推迟了合作伙伴的入职机会。

但是，如果团队专注于一个项目直到完成，他们可以在短短 6 周内交付移动应用程序。他们在第 12 周之前完成了安全更新，在第 18 周之前完成了 API。他们仍然可以在 18 周内完成所有工作，但与在项目之间切换上下文相比，他们会提前 10 周为客户提供有价值的最新信息。他们可以提前 5 周修复安全问题，并且整个流程更加高效。

简单的解决方案：在建工作 (WIP) 限制

您可以通过在建项目 (WIP) 限制来缩短上市时间，即限制团队一次处理的项目数量。

当西门子健康系统的开发团队开始使用 WIP 限制时，他们将交付周期从 71 天缩短到 43 天，提高了 42％。这些团队没有增加资源或延长工作时间。同样的团队在将近一个月前完成了相同的工作量，为客户创造了价值。质量也得到了显著提高——首次通过测试的成功率从 75％ 上升到 95％。同时专注于更少的物品可以加快交付速度和更好的结果。

Little's Law 描述了固定系统中物品随时间推移的平均数量，它在数学上证明了交付时间随着 WIP 的增加而增加：

其中：

• L = 系统中的平均项目数 (WIP)；
• α = 单位时间内到达的物品的平均数量（吞吐量）；以及
• W = 项目在系统中停留的平均时间（循环时间）。

如果 10 个项目正在进行中 (L) 且每周有 2 个项目完成 (α)，则每个项目需要 5 周 (W)：

即使完成率相同，WIP 也将翻倍至 20 件商品，交付时间翻倍至 10 周：

如果您想要更快的交付，有两种选择：增加吞吐量（这需要更多资源）或减少 WIP（这需要更多的注意力）。您无需大量投资或复杂的转型即可开始使用 WIP 限额；它是可用的最具成本效益的改进工具之一。

在最重要的地方使用 WIP 限制

WIP 限制对瓶颈最有效。根据约束理论，任何过程的吞吐量都受到其最慢步骤的限制。

价值流映射可以帮助您确定这些限制。它可视化您的整个开发过程（从概念到生产），从而清楚地了解工作积累的地方和瓶颈的形成。您可能会发现大量未经测试的代码或功能等待部署批准。这些瓶颈起到了限制作用，限制了您的整体交付速度。

通过策略性地将 WIP 限制设置在这些瓶颈阶段，可以产生调节整个系统的"拉动"效应。当瓶颈阶段达到其 WIP 极限时，上游阶段自然会减速，因为它们无法推动更多工作向前推进。这样可以防止在约束条件下累积工作，并减少系统中 WIP 的总量。同时，下游阶段只能像处理瓶颈一样快地处理工作。

在典型的开发过程中，测试是瓶颈。如果没有 WIP 限制，你可能会看到 10 个功能同时开发，6 个等待代码审查，8 个待测试，3 个待部署，也就是 27 个项目正在开发中。通过在测试时将 WIP 限制设置为 4 个项目，可以产生连锁效应：代码审查不能向前推进 4 个项目，因此开发侧重于较少的功能。现在你可能有 4 个功能在开发中，4 个在审查中，4 个在测试中，2 个在部署中，总共只有 14 个项目。在每周完成 3 项功能的情况下，你的周期时间几乎缩短了一半，从 9 周缩短到不到 5 周。

入门：使用 WIP 限制的前 12 周

要开始在组织中使用 WIP 限制，请选择试点小组。寻找一个拥抱变革并在当前工作量中挣扎的人——他们将是你在这方面的优秀合作伙伴。召集团队及其利益相关者，在价值流图中概述从概念到生产部署的每个步骤。要特别注意工作量较大的阶段——这些区域将从你最初的 WIP 限制中获得最大的优势。

找到瓶颈。然后将初始 WIP 限制设置为当前工作负载的 70％ 至 80％，以在不中断交付的情况下制造生产压力。在上面有关典型开发过程的示例中，您将在测试中设置六个项目的初始限制。

测量试点团队四周的周期时间。计算每个工作项需要多少天才能完成。跟踪团队每月完成多少项目（吞吐量）。计时开发和测试等每个步骤，然后随着团队的适应降低瓶颈处的 WIP 限制。

在前 4 周后，将限额降低 10% 至 20%。这个范围平衡了进步与实用性——硬限制会带来阻力，但软限制并不能推动足够的行为改变。考虑您的团队的需求。一个由 10 人组成的开发团队一开始可能会有 8 个并发项目，然后随着完成率的提高减少到 6 个。

在 8-12 周内继续测量相同的东西。看看区别。团队将以更少的项目更快地完成工作，但每月完成的项目数量相同。每周完成三个项目的团队将在图 2 中显示结果。

图 2。8 周内 WIP 限额的影响

当团队达到 WIP 限制时，他们应该支持积极工作（修复错误、改进代码、更新工具或共享知识），而不是开始新任务。个人贡献者可能会觉得他们的工作速度较慢，但团队完成工作的速度更快，总体交付速度也会加快。

在试点团队之外扩大成功规模

在整个组织中推出和扩展 WIP 限制。试点阶段成功后，从定期与试点团队互动的团队开始，扩大 WIP 限额。他们已经可以通过日常合作看到好处。这些团队面临着相似的挑战，在类似的要求下工作，这使他们成为理想的录用人选。

逐步扩大 WIP 限制。团队在故事层面上工作，但较大的计划通常会跨越多个团队。也可以在这些更高的级别上应用 WIP 限制。部门领导应限制积极的举措。当团队的交付持续达到 WIP 限制时，领导者将在投资组合层面使用它们。

在整个交付流程中扩展 WIP 限制。绘制从最初的概念到生产部署的旅程。许多组织发现他们的流程早在任何团队编写代码之前就已经开始了。在每个阶段应用 WIP 限制，以保持整个交付过程的顺畅流程。

停止启动；开始完成

WIP 限制不仅能在当今交付更快的软件；它们还能让您的组织为未来的挑战做好准备。使用 WIP 限制快速交付软件的组织可以在扩展时保持速度。

您的开发团队已经有能力更快地交付。WIP 限制释放了这种潜力。

马蒂亚斯·帕扎克

在担任亚马逊云科技解决方案架构首席顾问后，Matthias 于 2023 年初加入企业策略师团队。在这个职位上，Matthias 与高管团队合作，从人员、流程和技术的角度研究云如何帮助提高创新速度、IT 效率以及他们的技术产生的商业价值。在加入亚马逊云科技之前，马蒂亚斯曾在 AutoScout24 担任 IT 副总裁和欧洲家居购物董事总经理。在这两家公司中，他大规模引入了精益敏捷的运营模式，并成功领导了云转型，从而缩短了交付时间，增加了商业价值并提高了公司估值