Wip limit что это
Kanban.club
Канбан обычно связывают с ожиданиями по повышению пропускной способности системы. Канбан содержит простой, но мощный инструмент — ограничение количества незавершенной работы или WIP (work in progress) лимиты. В этой статье разберемся, как они работают, на примере отдельной операции. Во второй части мы разберемся как этот механизм работает при наладке производственной цепочки
Эксперимент с многозадачностью
Наверняка вы обращали внимание, что попытка делать несколько задач одновременно скорее приводит к тому, что все задачи делаются и дольше и хуже. Насколько именно? Проведем небольшой эксперимент с друзьями. Попросим одного из них (назовем его разработчик) переписать имена всех остальных друзей (заказчиков), по одному имени на каждой отдельной карточке. Заказчики записывают время начала и окончания работы на своей карточке с именем (более подробно можно посмотреть здесь https://www.crisp.se/gratis-material-och-guider/multitasking-name-game).
Это упражнение проводим дважды. В первом случае (многозадачный режим), разработчик пишет по одной букве для каждого заказчика, и каждый раз переключается между заданиями. Во втором случае (последовательный режим), разработчик выполняет задачу от начала до конца не переключаясь.
Результаты видны на рисунке (синий — первый вариант, оранжевый — второй):
Результат 1. Время, необходимое на завершение одной задачи в «последовательном» варианте в несколько раз меньше, чем в «многозадачном» (обратите внимание на длину оранжевых и синих отрезков)
Этот эффект нашел свое отражение в законе Литтла, который связывает средние значения времени пребывания задачи в системе, число задач в ней и пропускной способности (см рисунок)
Втягивая в систему большее число задач, мы как бы «размазываем» её мощность на большее число элементов и тем самым увеличиваем время выполнения каждого из них.
Результат 2. Время выполнения всей работы в «многозадачном» режиме существенно больше, чем в «последовательном» (обратите внимание на разницу между вертикальными красной и зеленой линиями).
Типичный разброс значений 1.5-3 раза. Это приводит к тому, что как правило заказчик получивший свой продукт в «многозадачном» варианте раньше других все равно проигрывает самому последнему заказчику из «последовательного» сценария
О чем это говорит? В обоих сценариях был проделан один и тот же объем работы — написано одно и тоже количество одинаковых имен. Различия только в способе организации работы. Оказывается, вечная «проблема» менеджеров «мы не можем сделать эту задачу, если у нас не будет новых ресурсов» имеет еще одну неожиданную грань — управляя числом задач, принимаемых в работу (т. е. управляя WIP лимитом), можно добиваться увеличения (и уменьшения) пропускной способности системы в разы.
Стоимость переключения между задачами сама по себе не бесплатна. Для человека она обычно составляет 10-15% при добавлении каждой новой, одновременно выполняемой задачи. Попытка делать 5 задач одновременно скорее приведет не к пятикратному замедлению выполнения задач, а к работе системы практически «в холостую», когда большая часть мощности будет тратиться на переключение контекста, а не на реальную работу.
Оптимальный WIP для рабочей группы
Проецируя эти выводы на рабочую группу, можно ожидать, что существует такое оптимальное значение WIP лимита, которое обеспечивает её наилучшую производительность. Выше или ниже этого уровня, система будет или не нагруженной или перегруженной. Для выбора оптимального значения WIP нужно учитывать как зависит время выполнения задачи и пропускная способность системы от него
От нуля и до момента «насыщения» системы работой, её пропускная способность будет расти с увеличением числа задач. По мере наполнения системы этот рост прекратится, и скорее всего даже сменится снижением (помните еще про стоимость переключения контекста?). Время выполнения задачи наоборот, до этого момента, будет постоянной (помните шутку про то, что девять женщин не родят за 1 месяц ребенка?), а затем начнется увеличиваться в соответствии с законом Литтла и внутренними потерями на переключение контекста.
Таким образом, можно ожидать, что оптимальное значение WIP будет находится вблизи этой границы.
WIP-лимиты здорового человека и WIP-лимиты курильщика
Я и мои коллеги по работе для внутренних сотрудников компании, в которой я работаю, периодически готовим небольшие статьи, где разбираем различные кейсы по гибким подходам, включая и кейсы использования Канбан-метода для совершенствования и управления процессами. Такие статьи мы называем «Agile-shorts». И я подумал, «А почему бы не открывать свои статьи и для более широкой аудитории?» И, вот, сегодня я публикую первую свою статью из этой серии.
Сегодня я расскажу один из кейсов, почему проваливается использование такой практики как «Ограничение количества незавершенной работы» или WiP-лимиты. Оговорюсь, что это не единственная причина, но, на моей практике, очень распространенная. В будущих статьях, я, возможно, раскрою эту тему дополнительными интересными ситуациями.
Мало кто, работающий в ИТ-сфере, не слышал про гибкие подходы к созданию продуктов. Слова Agile, Kanban, Scrum уже крепко проникли в лексикон современных компаний. Кто-то их произносит с гордостью, кто-то с иронией, а кто-то сквозь зубы.
Последние, вероятно, на своем опыте столкнулись с неудачным использованием какого-то управленческого инструмента, и спроецировали свой негативный опыт на все будущие идеи.
Но эта заметка не для них. Эта заметка для вас, тех, кто понимает, что инструменты можно использовать по-разному, а на ошибках готов учиться.
Ограничиваем Пользовательские Истории, а работаем с Подзадачами
Часто, познакомившись с основами практик и методов, которые используются в Agile-культуре, у людей складывается впечатление, что, нажав Ctrl+C и Ctrl+V, они у себя получат ту же замечательную вещь, которую они увидели в учебном кейсе. На деле же оказывается, что «Ctrl+V» приходится, как в анекдоте, тщательно дорабатывать напильником.
Визуализируя работу команды, неофиты часто совмещают на одном уровне задачи, которые несут ценность для Заказчика, с задачами, которые имеют ценность только внутри процесса. Почему, спросите, совмещают? В основном, потому что привыкли работать в парадигме – «мне поставили задачу – я делаю задачу – я сделал задачу», в которой для выполнения не обязательно задумываться о ценности: «Ведь начальник уже об этом сам подумал, раз отдает задачу в работу».
В итоге, на одном уровне управления можно встретить такие задачи:
Провести нагрузочное тестирование – не самостоятельная задача, а нужна для прогресса какой-то другой
Заключить контракт с поставщиком ХХХ – не самостоятельная задача, а нужна для старта работ по другой задаче
Реализовать функционал голосового ввода – пользователь получит новый функционал для использования
Что же делать, спросите вы? Ответ в том, чтобы разделить разные уровни управления и понимать, какую проблему мы решаем.
Какие бывают уровни:
Работа на уровне исполнения задач одним человеком.
Для снятия перегруза с сотрудника используются персональные лимиты. В этом случае рассматриваются взгляд исполнителя – на задачи смотрят со стороны сотрудника, который выполняет работу.
Работа на уровне команды. Для нормирования работы команды, используются:
лимиты на систему/команду/сервис (Бэклог спринта – частный случай лимита на систему)
лимиты на тип задач (Квотирование)
лимиты на этап (работа с узкими горлами)
и другие, более экзотические типы ограничений
В этом случае нужно смотреть на задачи глазами Заказчика работ. Появляется такой объект как Customer recognizable item – задача, смотря на которую, Заказчик понимает, что это именно то, что он заказывал, и видит, что происходит с заказом.
Работа на уровне портфеля
Для эффективного распределения ресурсов для реализации портфеля инициатив, используются лимиты на объекты портфеля.
Например, лимиты на Эпики, чтобы сфокусироваться на завершении какого-то направления, а не распыляться на всё сразу. Хотя, конечно, это уже вопрос маркетинговой стратегии. Или на инициативы портфеля инициатив – чтобы сфокусироваться на скорости проверки гипотез и, в свою очередь, выбрать именно те, что даст нам конкурентное преимущество.
Резюмируя эту заметку, хочется подчеркнуть три вещи, которые помогут вам избежать ошибок и получить положительный опыт:
Попробуйте понять, для чего нужен инструмент, и в каком контексте он работает
Осознайте проблему, которую вы хотите решить применением инструмента
Если что-то не получается, допустите, что это не инструмент плох, а есть что-то, что вы не учли
И тогда, разочарование от того, что «мы потратили кучу времени, а оно не работает», вас обойдет стороной.
Как снова привести работу в движение с помощью лимитов незавершенной работы
Лимиты незавершенной работы нужны совсем не для того, чтобы препятствовать работе. Как раз наоборот.
Просмотр тем
Что такое лимиты незавершенной работы?
Лимиты незавершенной работы (WIP) применяются в процессе agile-разработки, чтобы ограничить максимальное количество задач на каждом этапе рабочего процесса. Лимитируя объем незавершенной работы, вы можете обнаружить слабые места в рабочем процессе команды. Благодаря этому вы без труда выявите проблемы в потоке поставки продукта до того, как ситуация усложнится.
Почему лимиты незавершенной работы так важны?
Надеюсь, что теперь вам захотелось узнать подробнее.
Ограничения WIP повышают производительность команд и уменьшают количество «почти выполненных» задач, заставляя команды сосредоточивать усилия на меньших объемах работы. По сути, ограничения WIP вырабатывают у команды привычку выполнять работу до конца. Что еще важнее, они проливают свет на препятствия и проблемные места. Когда имеется некий индикатор, который однозначно указывает на проблемные места, команда может дружно штурмовать задачи, препятствующие дальнейшему продвижению работы, чтобы разобраться в них, выполнить и разрешить проблемы. После устранения препятствий работа в команде снова приходит в движение. Благодаря этому клиенты быстрее получают новые порции ценных изменений. Этим и важны ограничения WIP в процессе Agile-разработки.
В процессе разработки может появиться желание приостановить работу над текущей задачей и взяться за что-то другое. Когда открыты сразу две задачи, приходится переключать контекст или передавать работу коллегам. Переключение внимания с одной задачи на другую не проходит даром: на это тратится время и снижается концентрация. Практически во всех случаях лучше выполнить одну задачу до конца, чем взяться за новую работу и не завершить ее. Иными словами, ограничения незавершенной работы не дают нам тормозить собственный процесс.
Наконец, ограничения WIP помогают выявить случаи, в которых простой или перегруженность приобрели уже хронический характер. В результате команда может увидеть слабые места во всем процессе, а не только в отдельных областях работы.
Если команда раньше никогда не использовала лимиты незавершенной работы, они могут показаться неудобными. Поднимите вопрос о лимитах WIP в первых нескольких итерациях. Научитесь понимать, когда и почему команда достигает лимита незавершенной работы. На первых порах не поддавайтесь соблазну самовольно менять эти лимиты. Если лимит достигается на постоянной основе, значит, установлен слишком строгий лимит WIP или вы обнаружили слабое место в рабочем процессе команды.
Использование лимитов незавершенной работы в agile-командах
Теперь, когда вы осознали ценность лимитов WIP, можно перейти к сути дела.
При развертывании нового рабочего процесса обсудите всей командой, какое ограничение WIP нужно установить для каждого статуса. Прежде чем устанавливать ограничения, рекомендуем понаблюдать за несколькими спринтами и определить, сколько рабочих задач в среднем находится в каждом статусе. Ниже приведен пример Agile-доски с ограничениями WIP, которую использует обычная команда разработчиков ПО.
В примере выше для столбца Code review (Проверка кода) установлено ограничение незавершенной работы. Это ограничение превышено, поэтому фон столбца окрашен в красный цвет.
Поскольку задачи, перемещенные в столбец Done (Завершено), не требуют дополнительных действий, для него ограничение WIP не устанавливается. На доске выше статус Ready for dev (Готово к разработке) получают пользовательские истории, которые были тщательно проверены владельцем продукта и командой. Когда команда разработчиков приступает к выполнению рабочих задач, она переносит задачи из столбца Ready for dev в столбец In progress (В работе). Важно, чтобы в статусе Ready for dev всегда находилось достаточно задач. Так участники команды разработчиков будут задействованы максимально эффективно. При этом на этапе Ready for dev не должно быть слишком много историй, чтобы владелец продукта не ушел далеко вперед в тот момент, когда появятся новые требования, и чтобы программу было проще адаптировать к изменениям.
В статусе In progress находятся задачи, над которыми идет активная работа. Здесь ограничения WIP нужны, чтобы никто не сидел без работы и чтобы никто не занимался несколькими задачами одновременно. На доске, показанной выше, для задач в статусе In progress установлено ограничение в 4 задачи, и в этом статусе в настоящий момент находятся 3 задачи. Значит, команда может взяться за дополнительную задачу. В некоторых командах целесообразно выбирать такое ограничение незавершенной работы, которое было бы меньше числа участников команды. Это поможет подготовиться к внедрению надлежащих Agile-методик. Когда разработчик заканчивает работу над задачей и видит, что команда уже достигла ограничения WIP, он понимает, что пора выполнить несколько проверок кода или присоединиться к другому разработчику, чтобы заняться парным программированием.
В статусе Code review находятся истории, для которых код уже полностью написан, однако его требуется проверить, прежде чем выполнять слияние с базой кода. Своевременные проверки кода — лучшее средство для обеспечения высокого качества, ускорения вывода инноваций на рынок, упрощения слияний (открытых веток становится меньше) и обмена знаниями между участниками команды разработчиков. Приступать к работе на этой стадии следует как можно скорее по нескольким причинам.
Благодаря ограничениям незавершенной работы непроверенный код не будет накапливаться бесконечно.
Обратите внимание: на Agile-доске выше у команды скопилось слишком много задач по проверке кода, поэтому столбец окрашен в красный цвет.
4 цели для agile-команд, использующих лимиты незавершенной работы
Как и все новое, ограничения незавершенной работы могут поначалу показаться неудобными. В среднесрочной перспективе команда должна найти идеальный баланс, а в краткосрочной такое неудобство окажется даже на руку. Благодаря этому команда сможет увидеть слабые места в рабочем процессе. Поработав с ограничениями WIP в течение нескольких недель, можно будет при необходимости скорректировать их. Не поддавайтесь соблазну увеличить ограничение WIP просто потому, что команда постоянно его достигает. Не упустите возможность повысить производительность. Лучше всего делать это с помощью обучения команды и развития новых наборов навыков у каждого участника или через повышение эффективности в каком-то аспекте процесса разработки.
Цель 1. Научиться делить работу на отдельные задачи примерно равного объема. Разбивая на части требования и пользовательские истории, важно следить, чтобы на выполнение отдельной задачи уходило не более 16 часов. В итоге команда будет увереннее подходить к оценке сложности работы, и проблемных мест станет меньше. Ничто так не замедляет работу команды и не приближает ее к ограничениям WIP, как большая задача, препятствующая работе конвейера.
Если ограничения незавершенной работы выбраны командой правильно, время цикла для задачи снижается. Время цикла — это время, необходимое для выполнения задачи. Подробнее см. на нашей странице, посвященной показателям Agile.
Цель 2. Подбирать ограничения WIP в соответствии с навыками команды. В примере выше предполагается, что участники команды имеют схожий набор навыков. Если в команде есть специалисты, их участие может повлиять на ограничения незавершенной работы. Создайте отдельный статус для работы специалиста. Если в этом статусе будут возникать проблемы, используйте это как возможность пополнить набор умений участников команды навыками специалиста и повысить производительность всей команды.
Цель 3. Сократить простои. Если у какого-либо участника команды появилось свободное время, посоветуйте ему помочь коллегам на других этапах работы. Общая продуктивность команды повысится, а заодно и сотрудник чему-нибудь научится!
Цель 4. Сохранить здоровую культуру разработки. Ограничения незавершенной работы нужны не для того, чтобы разработчики спешили, опасаясь перегрузки на каком-либо этапе. Они нужны, чтобы поддержать устоявшиеся практики Agile-разработки, которые обеспечивают неизменное качество продукта и исправность базы кода.
Установка ограничений выполнения работы в Azure Boards
Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018–TFS 2013
Важнейшая практика канбана — ограничения на выполнение, которые называются «лимиты WIP» — ограничивает объем работы, которую команда будет выполнять на каждом рабочем этапе. Она предназначена для того, чтобы сосредоточиться на выполнении элементов перед началом новой работы. В первую очередь, интуитивно понятный счетчик, многие команды находят ограничения НЗП помогают повысить производительность и улучшить качество программного обеспечения.
Вы определяете ограничения WIP для каждого рабочего этапа, соответствующего каждому промежуточному столбцу. Ограничение устанавливает мягкое ограничение на число элементов, разрешенных в столбце. Ничто не предотвращает перемещение дополнительных элементов в столбец и превышение предела. На доске Канбан отображается количество элементов на каждом этапе рядом с каждым пределом.
При задании ограничений на WIP несложно соблюдать ограничения. Успешное внедрение ограничений WIP включает изменение языка и региональных параметров. Она перемещает команды в основное внимание на индивидуальную производительность для одной из рабочих групп.
Предварительные требования
Определение ограничений начального НЗП
Чтобы приступить к работе, необходимо, чтобы ваша команда определила начальные пределы НЗП, которые необходимо задать, а также их использование и отслеживание. Кроме того, несколько правил применяются к числу устанавливаемых чисел, так как они могут различаться в зависимости от нескольких факторов. Ниже приведены два руководства, которые помогут определить, какие ограничения следует задать.
Установите ограничения на основе текущих выполняемых операций. Подсчет элементов, имеющихся в существующих столбцах канбана.
Установите ограничения, которые не превышают два или три элемента на одного участника команды, работающего в пределах этапа. Например, если у вас есть три члена группы и каждый участник команды может работать с не более чем двумя задачами одновременно, то итоговый лимит НЗП равен 6 (= 3 разработчикам X 2 задачам и разработчикам).
С самого низкого уровня может помочь команде более быстро обнаруживать узкие места и выявлять проблемы, связанные с процессом.
После определения начального набора ограничений WIP, скорее всего, потребуется настроить их по мере продвижения проекта.
Не учитывать ограничения WIP
После настройки ограничений WIP необходимо отвестись от того, насколько хорошо ваша команда следит за ограничениями.
Соблюдение лимитов WIP означает, что команды не запрашивают элементы в столбец, если это приводит к тому, что число элементов в столбце превысит предел по столбцу. После этого ваша Доска Канбан немедленно предоставляет отзыв. Эта обратная связь должна действовать в качестве сигнала команде, чтобы немедленно сосредоточиться на действиях, чтобы сократить количество элементов в столбце.
Несмотря на то что простая в теории, хранение в пределах WIP может привести к принудительной работе отдельных пользователей, групп и организаций. Участники команды, которые наподобие многозадачности, могут быть ограничены. Другие могут найти себя без работы, если они ожидают завершения работы на вышестоящем этапе.
Выявление узких мест
Чтобы оптимизировать поток значений, необходимо точно выявлять и устранять узкие места. Узкие места указывают на то, что отходы существуют в общем рабочем процессе.
Отслеживая свою доску Канбан с течением времени, вы можете узнать, где возникают узкие места. Если несколько элементов находятся в столбце в нерабочее время в течение нескольких дней, возникло узкое место. Узкие места обычно возникают, если пределы WIP слишком высоки. Однако узкие места не могут означать, что ограничения НЗП слишком низкие.
Бесплатная электронная книга, Канбан и Scrum — большинство из нихпредоставляют следующие рекомендации:
Слишком низкое ограничение WIP = неактивные люди > = нехватка производительности>
Создание периодических моментальных снимков на вашей доске Канбан позволяет визуально систематизировать, где рабочие процессы плавно и появляются узкие места.
Такие моментальные снимки могут показывать вашу команду:
Устранение отходов
Поскольку узкие места придают слишком много ресурсов в рабочем процессе, вы захотите указать источник отхода. Канбан определяет отходы так, чтобы они не требовались для получения нужных результатов.
Распространенные отходы при разработке программного обеспечения включают:
Устранение незатратных вызовов для командных обсуждений для выяснения причин и решений, приемлемых для команды. Наряду с устранением проблем и решений, связанных с пределами WIP, группа может решить изменить их процессы или лимиты WIP.
Установка ограничений WIP
С учетом того, как вы будете использовать лимиты WIP, вы можете настроить их следующим способом. Если вы еще не сопоставили рабочий процесс команды со столбцами канбана, то сначала сделайте это. Сведения о доступе к доске Канбан см. в разделе основы канбана.
Откройте доску Канбан. Если вы не являетесь администратором группы, добавьте его в качествеадминистратора. Только администраторы команды и проекта могут настраивать доску Канбан.
После внесения изменений нажмите кнопку сохранить.
Откройте доску Канбан. Если вы не являетесь администратором группы, добавьте его в качествеадминистратора. Только администраторы команды и проекта могут настраивать доску Канбан.
После внесения изменений нажмите кнопку сохранить.
Откройте доску Канбан. Если вы не являетесь администратором группы, добавьте его в качествеадминистратора. Только администраторы команды и проекта могут настраивать доску Канбан.
TFS 2015,1 и более поздние версии
После внесения изменений нажмите кнопку сохранить.
TFS 2015
Установите ограничения WIP для каждого промежуточного столбца. 
Откройте доску Канбан. Если вы не являетесь администратором группы, добавьте его в качествеадминистратора. Только администраторы команды и проекта могут настраивать доску Канбан.
Установите ограничения WIP для каждого промежуточного столбца.