Яндекс Практикум

Как вы помните, при Scrum команда работает по спринтам, за время которых обязуется сделать определённый набор задач и не отвлекается на новые. Но что делать, если спринт уже начался, а команде разработки приходит новая срочная задача?

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

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

Если подобные ситуации происходят редко, то на работе команды по Scrum это не отразится. Но если так происходит регулярно, система работы по спринтам даёт сбой. Для таких ситуаций необходимо использовать другой подход из группы гибких технологий — Kanban.

Основная ценность Kanban — закрывать задачи как можно быстрее, но не за счёт принципов или чётких рамок, а благодаря постоянному отслеживанию состояния разработки. Лучше всего в этом помогает визуализация, поэтому вся методология строится вокруг доски команды разработки и работы с ней.

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

Процесс работы команды по Kanban

Основные активности команды по принципу Kanban:

Kanban-митинг.

Kanban-митинг — это ежедневная встреча команды, на которой обсуждаются статусы задач. Каждая команда самостоятельно выбирает, как называть статусы. Обозначить их можно, например, так: «Проектирование», «Готово к разработке», «Разработка», «Тестирование» и «Готово». Во время ежедневной встречи участники команды корректируют статусы задач, из-за чего меняется и их положение на доске: из «Готово к разработке» задача переезжает в статус «Разработка».

Встреча по наполнению очереди.

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

Встреча по планированию поставки.

На встрече по планированию поставки команда презентует результаты своей работы и договаривается о сроках поставки задач заказчикам. Цель команды — закрыть самые приоритетные задачи как можно скорее, но приоритеты могут меняться (о чём сообщается на ежедневных kanban-митингах). Поэтому в Kanban нельзя сказать точно, когда закончится работа над той или иной задачей, команда может гарантировать лишь приоритеты и очерёдность своей работы.

Активности в Kanban нужны для того, чтобы постоянно улучшать качество работы команды и найти то, что мешает ей работать эффективно. Чтобы оценить работу команды, можно пользоваться специальными метриками. Самая простая и наглядная из них — посчитать среднее время от взятия в работу задачи, до завершения всех работ по ней. За метриками следит Delivery Manager.

Delivery Manager — это участник команды разработки, ответственный за скорость и качество работы команды. Основная задача Delivery Manager — постоянно улучшать работу команды за счёт анализа метрик и наблюдений за доской.

Инструменты Kanban

Для визуализации работы в команде используется Kanban-доска. Это может быть физическая или виртуальная доска, где отражены задачи, над которыми работает команда. Она наглядно показывает, в каком статусе находятся задачи. Суть Kanban в том, чтобы сделать поток задач управляемым и уменьшить количество незавершённой работы. Управление потоком задач происходит во время встреч, на которых команда планирует сроки поставки и составляет очередь из задач.

Уменьшение незавершённой работы

Главное правило Kanban — у задач, расположенных на доске правее, приоритет выше, чем у задач, расположенных левее. То есть задачи, которые ближе к завершению, должны выполняться раньше, чем те, которые ещё не брали в работу.

Используя правило уменьшения незавершённой работы, нам необходимо сосредоточиться на завершении работы над задачами 7 и 8, а уже потом продолжать работу над задачей 6 и брать в работу новые задачи.

Чтобы обеспечить следование этому правилу, используются WIP-лимиты.

WIP-лимиты

WIP-лимиты — это ограничения по количеству задач на группу статусов или для каждого отдельного статуса. Это означает, например, что для статуса «В разработке» должно быть не больше четырёх задач, а для статуса «Тестирование» — не больше двух. Ограничения определяет размер команды и объём работы, который она может выполнить в рамках конкретного статуса. Ограничения в Kanban появились благодаря наблюдению: чем меньше задач в каждом статусе, тем быстрее они переходят на следующий этап (меняют статус). Это мотивирует команду продвигать задачи по статусу, чтобы освободить место для новых.

Что такое Kanban

Процесс работы команды по Kanban

Инструменты Kanban

Уменьшение незавершённой работы

WIP-лимиты