Слово «Канбан» можно услышать в разных контекстах. Это и доски со стикерами, и система работы в компании Toyota, и термин из рассуждений о бережливом производстве. В IT слово «Канбан» значит немного другое. В этом гайде мы попробуем структурировать информацию о Канбане и узнаем, как этот метод улучшает процесс разработки.
Методику Канбан хорошо описывает фраза:
«Перестаньте начинать, начните заканчивать»
У любой системы ценностей есть свой фундамент, и Канбан не исключение. У него есть свои принципы:
Как можно заметить, принципы направлены на гуманный подход к работе. Еще принципы описывают постепенные изменения. В начале стоит использовать те принципы, которые уже есть в команде. В первую очередь, нужно структурировать их и выявить боли команды и внешних агентов. Только после этого можно менять работу команды путем эволюционных изменений.
Правда, не каждое такое изменение может понравиться команде — и это нормально. У нас есть проблема, и мы ищем пути ее решения. На этом пути неизбежно будут неудачные попытки. Если перефразировать самураев:
«Канбан невозможно внедрить, по нему нельзя работать. Его можно использовать»
Давайте представим, что мы внедряем Канбан в команду. Резюмируем основные шаги, которые нужно сделать:
Еще раз вспомним первый принцип:
Начните с того, что есть сейчас
С первого взгляда может показаться, что нам необязательно как-то определять направление своего движения, но это не так. На самом деле, при внедрении Канбана команда опирается на STATIK (Systems Thinking Approach to Introducing Kanban) — системный подход к представлению Канбана. STATIK помогает внести изменения в уже работающий командный механизм, даже если разработка уже началась. Команда лучше и легче воспринимает изменения, когда в их основе лежат реальные выявленные потребности.
Чтобы применить STATIK, нужно понимать:
Этот подход делится на несколько этапов:
Визуализация производственного процесса происходит:
Выбор инструмента остается за командой.
Базовый производственный процесс в Канбане делится на этапы и внешне выглядит как таблица:
Более подробный процесс развития доски показан в этом видео.
В процессе визуализации работы мы внедряем важный принцип Канбана — вытягивание. Сигналом для вытягивания является пустота на определенном участке. Это смещает фокус внимания с загрузки людей на управление потоком работ. Если управлять занятостью людей, то вы получите только занятых людей. Это своеобразный конвейер наоборот.
Все задачи, над которыми работает команда, должны быть на доске. В Канбане доска — это инструмент для анализа рабочего процесса и точек роста команды. Если у задачи есть проблема в реализации, на нее вешается блокировка. Примерами таких проблем может быть найденный баг при тестировании или нехватка информации для дальнейшей проработки в анализе.
Внутри одной команды можно использовать более одной доски. Это позволяет лучше детализировать отдельные этапы и не загружать основную доску. Важно, чтобы каждый член команды мог посмотреть на доску и понять текущую ситуацию по проекту.
Для примера представим, что мы хотим поставить задачу команде. Подготовку к этому можно вынести на отдельную доску и разбить на этапы:
После всех этих этапов задача попадает в бэклог — список задач для команды, которые расставлены в порядке приоритетности и готовы к работе. Когда на первом этапе разработки освобождается место, происходит вытягивание — и команда берет верхнюю задачу из списка.
Внутри каждого этапа работ у задачи возможны различные статусы, например:
Каждая команда подбирает список статусов под себя.
В Канбане есть инструмент, который помогает уменьшить объем незавершенной работы — WIP-лимиты.
WIP-лимит (work in progress) — это число, которое показывает максимальное количество задач в определенной области доски. Эти лимиты могут устанавливаться на человека, на этап работ или на всю команду. Например, если у команды WIP-лимит равен четырем, то у нее в работе может находиться не больше четырех задач одновременно:
Если лимит закончился, команда должна посмотреть на доску и попробовать продвинуть вправо какую-нибудь из текущих задач. Если кто-то из членов команды свободен от задач, он может помочь коллегам — например, предложить парное программирование или помочь в тестировании уже готовых решений. Совместная работа помогает не только быстрее закрыть задачу, но и развить свои навыки.
Если команда установила WIP-лимит, то лучше его не превышать, иначе разработчики рискуют взять на себя слишком много обязательств и не уложиться в срок. Но если команда регулярно не укладывается в лимит, можно пересмотреть его, если есть объективные причины.
Команда не может приступить к работе, если у задач не определен приоритет. Приоритет по каждой задаче выставляют руководители проекта, ориентируясь на текущую ситуацию, запросы команды и бизнеса. Для визуального разделения работы внутри системы в Канбане используются классы обслуживания. Это группировка задач по стоимости задержки. Другими словами, задачи группируются с учетом того, сколько прибыли или убытков принесет задержка задачи или ее своевременное выполнение:
Можно выделить четыре основных класса обслуживания, по которым объединяются задачи:
Классы обслуживания важны не только тем, кто работает внутри. Например, через них можно наглядно представить ход работы заказчику и сформировать у него реалистичные ожидания. Если обсуждать с клиентами классы обслуживания, они будут четко понимать, что задачи не станут быстрее выполняться от того, что мы выставим класс «срочная».
В Канбане есть каденции — циклы обратной связи. Они помогают получать информацию от команды и заказчика, что улучшает работу сервиса в будущем. Существует четыре основные каденции:
Вариант периодов проведения и другие петли обратной связи показаны на картинке ниже:
В Канбан-команде выделяются менеджерские роли и функциональную команду.
У менеджеров бывает разделение на две роли:
Канбан направлен на управление потоком, поэтому роль первого менеджера — отбросить лишнее. Он работает над горизонтальной воронкой пожеланий, которые проходят через несколько стадий проработки и приобретают вид готовых задач с четким описанием. Задача второго менеджера — сделать обещанное, то есть провести задачу от первого процесса вытягивания до доставки для конечных пользователей. Между ними есть важный этап в проекте — точка принятия обязательств. Пример таких обязательств — обещание сделать определенную задачу за 5 дней.
Вся схема работы менеджеров выглядит так:
Обе эти роли выполняются одним человеком или распределяются между несколькими людьми. В классическом варианте на одного менеджера в команде приходится от пяти до восьми человек. При таком размере у менеджера хватает времени и внимания на каждого члена команды.
Функциональная команда отвечает за создание новых частей продукта. Она может состоять из:
Набор людей опционален и зависит от проекта.
В Канбане есть несколько важных метрик:
Эта информация может помочь в поиске «бутылочных горлышек». Как часть гибких методологий, Канбан нацелен на итерационный процесс. Метрики дают информацию для улучшения процессов в команде, показывают его изменения и слабые точки.
Примером работы с метриками можно назвать спектральную диаграмму. С ее помощью можно разбить работу на отдельные типы по уровню внешней зависимости, заказчику, сложности. После этого можно рассмотреть каждый тип отдельно и по получившимся результатам дать прогноз для заказчика.
Для примера возьмем такой график:
По нему можно сказать, что в 80% случаев задачи зеленого типа были сделаны за три дня. От этого можно оттолкнуться при оценке следующих задач этого типа.
Надеемся, эта информация поможет вам лучше структурировать информацию по этой теме. Помните, что нет правильного и неправильного Канбана. Этот метод больше похож на набор инструментов, которые можно применять для вашей текущей ситуации и получить эффект. Канбан направлен на развитие способности к обучению, а не действию по четкому плану, который был кем-то разработан.
Если вам интересно продолжить знакомство с Канбаном, можете обратиться к этим дополнительным источникам: