6 заметок с тегом

wiplimit

Задавались вопросом: на каком уровне поставить WIP лимит?

Для меня этот вопрос сопоставим с вопросом: кому проще поставить диагноз аппендицит пациенту студенту медицинского институра первого курса или последнего? Конечно студенту первого курса — он еще так мало знает :)

Так же и с WIP лимитом: для эксперта тут столько подводных камней, что из универсальной рекомендации я бы посоветовал — сделайте так, чтобы ситуация хотя бы не ухудшалась — WIP не должен увеличиваться. Берите столько работы сколько выходит из системы. Постепенно вам будет некомфортно и это может спровоцировать экспериментирование и эволюционные изменения. И на всякий случай, заручитесь поддержкой Канбан Коуча :)

2022   WIP   wiplimit   уровень

Эффективность потока

Первое, с чего стоит начать, чтобы измерять эффективность потока, очевидно, что нужен поток. Упрощенно, поток можно разделить на следующие этапы:

  1. Работа которую возможно надо делать, но по ней мы не дали обещания, что ее сделаем (еще ее называют Backlog)
  2. Запланированная работа, которую мы уже пообещали сделать, но ее не приступили к ней (To do)
  3. Работа над которой работаем (in Progress)
  4. Сделанная работа, по которой наши обещания исполнилось (Done)

Обратите внимание на первый пункт: это список работ, где есть элементы работы, которые не надо делать никогда. И здесь нужно учитывать контекст, где ваш поток находится. Если это ресторан, то людей, которые находятся в очереди на входе в ресторан вы не обязаны обслужить всех и более того, можете выбирать кого обслужить, а кого нет. Например, соответствует вашему дресс-коду или нет. (вспоминаем про  конкурс красоты ) Если вы техническая поддержка или служба оперативного реагирования, то вам нужно обслужить все запросы и как можно скорее. В этом случае, у вас нет пункта backlog и вся работа сразу попадает в To Do, а это значит, что вы по ней уже дали обещание (SLA договоренность об уровне сервиса) и время для клиента начинает тикать моментально.

Давайте подумаем, а как мы вообще начали думать об эффективности потока?

Бизнес всегда думает об эффективности, и первая эффективность которой легче всего управлять — это эффективность использования ресурсов. Т. е. мы должны следить, чтобы у всех людей обе руки были заняты и чтобы все станки в цеху, столики в ресторане, операторы в колл-центре и т. д. были в работе 100% (или близко к этому) времени, в реальности получается 75-80%, остальное уходит на перерывы, покурить, ненужные встречи и т. д.

Что мы получаем в итоге: у нас все люди заняты и много недовольных клиентов, потому, что для них время ожидания в очереди или в процессе обслуживания очень большое, которое их явно не устраивает.

Обычно, следующий шаг — это увеличить количество людей (аналитиков, поваров, кассиров, программистов и т. д.), так как кажется что именно в этом вся проблема. СТОП. Если вы пришли к этой точке, то это тот самый момент, когда пора подумать, а что же у нас с эффективностью потока?

Формула подсчета Эффективности потока

Подсчет эффективности потока делается следующим образом:
Эффективность потока (в %) = Время работы / (Время работы + Время ожидания)
Где,
Время работы = Времени, когда карточка находилась в колонках вида “В работе” (т. е. когда создавала ценность) минус время, когда в них карточка была заблокирована
Время ожидания = Время блокировки плюс Время, когда карточка находилась в колонках вида “Готово”, “Закончено”, “Сделано” плюс Время в бэклоге (если наши обязательства распространяются на колонку Бэклог)

Обычная эффективность около 15%, т. е. 85% времени с элементом работы никто не занимался.

Чтобы подсчет эффективности потока стал возможен нам потребуется визуализация, как минимум в виде канбан-доски и сбор статистики по выполненным элементам работы.

Эффективность ресурсов и эффективность потока — это две стороны одной медали. Мы привыкли фокусироваться на активную составляющую нашей работы: написание автотестов, обучение сотрудников, выстраивание devops трубы, качество приготовляемой еды на кухне, скорость работы кассира и т. д. Это все правильно, но работа только на этим может быстро перестать давать положительный эффект и каждым новым уровнем улучшения стоит дороже, но и есть темная сторона: это время, когда мы просто ждем и природа этого времени может быть разной: зависимости, смена приоритетов, ожидание следующего этапа, блокировки и т. д.

То, что задача находится в работе и то, что над ней кто-то работает не одно и тоже, и Эффективность потока показывает как часто это бывает правдой.

Очевидно, что нужно сбалансировать эффективность потока и эффективность ресурсов

Для начала посмотрим о чем нам говорит закон Литтла:

Т. е. при сохранении скорости потока (сколько элементов работы выходят из нашей системы в единицу времени), мы можем сократить среднее время выполнения за счёт того, что сократим количество одновременно выполняемой работы. К чему это приведет: заказчики встанут в очередь и кому-то из них нужно говорить “нет” или “подожди”, а некоторые сотрудники будут простаивать, ведь при меньшем количестве работы ее может на всех не хватить и это хорошо.

Дальше, мы должны убедиться, что мы рассматриваем единую систему создания ценности (в начале, в конце или с обоих концов должен быть внешний клиент) — это поможет нам избежать ловушки локальной оптимизации. И вот только теперь мы начинаем смотреть на корневые причины возникновения этапов “Ожидания”, делаем эксперименты по уменьшению времени ожидания и подбор лимитов незавершенной работы (об этом можно почитать:
WIP лимиты — часть 1
WIP лимиты — часть 2 ) .

Еще видео о ловушке утилизации ресурсов

PULL или PUSH?

Представьте, что вы отвечаете за организацию цепочки поставок и продаж в продуктовом магазине. Давайте для определенности считать, что речь идет об вкусных йогуртах. У вас есть производитель, поставляющий определенный объем продукции, есть склад (ну очень бОООльшой) и обычная магазинная витрина, откуда покупатели разбирают упаковки к себе в сумки. Она имеет конечный размер и может разместить сравнительно небольшое число упаковок продуктов. Как бы вы договорились с поставщиком об объемах регулярных поставок?

В этой системе есть WIP лимит, определяемый размерами самой витрины. Больше, чем она может вместить, ничего выложить не получится (просто некуда). Если поставлять продуктов меньше, чем раскупается, то на полке периодически не будет ничего, а значит будет потеряна прибыль и клиенты (кому понравится магазин, где ничего нет). Если заранее заказать больше упаковок, чем можно продать, скажем, за день, то складские остатки начнут увеличиваться и, как минимум, «заморозят» свободные деньги или, как максимум, со временем продукты испортятся. Важно сделать так, чтобы скорость поставок была синхронизирована со скоростью потребления.

Конечно можно попытаться компенсировать рост поставок, выкладывая в торговый зал больше упаковок (например на пол, соседнюю витрину). Однако поднимать таким образом продажи это тоже самое, как добавлять в принтер больше бумаги, в надежде на увеличение скорости печати. У системы есть свойственная ей скорость (потребления, печати и др. ), которую нельзя бесконечно стимулировать «впихивая невпихуемое». Этот подход называется проталкиванием (PUSH) когда в систему сначала «закачивают» элементы работы, а потом думают, что с этим делать.

Альтернативным вариантом является «вытягивающася» система, которая в 50е годы была подсмотрена начальником механического цеха компании Тойота Тайити Оно во время его поездки в США. По его воспоминаниям идея вытягивания (PULL) в магазине как раз в момент осмотра подобной витрины. Этот человек (к слову создатель Toyota Production System) обратил внимание, что система работает в обратную сторону: вначале покупатели разбирают продукты на полке, а уже потом сотрудники магазина пополняют со склада ровно столько, сколько было куплено за день и на основании этих данных делают заказ на склад. По его возвращении на родину этот принцип лег в основу работы с Канбан доской: вначале проверяются те элементы работы, которые расположены как можно ближе к концу процесса и только после освобождения соответствующего WIP лимита переходим к предшествующим этапам (прямо как в игре в «пятнашки»). Другими словами перед тем как начать делать что-нибудь нужное, сначала завершить то, что вам казалось нужным нужным до этого.

Принцип вытягивания нашел свое отражение не только в Канбан. Его следы также видны и в SCRUM. Так в Планировании Спринта Команда разработки сама прогнозирует задачи, которые могут быть сделаны в предстоящем спринте (вытягивание), а не автоматически получает их от Владельца продукт согласно заранее предопределенному «нормативу» или текущей необходимости (проталкивание).

Вытягивание, в принципе настроено на поддержание командой её естественного ритма, когда нет авралов и переработок (состояние потока). Конечно иногда бывают моменты когда нужно «поднажать» и достигнуть краткосрочных целей. Но принцип вытягивания помогает соответствовать долгосрочной цели, которая лучше всего написана в тексте манифеста Agile разработки программного обеспечения: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно».

2018   pull   Push   wiplimit   ДенисСоколов

WIP лимит — часть 2. Выравнивание потока

В прошлый раз ( http://kanban.club/all/wip-limit/ ) мы говорили о применении WIP лимита в качестве инструмента для управления производительностью отдельного этапа конвейера. Теперь поговорим о том, как WIP лимит можно использовать для настройки всей производственной цепочки.

Представьте, что ваша производственная система похожа на конвейер, чей технологический процесс содержит несколько этапов. Допустим, что каждый из его участков работает в соответствии с WIP лимитами, настроенными так, чтобы каждый из них находился на максимуме своей пропускной способности. Означает ли это, что теперь конвейер работает как надо? Не совсем.

В любой реальной системе пропускная способность отдельных этапов различается и сама по себе является переменной величиной. Практически наверняка в такой системе перед местами с наименьшей пропускной способностью начнут формироваться очереди. Это обстоятельство имеет сразу несколько негативных сторон:

  1. рост времени обработки. В соответствии с законом Литтла, который мы обсудили в первой части, время нахождения элемента работы в системе прямо пропорционально числу таких элементов. Например, чем больше статей одновременно вы пишите в kanban.club, тем дольше будет писаться каждая из них по отдельности:)
  2. потеря актуальности/порча элементов работы/хранение из-за долгого нахождения в очереди. Это может быть что угодно: от бизнес требований заказчика до парного молока.
  3. снижение оборачиваемости капитала. Любое незавершенное производство означает, что потраченные на него деньги еще не скоро вернутся в компанию. При этом не стоит забывать, что деньги сами по себе тоже имеют стоимость в виде процентной ставки по банковским кредитам.
  4. скрытые проблемы производства. Наличие внутренних очередей затрудняет диагностику проблем. Например, если в ней есть элемент работы, содержащий дефект, то выявить их удастся только тогда, когда до такого элемента работы дойдет очередь обработки. Все это время ожидания проблема будет находиться без решения.
  5. отложенная прибыль. Чем позже мы получим продукт, который можно продать на рынке, тем меньше мы получим прибыли, не так ли?

Но можно ли избежать таких «узких мест»? Они есть в любом реальном конвейере и их наличие говорит о том, что конвейер скорее жив, чем мертв. Вопрос не в том, как их избежать, а как научиться с ними работать.

Пропускная способность всей системы ограничивается самым узким местом этой системы (см рисунок). Попытка выжать максимум на каждом этапе конвейера приведет только к потерям из за формирования ненужных очередей. Как это ни парадоксально, но работа на 100% загрузки вне узкого места может приносить вред, а не пользу.

Делать ей было совершенно нечего, а сидеть без дела, сами знаете, дело нелегкое. Алиса в стране чудес (Льюис Кэрролл)

Такое случается, когда каждый этап конвейера сфокусирован на оптимизации своей работы без оглядки на вопрос «как это выглядит с точки зрения всей системы?». Это носит название «локальная оптимизация» и является распространенным примером, когда «добрыми намерениями, дорога в ад выстроена». Каждый элемент производственной системы должен производить скорее не «столько, сколько может», а «столько, сколько нужно». Идеальная система должна уметь перераспределять избыток мощности на те участки, где она необходима. Вот где концепцию T-shaped people сложно переоценить.

Алгоритм «настройки» такой системы может проиллюстрировать на примере Пяти Направляющих Шагов Теории Ограничений Элияху Голдратта (см. Eliyahu M. Goldratt, Jeff Cox. The Goal: A Process of Ongoing Improvement):

  1. Найти ограничение системы. Узкое место, перед которым формируются наибольшие очереди нашего конвейера и будет тем самым ограничением системы, с которого мы начнем настройку.
  2. Решить, как максимально использовать ограничение системы. Помните сколько стоит простой системы в узком месте? Следовательно именно здесь нам важно вывести участок на «пик формы». Механизм нам уже известен из предыдущей статьи — нужно подобрать значение WIP лимита при котором этот этап конвейера обладает максимальной пропускной способностью, но при этом сохраняет приемлемое значение времени обработки. По сути узкое место будет единственным участком, где мы сознательно добиваемся максимума утилизации ресурсов. Безусловно использование WIP лимита не отменят использования любых других доступных и приемлемых для вас средств оптимизации в этом месте.
  3. Подчинить все остальное этому решению.
    В отличие от предыдущего этапа все участки конвейера до узкого места должны производить только то количество работы, которое может быть обработано узким местом. Для этого WIP лимиты на эти участках должны быть «зажаты», чтобы не формировались запасы незавершенного производства. Обратите внимание, что на этих этапах окажутся недоиспользованные ресурсы (ведь там раньше был избыток мощности, верно?). Не беспокойтесь, мы подумаем и об этом :)
    Помните мы говорили, что пропускная способность это переменная величина? Узкое место — не исключение. Для компенсации таких колебаний перед ним можно предусмотреть небольшую очередь, которая будет буфером, обеспечивающим узкое место работой если в нем появится избыток мощности.
    А что будет на участках после узкого места? Их пропускная способность заведомо выше и следовательно наша цель здесь уменьшить WIP лимиты, обеспечив быстрое время обработки и высвободив «лишние» ресурсы
  4. Расширить ограничение (ограничения) системы. Теперь, когда система функционирует без внутренних запасов, дополнительный рост пропускной способности можно сделать либо улучшив технологию обработки в узком месте, либо перераспределив «избыточные» ресурсы, освободившиеся в предыдущем этапе в узкое место. Лучше делать и то и другое.
  5. Вернитесь к шагу 1. Поздравляю, теперь Вы получили настроенную систему, но так ли это на самом деле? В результате наших действий система поменялась. Теперь узкое место может переместиться, а значит процесс улучшения будет циклическим.

Вы можете не изменяться. Выживание не является обязанностью. Э.Деминг

WIP лимит — часть 1. Особенности погони за семью зайцами.

Канбан обычно связывают с ожиданиями по повышению пропускной способности системы. Канбан содержит простой, но мощный инструмент — ограничение количества незавершенной работы или 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 будет находится вблизи этой границы.

Ждите продолжения и оставайтесь с нами! ))

Продолжение http://kanban.club/all/wip-limit2/

Из чего состоит канбан-доска

Друзья,

для того, чтобы рассказать о сложных вещах, давайте сначала обсудим простые. И для этого ответим на вопрос: что чаще всего можно встретить на большинстве канбан-досок?

  1. Колонки. Вертикальные столбцы со всеми значимыми статусами, которые соответствуют этапам в работе создания ценности (To Do, In Progress, Done)
  2. Swimline (Плавательные дорожки) Желтая область, которая показывает горизонтальный путь движения работы (цвет выбран в целях наглядности и не является обязательным)
  3. WIP Limit (Ограничение незавершенной работы): Сверху («не больше, чем») — красные цифры 5 и 7, Снизу («не меньше чем») — зеленая 2, для swimline — красная 1
  4. Space (Свободная область), которая служит сигналом для втягивания новой работы в систему или с предыдущего этапа работ
2018   board   space   swimline   wiplimit