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

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

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

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

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

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

Индекс лояльности клиентов

Пожалуйста, оцените по шкале от 0 до 10 вероятность, что вы порекомендуете нас другу или коллеге?

Baши пpeдлoжeния пo улучшeнию кaчecтвa нaшeй paбoтыЧто нам нужно улучшить в нашей работе, чтобы вы могли оценить нас 10?
Извините! Вы уже проходили голосование. Если вы забыли дополнить свой отзыв, напишите нам через обратную связь.

Задайте мне вопрос

Спросите меня, если не нашли ответ на сайте

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