Система канбан начала свой путь в 1950-х годах на производственных линиях корпорации Toyota, после чего перекочевала в офисы и стала важным инструментом для проектных менеджеров.
Бескрайняя гибкость практики и ее возможности для самоорганизации персонала позволили добиваться эффективности там, где другие подходы не работали. Это тот случай, когда визитной карточкой системы стала сама карточка — она утвердилась как внутренняя валюта в организациях, которые внедрили канбан.
Происхождение
Как и концепция бережливого производства (Lean), система канбан была разработана менеджерами Toyota. Автора системы, японского инженера Тайити Оно, вдохновил принцип работы американских супермаркетов, где покупатель сам выбирал нужные себе товары. Роль «супермаркета» в корпорации Toyota выполнил склад.
Там сигнальными карточками — а именно так дословно с японского языка переводится «канбан» — обменивались работники, собственноручно регулируя производственный процесс.Карточки крепились к таре с деталями. На таких бирках указывалась информация о номере и количестве деталей, какой отдел их отправляет и куда они должны прибыть.
Работник, который непосредственно занимался монтажом и сборкой машин — нижний поток — забирал детали из тары, на которой был прикреплен «канбан» с запросом для склада. Карточка снималась и вместе с пустым ящиком передавалась транспортировщиком на склад. Там другой работник уже подготовил новую тару с запчастями, на которой крепился производственный «канбан» — бирка с информацией о произведенных запчастях.
Производственный «канбан» заменялся на «канбан» с запросом для склада и отправлялся на производственную линию запчастей — верхний поток. Поэтому производилось именно то количество деталей, которое указывалось в карточке. Тара с новыми запчастями относилась транспортировщикам на монтажную линию.
Принципы канбана
Менеджеры Toyota сформулировали 6 системообразующих правил:
- Исполнители из нижнего потока изымают ровно столько деталей из склада, сколько указано в канбане
- Представители верхнего потока тоже поставляют запчасти строго в соответствии с карточками
- Ничто не производится или не перемещается без канбана
- Канбан-дока должна быть всегда прикреплена к деталям
- Бракованные запчасти не используются в системе
- Уменьшение количества карточек канбан-доски делает управление более чувствительным к переменам. Но без крайней необходимости менять устоявшееся количество карточек не стоит.
Канбан — это «вытягивающая» система. В ней создается баланс между постоянным потоком, который устраняет затраты на ожидание, и минимальным количеством работы в процессе (РВП), что снижает риски перепроизводства. РВП регулируется с помощью карточек: их количество зафиксировано, а инструкции в них направляют исполнителей нижнего потока.
Лимит РВП составляется в пропорции к количеству канбан-карточек, которое рассчитывается в зависимости от уровня продаж и статистической вариантности в текущих процессах. Максимальное количество бирок — та самая «энергия» в системе — закрепляет верхний уровень РВП в любое заданное время. РВП также ограничивается принципом вытягивания: скорость производства верхнего потока зависит от скорости работы нижнего.
На графике видно, что одним из базовых элементов системы является культура Кайзен. Автономный процесс и стандартная вариантность освобождает менеджмент от постоянного управления, поэтому он может сосредоточиться на улучшении работы сотрудников.
Применение канбан в IT
Система канбан, продолжая приносить пользу на производственных конвейерах, проникла в сферу программного обеспечения.
Только карточки, на которых указаны информация о сроках выполнения, описание или номер процесса и имя исполнителя, теперь прикрепляются не к таре с запчастями, а к доске с расчерченными колонками:
- Бэклог — задачи, которые надо выполнить
- Задачи, которые в данный момент разрабатываются
- Задачи, которые выполнены, но еще не переданные тестировщикам
- Задачи, готовы к передаче отделу тестирования
- Задачи, которые проходят проверку проект-менеджером (ПМ)
- Выполненные задачи
Над колонками обычно пишется число — лимит, указывающий на максимальное количество процессов в ней. Лимит бэклога высчитывается в зависимости от ведущего времени. Если в системе 5 работ в процессе, и завершение каждой из них в среднем занимает 1 день, то и бэклог можно ограничить лимитом 5.
Структура выше не является строгой — в зависимости от специфики проекта могут быть добавлены импровизированные колонки. Нередко встречается канбан система, в которой требуется определить критерии готовности задачи перед ее выполнением. Тогда появляются две колонки, которые в английском языке называются specify (уточнить параметры) и execute (взяться за работу).
- Еще может добавляться колонка с приоритетной очередью. Когда исполнитель освобождается, то он должен опустошить именно эту колонку с задачами, а затем браться за другие.
- Задачи, которые не были выполнены, либо возвращаются в бэклог, либо вычеркиваются из схемы.
- Канбан не поощряет многозадачность, поэтому устанавливается лимит процессов для одного исполнителя.
- Выполненная работа предпочтительнее нескольким начатым.
- Браться за вторую работу можно, если первая была заблокирована.
- Время для выполнения задачи должно быть сбалансировано. Слишком короткий срок отразится на качестве. Чересчур растянутый лимит растрачивает ресурсы команды и повышает стоимость процесса.
Почему повсеместно используется канбан-доска, а не, например, планшеты или огромный монитор? Как отвечают на этот вопрос поклонники системы, обычная доска имеет два преимущества: она проста и обеспечивает визуальный контроль. На ней легко вносить изменения, и она обеспечивает тактильное и социальное взаимодействие между участниками команды.
Преимущества и недостатки канбан
Kanban имеет такие достоинства:
- Гибкость планирования. Команда концентрируется только на текущей работе, приоритет задачи выставляется менеджером.
- Высокое вовлечение команды в процесс разработки. Благодаря постоянным собраниям, прозрачности процессов и возможностям самоорганизации работники сплачиваются и проявляют искренний интерес.
- Меньшая продолжительность цикла. Если несколько человек обладает схожими навыками, продолжительность сокращается, если же только один — появляется узкое место. Поэтому сотрудники должны делиться знаниями и тем самым оптимизировать продолжительность цикла. Тогда вся команда сможет взяться за работу, которую забуксовала,и восстановить плавный поток.
- Меньше узких мест. Лимиты РВП позволяют быстро находить узкие и проблемные места, которые появились из-за дефицита внимания, людей или навыков.
- Наглядность. Когда все исполнители имеют доступ к данным, то узкие места легче заметить. Kanban-команды, помимо самих карточек, обычно используют два общих отчета: графики управления и совокупного потока.
На практике система отлично себя показывает в сферах неосновного производства:
- группы поддержки программного обеспечения или службы поддержки.
- Канбан хорошо работает при управлении стартапами без четкого плана, но где активно продвигается разработка.
Канбан имеет и недостатки:
- система плохо работает с командами численностью более 5 человек
- он не предназначен для долгосрочного планирования.
Отличия от Скрама
Скрам, как и agile kanban, является гибкой методикой и тоже часто применяется в IT-сфере. Различия между ними не очевидны на первый взгляд. Существует много схожестей, например, наличие бэклога в обоих подходах.
| Скрам | Канбан |
Темп | Повторяемые спринты фиксированной продолжительности | Непрерывный процесс |
Выпуск релиза | В конце каждого спринта после одобрения проектным менеджером (владельцем продукта) | Поток продолжается без перерывов или на усмотрение команды |
Роли | Владелец продукта, Scrum-мастер, команда разработчиков | Команда под руководством ПМ, в некоторых случаях привлекаются тренеры по agile kanban |
Главные показатели | Скорость команды | Ведущее время |
Приемлемость изменений | В ходе спринта изменения нежелательны, так как могут привести к неверной оценке задач | Изменение могут случиться в любой момент |
Примеры применения в IT
Сразу с Microsoft: Дебют Канбан в сфере программных разработок
Использование принципов канбана в сфере информационных технологий началось чуть более 10 лет назад. Дэвид Андерсон, один из главных популяризаторов канбана для программных разработчиков, консультировал в 2005 году компанию Microsoft. Там были недовольны работой своего отдела — XIT Sustained Engineering, который устранял ошибки во внутренних приложениях. К началу отчетного года этот отдел был худшим в своем департаменте. Бэклог превысил допустимый размер в 5 раз, а время на обработку одного запроса — ведущее время — обычно занимало 5 месяцев.
Новый ПМ с помощью консультаций Андерсона за 9 месяцев повысил продуктивность проблемного отдела на 155%. Ведущее время теперь составляло 5 недель, бэклог вернулся к нормальному размеру, а своевременное выполнение задач утвердилось на уровне 90%. Все эти результаты были достигнуты с минимальным привлечением новых работников, персонал продолжал теми же методами исправлять программные ошибки — поменялись лишь подходы к организации работы.
Интересный факт: программный менеджер Драгос Думитриу, который взялся переломить ситуацию в XIT, как раз был увлечен книгой Андерсона. К своему удивлению, он встретил идеолога программного канбана в самой компании Microsoft, куда тот накануне устроился. Думитриу попросил Андерсона помочь со своей задачей, и последний согласился применить принципы своей книги на практике.Думитриу застал отдел, состоявший из трех разработчиков и трех тестировщиков, у которых в бэклоге накопилось 80 запросов. Сам ПМ был назначен временно, так как требования к вакансии включали умение работы с технологией ASP, администрирование с помощью SQL Server и знание MS Project Server. Начальство видело на этой должности «технаря», который умеет программировать, должен составлять отчеты и прогнозировать загрузку бэклога. Как считалось тогда, проблема отдела будет выявлена, если собрать внушительный массив данных. Думитриу же таким «технарем» не был.
Однако начав вместе с Андерсоном анализировать работу XIT, он быстро выявил ключевые факторы, которые негативно влияли на скорость отдела:
- На прогнозирование последствий (ROM), к которым приведет исполнение запроса, уходило слишком много времени. И разработчику, и тестировщику приходилось тратить полный рабочий день, чтобы провести необходимые вычисления, проверку кода и заполнить документацию. В среднем ежедневно приходил один запрос. По подсчетам ПМ, на ROM уходило 40% от производительности отдела;
- Приоритет отдавался запросам с большей стоимостью. XIT получал финансирование за счет стоимости заказа. Приоритетность запросов обсуждалась каждый месяц на встрече менеджеров отдела с заказчиками — менеджерами других отделов. При распирающем бэклоге при текущий скорости, когда за месяц обрабатывались лишь 6-7 запросов, постоянно менялись приоритеты других заявок из-за проходящего времени. Многие из них были отложены на внушительное «потом», не равное даже следующему месяцу.
- На стадии ROM отсеивалась половина запросов. Часть из них были слишком большие и переквалифицировались в проекты с передачей другим отделам, другие являлись слишком дорогими и попросту отменялись. Некоторые запросы не брались в разработку из-за того, что их внедрение оказалось бы слишком долгим. Таким образом, 40% производительности отдела уходило на анализ запросов, 50% из которых были забракованы. Около 15-20% рабочих ресурсов тратилось впустую.
- Подготовительная работа по запросу могла длиться месяцами, прежде чем начиналось внедрение. Вычисления на стадии ROM могли за это время затеряться или забыться. Особенно, если внедрением занимался не тот разработчик, который начинал анализ.
Канбан-решения для проблемного отдела Microsoft
- Думитриу и Андерсон настояли в беседе с руководством и менеджерами-заказчиками на отказе от стадии ROM. Расчеты производились непосредственно перед внедрением и тем же исполнителем, то есть оставались «свежими».
- Приоритизация запросов проводилась не в ходе ежемесячных совещаний, а по ситуации, посредством телефонных звонков или электронных писем. 80 задач в бэклоге рассортировали в зависимости от заказчиков. Последних попросили выделить главные запросы, которые нужно выполнить в первую очередь.
- Финансирование XIT стало фиксированным.
- Стоимость запросов перестала браться в расчет.
- ПМ ввел буферы на канбан-доске. Разработчики брали работу из двух зон: одобренные и выполненные задачи. В буфере находились 6 запросов, 5 брались в работу. Тестировщики выбирали из буфера «ожидает тестирования». Некоторые задачи, которые не требовали изменений в коде, попадали туда, минуя разработчиков. Разбив запросы на однозадачные процессы, ПМ мог лучше контролировать ситуацию, а также обеспечить прозрачность для заказчиков. Введение буферов уменьшило ведущее время. Заказчики в условиях предсказуемой системы стали лучше определять, чей запрос должен попасть в буфер следующим.
- По слишком большим или дорогим запросам решение принималось сразу. Если разработчик подтверждал, что он готов выполнить задачу в течение 15 дней или изменения стоят того, то запрос брался в работу вне зависимости от размера или стоимости.
- Понаблюдав за потоком в отделе, ПМ пришел к выводу, что структуру штата стоит изменить в пользу разработчиков, которые были больше загружены работой. Изменения проводились в соотношении 2:1: в XIT стали работать 4 разработчика и 2 тестировщика.
По итогу 2005 года производительность отдела выросла на 155%. Чтобы еще улучшить работу XIT, туда привлекли двух сотрудников: одного разработчика и одного тестировщика. Количество запросов в бэклоге снизилось до 10, а один разработчик стал стабильно обрабатывать 11 заявок за квартал. В среднем за квартал завершались 56 запросов против 11 ранее. Стоимость запросов упала с $7500 до $2900.
Применение в компании Corbis
Добившись успеха в Microsoft, Андерсон в 2006 году приступил к решению новой сложной задачи. Теперь он работал в Corbis — другой компании Билла Гейтса, который тогда еще не покинул MS. Одним из видов деятельности Corbis было лицензирование фотографий. На тот момент это был второй крупнейший в мире фотосток с базой около 3,5 тыс. снимков.
Задачей Андерсона было ускорить главные релизы от компании. Интервал между их выходами составлял три месяца и мог вырасти еще больше. Только обсуждение плана релиза отнимало у менеджмента две недели. Требовалось наладить выпуск второстепенных релизов или обновлений каждые две недели. При этом ключевые ресурсы должны были быть направлены на работу над главным проектом.
В офисе Corbis появилась канбан-доска, у которой Андерсон ежедневно беседовал с коллективом. Целью ПМ было улучшить визуальный контроль над процессами, способствовать самоорганизации и большей персональной ответственности исполнителей. Также система канбан была направлена на уменьшение надзора со стороны менеджеров и увеличение производительности.
Кроме разноцветных карточек и графиков, на доске появилась «мусорная корзина» — в нее отправлялись задачи слишком большого размера.
Фото из официальной презентации
A Kanban System for Sustaining Engineering on Software Systems by David J Anderson
Система kanban прояснила, когда поток перестает быть плавными и где возникают задержки, так называемое бутылочное горлышко. Быстрые обсуждения с командой помогали выявить текущие проблемы. Например, тестирование длилось 3 дня, что негативно отражалось на сроке релиза. Трое сотрудников объединились и нашли способ, как уменьшить время до одних суток.
Бутылочное горлышко — участок схемы или алгоритма работы компании, где ограничение ресурсов или продуктивности людей резко сокращает проходимость потока задач. Нехватка рабочих рук, плохой интернет или директор в отпуске блокирует или замедляет выполнение задач.
Лимиты для канбан-карточек дважды устанавливались эмпирическим путем. В колонке «готово для разработки» лимиты были увеличены. Также появилась новая колонка — «готово для тестирования». Многие запросы для нижнего потока были некорректно сформулированы, вызывая лишние затраты времени. Поэтому ПМ исследовал работу верхнего потока и нашел ошибки.
Обработка запросов могла занимать 100 дней, но релизы все равно стали выходить раз в две недели, как и планировалось. Решение по содержимому выпуска принималось за 5 дней до публикации. Практика подсчетов, как и в случае с отделом XIT Microsoft, была отброшена в пользу продуктивности. Приоритет задачам расставлялся согласно «стоимости задержек» или готовности ресурсов.
Канбан система не только помогла добиться Андерсону поставленной цели, но и улучшила настроения в коллективе. Благодаря совместным обсуждениям и наглядности процессов у сотрудников утвердилось доверие друг к другу. Также персонал приобщился к кайзену, то есть практике постоянного улучшения.
Приложения и программы для Канбана
Trello
Популярная система канбан для управления задачами. Отличается визуальной привлекательностью и удобным интерфейсом. Пользователи отмечают его супергибкость.
Kanbantool
Бесплатная доска для двух пользователей. Поддержка API и touch-интерфейсов.
Lean Kit Kanban
Бесплатная доска для пяти пользователей с хорошей реализацией совместной работы. Поддержка API и возможность импорта/экспорта, широкая статистика.
Kanbanize
Полностью бесплатный сервис с достойной функциональностью. Его владельцы гарантируют прирост в производительности на 300% при использовании их приложения.
Worksection
Вердикт
Канбан — это практика, которая помогает добиться успеха, при этом использование только гибких методов необязательно. Важные изменения достигаются благодаря исключению потерь времени, управлению узкими местами и снижению вариативности.
Однако успешные изменения требуют времени. Они проходят постепенно, при этом сопротивление команды новшествам — минимальное. Канбан система мотивирует персонал совершенствоваться без изменений в инженерных методах.
Книги для статьи предоставлены kniga.biz.ua
Пару лет спустя тоже самое))