Канбан «на пальцах»

Что такое kanban

Цель kanban — сделать проект наглядным, отследить готовность работ и проконтролировать нагрузку специалистов. 

Для упрощения контроля рабочий процесс визуализируют на доске, поделенной на колонки. Каждая колонка — это текущее состояние работ

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

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

Пример структуры канбан-доски

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

Пример виртуальных kanban-досок: 

  • Trello. Можно создавать любое количество проектов с разным составом команды. К карточкам можно добавлять разноцветные метки, прикреплять вложения и оставлять комментарии. Число колонок неограниченно. Присутствует интеграция с другими приложениями. Бесплатно доступен почти полный функционал kanban. На платном тарифе отсутствует ограничение по объёму вложений, можно добавлять собственные стикеры и фоны. 
  • Taskify. Аскетичный сервис, предусматривающий деление доски на три колонки — «Общий список», «В процессе» и «Выполнено». Taskify доступен без регистрации любому числу пользователей. 
  • Asana. Это платформа для управления проектами с расширенным функционалом. Канбан-доска — один из предлагаемых инструментов. У сервиса есть платная и бесплатная версии. Преимущество Asana — интеграция с большим количеством приложений.

В самом простейшем варианте канбан-доску делят на три столбца с задачами: 

  • К выполнению (to do).
  • В процессе выполнения (doing). 
  • Выполненные (done). 

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

  • Бэклог — общий список. 
  • Разработка — задачи в работе.
  • Тест — на проверке у тестировщика. 
  • Проверка — отправленные на утверждение менеджеру проекта. 
  • Готово — полностью законченные.

Команда, работающая над созданием рассылки, видит на доске текущее состояние проекта.

За ведение доски ответственны все члены команды. Любой вовлечённый в процесс сотрудник может перемещать готовые карточки по доске. Такая структура обеспечивает наглядность выполнения. Можно посмотреть текущий статус задачи и своевременно выявить «заторы». 

Сервисная модель

И как же он действует? – спросите вы. На деле всё очень просто. Канбан использует сервисную модель. Он ложится на сервис, который вы, как компания, оказываете клиентам. Например, разработка сайтов или проведение SMM-кампаний, или же прием платежей (если вы банк). Или же он может лечь на внутренний сервис. Например, на IT-отдел, обеспечивающий жизнеспособность организации. Или на отдел Маркетинга, обеспечивающий позиционирование и продвижение (и много чего еще) товаров и услуг компании. Он выискивает, подсвечивает сервисы внутри организации и вне ее, и дальше улучшает их. 

Он минует границы между отделами, департаментами, компаниями в составе группы, чтобы добиться одной простой цели – оказывать максимально качественно услугу вашим клиентам и делать это вне зависимости от изменчивости окружающего мира. Помните, есть такой термин VUCA-мир или ”изменчивый” мир? Так вот Канбану как бы пофигу на него. Его задача обеспечить такой сервис, чтобы влияние этой изменчивости свелось к минимуму.


Рис. 2. Мем со странички Дэвида Дж. Андерсона.

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

На эти вопросы отлично ответил один из моих учителей – Алексей Жеглов (один из ведущих мировых экспертов в Канбан-методе). Как вы разработчика 1С (в его версии была команда разработчиков баз данных) не пересаживаете по разным командам и комнатам, а к нему как ходили все бухгалтера, кадровики и другие пользователи 1С, так и будут ходить. Он для них сервис, который будет существовать всегда вне зависимости от очередного витка трансформации или орг. структурных изменений. Сервис (и разработчик 1С) переживет всё

Плюсы

Преимущества системы Канбан очевидны. Выполнение каждой операции по каждому из заказов всегда под контролем.

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

Преимущества и недостатки канбан

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

Достоинства kanban: 

  • Гибкость планирования. Команда сконцентирована на текущих процессах, но при необходимости можно изменить приоритеты. 
  • Высокая вовлечённость команды. Совместное обсуждение всех вопросов и поиск оптимальных решений сплачивают коллектив. Каждый сотрудник понимает, что именно от него может зависеть общий успех проекта. 
  • Меньшая длительность итераций. За счёт того, что можно обратиться за помощью к коллегам при возникновении сложностей, сокращается продолжительность выполнения работы. Команда всегда видит, у кого задание «не идёт» и может помочь, чтобы восстановить плавный поток. 
  • Быстрое выявление проблем. Благодаря лимитам проблемные места сразу заметны. Поиск оптимальных решений можно направить именно на «узкое место». 
  • Наглядность. Рабочие процессы абсолютно прозрачны, поскольку любой сотрудник легко может просмотреть текущие этапы и статусы задач. 

Недостатки kanban: 

  • Ограниченность команды. Метод подходит для команд до 5-10 человек. При большем числе сотрудников становится сложно отслеживать выполнение работ. Поэтому целесообразно делить коллектив на команды и для каждой создавать отдельную доску. 
  • Краткосрочность планирования. Канбан-методология не предназначена для долгосрочного планирования. В этом её суть — в бэклог отправляют только актуальные задачи, и их приоритет меняют по ситуации. 

Различия между kanban и scrum

Хотя scrum и kanban имеют много общего, у них также есть достаточное количество отличительных характеристик. Понимание этих различий может помочь вам выбрать правильный фреймворк для вашего проекта.


Фото: Фотобанк Фотодженика

Особенности фреймворка scrum

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

Измерение производительности

Scrum измеряет Velocity (скорость): то есть количество задач (Stories) оцененных в Story Points, которые команда может выполнить за один спринт. После нескольких спринтов видна скорость выполнения задач и, следовательно, можно более точно планировать.

Каденция

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

События

Scrum предполагает проведение четырех типов митингов: планирование спринта (Sprint Planning), ежедневный скрам (Daily Scrum), обзор спринта (Sprint Review) и ретроспектива спринта (Sprint Retrospective).

Релиз

Релиз должен быть результатом каждого спринта. Обычно на обзоре спринта команда показывает инкремент, потенциально готовый к выпуску, а владелец продукта решает, релизить его или нет.

Внесение изменений

В scrum длительность итерации фиксирована. Не допускается внесение никаких изменений, которые бы повлияли на цель спринта (Sprint Goal).

Ключевые метрики

Прогресс скрам-команды измеряется показателем Velocity, который отображает скорость выполнения задачи командой. Основываясь на скорости, строятся burndown charts (диаграммы сгорания), которые помогают прогнозировать и планировать будущие релизы.


Фото: Фотобанк Фотодженика

Особенности kanban

В методе kanban не прописаны конкретные роли. Однако это не означает, что их не должно быть. Очень часто «за кулисами» стоит руководитель проекта, который спасает команду от рутины, решает вопросы, руководит процессом и так далее.

Измерение производительности

В kanban-методе измеряется время цикла — среднее время, в течение которого продукт проходит все этапы (например, от To Do до Done).

Каденция

Каденция kanban основана на непрерывном рабочем процессе. Команда может демонстрировать инкременты так часто, как это необходимо.

Релиз

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

События

В методе kanban совещания не обязательны; они могут проводиться регулярно, по требованию или не проводиться вообще. Как правило, взаимодействие происходит в рамках канбан-доски.

Внесение изменений

Kanban очень гибок к изменениям, которые могут быть сделаны в любое время (когда это возможно).

Ключевые метрики

Основная измеряемая единица — время цикла. На основе этого показателя можно сделать прогнозы относительно будущих релизов и скорости работы команды.

Происхождение

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

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

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

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

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

КАНБАН

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


Напоминаем, что теперь вы можете самостоятельно создавать дополнительные рабочие процессы под нужды определённых проектов Аккаунт > Статусы и метки. А пока вы этого не сделали, ваш Канбан работает по основным Статусам аккаунта.

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

Первая колонка — Backlog, она содержит все открытые задачи проекта без статусов согласно их иерархии. Задача берётся из бэклога и проходит все или только определённые статусы рабочего процесса, передвигаясь по ним слева направо, пока не будет сделана и закрыта.

Карточки на доске соответствуют Статусам проекта. Администратор может изменить название, цвет и порядок, перетащив всю карточку за шапку или через меню карточки

Обратите внимание редактирование названий, добавление новых статусов, и смена их очерёдности отразится на всех проектах с аналогичным рабочим процессом.
Последняя колонка — Закрытые задачи. Если вы перетащите одну или несколько заданий на эту карточку, — инициируется процесс их закрытия

Вы также можете переместить задачу из карточки Закрытых в Backlog, и она будет открыта заново.

Drag&Drop заданий на Канбан-доске

Одиночный перенос

Если вам нужно переместить одно задание, просто придавите его мышкой на некоторое время, дождитесь «отрыва с поворотом», и перетащите в нужное место

Конечно же, вы по-прежнему можете сделать то же самое без перетаскивания, изменив Статусы в параметрах задачи.
Обратите внимание на новые возможности работы с мышкой. Долгий клик левой кнопкой мыши — «поднимает» задачу для переноса, а клик правой кнопкой — вызывает её меню.

Массовый перенос

Если вам нужно переместить несколько заданий, — сначала отметьте всё необходимое, а затем просто потяните за одно из отмеченных

В таком режиме предварительный долгий клик не нужен, пачка для переноса формируется сразу.
Обратите внимание на Жёлтый / Серый колокольчик, который появляется слева вверху, в процессе «полёта». Он информирует о том, будут ли уведомлены подписчики о вашем «броске»

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

Положение «не уведомлять» останется до тех пор, пока вы снова не нажмёте пробел в «полете» или не измените его в другом месте, потому что это общий параметр для любых действий.

Каждую карточку можно свернуть/развернуть. Эта персональная настройка позволяет исполнителю видеть только нужные ему статусы.

Переименовать или перекрасить Статус можно, кликнув в название

Обратите внимание, это повлияет на все проекты, идущие по такому же рабочему процессу. Переименование здесь равносильно аналогичному действию в Аккаунт>Статусы и Метки

Изменить порядок можно, схватив карточку за пустое место шапки, используя долгий клик

Новое место карточки также повлияет на все проекты, идущие по этому рабочему процессу.
Быстро добавить новую задачу в нужный статус можно, кликнув в голубой плюс.
Сделать все то же самое и даже больше (+ Автоматизация и Скрытие) можно из Меню статуса. Для вызова меню кликайте в традиционные «три точки».

Добавить новый Статус можно прямо на Канбан-доске
Каждый статус из Рабочего процесса может быть Отключён и Скрыт в конкретном проекте. Это сделано для того, чтоб вам не приходилось создавать новые Workflow для похожих процессов. Например в проекте, идущем по стандартному процессу, отсутствует одна или несколько стадий — вы просто нажимаете Скрыть у всех лишних. Вернуть их можно через блок6, вы увидите все скрытые карточки при попытке добавить новую.

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

Для визуализации работы в Kanban используют специальную доску (неотъемлемую часть любой agile-методики) и набор карточек или стикеров. 

Доска может быть реальная (магнитная, пробковая, деревянная) и виртуальная (есть много сервисов, которые дают возможность работать с досками — WEEEK, Trello и так далее).

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

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

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

Задачи пишут на карточках или стикерах и прикрепляют в первую колонку. По ходу работы стикеры перемещают между колонками, пока работа не завершится. Если на каком-то этапе рабочего процесса есть проблема, команда это сразу видит и может исправить дело. Это называется управлением потоком.

Канбан-доску можно использовать для работы над несколькими проектами или направлениями. Например, у меня в WEEEK есть доска для контроля производства всего контента, где задачи разбиты на группы по видам контента.

Алгоритм работы системы Канбан

Рассмотрим алгоритм подачи заказов в системе Канбан на следующем примере. Пусть на предприятии функционируют два обрабатывающих цеха: ОЦ1 и ОЦ2. ОЦ 1 использует детали наименования «А» для производства полуфабрикатов «В», ОЦ 2 использует полуфабрикаты «В» для производства продукции наименования «С».

  1. В ОЦ 2 поступает пустой контейнер с прикрепленной к нему черной карточкой «С». Это значит, что поступил производственный заказ на производство определенного объема готовой продукции «С».

  2. Для выполнения производственного заказа ОЦ2 использует целый контейнер полуфабрикатов «В» и освобождает белую карточку.

  3. Рабочий на погрузчике забирает пустой контейнер, с прикрепленной к нему белой карточкой «В». Эта карточка дает разрешение на транспортировку другого контейнера с деталями «В» от ОЦ1.

  4. Рабочий на погрузчике с пустым контейнером и белой картой прибывает на ОЦ1, где снимает черную карточку с контейнера, заполненного деталями «В» и прикрепляет на него белую карточку с пустого контейнера.

  5. Свободная черная карточка «В» является заказом для ОЦ1 на производство следующего полного контейнера деталей «В». В процессе изготовления освобождается контейнер с деталями «А», и белая карта служит сигналом о пополнении запаса деталей «А» на один контейнер.

Автоматизация процессов

Для этого вновь обратимся к меню карточки

Для каждой карточки можно назначить Ответственного за статус в рамках конкретного проекта

В таком случае, при попадании заданий на карточку, — они изменят своего прошлого исполнителя на указанного человека.Обратите внимание Этот параметр назначается и сбрасывается только из Меню статуса на странице Канбан, но влияет на весь проект!

Для каждой карточки можно назначить Следующий статус, тот в который она должна попадать после прохождения текущего. В таком случае, при закрытии задачи исполнителю будет предложено две кнопки — Закрыть или Передать дальше

Если исполнитель нажмёт кнопку Передать дальше >>, то задача не будет закрыта, а перейдёт на указанный Следующий статус с возможностью автоматической смены ответственности см.1

Совет Возможность закрывать задачи исполнителями можно отключить в настройках проекта. В таком случае Исполнитель не сможет Закрыть задачу, однако сможет внести затраты и Передать дальше >> на следующий этап рабочего процесса.

Это позволяет построить автоматизацию по Push и Pull методологиям

Push — для карточек установлены конкретные ответственные. При перетаскивании задачи на карточку, или при её переходе из прошлой стадии, ответственный будет автоматически переустановлен.

Pull — для карточек установлен ответственный «Любой сотрудник». Это означает, что на следующую стадию задача будет попадать без исполнителя. Любой участник проекта сможет взять её себе в работу.

Что ещё нужно знать про Рабочий процесс и Канбан

  • Если в проекте изменился Рабочий процесс, то все задачи со статусами из прошлого процесса попадут в Backlog. Их старые статусы не исчезают, однако вы больше не сможете оперировать ими. Если вы сделали это случайно, то сможете с лёгкостью вернуть всё как было, изменив Рабочий процесс проекта на первоначальный.
  • Канбан всего аккаунта отображает все открытые Задачи из всех проектов по определённому Workflow.

На картинке выше показан выбор одного из трех Рабочих процессов аккаунта.

Жизнь МДФ истории на Канбан доске

Этот рассказ начинается с очереди МДФ историй, терпеливо ждущих на левой стороне Канбан доски. Они расположены рядом с целями так, что каждый может видеть, что эти МДФ помогают в достижении целей. Дизайнер пользовательского взаимодействия и бизнес аналитик, работая в паре, берут верхнюю историю из очереди и сдвигают все остальные вверх. Вытянутая история помещается в колонку «проработка в процессе». Они определяют необходимых для проработки стейкхолдеров и обсуждают с ними критерии приема готовности истории. Они встречаются с разработчиками, чтобы убедиться, что определенные ранее критерии понятны и достаточны для начала разработки. Все выражают свое согласие. Бизнес аналитик говорит «Значит я помещаю эту историю в буфер». «Нет нужды, мои активные слоты пусты — я сразу помещу историю в них и начну ей заниматься» — говорит разработчик. Использование системы Канбан вовсе не означает, что мы разрабатываем по модели водопада. Поскольку на доске все истории упорядочены слева направо, многие ошибочно считают, что Канбан исключает совместную работу над историей. Заметьте как бизнес аналитики и дизайнеры поработали вместе со стейкхолдерами и разработчиками. Они были ответственны за выполнение взятой истории, но это вовсе не означало, что они должны сделать все сами и не помогать никому с другими историями. В здоровом Канбан процессе есть множество мест, когда члены команды работают вместе. Продолжая работу над историей, мы видим, что она движется по доске слева направо, как только все, от кого зависит работа над историей на определенной стадии, делают все возможное, чтобы история вышла из этой стадии и пошла дальше. Они никогда не перебрасывают историю на следующую стадию, не выполнив своих обязательств. Они знают, что если перенести незавершенную историю в буфер, ответственные за следующую стадию просто не возьмут эту историю и отправят ее на доработку. Такой подход делает взаимодействие между членами команды и полноценное общение критически важными. Передвижение истории в обратном направлении – слева направо – вполне обычная ситуация. Чаще всего такое происходит, когда кто-то из следующей стадии считает, что качество работы предыдущих стадий можно немного улучшить. Проходит время, истории прорабатываются, перемещаются в разработку, а потом и в тестирование. Но вдруг случается маленький затык. Разработчики только что закончили свою историю и, подойдя к Канбан доске, чтобы перенести выполненную историю в буфер своей колонки, они видят, что в их буфере нет мест и колонка тестировщиков тоже забита под завязку. И что теперь? Разработчики идут к тестировщикам. — «Ребят, мы тут реально на всех фронтах загружены со своими историями. Свободные слоты появятся не раньше завтрашнего утра.» — «Хммммм», – говорят разработчики, – «А мы можем помочь тестировать?» — «Конечно вы можете!», – говорит тестировщик. — «С вашей помощью мы разгребемся уже к сегодняшнему вечеру». – Тестировщик улыбается, – «Только я не дам вам проверять сделанную вами же историю.»

Ограничения выявляют узкие места

Когда колонка на Канбан доске заполнена полностью, мы знаем, что группа загружена по максимуму. Мы также знаем, что если такая ситуация повторяется регулярно, данная стадия скорее всего является узким местом всего процесса. Канбан доска отчетливо показывает нам, что замедляет выполнение историй, и мы можем предпринять что-то, чтобы улучшить производительность именно там, где это расширит пропускную способность доски, а не в любой другой точке Канбан процесса. По факту, если все члены команды работают со своей постоянной скоростью, люди на проблемной стадии будут постепенно отставать от остальных. В идеале мы всегда хотим знать, как поддерживать разработку и пропускную способность доски на хорошем уровне: находить узкие места и устранять их, меняя подход к работе или количество людей на определенной стадии. В бережливом производстве такое сглаживание рабочего процесса называется Хейджунка, его цель – устранение неравномерности в работе, которая обозначается термином Мура. Впервые взглянув на Канбан доски, единственный эксперт по бережливому производству, которого я знаю, назвал их Коробками Хейджунка – инструментом, которым пользуются в бережливом производстве для определения неравномерности рабочего процесса. Хотя, конечно, я сам не эксперт и не хочу зацикливаться на терминологии. Да и вообще, многое из того, что строго определено в производстве, не напрямую ложится на разработку ПО.

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий