«LADA Цифра» выстроила процесс разработки ПО в Kaiten

В начале 2024 года в «Лада-Имидж», которая относится к ГК «АвтоВАЗ», собрали сильную команду практиков, чтобы создать IT-стартап «LADA Цифра». Новая компания разрабатывает технологичный продукт, который повлияет на цифровизацию автоиндустрии. Они делают маркетплейс автомобильных запчастей, который будет объединять поставщиков, магазины и сервисы для ремонта машин. Для покупателей это будет интернет-магазин с гарантией, что товары оригинальные, а не поддельные.

При запуске стартапа изначально предстоит отстроить множество процессов. И перед «LADA Цифра» стояла первостепенная задача настроить процесс разработки, чтобы он был несложным, структурным и масштабируемым.

Об опыте внедрения Kaiten и организации процесса разработки маркетплейса в «LADA Цифра» рассказал Юрий Москалев, руководитель команды разработки.

Как выбрали Kaiten

В «Лада-Имидж» работают в Яндекс Трекере, но для IT-стартапов этот сервис неудобен. В нем нет отчетности по метрикам, которые используют при разработке, например, отчет о завершенных заданиях. Ресурса на то, чтобы отчеты собирать вручную, у стартапа нет, поэтому решили посмотреть на предложения и возможности других сервисов.

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

Мы изучили и попробовали 20 разных сервисов. В итоге нам понравились Kaiten и EvaProject. Но отдали предпочтение первому, потому что он быстрее работал.

Переход и привыкание к Kaiten были нелегкими. Логика новой системы не такая, как в Jira, к которой привыкла наша команда. Она основана на Канбан-досках. Поначалу, когда только начали взаимодействовать с Kaiten, я пытался воспроизвести сценарии из Jira. Однако вскоре осознал: следует исходить не из того, как работают привычные таск-трекеры, а из потребностей и бизнес-целей, которые нужно реализовать. И именно их нужно адаптировать к особенностям нового сервиса. Только так вся эта система заработает.

Отстроили рабочий процесс, опираясь на жизненный цикл разработки ПО и Скрам

Разработка программ содержит в себе фазы Discovery и Delivery, в каждой из которых по 3 этапа: анализ → план → проект и дизайн → разработка новой функции → тест → выгрузка для использования.

Наш рабочий процесс основан на Скрам-фреймворке: работа длится спринтами по 2 недели, за которые мы делаем конкретный пул заданий. Чтобы было проще справляться с этим потоком задач, мы добавили 2 шаблона:

1. Критерии готовности к разработке, чтобы передавать задания в разработку.

2. Критерии готовности, разработчики по ним сдают готовую задачу.

В каждом спринте разработки у нас проходят регулярные встречи:

• рефайнмент — где менеджер продукта защищает функцию перед разработчиками, а они решают брать задачу или нет;
• оценка — где разработчики оценивают, за сколько времени будет выполнено задание;
• спринт-ревью — где команда разработчиков показывает продуктовому менеджеру, как была реализована задача, замыкая процесс.

Визуализация

Задания для спринта, над которым сейчас работают сотрудники, расположены в Kaiten на листе «Разработка». Он содержит 3 ключевые доски: «Бэклог», «Цели спринта», «Спринт».

На доске целей спринта отображены ключевые векторы работы, чтобы команда могла в любое время сверяться с ними. Карточки с заданиями попадают на эту доску благодаря автоматизации: если дочерняя карточка с задачей попадает в бэклог спринта, родительская — перемещается на доску с целями.

В названии каждой доски спринта содержится номер и дата для удобства. Колонки на доске названы по Канбан-методу и Скрам:

• Бэклог,
• В ожидании,
• В работе,
• Ревью,
• Готов к релизу.

Это позволяет отслеживать статус задачи и следить за прогрессом выполнения спринта.

Здесь тоже автоматизированы действия для карточек: если над дочерней задачей начинают работать, то на доске «Цель спринта» родительская карточка двигается в столбец «В работе». Когда дочерние карточки пройдут этап тестирования, то на доске с целями задача переместится в колонку «Готово».

Все задачи проходят через воронку бэклогов перед предстоящим спринтом

Перед тем как войти в спринт, задания из бэклога проходят ряд необходимых этапов валидации. Один из них — рефайнмент и оценка. Этот этап включает определение необходимости и важности задания и еще расчет трудозатрат разработки и тестировщиков. Все карточки из бэклога нужно дополнительно приоритизировать. Чтобы было проще с ними работать, мы создали воронку, которая включает в себя разные доски для разделения задач.

Задания попадают в воронку после того, как пройдут этап Discovery и будут заполнены необходимой информацией. «Воронка бэклогов» поделена на два этапа, для каждого из которых отдельный столбец.

Задания сначала размещаются в колонке «В рефайн». Все задачи из нее обсуждаются на совещании продакта и команды разработки. Если задача одобрена, она двигается в столбец «В оценку», где разработчики декомпозируют ее, используя дочерние карточки, и оценивают время на выполнение.

После оценки задача двигается в столбец «В разработку», где менеджер по продукту выставляет ей приоритет и перемещает на доску Delivery.

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

В Kaiten есть возможность дублировать доски в несколько пространств, что позволяет разным командам находиться в своем процессе, но быть в курсе верхнеуровневых задач. Например, задачи для текущего спринта разработчики берут из пространства «Разработка», которое дублируется из верхнеуровневой доски Delivery.

Используем поля в карточках для максимально подробного представления задания

Одна карточка — отдельная задача, в которой можно выбрать свой тип. От выбранного типа будут подставляться поля для заполнения и срабатывать автоматические настройки.

В «Лада-Имидж» пользуются несколькими настроенными типами, например:

• Task — для задач;
• Feature — чтобы работать над новыми функциями;
• Bug — для исправления недоработок;
• EPIC — чтобы группировать задачи по одной теме.

Еще помогают в работе отдельные поля, которые команда старается подробно заполнять.

• Метки — чтобы понимать, для какого блока разработчиков касается задание.
• Оценка в часах — сотрудники прикидывают время, которое будет затрачено на задание. Значение из этого поля помогает рассчитать объем спринта, чтобы точно его выполнить.
• Участники — все ответственные за задачу.
• Срок — дата завершения работ.
• Размер — количество условных единиц для оценки задачи, которые помогают оценить размер затраченных не нее ресурсов.
• DoD — критерии, по которым можно оценить, всё ли готово в карточке к разработке.
• DoR — признаки завершенной работы.

Пока не все из полей обязательно заполнять. Команда еще тестирует, какая информация может быть полезной для постановки задачи, а что можно упразднить.

Пользуемся двумя отчетами, и нам достаточно

Мы следим за ходом работы спринта, пользуясь 2 отчетами: «Скорость команды» и «График сгорания».

Отчет по скорости команды наглядно помогает оценить загрузку и ресурс подразделения: сколько заданий запланировали на текущий спринт и как много смогли сделать.

«График сгорания» помогает контролировать выполнение плана работы и влиять на сроки, если где-то задержались.

Остальными отчетами Kaiten мы пользуемся редко и только под определенный запрос.

Пользуемся модулем «Service desk», чтобы согласовать релизы

Чтобы снизить количество ошибок перед запуском релиза, сначала согласовываем его со смежными отделами. Для упрощения этого процесса пользуемся модулем «Служба поддержки». В нем реализована форма для заявки от пользователя, которая затем превращается в задачу на доске в Kaiten.

Через этот модуль мы уведомляем другие отделы о новых функциях, которые нужно выкатить в работу. Это предотвращает случаи, когда функция запущена без согласования одного из подразделений, например, дизайна.

После того как мы завершили работу над новой функцией, в модуле «Service desk» создаем «Запрос на изменения» с заявкой, которая включает:

• наименование и описание — информация о новой функции;
• вид релиза — продуктовый, операционный или технический;
• список систем и сервисов — что понадобится для публикации релиза;
• дата выхода релиза.

Запрос преобразуется в карточку и размещается на одноименном пространстве «Запросы на изменение». Внутри карточки, благодаря настройке, автоматом назначается ответственный. Само пространство состоит несколько треков: «Main», «Согласования» и «Этапы релиза». Когда карточки перемещаются внутри досок, срабатывают автоматизации.

Например, на доске «Main» собраны карточки для отслеживания релизов. Если карточка из колонки «Очередь» передвигается в столбец «В работе», то на доске «Согласования» автоматически создаются дочерние карточки с заданиями для утверждения. Только после всех согласований, основную карточку можно будет двинуть дальше по процессу.

После того как карточка на доске Main окажется в столбце «На исполнении», она автоматически попадет на доску «Этапы релиза» в колонку «Запланирован».

Когда карточка перемещается в столбец «В работе», срабатывает автоматизация и появляется поле с датой и временем начала. Это позволяет отслеживать время выполнения заданий и создавать отчеты по этому параметру.

Используем OKR-подход

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

В Kaiten у нас есть пространство «Продуктовая работа». В нем находится доска «Карта целей» с колонками «Новая», «В работе» и «Завершено». Здесь продакт-менеджеры размещают цели, а мы отслеживаем, на каком этапе выполнения находится каждая из них.

Придерживаясь OKR-подхода, мы пользуемся визуализацией пространства в виде таймлайна. Такое отображение задач помогает оценить время работы над конкретным заданием.

Подключаем в Kaiten «Ладу Имидж»

Kaiten — понятная платформа с гибкой настройкой воркфлоу именно вашей команды. Как и у любого сервиса, есть свои понятные преимущества и недостатки, но чтобы всё получилось настроить — нужно соблюдать правила, заложенные в него.

Мы планируем визуализировать в Kaiten процессы работы «LADA Цифра» и «Лада-Имидж». Пока только подключили и выстраиваем процессы и иерархию между ними для корректного отображения на разных пространствах.

Мы делаем технологичные проекты с сильной командой, и Kaiten помогает нам организовать эти сложные процессы.