Как перенести работу scrum-команды из Jira в Kaiten: кейс BotHelp

BotHelp — платформа для рассылок, автоворонок и чат-ботов в мессенджерах и соцсетях. Это no-code продукт, где любой маркетолог может создать свою воронку продаж и делать рассылки по своим подписчикам.

Подробный обзор платформы вы можете посмотреть здесь.

В феврале 2022 команды BotHelp вынужденно перешли из Jira в Kaiten, столкнувшись с рядом сложностей из-за разницы между двумя сервисами. Но сейчас уже 8 месяцев все разработчики, product-management и support-отдел успешно работают в Kaiten.

Андрей Соловьев — CTO компании BotHelp, рассказал, что было самым сложным при переходе из Jira и как удалось переложить существующие scrum-процессы на особенности нового инструмента.

Быстрый перенос данных стал решающим фактором

Для нас основная цель использования таск-трекера — это организация процессов разработки в компании. Раньше мы использовали для этого Jira и Confluence, но в связи с последними событиями были вынуждены искать российский аналог Jira и Confluence.

Мы довольно долго выбирали подходящий вариант, метаясь между YouTrack и Яндекс.Трекером, но один из наших тестировщиков посоветовал присмотреться к Kaiten, и в итоге мы решили остановиться на нем. Ключевым фактором было то, что в Kaiten сделали интеграцию по переносу тасков из Jira. Это позволило максимально быстро переехать на новый сервис и не тормозить разработку.

Jira и Kaiten устроены по-разному, это осложнило адаптацию команды

Несмотря на быстрый перенос данных, я не могу сказать, что переход дался нам очень просто, потому что Jira и Kaiten изначально устроены по-разному.

Вся разработка у нас ведется по Scrum-фреймворку, а Kaiten все-таки больше заточен под канбан. Конечно, в Kaiten тоже есть элементы Scrum, но под них нужно было переформатировать работу определенным образом.

Организовать процессы разработки и работу саппорта было несложно — инструменты Kaiten позволили нормально адаптировать их работу.

А вот перенос процессов продакт-менеджмента стал для нас камнем преткновения.

Мы постоянно развиваем и дорабатываем нашу платформу, поэтому от продактов у нас есть большой бэклог задач. В Jira можно было создавать scrum-доски, в которые продакты заносили огромный набор фич на год вперед. Все это выглядело как один длинный список, в котором было удобно фильтровать, приоритизировать и забирать в текущий спринт нужные user stories.

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

Так или иначе, мы приспособились к новому инструменту, и разбили пространства по терминологии Kaiten. Да, пришлось немного изменить формат, но в целом работа идет.

Как организовали работу в Kaiten на трех пространствах

Итак, в Kaiten мы создали три пространства под разные функции: Product, Support, и Developers.

Пространство продактов для работы с бэклогом

Для организации процессов продакт-менеджмента мы создали отдельное пространство. Нам важно было в удобном формате отобразить здесь те истории, которые в Jira хранились единым списком, и не запутаться в них.

Для этого мы разместили на пространстве доску, состоящую из трёх колонок: Epics, Pre-backlog и Backlog.

В эпиках лежат неотфильтрованные пользовательские истории.

Колонка Pre-backlog — это то, что уже имеет дизайн, но не имеет груминга по техчасти. В Jira это хранилось одним списком на год вперед, а в Kaiten мы здесь держим какое-то осмысленное количество историй.

После груминга эти карточки с историями попадают в колонку Backlog — то что уже зафиналено, дальше будет оцениваться и попадет к разработчикам.

После оценки продакт выделяет несколько карточек и отправляет их в пространство Разработки — то есть происходит планирование спринта. Мы стараемся делать максимально короткие user stories, чтобы они влезли в двухнедельную итерацию.

Пространство разработки: как работаем по спринтам и выполняем истории

В пространстве Developers у нас есть две доски: Stories и All tasks.

При планировании спринта отгрумленые и задизайненные истории попадают в пространство Developers, а именно на доску Stories на одну из двух дорожек: user stories или tech stories.

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

Когда эти этапы пройдены, карточка истории переходит «В работу». На этом этапе разработчики разбирают себе пункты чек-листа, за которые будут отвечать, и конвертируют их в соответствующие карточки на доске спринта — All tasks.

Дальнейшая работа ведется на том же пространстве, но на другой доске — All tasks.

Здесь лежат задачи, которые нужно закрыть, чтобы выполнить истории. Каждая карточка на этой доске является дочерней карточкой для истории, к которой относится. А ее размер, соответственно, берется из чек-листа, из которого она была сконвертирована.

По мере работы над задачами в спринте, карточки проходят все нужные этапы, пока не попадут в колонку «Готово к релизу». И после того как все дочерние карточки из истории окажутся в этой колонке, выполняется релиз самой истории — «готово».

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

Пространство саппорта для работы с инцидентами

Есть еще третье пространство, в котором работает Support. Они обрабатывают пожелания наших пользователей и работают с багами.

Здесь есть доска, на которую попадают найденные баги, и дальше фильтруются по колонкам: «подтвержден» — отсюда задачи забираются в пространство Developers, и «не подтвержден»  — то, что в итоге оказалось не багом.

Здесь же в пространстве Support продублирована доска All tasks из пространства Developers — это та же самая доска, на которой видно все карточки и их перемещения, только сотрудники поддержки не могут ничего в ней изменять. Зато могут следить за тем, что происходит с их карточками в разработке, когда они будут выполнены и т.д.

Как только карточка бага в пространстве Developers доходит до колонки «готово», срабатывает интеграция, и в канал поддержки в Slack приходит уведомление, что все готово, можно уведомить клиента.

Как отслеживаем скорость работы команды и отдельных сотрудников

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

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

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

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

Что мы имеем в итоге после переезда из Jira в Kaiten

Мы попытались оставить тот процесс, который у нас был в таск-трекере Jira, и при этом использовать Kaiten. В итоге получился некий симбиоз канбана и скрама — мы используем канбан-инструмент для организации работы по скрам-фреймворку. И это работает.

Да, он отличается от того, что было в Jira, но мы закрыли все свои потребности:

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

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