Управление IT-командой в Jira: опыт Банка ДОМ.РФ

Привет, Хабр! Меня зовут Игорь Рарог, в Банке ДОМ.РФ я совмещаю две роли: лид команды и релиз-менеджер, и сегодня поделюсь своим опытом ведения проектов в Jira.

Вначале хочу рассказать о нашем проекте под названием «Апикс» — это ипотечный конвейер (о нем мы уже писали тут: Методология разработки и архитектура кредитного конвейера АПИКС в Банке ДОМ.РФ).

В команде нас более 100 человек, и мы поделены на продуктовые команды, где каждая отвечает за свою часть функциональности или бизнес-направление.

К примеру, одна из команд занимается заявочной частью: пилит фичи по работе с персональными данными клиента, дорабатывает openAPI для работы с партнерами и т.д. 

Другая делает доработки для выдачи ипотеки клиенту, множество интеграций с шиной, АБС (Автоматизированная Банковская Система) и другими внешними сервисами.

Всего таких команд 10, причём одна из них, платформенная, занимается только техническим долгом и не реализует никаких бизнес-фич. Данная команда отвечает за оптимизацию разработанных микросервисов, рефакторинг, сокращение времени обработки запросов, развязыванием микросервисов и много чем еще интересным.

В каждой команде, за исключением команды тех. долга, есть следующие роли:

• Тимлид, он же Scrum-master, он же координатор команды. Выстраивает удобные и прозрачные процессы в команде, помогает взаимодействовать с другими командами. Отвечает за ресурсы, сроки, поставки и другие активности типа дейли, груминга, ретро, планирования и т.д.

• Продакт. Следит за своей частью продукта, строит по ней планы и перспективы развития.

• Бизнес-аналитик. Прорабатывает и детализирует идеи продакта, рисует диаграммы, продумывает и описывает клиентский путь (CJM).

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

• Бэкенд-разработчик. Разрабатывает серверную часть: базу данных, DTO (Data Transfer Object), API и т.д.

• Фронт-разработчик. Разрабатывает, соответственно, "фронтовую" часть. Делает так, чтобы у пользователя всё работало в UI, вёрстка была согласно дизайн-макетам, была реализована требуемая логика работы формы: вовремя появлялись лоадеры, выполнялись запросы на бек и т.д.

• Тестировщик. Ответственный сотрудник, т.к. именно он (точнее, они — их у нас несколько в каждой команде, как и по другим ролям) определяет и решает, может ли задача пойти в релиз на прод или нет. Для этого они изучают требования аналитиков, пишут тест-кейсы к каждой доработке, вручную прогоняют заявки по бизнес-процессу, заводят баги в Jira, потом их перепроверяют и заполняют отчет по тестированию.

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

В работе используем методику Scrum и основные активности: дейли, груминг, планирование, ретро, демо.

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

Кстати, раньше мы релизились один раз в месяц, а теперь переходим к релизам каждый спринт, т.е. каждые 2 недели. Мы долго шли к такому результату, и он получился благодаря сокращению регресионного тестирования с 10 до 7 дней, а также результатам работы команды, занимающейся техническим долгом. И теперь бизнес-заказчики могут оперативно получать свои доработки на проде через короткие промежутки времени.

Как наши команды работают в Jira

Каждая команда имеет свою метку (label) в Jira, которая определяет, к какой команде относится каждая заведенная задача:

Задача может иметь две метки, если это эпик, в рамках которого каждая команда делает свою часть работ.

Иерархия задач

По количеству получается примерно следующее соотношение:

1. Каждая команда заводит 5-10 инициатив;

2. Каждая инициатива содержит от 3 до 10 эпиков;

3. Каждый эпик включает от 2 до 30 историй;

4. Каждая история может содержать по 1-3 подзадач на анализ, разработку, тестирование и большое количество дефектов.

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

Про workflow

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

Пример:

CAB (Change Advisory Board) – это комитет по изменениям, выполняющий проверку всех изменений, выкатываемых на прод в Банке. На комитете проверяются результаты тестирования, план выполнение работ, план отката и другие нюансы. В результате на прод устанавливаются только проверенные поставки, что сокращает количество сбоев и багов на бою.

Об основных типах задач, которые мы используем в своей команде (в действительности их чуть больше):

Инициатива

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

Эпик

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

Выполнение эпика обычно занимает несколько спринтов, может доходить до нескольких кварталов.

Эпики связываются ссылками (link) с инициативой связью «Потомок от».

История

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

Истории связываются с эпиком через поле «Ссылка на эпик», у истории может быть только один эпик, а эпик в свою очередь может быть связан с несколькими историями.

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

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

Разработчик сделает задачу, история перейдет в статус "Готова к тестированию", что увидит тестировщик на Scrum-доске в Jira или email–отбивке.

Можно увидеть определенные этапы работы с историями:

Технический долг

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

Ошибки на продуктиве

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

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

Релиз

Тип задачи, используемый для поставки и внедрения релиза или хотфикса на прод.

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

Подзадачи

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

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

Для чего же нужны подзадачи

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

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

Подзадача на анализ

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

В названии задачи указывается один из префиксов [BA] (бизнес-анализ), [SA] (системный-анализ) в зависимости от того сотрудник какой роли проводит анализ. Префикс служит для дальнейшей фильтрации таких задач.

Подзадача на разработку

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

В названии указывается префикс [BE] (backend-разработка) или [FE] (frontend-разработка), также для фильтрации.

Подзадача имеет отдельные статусы для разработки, проведения Code review и Ready for merger, чтобы детально понимать, по какой части истории уже написали код и нужно коллегам провести ревью, по какой провели ревью и можно мержить в девелоп, а какая уже смержена.

Подзадача на тестирование

Тип задачи, который используется для написания тест-кейсов и тестирования определенной функциональности, описанной в Истории (родительской задаче) или Техническом долге.

В названии указывается  префикс [QA].

Подзадача: дефект

Тип задачи, который используется при заведении багов (дефектов) к конкретной истории или техническому долгу. Бага переводится на разработчика для исправления дефекта, а после исправления вновь возвращается автору задачи – тестировщику, чтобы проверить результат исправлений.

Доски

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

Давайте рассмотрим в качестве примера доску команды ЛКИ (Личный Кабинет Ипотеки):

Начнём с колонок:

Sprint backlog

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

Blocked

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

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

• Ожидаем ответ от другой команды или системы;

• Задача зависит от другой задачи, которую не взяли в реализацию;

• Имеются какие-то технические проблемы, к примеру, со стендом и т.д.

In progress

Задача в процессе реализации. Обычно здесь располагаются задачи разработки либо аналитиков.

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

Code Review

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

Ready for merge

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

QA

Данная колонка аналогична In progress, но для тестировщиков: в ней отображаются все задачи тестирования. Также в эту колонку попадают баги, которые были исправлены, и по ним нужно провести ретест.

Done

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

Дорожки

Чаще всего в командах используются настройки Jira-досок либо по исполнителям (assignee) либо по историям.

Возможны оба формата, и они применяются в разных командах для проведения дейли. 

Быстрые фильтры

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

Как доски Jira помогают в проведении дейли-митингов

У нас распределенные команды, поэтому дейли проводятся в онлайн-формате – тимлид либо ведущий дейли шарит доску.

Варианты использования доски для проведения дейли:

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

2. В других командах дейли проводят по историям, в данном случае рассказывает не человек, а команда проходится по всем историям спринта, и исполнители подзадач рассказывают про статус, проблемы и т.д. 

Цифровой профиль

На примере реализации доработок по интеграции с Цифровым профилем расскажу, как в реальности были декомпозированы задачи:

1. В рамках инициативы «Вход и регистрация» был создан эпик «Цифровой профиль», в описании общие формулировки и требования для формирования границ будущих доработок;

2. В эпике было заведено 14 историй, заводились они постепенно, не все сразу, по мере проработки требований. Первые истории были для запуска MVP на проде, а последующие для развития. В каждой из них детальное описание необходимых доработок;

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

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

После исправления багов в обеих историях данные доработки были запланированы к поставке в релиз на прод.

Названия спринтов

Спринты называются меткой команды, далее — последние две цифры года, порядковый номер спринта текущего года и даты спринта.

Например: APIX-LKI 23.7 [23.1–3.2]

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

Груминг и оценка задач

Истории оцениваются по направлениям: бэкенд [BE], фронтенд [FE], тестирование [QA].

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

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

Вероятно, у кого-то меньше опыта и ему требуется больше времени на реализацию – это нормально. А может быть, есть проблемы с пониманием задачи, и тогда какие-то моменты стоит еще раз проговорить голосом.

Баги, недоступность стендов, коммуникация и другие активности не учитываются при оценке.

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

Трекинг времени

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

Вероятно, кто-то из читающих скажет про стори-поинты и спросит, почему же мы их не используем? 

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

Дополнительные задачи для коммуникаций

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

Например, это может выглядеть так:

Автоматизация Jira

В нашем проекте реализованы триггеры, например:

1. При переводе задачи типа "релиз" в финальный статус все задачи, где указана fix version (релиз), тоже переводятся в финальный статус. Таким образом мне как релиз менеджеру не приходится вручную проходиться по всему списку внедренных задач, чтобы вручную их перевести в финальный статус. Также это решает проблему, когда кто-то вручную перевел задачу в финальный статус, хотя её не внедряли на прод.

2. После перевода всех подзадач на разработку в статус Merged сама история автоматически переводится в статус "готова к тестированию". Это минимизирует забывчивость коллег переводить в нужный статус историю, а тестировщики получают отбивку и начинают тестирование.

Также мы используем плагин для Jira — BigPicture, и дашборды с rich-фильтрами, но об этом в другой раз.