Агрегированный командный Канбан

0
(0)

Данная статья является продолжением цикла публикаций о прото-Канбан системах.

Что такое агрегированный командный Канбан

Агрегированный командный Канбан – прото-Канбан система уровня зрелости 3 из KMM. Данному уровню зрелости соответствует:

  • устойчивый процесс
  • устойчивые результаты
  • попадания в ожидания заказчиков
  • соответствие цели заказчиков
  • неустойчивая экономика (сервиса)

Для чего нужен

Последняя в списке, но не по значению, форма прото-Канбана – агрегированный командный Канбан. Еще один очень часто встречающийся на практике дизайн канбан-доски. 

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

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

Как устроен

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

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

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

Пример использования

Рис. 2. Агрегированный командный Канбан в команде банковского сервиса.

На рисунке 2 приведен пример агрегированного командного Канбана. В колонке “Аналитика готова” бесконечная очередь, которая образовалась после того, как команда сервиса решила визуализировать весь процесс поставки ценности с помощью первой Канбан практики.

Ранее данная колонка была “Бэклогом продукта” для команды разработки, куда входили только разработчики и тестировщики. Аналитики не входили в состав скрам-команды. Они готовили элементы бэклога продукта для разработчиков прямо в бэклоге продукта.

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

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

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

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

Заключение

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

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

Требуется большой уровень доверия к агенту изменений, чтобы внедрить WIP-лимиты на всех этапах поставки задач и закрепить уровень зрелости ML3 для данного сервиса.

Подробно эта форма прото-Канбан системы разбирается на онлайн-тренинге Team Kanban Practitioner.

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

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

С вами был Игорь Филипьев, руководитель школы Канбана. 

За ревью спасибо Евгению Степченко (Telegram – @StepEv).

Интересует корпоративное обучение и консалтинг по Канбану?
Пишите нам на school@filipyev.ru.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Сожалеем, что вы поставили низкую оценку!

Позвольте нам стать лучше!

Расскажите, как нам стать лучше?

Мы используем cookie-файлы. Оставаясь на сайте, вы соглашаетесь с политикой конфиденциальности.
Хорошо