Wip limits что это
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-лимит (work in progress) в жизни, в работе, в семье
WIP-лимитирование — уникальное явление, которое можно описать одним предложением: «Сделай больше в будущем, сделав меньше прямо сейчас».
Ограничение побуждает закончить задачу до того, как перейти к другой. Именно это качество делает work-in-progress ограничение таким привлекательным в Agile и Kanban методологиях. При этом используют его как в бизнес-сфере, так и для достижения личных целей.
Что такое WIP?
WIP (аббревиатура от Work In Progress) — работа, которая представлена (W.I.P. — Work In Progress), но не закончена, и ожидающая продажи (например, в случае с продуктовым бизнесом).
Так могут обозначаться рисунки, модели, эскизы, концепт-арты; самый известный пример Work-in-progress — презентационная модель NeXT Computer, представленная в 1988 году Стивом Джобсом. Внешне готовое изделие, оно представляло из себя по сути коробку с запрограммированными действиями, и именно поэтому прошёл год между презентацией и выпуском в продажу первых сборок.
Уменьшение WIP — это одна из ключевых целей производственного менеджмента.
Ведь незавершенные изделия требуют место для хранения, несут риск истечения срока годности или актуальности продукта, не дают возможности инвестировать дальше вложенный в производство капитал.
Роль WIP-лимитов в производственном процесе
Одно из пяти ключевых практик канбана по мнению Дэвида Андерсона, автора книги «Канбан: Альтернативный путь в Agile» — ограничение числа незавершенных задач. Выбор WIP-лимитов становится важным и должен разрабатываться не в одностороннем порядке, а с привлечением всех участников проекта. WIP-лимит учитывается при создании новых задач или переходе на другие этапы в планировщике задач.
Различают три основных концепции построения WIP-лимитов:
WIP-канбан
С помощью WIP-лимитов можно во время самого рабочего процесса выявить организационные проблемы, дисфункции, искать решения и тут же применять их на практике. Культура постоянного самосовершенствования как одна из основ канбана невозможна без введения ограничений.
Возьмём для примера популярный медицинский центр. Звонки для записи идут на протяжении всего дня, но администраторы, которые не хотят задерживаться на работе, прекращают запись клиентов после 16:00. Недовольны все: врачи, вынужденные уделять меньше времени пациентам, клиенты, ожидающие своей очереди, администраторы, о работе которых негативно отзываются врачи и пациенты.
Что можно сделать? За основу берём WIP-лимит в 6 человек. Это значит, что как только в приёмной собирается 6 пациентов, происходит следующее:
Очередей нет, пациенты довольны, медицинский центр получает позитивные отзывы в сети.
Что произойдёт, если мы вдруг откажемся от WIP-лимитов:
WIP-лимиты в повседневной жизни
В 1927 году советский психолог Блюма Зейгарник описала интересный феномен: когда мы завершаем задачи, то чувствуем приближение к цели и двигаемся дальше. В противном случае мы думаем о незавершенных действиях, подсознательно или сознательно нуждаемся в их выполнении. «Эффект Зейгарник» стал одним из краеугольных камней гештальт-психологии.
Современные исследования механизмов работы памяти продвинулись еще дальше. Вот что будет если выполнять одновременно несколько задач:
Одна из самых известных техник WIP-лимитирования как в личной жизни, так и в отдельных видах работ — Pomodoro, придуманная Франческо Цирилло в конце 80-ых. Метод назвали в честь кухонного таймера в виде помидора (а не потому что помидор можно разрезать на несколько частей, как и время работы над задачей).
Схематично это выглядит так:
Цикл повторяется до полного завершения всех задач. Самое важное при этом не отвлекаться во время рабочих периодов, а если не удалось удержаться — начать считать «помидоры» заново. Также по совету автора техники больше 16 «помидоров» в день лучше не использовать.
Мы сталкиваемся с work-in-progress ограничениями чаще, чем думаем. Например, бегун на длинные дистанции хочет улучшить свои показатели. Он начинает бежать быстро, но замедляется в конце дистанции. Изначально взяв более медленный темп бега (в этом случае аллюр будет формой WIP-лимита) у него будет стабильная скорость и запас энергии, достаточный чтобы пробежать всю дистанцию быстрее, без остановок. Для этого достаточно будет совершить парадоксальное: замедлить бег в начале гонки!
Ограничение работы одним проектом означает
WIP-лимит в 1.
Избегание назначения двух встреч
в одно и то же время — аналогично.
Личный или корпоративный бюджет — WIP-лимит денег. Чем меньше денег тратите на безделушки, тем больше сможете потратить на здоровую и вкусную еду. Регулирование трат поможет накопить деньги, а выплата кредита в банке избавит от необходимости доплачивать проценты.
Как высчитать WIP-лимит?
Рассмотрим расчёт на примере компании Corbis. В 2006 году было принято решение о том, что аналитики, разработчики и тестировщики должны работать над одной задачей одновременно. При этом новые проекты часто были такими большими, что один человек параллельно работал над двумя-трёмя заданиями. Сами же задачи могли откладываться или блокироваться, а значит WIP-лимит нужно было задать с таким расчётом, чтобы над 1 задачей работало 2-3 человека с возможность перекрытия задач.
WIP-лимит = 10:2+S, где S — «амортизационное» количество людей для нивелирования эффекта от блокировки задачи. Таким образом, work-in-progress-лимит составит 5+3 = 8.
Это число и есть то среднее количество элементов на двух человек, которые работают над единым проектом.
Но сводить ограничения к механическому расчёту будет неправильно. Вместо борьбы с мультизадачностью и организации бесперебойности рабочего процесса жёсткие WIP-лимиты могут привести к простою, стрессам, снижению общей эффективности работы. Чем неопытнее организация и меньше её изначальный уровень продуктивности, тем более свободные ограничения стоит вводить.
Эта проблема поднимается в эффекте J-кривой. При изменении WIP-лимитов на графике производительности в канбан появляется фигура, похожая на букву J, и чем более жёсткие ограничения, тем сильнее эффект. Кстати, это может привести к мысли о негативном характере канбана и проектный менеджер примет ошибочное решение.
При этом WIP-лимиты не являются чем-то стабильным, они должны подвергаться изменениям с учётом роста мощностей, смены формата задач, увеличения квалификации проектной команды и т.д.
Хороший, плохой, правильный WIP-лимит
Чересчур маленький лимит WIP:
Чересчур высокий лимит WIP:
Оптимальный лимит WIP:
ТОП-литературы о WIP-лимитах
Вердикт
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-разработки, которые обеспечивают неизменное качество продукта и исправность базы кода.