Як працює Канбан?

Так, за продуктом чи за результатом в проекті стоїть певний ланцюжок дій, етапів, що створюють цей продукт або досягають цього самого результату. Якщо під час виконання немає проблем, то кожен етап буде швидко передавати задачі наступному без затримки та на виході виробництво чи команда матиме рівнозначний затратам результат. У випадку, якщо на одному з етапів задачі швидше накопичуються ніж вирішуються та не передаються далі, то саме в цьому та сусідніх етапах заховалось вузьке місце.

Завдання Канбану, як підходу в цій ситуації — зробити проблему видимою, а потім встановити обмеження на незавершену роботу. Це дозволить усунути накопичення запасів напівготової роботи перед вузьким місцем, і відповідно, запобігти марнуванню ресурсів і затримкам. Практично це виглядає так — на кожен етап встановлюється ліміт незавершених задач, які одночасно можуть бути «в роботі». Таким чином, робота ланцюжка оптимізується, адже задач виконується рівно стільки, скільки необхідно для виконання успішного кінцевого результату.

Ще одна з фішок Канбану — ставити один KPI на весь ланцюжок, а не окремо працівникам чи відділам. Найоптимальніша оцінка за терміном виконання, тобто чим скоріше виконуються замовлення/задачі, тим краще. За логікою Канбану, у будь-якому бізнес-процесі головне — знайти та тримати баланс між швидкістю виконання нових замовлень та ефективністю використання наявних ресурсів, обладнання та працівників.

Що таке канбан?

   Система канбан розпочала свій шлях у 1950-х роках на виробничих лініях корпорації Toyota, після чого перекочувала в офіси і стала важливим інструментом для проектних менеджерів.

   Як і концепція бережливого виробництва (Lean), система канбан була розроблена менеджерами Toyota. Автора системи, японського інженера Тайіті Оно, надихнув принцип роботи американських супермаркетів, де покупець сам вибирав потрібні собі товари.

   Безмежна гнучкість практики і її можливості для самоорганізації персоналу дозволили домогтися ефективності там, де інші підходи не працювали. Це той випадок, коли візитною карткою системи стала сама картка — вона утвердилася як внутрішня валюта в організаціях, які впровадили канбан.

Канбан — это «вытягивающая» система. В ней создается баланс между постоянным потоком, который устраняет затраты на ожидание, и минимальным количеством работы в процессе (РВП), что снижает риски перепроизводства. РВП регулируется с помощью карточек: их количество зафиксировано, а инструкции в них направляют исполнителей нижнего потока.

Kanban имеет такие достоинства:

На практике система отлично себя показывает в сферах неосновного производства:

Канбан имеет и недостатки:

Применение канбан в IT

Система канбан, продолжая приносить пользу на производственных конвейерах, проникла в сферу программного обеспечения.

Карточки, на которых указаны информация о сроках выполнения, описание или номер процесса и имя исполнителя, прикрепляются к доске с расчерченными колонками:

• Бэклог — задачи, которые надо выполнить
• Задачи, которые в данный момент разрабатываются
• Задачи, которые выполнены, но еще не переданные тестировщикам
• Задачи, готовы к передаче отделу тестирования
• Задачи, которые проходят проверку проект-менеджером (ПМ)
• Выполненные задачи

Что такое Канбан

В 60-е годы 20 века японская компания Toyota искала способ, как минимизировать затраты производства и решить проблему застоя ресурсов. Так была изобретена методология Канбан, основа которой — конвейерный метод производства с использованием карточек и полномерной визуализации. 

Главное достоинство Канбана и причина его популярности в последнее время — простота, по сравнению с другими методологиями разработки и настройки процессов. В нем нет особых терминов, жестко регламентированных устоев и ролей. Команда, использующая эту методологию, может самостоятельно устанавливать себе стандарты или заимствовать их из других методологий (например, со Scrum). 

Канбан — это не конкретный процесс, а система ценностей. Как Scrum и XP. Но более гибкая методология, чем Scrum и XP. 

Если называть его одной простой фразой, то это «уменьшение выполняющейся в данный момент работы» или “work in progress”.

3 принципа, на которых строится Канбан

В построении Канбана все достаточно просто и ориентируется на игровой формат: все должно быть ярко, наглядно и визуально красиво. Выделяют 3 принципа этой методологии: 

1. Визуализация потока создания ценностей.
2. Ограничение незавершенной работы (количество или время).
3. Оптимизация процесса, используя метрику «среднее время прохода» (Lead Time) или другую, которая показывает отношение эффективности к общим затратам. 

Проблемы, которые он решает

В последние годы Канбан стал часто применяться в сфере разработки программного обеспечения. Но одна из самых больших проблем в разработке софта — время простоя задачи, когда над ней никто не работает. По некоторым исследованиям, среднее время простоя в IT-отрасли — 98%. Лучшие из компаний (Facebook, Google, Amazon) снижают его до 60%. 

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

Соответственно, Канбан учит тому же — выбирать приоритеты, помещать все в определенный порядок и ставить ограничения на конкретный этап ваших проектов. 

Где применяется Канбан

Главное достоинство Канбана — простота и низкий порог входа для внедрения в уже работающих бизнесах. Поэтому эта методология подходит для внедрения в новый бизнес, и может использоваться как добавление эффективной системы в уже существующий. 

Чаще всего «чистый» Канбан используется только в поддержке проектов. В продуктовых и аутсорсинговых проектах он также работает, но для эффективности необходимо сочетание с дополнительными системами (тем же Scrum`ом, например). Хотя в Канбане можно установить ограничение по времени и бюджету, но без более глубоких вещей мы не сможем довести проект до качественного финального результата. 

Когда мы заканчиваем работу над проектом, доводим его до финальной стадии, то чаще всего клиент возвращается к нам с дополнительными задачами. С помощью Канбана их можно спокойно поместить в очередь и перемещать внутри системы, придерживаясь приоритетов. 

Второй вариант применения — внутренние работы компании и сайт своих услуг (например, маркетинговая часть). Обычно здесь нет ограничения в ресурсах и сроках, а потому Канбан — подходящее решение для ведения внутренних процессов и их контроля. 

Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Во-вторых, весь Канбан можно описать одной простой фразой — «Уменьшение выполняющейся в данный момент работы (work in progress)».
В-третьих, Канбан — это даже еще более «гибкая» методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов. И это также значит, что команда должна быть еще более готовой к гибкой работе, чем даже команды, использующие SCRUM и XP.

Разница между Канбан и SCRUM:
— В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты)
— В Канбан задачи больше и их меньше
— В Канбан оценки сроков на задачу опциональные или вообще их нет
— В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи

Например, общеизвестная проблема SCRUM — это большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов (когда как минимум день уходит на закрытие одного спринта, а потом день на открытие нового. И если спринт — 2 недели, то 2 дня из 2 недель — это 20%, чертовски много). В итоге чуть ли не 30-40% времени при применении SCRUM тратится на поддержание самого процесса — на ежедневные митинги, на 5% workshop, на спринт ретроспектив и т.п. 30%!

Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды — это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи.

Kanban - метод управління робочим потоком, розроблений для того, щоб допомогти вам візуалізувати свою роботу та максимізувати ефективність. З японської мови kanban дослівно перекладається як рекламний щит або вивіска. Почавшись із виробництва, згодом він став сферою, в якій домінують спритні команди з розробки програмного забезпечення. Нещодавно його почали визнавати бізнес-підрозділи в різних сферах.

Визначення Kanban. Спочатку він виник як система планування для витонченого виробництва, що походить від виробничої системи Toyota (TPS). Наприкінці 40-х рр. Toyota впровадила у виробництво підхід "саме час". Підхід являє собою тягучу систему. Це означає, що виробництво базується на попиті покупців, а не на стандартній практиці виробництва певної кількості товарів та просування їх на ринок.

Приділяючи найбільше уваги ефективності та використовуючи прогрес у обчислювальній техніці, Kanban залишив царину автомобільної промисловості та  став успішно застосовуватися в інших складних комерційних секторах, таких як ІТ, розробка програмного забезпечення, маркетинг тощо.

Найпростіша дошка Kanban може починатися з трьох стовпців - "Потрібно зробити", "Виконується" та "Готово". При правильній побудові, управлінні та функціонуванні дошка служить сховищем інформації в режимі реального часу, підкреслюючи слабкі місця в системі та інше, що може заважати безперебійній  роботі.

Є 4 принципи Kanban:

1. Починайте з того, чим займаєтеся в даний момент

2. Погодьтеся на поступові, еволюційні зміни

3. Поважайте наявний прогрес, розподіл ролей та обов'язків

4. Заохочуйте акти лідерства на всіх рівнях.

Kanban використовує наступні практики: 

1. Візуалізація робочого процесу

2. Обмеження незавершеної роботи

3. Управління робочим процесом

4. Зробити політику процесів явною

5. Організація фідбеків

6. Поліпшення спільної роботи

Переваги Kanban:

- Прогрес всіх учасників на одній дошці

- Kanban ефективно виявляє слабкі місця у вашому робочому процесі

- Kanban привносить гнучкість у робчий процес

- Команда стає більш відповідальною

- Ви зосереджуєтеся на закінченні роботи, щоб покращити продуктивність  взаємодію з колегами.

Детальніше: https://kanbanize.com/kanban-resources/getting-started/what-is-kanban/

Основи методології

Обмеження за часом або дуже широкі, або відсутні. Як правило, визначаються цілі, які необхідно досягти, потім команда послідовно працює, розбиваючи їх на завдання. Вимірюється час на виконання завдання і ефективність колективу в ході виконання.

Бережливе виробництво і зменшення кількості завдань
Замість великої кількості дрібних завдань ставиться кілька глобальних, які поділяються на етапи. Це робиться і для скорочення часу на виробництво, і для виключення перевиробництва. Завдання поступово переходить від однієї команди до іншої або від одного члена команди до іншого. Наприклад, дизайнер розробляє макет сайту і передає його розробнику, той після завершення роботи відправляє сайт на тестування. Таких етапів в залежності від типу виробництва може бути різна кількість. На кожному з них фахівці вирішують одну поточну задачу, а після передачі її на наступний етап переходять до іншої.

Візуалізація
Весь робочий процес візуалізується, щоб команда завжди розуміла, які завдання можуть почекати, а над якими необхідно працювати прямо зараз. Найбільш підходящий інструмент для цього: Канбан-дошка.

Канбан-дошка - це таблиця з декількома стовпцями. Усередині стовпців знаходяться стікери з завданнями. Розглянемо кожен з них, а також інші важливі елементи.

  - Глобальні цілі. Стовпець варто на самому початку, завдяки йому команда бачить, яким повинен стати продукт за цей рік, півроку або кілька місяців. Наприклад, підвищення продуктивності на 30%.
  - Завдання в черзі. Тут розташовуються ті завдання, які можна почати виконувати. Чим вище в стовпці завдання, тим вище її пріоритет, починати потрібно з самої верхньої.
  - Колонки з етапами роботи над завданням. Завдання переміщається по ним, поки не дійде до завершального стовпчика. Їх кількість залежить від типу роботи, іноді можна обійтися і однією-двома. Стікер переходить як вперед, якщо черговий етап виконаний успішно, так і назад, якщо були виявлені дефекти на попередній стадії.
  - Останній стовпець містить стікери з виконаними завданнями. Перед ним корисно ставити колонку «Тест» або «Перевірка». Причому не тільки для розробників ПЗ, але і в інших сферах, щоб перед завершенням переконатися в якості виконання.
  - На Канбан-дошці буде незайвим виділити область для термінових завдань. Їм буде відразу ж виділятися пріоритет у всієї команди. При цьому не може бути більше однієї невідкладної завдання одночасно - тоді інші теж стоять в черзі.
  - Максимальна кількість завдань. Це цифра, яка ставиться під кожною колонкою крім «Цілей» і «Виконано». Виходячи з чисельності команди, визначається, над скількома завданнями вони можуть працювати одночасно. Не можна перенести стікер в наступний стовпець, якщо під ним стоїть цифра «3», а їх там вже три. Так, якщо члени команди виявляють, що робочий процес встав, вони приходять на допомогу своїм товаришам, щоб ті швидше відправили завдання на наступний етап.
  - Кольори карток. Колір кожного стікера теж може нести дополнтельная інформацію. Наприклад, ступінь важливості або терміновості або необхідність пропустити кілька етапів, потрапивши лише в один-два певних.
Інший інструмент візуалізації - картки Канбан. Їх вперше почали використовувати на заводах Toyota.

Что такое Канбан?

Большинство людей, отвечая на этот вопрос, говорят, что это — методология разработки. Но так ли это на самом деле? Я бы хотел помочь разобраться с этим вопросом.

Идея единого потока

Для начала нужно понять, что это вообще такое и для каких целей появилось. Канбан был изобретён проектными менеджерами на заводах Toyota для того, что бы процесс создания продукта (в данном случае, автомобилей) стал более прозрачным. Классическая схема, используемая в то время, предполагала производство огромного количества деталей в разных цехах или даже предприятиях, не связанных между собой. Перед финальной сборкой могли пройти дни, недели и даже месяцы. Таким образом, если один из отделов допускал ошибку, о ней узнавали только через несколько недель, и все это время выпускались бракованные комплектующие. Убытки в данном случае чудовищны: оплаченная работа, испорченный материал, транспортировка, складирование, переработка и время. Спасительной и ключевой здесь являлась идея создания единого потока.

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

Что же нужно сделать, дабы обеспечить возможность существования такого потока? Прежде всего, следует заменить классическую модель выталкивания на модель вытягивания. Что это значит? То, что каждый следующий этап производства готов принять результаты предыдущего этапа, и, следовательно, равен по своей пропускной способности или превышает его.

Как это выглядит на практике

Рассмотрим пример использования Канбана. Допустим, перед нами рядовая IT-компания, которая при производстве применяет итеративную методологию, а для отслеживания оперативной ситуации внутри спринта используется Канбан доска.

To do — спринт бэклог.
In progress — задачи, которые разрабатываются в данный момент.
Ready for deploy — задачи, которые уже выполнены, но не представлены в тестовом окружении.
QA — задачи, готовые к тестированию.
PO/PM approving — готовые задачи проходят проверку project owner-ом или проектным менеджером.
Done — выполненные (завершённые) задачи текущего спринта.

Процессы в спринте здесь проходят таким образом: приступая, разработчик перетягивает задачу из To do в In progress. В один момент времени он имеет только одну задачу, так как параллельное выполнение задач ничем хорошим не кончается. После окончания своей части работы, он перетаскивает её в колонку Ready for deploy.

Начиная с этого момента за дело берётся отдел тестирования. По достижению лимита задач в этой колонке QA инженер инициируют сборку билда, или сервера, или ещё чего-нибудь. В идеале для этих целей хорошо иметь continuous integration инструмент, такой как Jenkins, например. Также допустимо просто попросить разработчика собрать билд или обновить сервер. При успешных результатах тестирования задача отправляется в колонку PO/PM approving, где получает финальное подтверждение и перетягивается в последнюю колонку Done. Если задача не проходит тестирование, она снова попадает в колонку To do с соответствующим комментарием. Багрепорт имеет точно такой же жизненный цикл.

Для построения такого процесса необходимо, чтобы у всех членов команды были правильно настроены нотификации. В таком случае можно избежать простоя при переходе задач между исполнителями.

Также желательно осуществлять промежуточные поставки кода в колонку Ready for deploy, так как это сможет обеспечить более оперативную обратную связь. Скопление тасок в любой из колонок называется «бутылочное горлышко». Это значит, что пропускной способности на данном участке не достаточно, и нужно найти причину и решить её.

Для быстрой обратной связи QA инженер должен иметь возможность протестировать отдельные компоненты: БД, API, front-end, back-end.

Почему именно Канбан

С таким инструментом компания имеет слаженную работу, где каждый знает свою локацию на общей карте. Перед ней открываются все преимущества Канбана, из которых следует отметить:
— Уменьшение времени прохождения каждой конкретной таски и, как следствие, выполнения всего проекта в целом;
— Быстрая обратная связь от отдела тестирования;
— Раннее вовлечение тестировщиков и, как следствие, никакой головной боли перед релизом;
— Высокое вовлечение команды в процесс разработки;
— Выполнение проекта в срок за счёт уменьшения времени простоев и автоматизации интеграции;
— Высокое качество продукта.

Канбан - система організації виробництва і постачання, що дозволяє реалізувати принцип «точно в строк». Слово «камбан» з японської означає «рекламний щит, вивіска». Це метод управління ощадливими виробничими лініями (японське слово, що позначає «сигнал» або «картка»), що використовує інформаційні картки для передачі замовлення на виготовлення з наступного процесу на попередній.
 
ІСТОРІЯ
 
Поява терміну канбан пов'язано з перерахуванням стандартних операцій: майстри дільниць перераховували виконувані роботи на папері і вивішували їх на видному місці поруч з такими ж списками майстрів інших ділянок.
Система канбан була розроблена і вперше в світі реалізована фірмою «Toyota». У 1959 році ця фірма почала експерименти з системою канбан і в 1962 році запустила процес перекладу всього виробництва на цей принцип.
В основі організації виробництва фірми «Toyota» лежить річний план виробництва і збуту автомобілів, на базі якого складаються місячні і оперативні плани середньодобового випуску на кожній ділянці, засновані на прогнозуванні купівельного попиту (період попередження - 1 і 3 місяці). Добові графіки виробництва складаються лише для головного складального конвеєра. Для цехів і дільниць, обслуговуючих головний конвеєр, графіки виробництва не складаються (їм встановлюються лише орієнтовні місячні обсяги виробництва).
Постійне використання філософії «точно в строк» дозволяє розкрити не виявленні досі дефекти. Так як запаси продукції і деталей можуть приховувати проблеми на виробництві, то при їх зменшенні щоденний контроль виявить, наприклад, несправності або простої.
 
ОСОБЛИВОСТІ
 
Ключовими елементами цього методу є:
·         раціональна організація і збалансованість виробництва;
·         комплексне управління якістю на всіх стадіях виробничого процесу і якості вихідних матеріальних ресурсів у постачальників;
·         партнерство тільки з надійними постачальниками і перевізниками;
·         підвищена професійна відповідальність і висока трудова мораль всього персоналу.
Систему Kanban практично неможливо реалізувати без одночаснного впровадження комплексної системи управління якістю.
Важливими елементами системи Kanban є:
·         інформаційна система, що включає не тільки картки, але і виробничі, транспортні та постачальницькі графіки, технологічні карти;
·         система регулювання потреби і професійної ротації кадрів;
·         система загального та вибіркового контролю якості.
ПЕРЕВАГИ
 
·         короткий виробничий цикл, висока оборотність активів, у тому числі запасів;
·         відсутні або надзвичайно низькі витрати зберігання виробничих і товарних запасів;
·         висока якість продукції на всіх стадіях процесу.
 
НЕДОЛІКИ
 
·         складність забезпечення високої узгодженості між стадіями виробництва продукції;
·         значний ризик зриву виробництва і реалізації продукції.
 
ОРГАНІЗАЦІЯ
 
Ідентифікують три ключові властивості, спостережуваних у кожній успішній реалізації методу Канбан.
Візуалізація. Типовим способом візуалізації процесу роботи, є використання дошки з колонками і картками. Колонки на дошці позначають стадії роботи.
Обмеження завдання в процесі виконання. Обмеження завдань у процесі виконання, мається на увазі використання системи «витягування». Система "витягування" працює як один з головних стимулів до постійних поліпшень в системі. Критичним елементом є те, що робота, яка знаходиться в стані виконання, на кожному кроці робочого процесу обмежена, і нова робота "витягується" в кожен крок тоді, коли з'являється місце в колонці кроку.
Вимірювання часу виконання задачі. Оптимізуйте процес, щоб звести час виконання задачі до мінімуму і зробити його на стільки прогнозованим, наскільки це можливо.
 
РЕЗУЛЬТАТ
 
Канбан - це сигнальна система, і вимога про виготовлення продукції надходить від попереднього процесу починаючи із замовлення по-споживача. З цього можна вивести, що за допомогою цього методу Канбан - продуктивна методика, що дозволяє швидко і якісно виконувати надане завдання.

Канбан — це метод управління розробкою програмного забезпечення з наголосом з доставкою якраз вчасно, та униканні перевантаження членів команди. При цьому підході процес від опису задачі до доставки результатів її виконання користувачу, наочно показується учасникам процесу, і члени команди можуть витягувати роботу з черги.

У спрощеному варіанті, Kanban включає два простих правила:

виробнича станція має план виробництва деталей ("backlog"). План відсортований по пріоритету, і може мінятися у будь-який час;

кількість завдань, що виконуються на станції одночасно обмежено (тобто робити не більше заданої кількості дзеркал одночасно). Це обмеження потрібне для управління швидкістю виробництва на станції, а також швидкістю реагування на зміни плану.

Засадничі принципи Розпочніть з того, що ви робите зараз :Метод Канбан (далі іменований просто Канбан) настійно підкреслює, що відразу не треба вносити ніяких змін у вашу існуючу установку / процес. Канбан повинен застосовуватися безпосередньо до поточного робітника процесу. Будь-які необхідні зміни можуть відбуватися поступово впродовж певного періоду часу з тією швидкістю, з якою команда почуває себе комфортно.

Погодьтеся продовжувати поступові, еволюційні зміни: Канбан закликає вас робити невеликі поступові зміни, а не радикальні зміни, які можуть привести до опору усередині команди і організації.

Спочатку, поважайте поточні ролі, обов'язки і посади : на відміну від інших методів, Kanban не вносить ніяких організаційних змін сам по собі. Таким чином, немає необхідності вносити зміни в існуючі ролі і функції, які можуть працювати добре. Команда спільно визначатиме і впроваджуватиме будь-які необхідні зміни. Ці три принципи допомагають організаціям здолати типовий емоційний опір і страх змін, які зазвичай супроводжують будь-які ініціативи по зміні в організації.

Заохочувати акти лідерства на усіх рівнях: Канбан заохочує постійне поліпшення на усіх рівнях організації і говорить, що акти лідерства не повинні виходити тільки від старших менеджерів. Люди на усіх рівнях можуть пропонувати ідеї і демонструвати лідерство в реалізації змін, щоб постійно покращувати спосіб доставки своїх продуктів і послуг.

Як працює Kanban?

Концепція Канбан - це неруйнівна система управління еволюційними змінами. Це означає, що існуючий процес покращується невеликими кроками. Завдяки впровадженню безлічі незначних змін (а не великих) ризик для усієї системи зменшується. Еволюційний підхід Kanban призводить до низького або відсутності опору в команді і зацікавлених сторін.

Першим кроком у введенні Kanban є візуалізація робочого процесу. Це зроблено у формі Канбан дошка, що складається з простої дошки і липких заміток або карт. Кожна карта на дошці є завданням.

Что такое канбан
и чем он полезен?

Визначення Канбана
Канбан - це візуальна система управління роботою під час руху через процес. Канбан візуалізує як процес (робочий процес), так і фактичну роботу, що проходить через цей процес. Мета Kanban - виявити потенційні вузькі місця у вашому процесі та виправити їх, щоб робота могла протікати через нього економічно ефективно з оптимальною швидкістю чи пропускною здатністю.

Основні принципи

• Почніть з того, що ви робите зараз:  Метод Kanban (далі - Kanban) сильно наголошує на тому, що не вносити жодних змін у існуючі налаштування / процес відразу. Kanban потрібно застосовувати безпосередньо до поточного робочого процесу. Будь-які необхідні зміни можуть відбуватися поступово протягом певного періоду тим часом, в якому команда комфортна.

• Погодьтеся на здійснення поступових, еволюційних змін:  Канбан рекомендує вам вносити невеликі поступові зміни, а не вносити радикальні зміни, які можуть призвести до опору в команді та організації.

• Спочатку поважайте поточні ролі, обов'язки та посади:  На відміну від інших методів, Канбан не нав'язує ніяких організаційних змін сам по собі. Отже, не потрібно вносити зміни до своїх існуючих ролей і функцій, які можуть бути успішними. Колектив буде спільно визначати та впроваджувати будь-які необхідні зміни. Ці три принципи допомагають організаціям подолати типовий емоційний опір і страх змін, які зазвичай супроводжують будь-які ініціативи щодо зміни в організації.

• Заохочуйте акти лідерства на всіх рівнях:  Канбан заохочує постійне вдосконалення на всіх рівнях організації, і це говорить про те, що акти лідерства не повинні походити лише від вищих керівників. Люди всіх рівнів можуть надавати ідеї та проявляти лідерство для впровадження змін для постійного вдосконалення способу доставки своїх продуктів та послуг.

Що таке канбан
і чим він корисний?

Система канбан розпочала свій шлях у 1950-х роках на виробничих лініях корпорації Toyota, після чого перекочувала в офіси і стала важливим інструментом для проектних менеджерів.

Безмежна гнучкість практики і її можливості для самоорганізації персоналу дозволили домогтися ефективності там, де інші підходи не працювали. Це той випадок, коли візитною карткою системи стала сама картка — вона утвердилася як внутрішня валюта в організаціях, які впровадили канбан.

Походження

Як і концепція бережливого виробництва (Lean), система канбан була розроблена менеджерами Toyota. Автора системи, японського інженера Тайіті Оно, надихнув принцип роботи американських супермаркетів, де покупець сам вибирав потрібні собі товари. Роль «супермаркету» в корпорації Toyota виконав склад.

Там сигнальними картками — а саме так дослівно з японської мови перекладається «канбан»- обмінювалися працівники, власноруч регулюючи виробничий процес.

Картки кріпилися до тари з деталями. На таких бірках вказувалася інформація про номер і кількість деталей, який відділ їх відправляє і куди вони повинні прибути.

Працівник, який безпосередньо займався монтажем і складанням машин («нижній потік») забирав деталі з тари, на якій був прикріплений «канбан» із запитом для складу. Картка знімалася і разом з порожнім ящиком передавалася транспортувальником на склад. Там інший працівник уже підготував нову тару з запчастинами, на якій кріпився виробничий «канбан» — бірка з інформацією про проведені запчастинах.

Виробничий «канбан» замінювався на «канбан» із запитом для складу і відправлявся на виробничу лінію запчастин — «верхній потік». Тому вироблялася саме та кількість деталей, яка вказувалася в картці. Тара з новими запчастинами ставилася транспортувальників на монтажну лінію.

Принципи канбана

Менеджери Toyota сформулювали 6 системоутворюючих правил:

1. Виконавці з «нижнього потоку» вилучають рівно стільки деталей зі складу, скільки вказано в канбані
2. Представники «верхнього потоку» теж постачають запчастини строго відповідно до карток
3. Ніщо не виготовляється або не переміщається без канбана
4. Канбан має бути завжди прикріплений до деталей
5. Браковані запчастини не використовуються в системі
6. Зменшення кількості карток канбан робить управління більш чутливим до змін. Але без крайньої необхідності змінювати усталену кількість карток не варто.

Канбан — це «витягаюча» система. У ній створюється баланс між постійним потоком, який усуває витрати на очікування, і мінімальною кількістю роботи в процесі (РВП), що знижує ризики перевиробництва. РВП регулюється за допомогою карток: їх кількість зафіксована, а інструкції в них направляють виконавців «нижнього потоку».

Правило «обов’язково прикріпленої бірки» працює як закон збереження енергії.

Ліміт РВП складається в пропорції до кількості канбан-карток, яка розраховується залежно від рівня продажів і статистичної варіантності в поточних процесах. Максимальна кількість бирок — та сама «енергія» в системі — закріплює верхній рівень РВП в будь-який заданий час. РВП також обмежується принципом витягування: швидкість виробництва верхнього потоку залежить від швидкості роботи нижнього.

На графіку видно, що одним з базових елементів системи є культура Кайзен. Автономний процес і стандартна варіантність звільняє менеджмент від постійного управління, тому він може зосередитися на поліпшенні роботи співробітників.

Застосування канбан в IT

Система канбан, продовжуючи приносити користь на виробничих конвеєрах, проникла в сферу програмного забезпечення.

Тільки картки, на яких вказані інформація про терміни виконання, опис або номер процесу і ім’я виконавця, тепер прикріплюються не до тари з запчастинами, а до дошки з розкресленими колонками:

• Беклог — задачі, які треба виконати
• Задачі, які на даний момент розробляються
• Задачі, які виконані, але ще не передані тестувальникам
• Задачі, готові до передачі у відділ тестування
• Задачі, які проходять перевірку проект-менеджером (ПМ)
• Виконані задачі

Над колонками зазвичай пишться число — ліміт, який вказує на максимальну кількість процесів в ній. Ліміт беклога вираховується в залежності від провідного часу. Якщо в системі 5 робіт в процесі, і завершення кожної з них в середньому займає 1 день, то й беклог можна обмежити лімітом 5.

Структура вище не є строгою — в залежності від специфіки проекту можуть бути додані імпровізовані колонки. Нерідко зустрічається канбан система, в якій потрібно визначити критерії готовності задачі перед її виконанням. Тоді з’являються дві колонки, які в англійській мові називаються specify (уточнити параметри) і execute (взятися за роботу).

• Ще може додаватися колонка з пріоритетною чергою. Коли виконавець звільняється, то він повинен очистити саме цю колонку з задачами, а потім братися за інші.
• Задачі, які не були виконані, — або повертаються в беклог, або викреслюються зі схеми.

• Канбан не заохочує багатозадачність, тому встановлюється ліміт процесів для одного виконавця.

• Виконана робота краще, ніж декілька розпочатих.

• Братися за другу роботу можна, якщо перша була заблокована.
• Час для виконання задачі має бути збалансованим. Занадто короткий термін відіб’ється на якості. Надто розтягнутий ліміт витрачає ресурси команди і підвищує вартість процесу.

Чому усюди використовується канбан-дошка, а не, наприклад, планшети або величезний монітор? Як відповідають на це питання шанувальники системи, звичайна дошка має дві переваги: ​​вона проста і забезпечує візуальний контроль. На ній легко вносити зміни, і вона забезпечує тактильну і соціальну взаємодію між учасниками команди.

Переваги та недоліки канбан

Kanban має такі переваги: ​​

1. Гнучкість планування. Команда концентрується тільки на поточній роботі, пріоритет задачі виставляється менеджером.
2. Висока включеність команди в процес розробки. Завдяки постійним зборам, прозорості процесів і можливостям самоорганізації працівники гуртуються і проявляють щирий інтерес.
3. Менша тривалість циклу. Якщо потрібний навичок має кілька людей, — тривалість скорочується, якщо ж тільки одна людина — з’являється вузьке місце. Тому співробітники повинні ділитися знаннями і тим самим оптимізувати тривалість циклу. Тоді вся команда зможе взятися за роботу, яку забуксувала, і відновити плавний потік.
4. Менше вузьких місць. Ліміти РВП дозволяють швидко знаходити вузькі і проблемні місця, які з’явилися через дефіцит уваги, людей або навичок.
5. Наочність. Коли всі виконавці мають доступ до даних, то вузькі місця легше помітити. Kanban-команди, крім самих карток, зазвичай використовують два загальних звіти: графіки управління і сукупного потоку.

На практиці система відмінно себе показує в сферах неосновного виробництва:

• групи підтримки програмного забезпечення або служби підтримки.
• Канбан добре працює при управлінні стартапами без чіткого плану, але де активно просувається розробка.

Канбан має і недоліки:

1. система погано працює з командами чисельністю понад 5 осіб
2. він не призначений для довгострокового планування.

Відмінності від скрам

Скрам, як і 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

 

Український saas — додаток для швидкого відстеження та управління проектами. Зараз у функціях, крім обліку фінансів і термінів, є діаграма Ганта. В найближчі місяці розробники додадуть канбан-дошку з можливістю налаштувать, що зробить сервіс ще більш придатним для канбана.

---

Вердикт

Канбан — це практика, яка допомагає досягти успіху, при цьому використання тільки гнучких методів є необов’язковим. Важливі зміни досягаються завдяки виключенню втрат часу, управління вузькими місцями і зниження варіативності.

Однак успішні зміни вимагають часу. Вони проходять поступово, при цьому опір команди нововведенням — мінімальний. Канбан-система мотивує персонал вдосконалюватися без змін в інженерних методах.