Меня зовут Артём Лопатин, я старший фронтенд-разработчик ЮMoney. В нашей компании работает тысяча человек, почти половина из них — IT-специалисты, в том числе 40 фронтенд-разработчиков. Чтобы мы могли развиваться и добиваться нужных результатов, вся эта большая команда должна работать как отлаженный механизм. Сегодня я расскажу, что нам в этом помогает, как устроены процессы в продуктовой команде и какие встречи есть у фронтендеров.

Структура команды

Я работаю в компании больше четырёх лет. За это время я успел побывать частью разных команд. Наши команды разработки укомплектованы классическим набором: продакт-менеджер, проджект-менеджер, аналитик, дизайнер, бекенд- и фронтенд-разработчики (обычно их по два в команде), тестировщики.

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

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

Как происходит работа в команде

Когда product owner приходит в команду с бизнес-идеей, её отдают аналитику и дизайнеру на проработку технического решения и макетов. Бэкенд- и фронтенд-разработчики с какой-то определённой периодичностью с ними встречаются, чтобы корректировать техническое решение. Затем разработчики приступают к анализу и декомпозиции проекта. Предложенное решение рассматривают, и из него формируются отдельные задачи, которые будут браться в разработку спринтами.

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

Автоматизируем процессы: как и зачем

Когда разработчик получил задачку, его работа начинается с ветки. У нас есть одна мастер-ветка, и каждый разработчик отделяет от неё фича-ветку, в которой пишет свой код. Менеджер следит за процессом в Jira. Здесь появляется первая автоматизация: при создании ветки задача в Jira автоматически переводится в нужный статус.

Готовый код идёт на проверку — сначала разработчик проверяет его сам (с помощью ESLint, Prettier, SonarQube, Jest), после чего направляет на ревью, где его отсматривают другие разработчики.

Из интересного — указание размера пулл-реквеста: S, M и L. Если у пулл-реквеста указан размер S, его можно посмотреть за пять минут. За счёт этого рвьюер сразу понимает, сколько примерно времени нужно на проверку кода.

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

Jenkins автоматически запускает проверку кода при добавлении новых коммитов в ветку. Проверка состоит их нескольких этапов, основные — это линтинг, юнит-тестирование, проверка версий зависимостей и проверка переводов.

Отдельно скажу про переводы. Раньше специалист вручную писал текст на русском, затем удалял ключи локализации, отдавал задачу переводчику, ждал и только после этого вставлял результат в код. Сейчас разработчику достаточно перевести задачу в Jira статус «Ожидание перевода», а Jenkins автоматически добавит переводы в пулл-реквест разработчика.

Помимо проверки кода, задача отправляется на проверку тестировщикам. Тестирование состоит из двух этапов: ручная проверка и регрессионное тестирование.

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

Встречи, ревью, опросы: как мы взаимодействуем

У нас много сервисов, поэтому разные команды часто работают вместе над одним или несколькими проектами. Чтобы их синхронизировать и свести к минимуму технические конфликты, мы регулярно проводим стендапы и технические синки. Ребята решают, что и как они делают и в какой последовательности. Также обсуждается совместная работа над качеством кода, над обновлением библиотек и использованием новых технологий.

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

Кроме встреч, которые непосредственно связаны с разработкой, есть и другие, направленные на улучшение взаимодействия в команде и компании, на развитие сотрудников. Например, Опрос 360, который проводится два раза в год по каждому разработчику. В процессе оцениваются Hard и Soft Skills специалистов, это помогает подсветить их сильные стороны и точки роста.

Вместо вывода: иллюстрация пользы автоматизации на примере деплоя релизов

Пять лет назад у нас выходило до двух тысяч релизов в год, они обрабатывались вручную. Их становилось всё больше, а нервных клеток у администраторов — всё меньше. Но теперь, когда процесс деплоя автоматизирован и релизы катятся автоматически, админы стали чаще улыбаться. При этом количество релизов превысило 10 тысяч в год.

А какие рабочие процессы автоматизированы у вас? Пишите в комментариях :)

Фронтенд Юмани: как пить чай, пока задачи доделываются сами