Как мы перешли из Jira в российский таск-трекер Kaiten

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

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

Наши разработчики работают по Scrum-фреймворку, и понятно, что для организации этих процессов нужен функциональный таск-трекер. И до февраля 2022 мы использовали для этого Jira и Confluence. Но по понятным причинам нам пришлось искать отечественный аналог.

Расскажу, как именно мы выбирали подходящий сервис, что было самым сложным из-за разницы между Jira и новым таск-трекером и как нам удалось переложить существующие scrum-процессы на особенности канбан-инструмента.

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

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

В итоге уже 8 месяцев разработчики, product-management и support-отдел работают в Kaiten.

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

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

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

С таким списком удобно работать — все задачи видно сразу, можно их легко фильтровать, приоритизировать и забирать в текущий спринт нужные user stories.

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

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

Основная сущность для работы с задачами в Kaiten — это пространства. На пространствах находятся канбан-доски с карточками. Вот так это выглядит:

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

Расскажу, как устроено каждое из них.

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

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

Получается, что то, что в Jira мы фильтровали в самом списке, здесь теперь разложено по разным колонкам доски:

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

После оценки продакт выделяет несколько карточек и отправляет их в пространство Разработки — то есть происходит планирование спринта.

В Kaiten можно расположить несколько досок на одном пространстве и просматривать их на одном экране. В пространстве Developers у нас есть доски: Stories (для удобной работы с историями) и All tasks (доска спринта).

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

Каждую такую историю мы разбиваем на подзадачи, которые нужно выполнить, чтобы закрыть ее. Эти подзадачи заносятся пунктами в чек-лист внутри карточки.

Каждому пункту чек-листа мы присваиваем размер. Финальный размер истории — это сумма размеров всех пунктов её чек-листа.

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

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

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

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

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

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

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

В Kaiten можно расположить одну и ту же доску одновременно на нескольких пространствах вместе со всеми ее карточками. Поэтому на пространстве Support продублирована доска All tasks (Доска спринта) из пространства Разработчиков.

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

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

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

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

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

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

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

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

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

#scrum #jira #российскоепо