Кейтен Кайтен: Как Команда Из Четырех Человек Использует Методологию Канбан Для Работы Над Девятью Проектами

Вячеслав Цырульник, руководитель системы управления Кайтен , описал для vc.ru опыт использования методологии Канбан в дистрибьюторе автозапчастей для упрощения ИТ-разработки.



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

В 2014 году дистрибьютор автозапчастей «Росско» не смог запустить новые IT-проекты.

Ошибки, срыв сроков.

Перед новым CIO стояла задача наладить взаимодействие с бизнес-заказчиками и оптимизировать производственный процесс.



При чем здесь ИТ?

При численности компании более 1000 человек в ИТ-отделе работают около 50 сотрудников, занимающихся разработкой и поддержкой решений на базе платформы 1С.

Основные клиенты в ИТ-отделе — руководители логистики, продаж, бухгалтерии и так далее (всего их 9).

Бизнес зависит от стабильности разрабатываемых продуктов и скорости выпуска новых.

Таким образом, можно смело сказать, что Росско — это IT-компания.



Agile-курс

Пройдя обучение по Agile-методологиям и проведя внутреннее обучение, компания перешла к гибким методологиям разработки.

Для создания нового продукта была собрана команда и начала работать по Scrum. Эксперимент удался – продукт был запущен, бизнес-заказчик получил именно то, что хотел.



Как сейчас организована работа?

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

Команда поддержки работает по системе Канбан и обслуживает сразу нескольких внутренних клиентов.

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



Канбан, эффективное взаимодействие с девятью внутренними клиентами

Команда поддержки продукта работает по методологии Канбан:
  • используются два класса предоставления услуг (срочный – выдвижение задачи, и стандартный – вытягивание);
  • все этапы, кроме начального и финального, имеют ограничение на максимальное количество одновременно выполняемых задач;
  • у каждого заказчика есть представитель, который отвечает за описание требований, предоставление информации по задаче и расстановку приоритетов в его короткой очереди;
  • есть релиз-менеджер, который отвечает за реализацию задачи с момента принятия командой команды на ее реализацию.

Стоит отметить, что долгое время в команде было всего четыре человека.



Рабочее место клиента

Рабочее пространство каждого внутреннего заказчика организовано следующим образом:
  • Есть доска с его планами, которая разделена на две колонки: «Планы» — что нужно сделать по его направлению, и «Готов к работе» — что нужно сделать в ближайшее время.

  • Подключено табло «ИТ-производство», на котором отражается текущее состояние задач по всем внутренним заказчикам.

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

Обратите внимание, что он разделен на две части (две платы):

  • «Продажи» — планы по направлению «продажи» (соответствует блоку «ПЛАНЫ КЛИЕНТА НОМЕР 1» на схеме);
  • DevOne — это команда поддержки, которая обслуживает всех клиентов (на схеме соответствует блоку «ИТ-ПРОДУКЦИЯ»).

С правой стороны (плата DevOne) отмечены карты, актуальные для текущего клиента.

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

Основной характеристикой такого процесса является прозрачность и ясность текущих статусов.

Заказчику не нужно звонить, писать или узнавать, как обстоят дела с его задачей; ему просто нужно посмотреть на экран и найти свои задания.

Kaiten позволяет создавать рабочие пространства из комбинаций досок.

Создать описанные пространства в Кайтене можно за 1 минуту.

Конфигурация пространства в Кайтене:

Приоритизация задач между клиентами

Бизнес определяет приоритетность направления согласно стратегическим планам компании.

В рамках стандартного приоритета на ИТ-производстве у каждого заказчика есть свой «трек», который позволяет ему сразу понимать, где находятся его задачи.

Он также видит общую картину ИТ-производства — задачи других заказчиков.

Для приоритезации задач от 9 заказчиков были введены следующие правила:

  • Для каждого клиента всегда есть лимит на ячейку «Сделаем» (ячейка — пересечение столбца с треком), на схемах над лимитами на ячейки — цифры «1/3», «1».

    /1», «2/2».

  • Общий лимит ячеек не превышает лимит для этапа «Давайте сделаем».

  • Непрерывная нумерация FIFO (First In, First Out – «первым пришел, первым ушел») задач в графе «давайте сделаем» (на схеме карточка в треке клиента отмечена порядковым номером 3, т.к.

    в очередь третью по отношению к картам других клиентов).

Как это работает на практике:
  1. Бизнес решает, какие области являются наиболее приоритетными на данный момент, и на их основе устанавливает лимиты ячеек по областям.

    То есть для клиента №1 можно выделить лимит 3, а для клиента №2 – 1 (это сделано на схеме).

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

  3. Карте присваивается порядковый номер в общей очереди (FIFO), что обеспечивает равномерное выполнение задач.

  4. Нумерация карточек в графе «Давайте сделаем» всегда начинается с 1 и все участники процесса понимают, за какую задачу возьмутся следующей.

    Когда разработчики берут задачу из графы «Давайте сделаем», номера оставшихся карточек уменьшаются на 1.

  5. Каждый заказчик имеет возможность изменять приоритет задач в своей ячейке, не влияя при этом на общее состояние очереди.

Работа с неотложными задачами Срочные задачи — это задачи, которые обслуживаются вне очереди.

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

Клиент имеет право срочно занять ячейку в полосе, если он свободен и это согласовано с другими клиентами.

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



Анализ процессов с использованием возможностей канбан-аналитики

Двумя наиболее важными характеристиками сервиса являются время и качество обслуживания клиентов.

Служба поддержки — это сервис для внутренних клиентов.

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



Проектный импульс (кумулятивный поток)

На графике видно плавное увеличение задач на стадии «Готово» (Росско/Done); команда практически каждый день подает задания на бой.

Но в период с 15 по 29 февраля задачи зависли в стадии «готово к выпуску» (оранжевая область стала шире, чем обычно).

В этот период возникла проблема с доставкой обновлений боя, на решение которой ушла неделя.

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

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



Время разрешения инцидента

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

Например, установив SLA на 3 дня, вы сможете увидеть, какой процент задач выполнен в этот срок.



Пропускная способность группы поддержки

Для контроля пропорционального распределения задач согласно настройкам системы канбан команда обращается к графику пропускной способности.

На графике показаны периоды (месяцы), каждый с двумя столбцами:

  • сколько задач было поставлено (левая колонка);
  • сколько задач было выполнено (правый столбец).

Расписание можно просмотреть как по количеству задач, так и по их размеру.

В этом случае график строится по размеру карточек.

Бизнес-заказчик может в любой момент просмотреть процент выполнения своих задач по отношению к общему объему.



Когда задание будет готово?

В созданной системе работы с задачами для каждого заказчика можно выделить два временных раздела:
  1. Ожидание — это время от момента перехода задачи в стадию «Готово к работе» до момента достижения ею стадии «Давайте сделаем».

  2. Реализация – от «Сделаем» до «Готово».

Распределение времени исполнения в сегменте «Ожидание»: В первом столбце, например, показано, что за наблюдаемый период в течение суток с момента постановки в короткую очередь («Готово к использованию») было принято к использованию 17 карт. Но здесь нужно обратить внимание на вторую вертикальную красную линию, это процентиль 85%.

Это отметка, которая говорит о том, что для 85% задач ожидание составило не более 10 дней (календарных).

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

А это распределение времени для сегмента «Внедрение» (от момента постановки задачи до момента ее готовности).

85% задач выполняются менее чем за 13 календарных дней.

Здесь стоит отметить, что самые длинные задачи длились 20 дней, то есть максимальная задержка по отношению к большинству задач составила всего неделю.

И это график, охватывающий оба периода времени.

85% задач с момента постановки в очередь ожидания до реализации были выполнены за 20 дней.



Как производительность команды меняется с течением времени

На графике показано, как менялось время выполнения задач (по процентилю 85%) по каждому направлению с начала 2016 года по апрель 2016 года.



Росско о реализации Кайтена

Благодаря простому интерфейсу мы смогли быстро перейти с Jira на Kaiten для Канбан-команд. С момента появления поддержки Scrum мы начали постепенно переводить и Scrum-команды.

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



Ценности Кайтен

  1. Легко настроить.

  2. Прозрачность процесса для заказчиков и исполнителей.

  3. Поддержка гибких методологий.

  4. Аналитические возможности для диагностики процессов.

Рекомендация от директора по информационным технологиям Rossko Кирилла Зуева
Одна из основных практик в Канбане — ограничение количества одновременно выполняемых задач, стремясь выполнить задачи как можно быстрее.

Поначалу у коллег были сомнения в эффективности такого подхода.

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

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

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

Не пытайтесь придумать свой собственный Agile и свою собственную структуру.

Посещайте тренировки.

Agile окупится, если вы максимально вовлечете руководство.

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.