Это перевод ещё одной статьи Ювала Ерета — до этого мы пересказывали, какие метрики Канбана можно использовать в Скраме и как эти метрики улучшают события. Теперь — обстоятельный разговор о WIP-лимитах.
Ограничение количества незавершенной работы (WIP-лимиты) — одна из ключевых практик Канбана. Она улучшает показатели рабочего потока, делает его предсказуемым и, что более важно, приводит к вытягивающей Канбан-системе, а не к обычной визуализации. Есть даже команды, которые считают, что эта практика важнее визуализации и должна быть первой.
Однако при внедрении WIP-лимитов команда должна решить, как именно ограничивать и сокращать количество незавершенной работы. Здесь ключевую роль играет определение рабочего потока в команде.
Кто должен определять WIP-лимиты
Предположим, Скрам-команда использует Канбан, чтобы улучшить рабочий поток за счет визуализации и управления Бэклогом Спринта. Бэклог Спринта принадлежит Разработчикам, а значит, они должны определять и количество незавершенной работы.
Даже если Разработчики включили в свой поток Владельца Продукта, чтобы он проводил ревью и давал обратную связь, Бэклогом Спринта всё равно владеют разработчики. Они отвечают за доставку ценности.
Однако когда Скрам-команда использует Канбан более комплексно, в том числе для Уточнения Бэклога Спринта, именно она владеет рабочим потоком и уже ей надлежит обсуждать WIP-лимиты.
Можно ли менять WIP-лимиты в середине Спринта
Представим, что в середине Спринта появился важный элемент, который Владелец Продукта хочет добавить в Бэклог Спринта. Элемент согласуется с Целью Спринта, но команда уже взяла максимальное количество незавершенной работы.
Если команда решает вытянуть элемент в Бэклог Спринта, Разработчикам нужно понять, могут ли они начать работу над этим элементом сразу. Это зависит от ограничений и количества незавершенной работы в текущий момент. При перегрузе за новый элемент стоит браться, только когда освободится место. Если остальные элементы маленькие, место для нового слота освободится быстро. Если большие, какое-то время придется подождать. Чем больше времени нужно, чтобы освободить слот в Бэклоге Спринта, тем сильнее давление на команду.
Превышение WIP-лимитов и проталкивание элемента вверх называется экспедированием. Обычно в таких случаях ограничение не снимается — команда берет элемент и указывает, что было сделано исключение. Такие исключения — тема для инспекции и адаптации.
Когда адаптировать WIP-лимиты
В большинстве случаев корректировать WIP-лимиты следует во время Ретроспективы Спринта, чтобы подходить к этому стратегически, а не улучшать рабочий поток на ходу. Похожим образом команда работает с Критериями Готовности (DoD): она не меняет их во время Спринта только потому, что возникла проблема с готовым Инкрементом, а отмечает исключение, может быть, даже провал в создании Инкремента, и обсуждает его во время Ретроспективы.
При этом ничто не мешает команде корректировать WIP-лимиты в любой точке Спринта. Есть разница между тем, что можно делать, и тем, что следует делать.
Как ограничивать WIP
Последнее, что стоит отметить: команда может ограничивать количество незавершенной работы и для каждого участника, и для всей команды — по потоку или по времени. Пример такого ограничения: «Мы будем работать только над 10 элементами на этой неделе». Знакомо звучит?
Если хотите узнать о WIP-лимитах в Скраме еще больше, изучите Краткое руководство по Канбану и приходите на курс Professional Scrum with Kanban (PSK).
Ограничение количества незавершенной работы (WIP-лимиты) — одна из ключевых практик Канбана. Она улучшает показатели рабочего потока, делает его предсказуемым и, что более важно, приводит к вытягивающей Канбан-системе, а не к обычной визуализации. Есть даже команды, которые считают, что эта практика важнее визуализации и должна быть первой.
Однако при внедрении WIP-лимитов команда должна решить, как именно ограничивать и сокращать количество незавершенной работы. Здесь ключевую роль играет определение рабочего потока в команде.
Кто должен определять WIP-лимиты
Предположим, Скрам-команда использует Канбан, чтобы улучшить рабочий поток за счет визуализации и управления Бэклогом Спринта. Бэклог Спринта принадлежит Разработчикам, а значит, они должны определять и количество незавершенной работы.
Даже если Разработчики включили в свой поток Владельца Продукта, чтобы он проводил ревью и давал обратную связь, Бэклогом Спринта всё равно владеют разработчики. Они отвечают за доставку ценности.
Однако когда Скрам-команда использует Канбан более комплексно, в том числе для Уточнения Бэклога Спринта, именно она владеет рабочим потоком и уже ей надлежит обсуждать WIP-лимиты.
Можно ли менять WIP-лимиты в середине Спринта
Представим, что в середине Спринта появился важный элемент, который Владелец Продукта хочет добавить в Бэклог Спринта. Элемент согласуется с Целью Спринта, но команда уже взяла максимальное количество незавершенной работы.
Если команда решает вытянуть элемент в Бэклог Спринта, Разработчикам нужно понять, могут ли они начать работу над этим элементом сразу. Это зависит от ограничений и количества незавершенной работы в текущий момент. При перегрузе за новый элемент стоит браться, только когда освободится место. Если остальные элементы маленькие, место для нового слота освободится быстро. Если большие, какое-то время придется подождать. Чем больше времени нужно, чтобы освободить слот в Бэклоге Спринта, тем сильнее давление на команду.
Превышение WIP-лимитов и проталкивание элемента вверх называется экспедированием. Обычно в таких случаях ограничение не снимается — команда берет элемент и указывает, что было сделано исключение. Такие исключения — тема для инспекции и адаптации.
Когда адаптировать WIP-лимиты
В большинстве случаев корректировать WIP-лимиты следует во время Ретроспективы Спринта, чтобы подходить к этому стратегически, а не улучшать рабочий поток на ходу. Похожим образом команда работает с Критериями Готовности (DoD): она не меняет их во время Спринта только потому, что возникла проблема с готовым Инкрементом, а отмечает исключение, может быть, даже провал в создании Инкремента, и обсуждает его во время Ретроспективы.
При этом ничто не мешает команде корректировать WIP-лимиты в любой точке Спринта. Есть разница между тем, что можно делать, и тем, что следует делать.
Как ограничивать WIP
Последнее, что стоит отметить: команда может ограничивать количество незавершенной работы и для каждого участника, и для всей команды — по потоку или по времени. Пример такого ограничения: «Мы будем работать только над 10 элементами на этой неделе». Знакомо звучит?
Если хотите узнать о WIP-лимитах в Скраме еще больше, изучите Краткое руководство по Канбану и приходите на курс Professional Scrum with Kanban (PSK).
