Всем привет! Я Айыына Егорова, Agile Coach в inDrive. Хочу поделиться небольшим опытом работы с командами без спринтов с применением Kanban-метода. Cтатья будет полезна руководителям команд, скрам-мастерам и любым агентам изменений.
Вы узнаете, как быстро запустить работу в команде без спринтов: с чего начать, какими инструментами мы пользуемся в компании и какие ошибки нельзя допускать. Отдельно разберем пример проведения воркшопа STATIK в команде Localization.
Введение
Если у вас есть команда, которая устала от спринтов и хочет применять Kanban-метод, первое, в чем нужно разобраться — понять, подходит ли команде этот стиль работы.
В своей работе мы используем итеративно-инкрементальный процесс — подход к организации, в котором сочетается поэтапность и работа по инкрементам продукта (созданию его ценности). Один из примеров такого фреймворка — Scrum.
Частый случай, когда команда работает по Scrum или ориентируется на него — поставляет ценность поэтапно, используя роли и события из фреймворка. В начале каждого спринта команда планирует задачи, в конце — демонстрируют готовую часть продукта. Не будем останавливаться на определении Scrum, подробнее можно изучить в официальном гайде.
Единственное, что нужно знать — критерии, которые можно обсудить и проверить вместе с командой. В результате понять, комфортно ли вам и вашим стейкхолдерам работать с помощью фреймворка.
Критерии Scrum как основы работы команды
Разработку продукта можно разбить по значимым этапам с ощутимой бизнес-ценностью на каждом из них.
Работа в условиях высокой неопределенности без знания того, какие практики и инструменты могут подойти.
Определение каждого спринта как эксперимента — продуктового, командного, организационного.
Наличие продуктовых гипотез, которые вовлекают всю команду.
Понимание метрик, на которые влияет команда.
Организация команды вокруг единственной цели на спринт.
Продуктовые задачи в бэклоге превалируют (80%+) над сервисными задачами для других команд.
Большая степень автономности команды для принятия решений и управления своим бэклогом — что, когда, зачем и в каком порядке разрабатывать.
Что еще можно использовать?
В последнее время набирает популярность применение Kanban-метода как инструмента для управления интеллектуальной работой и выравнивания процессов в продуктовых командах. Вы можете использовать все практики метода, часть или применить только одну — зависит от контекста. Нет строгого понятия, что такое Kanban, нет отсечки, когда можно сказать, что работа идет по Kanban. Подробнее о практиках можно почитать в этом гайде.
Перейду к тому, как мы применяем практики Kanban в продуктовых и сервисных командах.
Визуализация рабочего процесса |
Используем электронную доску с разными визуальными сигналами: отметками, цветовыми кодами, шаблонами. |
Ограничение незавершенной работы |
Ставим лимиты на работу в прогрессе для каждой из колонок: персонально, на команду и так далее. |
Управление потоком работы |
Смотрим метрики, которые измеряют скорость потока, настраиваем доску и каждый этап в потоке. |
Использование явных правил |
Создаем видимые всем рабочие соглашения. |
Ввод петли обратной связи |
Показываем свою работу заинтересованным лицам и собираем обратную связь. |
Постоянное совершенствование |
Проводим ретроспективу и задаемся вопросом: что можно улучшить? |
Kanban можно применять при следующих кейсах и потребностях:
Потребность в выявлении скрытой работы.
Потребность в выравнивании потока.
Потребность в разгрузке потока и сотрудников.
Потребность в предсказуемости поставки ценности.
Сложные организационные условия и необходимость начать с чего-то уже сейчас.
Четкие стрессоры и мотиваторы к изменениям — например, недовольство руководства, заказчика или команды.
Если организация не готова к резкому переходу на гибкие практики (например, на фреймворки масштабирования) или ей не подходят широко распространенные гибкие подходы, Kanban предлагает альтернативный подход к гибкости организации.
Что важно для начала использования Kanban?
Kanban-метод значительно повышает результативность команд, в которых постоянно возникает поток новых задач. Он применяется в разных сферах: от строительства до IT. Рекомендуется использовать все шесть практик Kanban, но самыми ценными для начала я посчитала две — визуализация и явные правила. Сначала расскажу про первую практику.
Визуализация работы
Для визуализации Kanban-системы существует несколько вариантов. Самая популярная из них — онлайн-доска с отображением задач. Важно учитывать, какую информацию вы используете на доске для принятия решений. В идеале карточки должны подходить и отвечать потребностям контекста. Пример: если четко следите за сроками задач, на карточке должны быть отражены дедлайны.
Зачем нужна визуализация:
Найти скрытую работу и посмотреть на полный объем задач, который выполняется командой.
Отобразить блокирующие задачи, над которыми невозможно вести работу.
Понять, какие виды работ выполняются. Например, карточки разного цвета для доработок и техдолга.
Определить объем работы на каждом этапе и визуальное отображение исполнителей.
Хочу отменить, что в современном мире физические доски — большая редкость. Ниже поделюсь, какие инструменты для визуализации мы используем в inDrive.
1. Wrike
Во Wrike удобно создавать пространство для работы конкретного отдела, отслеживать сроки и исполнителей. Можно создать цветовую метку, выставить приоритетность задач, сделать чеклист и назначить нескольких исполнителей на задачу.
2. Jira
Инструмент отлично подходит для командной работы по разработке ПО. Можно фиксировать изменения в коде, строить дорожные карты, формировать детальные отчеты в виде метрик и графиков, а также формировать бэклог.
Явные правила
Необходимо зафиксировать правила и сделать их прозрачными для каждого участника команды, чтобы снизить человеческий фактор. Они должны быть простыми, наглядными, четко сформулированными, гибкими и применимыми в любых обстоятельств.
Полезно начинать с простых правил и совершенствовать по мере необходимости. Важно понимать, что правила развиваются и меняются в процессе. Ниже описаны примеры основных правил:
Договоренности о времени выполнения.
Критерии готовности (Когда можно считать задачу завершенной?).
Критерии перемещения по статусам (Когда элемент может перемещаться из одного статуса в другой?).
Критерии приоритизации (Какие задачи являются приоритетными?).
Когда необходимо пополнять бэклог?
Как долго элементы могут задерживаться в колонке?
Пополнение при выборе новых задач.
Формирование правил и следование им необходимо, чтобы команда работала самостоятельно. Обсуждение и формирование договоренностей входит в подход STATIK. Он применяется, чтобы запустить Kanban-систему или найти точки роста текущей. Далее поэтапно разберу воркшоп STATIK на примере проведения в нашей команде Localization.
Описание системы через STATIK
Что это? System Thinking Approach to Introducing Kanban (STATIK) — подход, который упрощает запуск Kanban-системы. Это воркшоп, в котором нужно пройти определенные шаги: оценить задачи, проблемы и ожидания, приоритеты задач.
Для чего? STATIK проводят разные люди: менеджеры процессов, проектов и команд, которые хотят изменить процесс или запустить Kanban-систему. Обычно команды хотят понять, как Kanban может повлиять на процесс и как можно задизайнить первую Kanban-систему.
Формат. Это воркшоп с фасилитацией и обсуждениями, который занимает от одного до нескольких дней. Необязательно проводить за один раз, можно провести небольшие сессии по 2 часа. Интервалы между сессиями лучше сделать небольшими, команда должна сохранять концентрацию на протяжении всего периода, ведь только так можно добиться результатов.
STATIK включает в себя восемь ключевых шагов, но некоторые мы пропустили и немного переделали воркшоп под себя. Далее я подробно расскажу, как проводила воркшоп в команде Localization. Перед нами стояла цель — добиться прозрачности процессов и найти точки улучшения.
Воркшоп для команды Localization
Команда Localization занимается переводами и локализацией приложения inDrive на разные языки. Мы разделили воркшоп с ними на две сессии по 120 минут, которые проводили с интервалом в одну неделю, чтобы ничего не забывать. Ниже пошагово расскажу о каждом этапе. Первая сессия включала в себя шаги 1-4, вторая — шаги 5-7.
Первый шаг. Что такое STATIK?
Время: 10-15 минут.
Фасилитатор встречи погружает команду в контекст: озвучивает цель воркшопа, рассказывает теорию и совместно с командой формирует правила, если это необходимо. Формат, по которому прошлась я:
Что такое STATIK? Зачем нужен и что даст?
Когда и зачем применять подход?
Какие будут шаги? Что будем делать на воркшопе?
Сформировала правила встречи: участвовать, не отмалчиваться, присутствовать здесь и сейчас. Сделала упор на то, что нам даст встреча и зачем тратить на нее время.
Второй шаг. Ice-Breaker
Время: 10-15 минут.
Задание: закинуть мемасик или картинку, который отвечает на вопрос: «На что похож наш процесс?».
На сбор информации ушло 3-4 минуты, далее каждый описывал выбранный вариант и рассказывал, что для него значат процессы в команде.
Третий шаг. Источники неудовлетворенности
Цель: определить точки роста и осознать, зачем команде меняться.
Время: 20-25 минут.
Формат: команда рассматривается как корабль, которому мешают якоря. Так проще выгрузить больше скрытых источников недовольства. Делим доску на две стороны: слева — внутренние источники, справа — внешние источники.
Задание:
Опишите внутренние источники неудовлетворенности вашей команды.
Опишите внешние источники неудовлетворенности заказчика.
Примечание: мы потратили на задание много времени, так как раскрывали внешние и внутренние источники неудовлетворенности раздельно. Для экономии времени лучше заполнять и обсуждать сразу два столбца. Собранные проблемы более подробно разобрали на ретроспективе.
Четвертый шаг. Анализ спроса и возможностей системы
Время: 40 минут.
Цель: посмотреть, насколько сервис востребован и какого типа задачи в него поступают.
Формат: распределяем тип работ.
Задание:
Написать на стикерах, над какими задачами сейчас работает команда.
Откуда приходит нагрузка? Что просит заказчик?
Для каждого типа работы анализируем скорость прилета задачи, природу нагрузки, ожидания клиентов.
Примечание: задание делали с командой совместно, не разделяясь на подгруппы.
Пятый шаг. Жизненные циклы типов работ
Время: 35 минут.
Цель: понять, какие этапы проходит задача, как мы накапливаем знания о ней и поставляем ценность
Формат: собрать полный путь получения знаний, который привел бы к готовому элементу типа работ. В нашем случае, чтобы не тратить много времени, выбрали два типа: самый часто встречающийся и самый длинный.
Задание:
5 минут — выбрать самый длинный и самый часто встречающийся тип работ.
15 минут — объединить и разбить этапы, как происходит сейчас. Можно открыть нынешние статусы.
10 минут — как понять, по какому принципу задачи переходят в следующий этап? Definition of Done, тригеры для каждого статуса.
Здесь важно смотреть не только на свою команду, но и рассматривать моменты до и после. Например, в каком статусе работа, когда попадает к нам?
Примечание: этот этап воркшопа шел отдельной сессией, перед началом мы потратили минут 7-10 для того, чтобы воспроизвести прошлый сеанс и вспомнить, что делали.
Шестой шаг. Классы обслуживания
Время: 20 минут.
Цель: понять, как мы работаем с задачами
Формат: совместная командная работа, распределение типов задач по классам обслуживания.
Задание:
10 минут — попросить команду привести примеры запросов всех типов в их конкретных ситуациях:
Ускоренный. Рабочие задачи настолько срочные, что приходится откладывать выполнение других работ и немедленно переключиться на них.
Фиксированная дата поставки. Рабочие задачи, невыполнение которых к конкретной дате приводит к наложению существенного штрафа, несопоставимого с любой выгодой от ранней поставки.
Стандартный. Задачи, выполняемые в соответствии с порядком, согласованным с заказчиком.
15 минут — распределение типов задач, к какому классу обслуживания относится.
Примечание: какие риски у вас связаны с различными типами запросов? Какова стоимость задержки?
Седьмой шаг. Дизайн Kanban-системы
Цель: зафиксировать дальнейшие шаги, что и когда мы будем вносить в систему.
Формат: понять, чего мы добились?
Вопросы для обсуждения:
Как выглядит доска, заполненная рабочими задачами? Хватает ли на ней места?
Насколько продвигаются рабочие задачи в интервале от одной летучки до другой?
Понятна ли доска для тех, кому предстоит ей пользоваться?
Хорошая доска обеспечивает прозрачность. Необходимо улучшать поток и изменять доску так, чтобы в результате менялась сама система.
Примечание: данный шаг мы не успели проделать совместно в рамках воркшопа. Поэтому я предложила дальнейшие шаги по улучшению отдельно, и мы после воркшопа мы с командой обсуждали, что и когда начнем применять.
Итоги
В основе Scrum лежит итеративно-инкрементальный подход, стремление к постоянному обучению, а также адаптации к изменениям. Эффективнее всего он подходит небольшим командам, которые создают или улучшают продукт в условиях неопределенности.
Метод Kanban ориентирован на непрерывную поставку ценности. Вы можете использовать все практики метода, часть или применять только одну — нет строгого понятия, что работа идет по Kanban.
Визуализация как основа Kanban помогает видеть полную картину и отдельные части.
STATIK — классный воркшоп с последовательными действиями, который необходим для запуска новой Kanban-системы или улучшения текущей.
О том, как мы оцениваем задачи, проводим события, за какими метриками следим и как применяем классы обслуживания — расскажу в следующей части статьи. Огромная благодарность Даниилу Короткову в написани этого материала и шерингу экспертизы. Буду рада вашим вопросам в комментариях :)
w84gg
Эсь, кхая