Scrum 中的 WIP 限制：让冲刺停滞的看板错误
许多 Scrum 团队已经在工作流中加入了看板板和在制品(WIP)限制,而 Scrum.org 的《Kanban Guide for Scrum Teams》正是认可这种做法。运用得当,WIP 限制能暴露瓶颈,促使团队倾向于完成工作而不是不断开新工作。运用草率,则只会制造摩擦而无助于改善流动。在分布式办公一年之后,一个卡住的工作项可能在某人的居家办公队列里数日无人察觉,因此把这件事做对比以往任何时候都更重要。下面是团队最常犯的错误。
团队容易出错的地方
把限制设得过高,以至于形同虚设。 如果 WIP 限制超过了团队任何时候会同时处理的工作量,那它什么也改变不了。限制的意义在于让团队感受到约束,在拉取更多工作之前先把手头的事做完。若它从不咬人,就只是摆设。
把 WIP 限制当成冲刺的替代品。 加入看板并不会取消 Scrum。冲刺、冲刺目标以及所有事件依然保留。《Kanban Guide for Scrum Teams》说得很明确:这些实践是对 Scrum 框架的补充——并不取代每日 Scrum、冲刺评审或回顾会议。
板子立起来后就不再关注流动指标。 一块设了限制却无人关注周期时间、工作项时龄或吞吐量的板子,不过是一面贴满便利贴的墙。价值来自于观察工作项耗时多久,并在它们变老时采取行动。
从不让团队调整限制。 WIP 限制不是一次下达便永久冻结的。团队应在回顾会议上检视并调整它——过紧,人会闲着;过松,工作项就会半成品般堆积起来。
遇到限制就阻塞,而不是群起协作。 当达到限制时,正确的做法是团队群起协作把进行中的工作做完,而不是去另一列开新工作。那些悄悄绕开限制的团队,会丧失它的全部益处。
怎样才算做好
运用得当,WIP 限制与每日 Scrum 会相互强化:对话从「我昨天做了什么」转向「是什么在阻挡那些最接近完成的工作项」。用几个习惯让这套实践保持诚实。
把初始限制定得略低于当前的舒适区,再在回顾会议上根据真实的周期时间数据进行微调。
让被阻塞的工作项高调可见——对分布式团队来说,在大家真正会查看的工具里打个标记,胜过实体板上的某个角落。
达到限制时,先完成再开始:群起协作、结对或评审,而不是开启新工作。
在每日 Scrum 上检视工作项的时龄,使任何事项都不会被遗忘在某个远程队列里。
如果你的团队希望以一种真正能落地的方式把 Scrum 与看板的流动实践结合起来, XNM 的项目集与项目交付咨询服务 可以帮助你搭建并辅导落实。