К недавней заметке «Эксперименты с Kanban, визуализацией и потоком создания ценности» Олега Скрынника хотел бы добавить пару соображений по поводу разработки канбан и разницы между канбан и картой потока создания ценности.
1.
При формировании структуры доски канбан нередко на первых шагах получают некое подобие списка задач со статусами выполнения. На самом деле, как описал Олег, канбан используется в том числе для того, чтобы организовать производство вытягивающего типа.
Собственно для этого исходно (на производстве Тойота) и была разработана система Канбан. Это система карточек, используемых для сигнализации о том, что нужно произвести перемещение продукции или материалов/комплектующих между участками производственной цепочки. По завершению или приближению к определённому порогу производства на одном участке, сигналим предыдущему участку: «Пора производить очередную порцию, чтобы подать её на скоро освобождающийся участок, который следует за вашим». Такой механизм позволяет построить систему производства «точно-во-время (just-in-time, JIT), минимизируя складские запасы и повышая скорость выпуска продукции.
Поэтому одним из проверочных вопросов, который нужно задать при разработке канбан является следующий: «Каким образом наш канбан обеспечивает возможность для каждого этапа процесса максимально оперативно получать, когда это понадобится, на свой вход результат с предыдущего этапа?»
Возможно, помня о том, как появилась система Канбан, вы будете помнить про эту задачу.
2.
Довольно часто в литературе встречается подход, согласно которому канбан – это и есть визуализация потока создания ценности. Хотя в оригинале (производственная система Тойота → бережливое производство/Lean) есть два инструмента визуализации: канбан и карта потока создания ценности (value steam map, VSM). Разумеется, ничто не мешает использовать канбан для визуализации потока создания ценности. Но в чём всё-таки разница?
Канбан, в отличие от карты потока создания ценности не визуализирует потери времени. Именно поэтому для оптимизации потока обычно используется VSM, а основной параметр контроля эффективности – отношение времени, в течение которого в потоке выполнялась полезная работа ко всему времени затраченному на производство (большая часть которого обычно – это ожидание. В реальном производстве, кстати, коэффициент эффективности, рассчитанный таким образом, часто составляет единицы(!!!) процентов).
И, наоборот, в классической карте потока (VSM) не указывается ограничение на максимальное количество задач, одновременно находящихся в работе (work in progress, WIP). Точнее, ограничение всей системы мы можем определить по точке в потоке, имеющей минимальную производительность. Но, например, в DevOps идея ограничения количества задач, находящихся в работе обусловлена не только стремлением увеличить скорость прохождения задачи по всему процессу, но и желанием зарезервировать ресурсы под неплановые задачи (например, решение инцидентов). И канбан позволяет наглядно задать такие ограничения WIP как общие, так и по каждой категории задач. Кроме того канбан – это инструмент, который может быть использован для улучшения любого процесса и любой части потока создания ценности.
Понятно, что ничто не мешает модифицировать и канбан и карту потока создания ценности (VSM) для того, чтобы они отображали то, что нам нужно и как нам нужно. Набор правил формирования канбан минимален, в остальном – полная свобода творчества. Например, на проведённой на прошлой неделе нашим замечательным DevOps Master’ом игре «Проект Феникс» команда модифицировала канбан, превратив доску из привычного настенного варианта в настольный (см. фото).
При этом коллеги настолько овладели подходом «поток в одну задачу» (one piece flow), что под конец игры второй ряд столов уже не использовался.
Круто! Прям мозги мне эта информация отформатировала)