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

Слово «Канбан» можно услышать в разных контекстах. Это и доски со стикерами, и система работы в компании Toyota, и термин из рассуждений о бережливом производстве. В IT слово «Канбан» значит немного другое. В этом гайде мы попробуем структурировать информацию о Канбане и узнаем, как этот метод улучшает процесс разработки.

• Принципы Канбана
• STATIK
• Внешний вид
• WIP-лимиты
• Классы обслуживания
• Каденции
• Состав команды
• Метрики
• Выводы

Принципы Канбана

Методику Канбан хорошо описывает фраза:

«Перестаньте начинать, начните заканчивать»

У любой системы ценностей есть свой фундамент, и Канбан — не исключение. У него есть свои принципы:

1. Начните с того, что есть сейчас
2. Договоритесь об эволюционном развитии
3. Поощряйте лидерство на любом уровне — от начинающего сотрудника до высшего руководства
4. Управляйте потоком, а не людьми — дайте людям объединиться вокруг работы для более качественного результата
5. Выявляйте потребности и ожидания, которые есть от вашей команды
6. Сделайте правила работы явными и развивайте их

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

Правда, не каждое такое изменение может понравиться команде — и это нормально. У нас есть проблема, и мы ищем пути ее решения. На этом пути неизбежно будут неудачные попытки. Если перефразировать самураев:

«Канбан невозможно внедрить, по нему нельзя работать. Его можно использовать»

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

• Описываем текущий формат работы
• Собираем боли заказчика и команды
• Внедряем новые практики для решения этих болей

STATIK

Еще раз вспомним первый принцип:

Начните с того, что есть сейчас

С первого взгляда на него может показаться, что нам необязательно как-то определять направление своего движения, но это не так. На самом деле, при внедрении Канбана команда опирается на STATIK (Systems Thinking Approach to Introducing Kanban) — системный подход к представлению Канбана. STATIK помогает внести изменения в уже работающий командный механизм, даже если разработка уже началась. Команда лучше и легче воспринимает изменения, когда в их основе лежат реальные выявленные потребности.

Чтобы применить STATIK, нужно понимать:

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

Этот подход делится на несколько этапов:

1. Найти источник неудовлетворенности
2. Проанализировать текущие запросы и возможностей сервиса
3. Построить жизненный цикл работы
4. Внедрить классы обслуживания
5. Разработать Канбан-систему
6. Начать использовать Канбан-систему

Внешний вид

Визуализация производственного процесса происходит:

• Офлайн — с помощью пробковой доски и стикеров разных цветов в кабинете
• Онлайн — на цифровых досках для управления проектом (Trello, Jira, Kaiten и так далее)

Выбор инструмента остается за командой.

Базовый производственный процесс в Канбане делится на этапы и внешне выглядит как таблица:

Более подробный процесс развития доски показан в этом видео.

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

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

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

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

• Сбор требований
• Написание технического задания
• Отрисовка макета
• Создания задачи для команды

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

Внутри каждого этапа работ у задачи возможны различные статусы, например:

• Новая
• В процессе
• Заблокирована

Каждая команда подбирает список статусов под себя.

WIP-лимиты

В Канбане есть инструмент, который помогает уменьшить объем незавершенной работы — WIP-лимиты.

WIP-лимит (work in progress) — это число, которое показывает максимальное количество задач в определенной области доски. Эти лимиты могут устанавливаться на человека, на этап работ или на всю команду. Например, если у команды WIP-лимит равен четырем, то у нее в работе может находиться не больше четырех задач одновременно:

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

Если команда установила WIP-лимит, то лучше его не превышать, иначе разработчики рискуют взять на себя слишком много обязательств и не уложиться в срок. Но если команда регулярно не укладывается в лимит, можно пересмотреть его, если есть объективные причины.

Классы обслуживания

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

Можно выделить четыре основных класса обслуживания, по которым объединяются задачи:

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

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

Каденции

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

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

Вариант периодов проведения и другие петли обратной связи показаны на картинке ниже:

Состав команды

В Канбан-команде выделяются менеджерские роли и функциональную команду.

У менеджеров бывает разделение на две роли:

• Один менеджер управляет запросами к сервису
• Другой — реализацией этих запросов

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

Вся схема работы менеджеров выглядит так:

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

Функциональная команда отвечает за создание новых частей продукта. Она может состоять из:

• Дизайнеров
• Аналитиков
• Фронтенд- и бэкенд-разработчиков
• Специалистов по тестированию
• DevOps-инженеров

Набор людей опционален и зависит от проекта.

Метрики

В Канбане есть несколько важных метрик:

• Время выполнения задачи — от взятия в работу на первом этапе до публикации результата для пользователя
• Время на каждом этапе
• Время в каждом статусе на каждом этапе
• Доля задач, которые выполнены в запланированное время

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

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

Для примера возьмем такой график:

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

Выводы

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

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

• Альтернативное короткое описание Канбан-метода
• Много полезных видео о Канбан и не только
• Книга Дэвида Андерсона «Канбан. Альтернативный путь в Agile»