Система Канбан начала свое путешествие в 1950‑х годах на производственных линиях Toyota, после чего она перешла в офисы и стала важным инструментом для менеджеров проектов.
Безграничная гибкость практики и ее способность самоорганизовывать персонал обеспечивали эффективность там, где другие подходы не работали. В этом случае визитной карточкой системы стал сам «канбан» — он утвердился как внутренняя валюта в организациях, которые внедрили Канбан.
Происхождение
Как и концепция Lean-производства, система Канбан была разработана менеджерами Toyota. Автор системы, японский инженер Таиити Оно, был вдохновлен принципами работы американских супермаркетов, где клиенты сами выбирали необходимые им товары. Роль «супермаркета» в Toyota выполнял склад.Там обменивались сигнализационными карточками — именно это и означает «канбан» в дословном переводе с японского — которые передавались между работниками, которые вручную регулировали производственный процесс.Карточки прикреплялись к ящикам с деталями. Такие ярлыки указывали информацию о номере детали и количестве, какой отдел отправляет их, и куда они должны прибыть.
Рабочий, непосредственно занимающийся сборкой машин (« downstream »), забирал детали из ящика, к которому была прикреплена карточка «канбан», запрашивающая пополнение. Карточка снималась и передавалась вместе с пустым ящиком транспортеру на склад. Там другой рабочий готовил новый ящик с запасными частями, к которому прикреплялась производственная карточка «канбан» — ярлык с информацией о произведенных запасных частях.
Производственный «канбан» заменялся «канбаном», запрашивающим пополнение, и отправлялся на линию производства запасных частей — « upstream ». Таким образом, точно такое количество деталей, какое указано на карточке, производилось. Ящик с новыми запасными частями помещался транспортерами на сборочную линию.
Принципы Канбан
Менеджеры Toyota отметили 6 формирующих правил системы:
- Работники из «downstream» извлекают ровно столько деталей из запасов, сколько указано на канбане
- Работники из «upstream» также поставляют детали строго согласно карточкам
- Ничего не производится и не перемещается без канбана
- Канбан всегда должен быть прикреплен к деталям
- Бракованные детали не используются в системе
- Сокращение количества карточек канбан делает управление более чувствительным к изменениям. Но без крайней необходимости изменять установленное количество карточек нецелесообразно.
Канбан — это система «вытягивания». Она создает баланс между постоянным потоком, который исключает затраты на ожидание, и минимальным количеством дел в работе (WIP), что снижает риски перепроизводства. WIP регулируется с помощью карточек: их количество фиксировано, а инструкции в них направляют работников «downstream».
Лимит WIP зависит от количества карточек канбан, которое рассчитывается на основе уровня продаж и статистической вариабельности в текущих процессах. Максимальное количество ярлыков — «энергия» в системе — обеспечивает верхний уровень WIP в любой момент времени. WIP также ограничивается принципом вытягивания: скорость производства «upstream» зависит от рабочей скорости «downstream».
График показывает, что одним из базовых элементов системы является культура Кайдзен. Автономные процессы и стандартная вариабельность освобождают управление от постоянного контроля, тем самым позволяя сосредоточиться на повышении производительности сотрудников.
Применение Канбан в ИТ
Система Канбан, продолжая приносить пользу на производственных линиях, проникла в область программного обеспечения.
Теперь карточки, которые содержат информацию о сроках, описаниях или номерах процессов и имени исполнителя, прикрепляются не к ящикам с запасными частями, а к доскам с разделенными колонками:
- Backlog — задачи, которые необходимо выполнить
- Задачи, находящиеся в разработке
- Задачи, завершенные, но еще не переданные тестировщикам
- Задачи, готовые к передаче в тестирующий отдел
- Задачи, которые проходят проверку у менеджера проекта (PM)
- Завершенные задачи
Число обычно пишется над колонками — лимит, что указывает максимальное количество процессов в ней. Лимит для backlog рассчитывается в зависимости от времени выполнения. Если в системе 5 рабочих процессов, и среднее время выполнения каждого — 1 день, backlog может быть ограничен до 5.
Структура выше не является строгой — в зависимости от специфики проекта могут быть добавлены импровизированные колонки. Система Канбан может часто потребовать определения критериев готовности задачи перед выполнением. В этом случае появляются две колонки, в английском называемые specify (уточняющие параметры) и execute (выполнение работы).
- Кроме того, может быть добавлена колонка с приоритетным очередью. Когда исполнитель становится свободным, ему необходимо сначала очистить эту колонку от задач перед тем, как взять другие.
- Задачи, которые не были выполнены, либо возвращаются в backlog, либо вычеркиваются из схемы.
- Канбан не поощряет многозадачность, тем самым ограничивая количество процессов для каждого исполнителя.
- Завершенная работа лучше, чем несколько начатых задач.
- Вторую работу можно взять, если первая заблокирована.
- Время на выполнение задач должно быть сбалансировано. Слишком короткий срок может повлиять на качество. Чрезмерно продленный лимит сжигает ресурсы команды и увеличивает затраты на процесс.
Почему Канбан-доска используется повсюду вместо, например, планшетов или больших мониторов? Сторонники системы отвечают на этот вопрос, утверждая, что обычная доска имеет два преимущества: она проста и обеспечивает визуальный контроль. На ней легко вносить изменения, и она поощряет тактильное и социальное взаимодействие среди членов команды.
Преимущества и недостатки Канбан
У Канбан следующие преимущества:
- Гибкость в планировании. Команда сосредоточена исключительно на текущей работе, приоритет задач устанавливается менеджером.
- Высокая вовлеченность команды в процесс разработки. Благодаря регулярным встречам, прозрачности процессов и возможностям для самоорганизации сотрудники объединяются и проявляют искренний интерес.
- Сокращение продолжительности цикла. Если необходимые навыки обладают несколько человек, продолжительность уменьшается; если только один человек владеет ими, возникает узкое место. Поэтому сотрудники должны делиться знаниями, оптимизируя продолжительность цикла. Это позволяет всей команде работать над застрявшими задачами и восстанавливать плавный поток.
- Меньше узких мест. Ограничения WIP позволяют быстро выявлять узкие места и проблемные области, возникающие из-за отсутствия сосредоточенности, рабочей силы или навыков.
- Видимость. Когда все исполнители имеют доступ к данным, легче заметить узкие места. Команды Канбан, помимо самих карточек, обычно используют два общих отчета: контрольные графики и кумулятивный поток.
На практике система показывает отличные результаты в неосновных производственных областях:
- группы поддержки программного обеспечения или службы поддержки.
- Канбан хорошо работает в управлении стартапами без четкого плана, но с активным развитием.
У Канбан также есть недостатки:
- система плохо работает с командами более 5 человек
- не предназначена для долгосрочного планирования.
Различия со Scrum
Scrum, как и гибкий Канбан, является гибкой методологией, которая также часто применяется в сфере ИТ. Различия между ними на первый взгляд не очевидны. Существует множество схожестей, например, наличие backlog в обоих подходах.
Scrum | Канбан | |
Темп | Повторяющиеся спринты фиксированной продолжительности | Непрерывный процесс |
Результат релиза | В конце каждого спринта после утверждения менеджером проекта (владельцем продукта) | Поток продолжается без перерыва или по усмотрению команды |
Роли | Владелец продукта, мастер Scrum, команда разработки | Команда, возглавляемая PM; в некоторых случаях участвуют тренеры гибкого Канбана |
Ключевые метрики | Скорость команды | Время выполнения |
По поводу приемлемости изменений | Во время спринта изменения нежелательны, так как они могут привести к неправильной оценке задач | Изменения могут происходить в любой момент |
Примеры применения в ИТ
Прямо от Microsoft: Дебют Канбана в разработке программного обеспечения
Использование принципов Канбана в информационных технологиях началось чуть более 10 лет назад. Дэвид Андерсон, один из главных промоутеров Канбана для разработчиков программного обеспечения, проконсультировался с Microsoft в 2005 году. Они были недовольны производительностью своего отдела — XIT Sustained Engineering, который исправлял ошибки в внутренних приложениях. К началу отчетного года этот отдел был худшим в своем подразделении. Объем backlog превышал допустимый размер в пять раз, а время выполнения одного запроса обычно составляло пять месяцев.
Новый PM, с консультациями Андерсона, увеличил продуктивность проблемного отдела на 155% за девять месяцев. Время выполнения теперь составляло пять недель, объем backlog вернулся к нормальному размеру, а своевременное выполнение задач стабилизировалось на уровне 90%. Все эти результаты были достигнуты с минимальным внедрением новых сотрудников; персонал продолжал исправлять ошибки так же, как и прежде — только подходы к организации работы изменились.
Интересный факт: менеджер программы Драгош Думитриу, который решил изменить ситуацию в XIT, был просто очарован книгой Андерсона. К его удивлению, он встретил идеолога программы Канбан именно в Microsoft, где он начал работать всего накануне. Думитриу попросил Андерсона помочь с его задачей, и тот согласился применить принципы своей книги на практике.Думитриу столкнулся с отделом, состоящим из трех разработчиков и трех тестировщиков, в котором накопилось 80 запросов. Сам PM был назначен временно, так как требования к работе включали экспертизу в технологии ASP, администрирование SQL Server и знание MS Project Server. Управление представляло собой «технического специалиста», который мог программировать, готовить отчеты и прогнозировать загрузку backlog в данной должности. Как считалось тогда, проблема отдела проявится, если будет собрана большая сумма данных. Думитриу не был таким «техническим специалистом».
Однако, начав анализировать операции XIT вместе с Андерсоном, он быстро выявил ключевые факторы, отрицательно влияющие на скорость работы отдела:
- Прогнозирование последствий (ROM) выполнения запроса занимало много времени. И разработчик, и тестировщик должны были потратить целый рабочий день на выполнение необходимых расчетов, проверку кода и завершение документации. В среднем в день поступал один запрос. По расчетам PM, 40% производительности отдела уходило на ROM;
- Приоритет отдавался запросам более высокого значения. XIT финансировался на основе стоимости заказа. Приоритезация запросов обсуждалась ежемесячно на собраниях менеджеров отдела с клиентами — менеджерами из других отделов. При расширении backlog при текущей скорости, когда обрабатывалось только 6 – 7 запросов в месяц, приоритеты других запросов постоянно менялись с течением времени. Многие из них откладывались на значительное «позже», не равное даже следующему месяцу.
- На этапе ROM половина запросов отсеивалась. Некоторые были слишком большими и переквалифицировались как проекты, которые передавались в другие отделы, другие были слишком дорогими и просто отменялись. Некоторые запросы не брались в разработку, так как их выполнение заняло бы слишком много времени. Таким образом, 40% производительности отдела расходовало на анализ запросов, 50% которых отвергалось. Около 15 – 20% рабочих ресурсов было потеряно.
- Подготовительная работа по запросам могла длиться месяцами до начала выполнения. Расчеты на этапе ROM могли быть потеряны или забыты за это время. Особенно если реализацию вели другой разработчик, а не тот, кто начал анализ.
Решения Канбан для проблемного отдела Microsoft
В конце 2005 года продуктивность отдела увеличилась на 155%. Чтобы дальше улучшить работу XIT, были привлечены двое сотрудников: один разработчик и один тестировщик. Число запросов в backlog уменьшилось до 10, и один разработчик последовательно обрабатывал 11 запросов за квартал. В среднем было завершено 56 запросов за квартал, по сравнению с 11 ранее. Стоимость запросов снизилась с $7500 до $2900.
Применение в Corbis
После достижения успеха в Microsoft, Андерсон в 2006 году начал решать новую сложную задачу. Теперь он работал в Corbis — еще одной компании Билла Гейтса, который еще не покинул MS. Одна из деятельностей Corbis заключалась в лицензировании фотографий. На тот момент это была вторая по величине библиотека стоковых фотографий в мире с базой данных около 3.5 тысячи изображений.
Задачей Андерсона было ускорить основные релизы компании. Интервал между их релизами составлял три месяца и мог расти еще дольше. Обсуждение плана релиза занимало у руководства две недели. Необходимо было установить выпуск вторичных релизов или обновлений каждые две недели. При этом ключевые ресурсы должны были быть направлены на основной проект.
В офисе Corbis появилась доска Канбан, где Андерсон ежедневно общался с командой. Цель PM заключалась в улучшении визуального контроля над процессами, поощрении самоорганизации и большей личной ответственности среди исполнителей. Система Канбан также была направлена на снижение контроля со стороны менеджеров и повышение продуктивности.
Кроме цветных карточек и графиков, на доске появилась «мусорная корзина» — в которую отправлялись слишком крупные задачи.
Фото из официальной презентации
Система Канбан для поддержания инженерных систем программного обеспечения от Дэвида Дж. Андерсона
Система Канбан проясняла, когда поток перестает быть плавным и где происходят задержки, так называемое узкое место. Быстрые обсуждения с командой помогали выявить текущие проблемы. Например, тестирование занимало 3 дня, что негативно влияло на временные рамки релиза. Трое сотрудников собрались и нашли способ сократить время до одного дня.
Узкое место — это участок схемы или алгоритма операций компании, где ограничения производительности ресурсов или людей резко снижают пропускную способность потока задач. Нехватка рабочей силы, плохой интернет или директор в отпуске блокируют или замедляют выполнение задач.
Лимиты для карточек Канбан устанавливались эмпирическим способом дважды. В колонке «готово к разработке» лимиты были увеличены. Появилась новая колонка — «готово к тестированию». Многие запросы на «downstream» были неправильно сформулированы, что вызвало ненужные временные затраты. Поэтому PM исследовал операции верхнего потока и нашел ошибки.
Процедура проверки запросов могла занять 100 дней, но релизы все равно начали появляться каждые две недели, как планировалось. Решения по содержанию релиза принимались за 5 дней до публикации. Практика подсчета, как в случае с отделом XIT в Microsoft, была отвергнута в пользу продуктивности. Приоритеты задач устанавливали согласно «стоимости задержек» или готовности ресурсов.
Система Канбан не только помогла Андерсону достичь поставленной цели, но и улучшила моральный дух команды. Благодаря коллективным обсуждениям и видимости процессов сотрудники установили доверие друг к другу. Персонал также принял Кайдзен, то есть практику непрерывного улучшения.
Программы и приложения для KANBAN
Trello
Популярная система Канбан для управления задачами. Она отмечается своей визуальной привлекательностью и удобным интерфейсом. Пользователи подчеркивают ее супер гибкость.
Kanbantool
Бесплатная доска для двух пользователей. Поддержка API и сенсорные интерфейсы.
Lean Kit Kanban
Бесплатная доска для пяти пользователей с хорошими возможностями сотрудничества. Поддержка API и возможности импорта/экспорта, обширная статистика.
Kanbanize
Совершенно бесплатный сервис с приличной функциональностью. Его владельцы гарантируют 300% увеличение продуктивности при использовании их продукта.
Worksection
Украинский SaaS — приложение для быстрого отслеживания и управления проектами. В настоящее время, помимо учета финансов и сроков, имеется диаграмма Ганта. В ближайшие месяцы разработчики добавят доску Канбан с возможностями настройки, что сделает сервис еще более подходящим для Канбан.
Вердикт
Канбан — это практика, которая помогает достичь успеха, при этом использование только гибких методов не является обязательным. Значительных изменений можно добиться, устраняя потери времени, управляя узкими местами и снижая вариабельность.
Однако успешные изменения требуют времени. Они происходят постепенно, в то время как сопротивление команды нововведениям минимально. Система Канбан мотивирует персонал к улучшениям без изменений в инженерных методах.
Книги для статьи предоставлены kniga.biz.ua
Пару лет спустя тоже самое))