Как выстроить цикл разработки в Kaiten: опыт IT-стартапа от «АвтоВАЗа»
«LADA Цифра» — это стартап «Лада-Имидж», одной из дочерних компаний группы «АвтоВАЗ». А еще это уникальный микс из талантов разных людей, которые приняли вызов создать цифровое будущее в автомобильной индустрии. Команда успела поработать в крупных проектах и знает про IT не из учебников.
Стартап образовался в январе 2024 года, чтобы создать маркетплейс для оптовой и розничной торговли между поставщиками, магазинами и станциями технического обслуживания. Для конечных покупателей это, по сути, интернет-магазин с гарантией отсутствия подделок.
Новый технологичный стартап — это огромное количество процессов, которые нужно организовать с нуля. Одной из первых задач стало наладить процесс разработки. С одной стороны, он должен быть простым, понятным и системным, а с другой — сохранять возможность масштабирования.
Привет, меня зовут Юрий Москалев, я руководитель разработки в «LADA Цифра». Расскажу, как мы внедрили Kaiten и организовали цикл разработки с его помощью.
Выбрали Kaiten среди 20+ сервисов
Наши коллеги из «Лада-Имидж» пользовались Яндекс Трекером. Но для IT-команд он не всегда подходит: разработка состоит из множества сложных процессов, а в сервисе, на момент старта работы, не было встроенных инструментов отчетности. Мы не могли выгрузить отчеты о выполненных задачах и по другим метрикам, которые используем.
Поскольку мы работаем как стартап, в условиях жестко ограниченных ресурсов, то не можем выделить сотрудников, которые будут формировать отчеты вручную. Именно поэтому, несмотря на сопротивление бизнеса, мы решили отказаться от Яндекс Трекера и изучить другие решения.
Разработка — это отдел с самыми многочисленными и сложными процессами, поэтому мы решили: если найдем сервис, который подойдет нашей команде и закроет ее потребности, то его можно будет использовать и для других подразделений.
Мы перебрали около 20 инструментов и протестировали каждый. В итоге осталось два финалиста — Kaiten и EvaProject. Выбрали первый — скорость работы у него оказалась выше. Перешли в Kaiten в марте 2024 года.
Миграция и адаптация в Kaiten происходили непросто. Логика его работы построена на основе Канбан-досок и во многом отличается от Jirа, привычной для айтишников. Когда мы только начинали, я мыслил в парадигме Jira и пытался выстроить в Kaiten похожие сценарии. Но потом понял: нужно отталкиваться не от того, как функционируют уже знакомые нам таск-трекеры, а от устройства и задач бизнеса, которые необходимо отобразить. И уже их облекать в парадигму конкретного сервиса. Тогда это будет работать.
Настроили воркфлоу на основе цикла разработки ПО и фреймворка Scrum
Цикл разработки программного обеспечения состоит из шести этапов: анализ требований → планирование → проектирование и дизайн → поставка фичи → тестирование → развертывание.
Этапы цикла разработки делятся на две фазы: Discovery и Delivery
Мы работаем по Scrum: работа делится на двухнедельные спринты, в течение которых мы выполняем определенный объем задач. Чтобы управлять потоком задач, мы ввели в работу два стандарта:
Definition of Ready — стандарт, по которому должна быть описана любая поступающая к разработчикам задача.
Definition of Done — стандарт, по которому команда разработки выдает готовые задачи.
В спринте разработки есть несколько обязательных встреч:
Рефайнмент — встреча, на которой продуктовый лидер защищает проработанную на этапе discovery фичу перед командой разработки, а она на основе имеющихся данных принимает решение, сможет взять ее в работу или нет.
Оценка — если идея принята, команда планирует реализацию задачи и оценивает ее в относительных часах.
Спринт-ревью — команда разработки защищает реализацию перед продактом. Процесс замыкается.
Схема двухнедельного спринта разработки
Визуализировали спринт
Задачи текущего спринта находятся в пространстве «Разработка». В нем три основные доски: «Бэклог», «Цели спринта» и «Спринт».
«Цели спринта». Здесь собраны главные направления спринта, чтобы они всегда были перед глазами у команды. Мы настроили правила автоматизации в Kaiten таким образом, что при перемещении любой дочерней карточки в бэклог спринта родительская карточка помещается на доску «Цели спринта».
«Спринт». Мы работаем стандартными двухнедельными спринтами, в названии доски прописываем номер и даты текущего спринта. Столбцы на доске соответствуют принципам Канбан и этапам спринта по Scrum: «Бэклог», «В ожидании», «В работе», «Ревью», «Готов к релизу». Так мы наглядно видим, на какой стадии находится каждая задача и как продвигается работа.
Здесь мы также применили правила автоматизации. Когда первая дочерняя карточка попадает в колонку «В работе», родительская карточка также перемещается на доске целей в колонку «В работе». Если все дочерние карточки прошли этап тестирования, родительская карточка автоматически перемещается в колонку «Готово».
Спринты длятся две недели — стандартный срок для Scrum
Создали воронку бэклогов
Входящие задачи традиционно попадают в бэклог в виде карточек. Прежде чем попасть в спринт, они должны пройти несколько обязательных процедур. Рефайнмент и оценку — когда мы определяем, нужно ли вообще выполнять задачу, с каким приоритетом и в какой последовательности, а также какое время разработчика и тестировщика будет затрачено на это решение. Нам неудобно, когда все карточки находятся в общем бэклоге: так их сложно приоритизировать. Чтобы решить эту проблему, мы организовали воронку из нескольких досок для работы с задачами, которые нужно обсудить, оценить и после этого взять в спринт.
Карточки, которые прошли этап Discovery и готовы к передаче в команду разработки, попадают в пространство «Воронка бэклогов». Оно разбито на два этапа, у каждого своя колонка.
«Воронка бэклогов» позволяет держать в одном месте, но при этом не смешивать все входящие задачи
Сначала продакт-менеджер помещает карточку в первый столбец — «В рефайн». На отдельной встрече продакт-менеджера с командой разработки происходит обсуждение каждой задачи в этом столбце. Команда разработчиков принимает решение, достаточно ли информации и материалов по каждой из задач и готова ли команда взять эту задачу в декомпозицию и оценку. Если все прошло хорошо, команда разработки забирает ее в столбец «В оценку», чтобы декомпозировать задачу с помощью инструмента «Дочерние карточки», выставить оценку в часах для декомпозированных дочерних задач. Так, перед тем как попасть в спринт, задача становится максимально подробной — можно работать над ней в нескольких параллельных потоках.
Дочерние карточки можно создать прямо из родительской: сразу задать им тип и оценить в часах
Оцененные и декомпозированные задачи переходят в столбец «В разработку». Продакт-менеджер еще раз приоритезирует задачи и передает на доску Delivery.
В Delivery попадают задачи, которые прошли этап исследования, оценки и приоритизации. На доске мы решили создать отдельную колонку для багов и технического долга, чтобы всегда была возможность взять дополнительные задачи в спринт при наличии свободного времени.
Продакт перекидывает задачи, которые решили брать в работу, в бэклог «Разработка (Delivery)»
В Kaiten есть функция дублирования досок, когда одна доска одновременно отображается в разных пространствах. Если внести на ней изменения в одном пространстве, они автоматически отобразятся в другом. У нас доска Delivery дублируется в пространстве «Разработка». Именно там разработчики видят оцененные по времени задачи и забирают их в текущий спринт.
Дублирование доски «Разработка (Delivery)» в пространстве «Разработка»
В карточке задачи настроили поля, чтобы получать максимально точное описание задачи
Каждая карточка в Kaiten — это задача, ей присваивается один из типов: Task для задач, Feature для запуска новых фич, Bug для сообщений о проблемах или EPIC для группировки нескольких задач по одной теме. Мы проставляем тип, чтобы сразу видеть, к какой категории относится задача, и задавать условия для автоматизации. Кроме типа, в карточке мы предусмотрели следующие поля:
Метки — например, Frontend и Backend.
Оценка в часах — во время оценки в этом поле мы указываем, сколько времени, по нашему мнению, уйдет на задачу. Это важно, чтобы потом не взять в спринт больше карточек, чем мы физически можем выполнить.
Участники — ответственные за задачу. Поле помогает понять, кто отвечает за карточку и к кому обращаться, если нужно уточнить по ней информацию.
Срок — дедлайн, в который необходимо выполнить задачу.
Размер — количество Story Points, то есть условных единиц, которые используют при оценке задачи по фреймворку Scrum. Позволяет прикинуть, сколько ресурсов на нее уйдет.
DoD — критерии, которые определяют, готова ли карточка к разработке.
DoR — признаки, по которым мы понимаем, завершена ли задача.
Большинство полей не обязательны к заполнению. Мы сделали так, чтобы избежать ненужного формализма и усложнения рабочих процессов. Сейчас команда знакомится с сервисом, поэтому мы пытаемся понять, какие поля действительно необходимы при постановке задачи, а от каких можно отказаться.
Мы не хотим создавать огромные чек-листы, которые не помогают процессу, поэтому сделали обязательными только два поля
Используем два отчета — пока больше не нужно
По каждому спринту мы отслеживаем работу с помощью двух основных отчетов: «Скорость команды» и «График сгорания».
«Скорость команды». Оцениваем нашу производительность: какой объем задач взяли в спринт и сколько из них выполнили.
Параметры оцениваются по количеству Story Points в поле «Размер карточки». На графике в отчете два столбца. Левый показывает сумму оценок по задачам, которые в начале спринта находились в колонках «Очередь» и «В работе». Правый — в колонке «Готово» в конце периода.
Отчет помогает рационально оценивать нагрузку и рассчитывать силы команды
«График сгорания». Отслеживаем прогресс спринта. Так мы контролируем, выполняется ли план по работе, а если есть задержки — вовремя выявляем их.
На графике две линии. Голубая показывает идеальный ход работы, оранжевая — актуальный.
Чем точнее совпадают траектории, тем меньше отличается реальный процесс от запланированного
Другие отчеты, которые можно сформировать в Kaiten, используем только по необходимости. Для нас это не общие инструменты, а точечные. Мы не отслеживаем их регулярно, а открываем, чтобы проверить конкретную гипотезу.
Согласовываем релизы через модуль «Служба поддержки»
Перед выпуском релиза мы согласовываем его с другими подразделениями — это сводит к минимуму риск ошибок. Чтобы упростить процесс согласования, мы используем в Kaiten модуль «Служба поддержки» (Service Desk). В нем можно настроить форму, в которой пользователь будет оставлять заявку, и она в виде карточки задачи будет попадать в Kaiten.
Мы используем модуль так: уведомляем другие подразделения о реализованных на нашей стороне функциях, которые готовы выкатить в прод. Это помогает избежать ситуации, когда мы зарелизили какую-то фичу, а ее не согласовал или вообще не видел один из отделов — например, дизайн.
Поэтому, когда заканчиваем работу над фичей, в форме модуля Service Desk мы создаем «Запрос на изменения», а в нем заявку со следующими полями:
название и описание — суть фичи;
вид релиза — например, продуктовый, операционный или технический;
список систем и сервисов — в каких системах выпускаем релиз: набор опций зависит от вида, который выбрали на предыдущем этапе;
дата релиза.
Так выглядит форма запроса
А так — готовая заявка
Заполненная заявка в виде карточки попадает в отдельное пространство Request for Changes, и к ней автоматически добавляется ответственный. В пространстве несколько треков, а для перемещения карточек задач между ними у нас настроены автоматизации.
Main. Это доска, на которую карточка заявки попадает в первую очередь, — основной трек, на котором отслеживаются релизы. Изначально карточка находится в столбце «Очередь». Сотрудник, который назначен ответственным за задачу, двигает карточку в следующий столбец «В работе». Начинается процесс согласований.
«Согласования». Здесь отслеживаем, согласован ли релиз. Как только карточка задачи на доске Main оказывается в работе, на доске согласований в первом столбце «Очередь» формируется список дочерних карточек задач для разных согласующих. Они могут быть разными в зависимости от типа релиза. Согласующие перемещают дочерние задачи по колонкам «Требует уточнения» и «Согласовано».
Чтобы случайно не взять несогласованную задачу в работу, мы настроили автоматизацию, и теперь в пространстве Main невозможно взять карточку в статус «На исполнении», пока все задачи по согласованию не будут выполнены.
«Этапы релиза». Трек показывает, на какой стадии находится релиз: «Запланирован», «В работе» или «Готово». Сюда карточка задачи попадает автоматически после согласования, когда на треке Main ее передвинули в столбец «На исполнении».
Когда релиз перемещают в столбец «В работе», автоматически добавляется поле с датой и временем старта. Так мы понимаем, сколько времени занимает задача, и можем формировать отчеты с этим параметром.
Автоматизация позволяет нам тратить меньше времени на расстановку карточек
Применяем OKR-подход
В работе с задачами мы внедряем OKR-подход: стремимся, чтобы у каждой задачина вершине иерархии находилась определенная бизнес-цель. Это нужно для прозрачности: по итогам квартала можно посмотреть, что конкретно было сделано и как это повлияло на бизнес.
В Kaiten мы создали отдельное пространство для этого. На нем есть доска «Карта целей» со столбцами «Новая», «В работе» и «Завершено». В них находятся цели, которые ставят продуктовые лидеры. Так мы понимаем, на какой стадии исполнения находится каждая цель.
Для OKR-стратегии в пространстве мы активно используем отображение в виде таймлайна, чтобы понять, сколько времени ушло на выполнение задачи.
С OKR-подходом мы учитываем цели бизнеса, а не просто делаем задачи ради того, чтобы делать их
Переводим в Kaiten вторую компанию
Kaiten для нас удобен тем, что это песочница с понятными плюсами и минусами. Мы можем настроить платформу под свои задачи, главное в организации процессов — придерживаться логики, которая изначально заложена в сервис.
Сейчас в планах организовать в Kaiten работу двух компаний: «LADA Цифра» и «Лада-Имидж». Второе подразделение уже подключено в аккаунте, мы начинаем иерархически разводить их с первым, чтобы у каждого были свои пространства.
Чтобы мы в «LADA Цифра» могли реализовывать все более трендовые и экологичные продукты, нам нужна топовая команда. Часть уже есть, но мы продолжаем активно развиваться и искать наших сотрудников. Все актуальные позиции можно найти на нашем сайте ladadigit.ru.
