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