将“流”放回具有 WIP 限制的工作流中

在制品限制并不是要真正限制您的进度。事实恰恰相反。

Dan Radigan 作者:Dan Radigan
浏览主题

什么是 WIP 限制?

在敏捷开发中,在制品 (WIP) 限制设定了工作流中每个状态所能允许的最大制品量。限制在制品数量更易于发现团队工作流中的低效率现象。团队交付管道中的瓶颈也可以在局势变严重之前显现出来。

为什么 WIP 限制很重要?

现在您可能在想,“不够,我还想知道更多!”(希望如此)。

WIP 限制通过迫使团队专注于较小的任务集来提高吞吐量并减少“接近完成”的工作量。从根本上讲,WIP 限制鼓励一种“完成”文化。更重要的是,WIP 限制让障碍和瓶颈显而易见。当有明确的迹象表明当前有些工作产生了瓶颈时,团队可以集中力量先去理解、实施和解决这些构成障碍的事务。待障碍消除后,便可继续团队整个团队的工作。这些优势可保证更快为客户增加价值,因此 WIP 限制已成为敏捷开发中的一个宝贵工具。

开发过程中,很容易会想“哦,这个事务先暂停一下,我先处理另一个事务。”有两个未解决的事务意味着要在两件事之间切换背景,或在队友之间转移工作。暂停一个事务而开始另一个事务并非毫无影响,需要花时间,而且会削弱注意力。更好的办法应该是先解决原事务,而不是原事务还没完成,就开始新的工作。换句话说,WIP 限制希望我们不要在流中自设障碍。

最后,进行中的工作限制可指出长期闲置或长期超负荷的环节,继而可帮助团队看到整个流程中效率低下的领域,而非仅仅自己工作中的特定领域。

专业提示:

对于刚刚接触 WIP 限制的团队来说,他们会感觉无所适从。在最初的几次迭代中,花点时间跟他们讨论。了解什么时间团队需要设定 WIP 限制以及为什么要设定。不要一开始就武断做出调整。如果持续出现违规,则表明要么在制品限制过于严格,要么团队流程效率低下。

对敏捷团队使用 WIP 限制

现在您对它们的价值已经心中有数了,我们来言归正传。

推出新工作流时,团队要决定每个状态的 WIP 限制。我们建议先监控几次冲刺中,每个状态下的平均工作项目数后再设置 WIP 限制。下面是一般软件开发团队所使用的,设有 WIP 限制的示例敏捷看板。

WIP 限制 | Atlassian 敏捷教练

上图中,针对代码审核设定了 WIP 限制。因该列超出了限制,所以其背景变成了红色。

鉴于事务完成后就不需要采取任何行动了,所以那里不需要设定 WIP 限制。在上面的看板中,进入“待办”状态表明故事已经过产品负责人和团队的全面审查。开发团队开始处理工作项目时,会将相应工作从“待办”状态移至“进行中”状态。理想状况是在“待办”状态下保留足够多的工作量,以充分发挥开发团队中每个成员的作用。通过在“待办”状态下保留足够多的故事,产品负责人可确保在充实要求时不会过于超前,并且项目对变化的反应也会更加灵敏。

“进行中”状态列出了正处于开发状态的工作项目。这种情况下,在制品限制的目标是确保每个人都有工作要做,同时避免一人承担多项工作。在上面的看板中,“进行中”的项目数上限为 4,目前有 3 个项目处在这一状态。由此显示出该团队还有余力承担更多工作。为实现最佳效果,有些团队会将 WIP 限制的上限设置到团队成员数以下。这样做旨在为良好的敏捷实践留出空间。如果某个开发人员完成了某个项目,但该团队已达到其 WIP 限制,这个时候团队就知道该去掉几项代码审查工作,或者该增加一位开发人员做一些配对编程的工作了。

到达“代码审查”状态表明已充分完成故事编写,但还需要审查后才能并入代码库。及时进行代码审查是一项最佳实践,可以保障质量,可以加快向市场推出新的创新,可以通过减少开放分支简化合并,还可以在整个工程团队传播知识。处于这一状态的项目需要紧急处理,原因如下:

  • 避免当团队成员签入新代码时,代码被破坏
  • 避免开发人员失去其编写原代码时获得的背景信息
  • 该功能可合并到主分支进行发布

WIP 限制可确保不会有未经审查代码堆积。

注意,在以上敏捷看板中,团队的代码审查项目太多了,所以该列显示为红色以示警告。

应留意的反模式:
  • 根据需要提高 WIP 限制,以避免团队再次达到上限。(“债务上限”,有人吗?)
  • 每个人都有大量的“后台任务”要做,以此来掩盖其原本空闲的时间。
  • 团队成员空闲下来等待更多工作进入,而非共同去处理瓶颈。
  • 相比改进工程实践或团队流程,更可取的办法是增加投入人工时间解决持续存在的瓶颈。

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

与其他新事务一样,WIP 限制在刚引入时也会让人不知所措。其目标在于在中期优化团队,而短期的不知所措不是什么坏事。在此过程中,团队会有一些不适。在团队使用 WIP 限制几周后,根据需要做出调整。避免仅仅因为团队总是达到在制品限制,而提高限制上限。要抓住这样的机会来提高能力,最好是能够为团队提供指导,赋予每个团队成员以新的技能集,或提高开发过程的某些方面的效率。

目标 1:统一单项任务的大小。分解要求和用户故事时,一定要确保单项任务的工作时间不能超过 16 个小时。这样可以提高团队从容估算的能力,有助于防止瓶颈的产生。没有什么比一个大的工作项目阻塞管道更能减慢团队速度和加剧 WIP 限制的了。

专业提示:

为团队设定在制品限制后,将随之下达一个事务周期时间。周期时间是指完成事务所花费的时间。有关详情,请参阅我们的敏捷指标页面。

目标 2:将 WIP 限制与团队技能形成映射。以上示例假设团队成员具有相似的技能组合。如果您的团队中有专家,则当专家参与时,在制品限制可能会有所不同。为专家的工作创建专属状态。如果该状态出现瓶颈,则可以借此机会指导团队成员为专家的技能组合赋能,并提高整个团队的流动性。

目标 3:减少空闲。当一个团队成员有空闲时间时,鼓励其为上下游团队成员提供帮助。这样一来,他们不仅可以提高团队的整体生产力,还可以从中学到东西!

目标 4:保护可持续的工程文化。在制品限制并不意味着开发人员需要匆忙工作,以避免在特定状态下出现工作过载。这项限制旨在为强大的敏捷工程实践提供支持,以保障产品质量和代码库的运行状况。

后续内容
看板和 Scrum