Привет, Хабр! Меня зовут Игорь Рарог, в Банке ДОМ.РФ я совмещаю две роли: лид команды и релиз-менеджер, и сегодня поделюсь своим опытом ведения проектов в Jira.
Вначале хочу рассказать о нашем проекте под названием «Апикс» — это ипотечный конвейер (о нем мы уже писали тут: Методология разработки и архитектура кредитного конвейера АПИКС в Банке ДОМ.РФ).
В команде нас более 100 человек, и мы поделены на продуктовые команды, где каждая отвечает за свою часть функциональности или бизнес-направление.
К примеру, одна из команд занимается заявочной частью: пилит фичи по работе с персональными данными клиента, дорабатывает openAPI для работы с партнерами и т.д.
Другая делает доработки для выдачи ипотеки клиенту, множество интеграций с шиной, АБС (Автоматизированная Банковская Система) и другими внешними сервисами.
Всего таких команд 10, причём одна из них, платформенная, занимается только техническим долгом и не реализует никаких бизнес-фич. Данная команда отвечает за оптимизацию разработанных микросервисов, рефакторинг, сокращение времени обработки запросов, развязыванием микросервисов и много чем еще интересным.
В каждой команде, за исключением команды тех. долга, есть следующие роли:
Тимлид, он же Scrum-master, он же координатор команды. Выстраивает удобные и прозрачные процессы в команде, помогает взаимодействовать с другими командами. Отвечает за ресурсы, сроки, поставки и другие активности типа дейли, груминга, ретро, планирования и т.д.
Продакт. Следит за своей частью продукта, строит по ней планы и перспективы развития.
Бизнес-аналитик. Прорабатывает и детализирует идеи продакта, рисует диаграммы, продумывает и описывает клиентский путь (CJM).
Системный-аналитик. Проектирует техническое решение, описывает требования для разработчиков, методы интеграции между микросервисами и другими системами.
Бэкенд-разработчик. Разрабатывает серверную часть: базу данных, DTO (Data Transfer Object), API и т.д.
Фронт-разработчик. Разрабатывает, соответственно, "фронтовую" часть. Делает так, чтобы у пользователя всё работало в UI, вёрстка была согласно дизайн-макетам, была реализована требуемая логика работы формы: вовремя появлялись лоадеры, выполнялись запросы на бек и т.д.
Тестировщик. Ответственный сотрудник, т.к. именно он (точнее, они — их у нас несколько в каждой команде, как и по другим ролям) определяет и решает, может ли задача пойти в релиз на прод или нет. Для этого они изучают требования аналитиков, пишут тест-кейсы к каждой доработке, вручную прогоняют заявки по бизнес-процессу, заводят баги в Jira, потом их перепроверяют и заполняют отчет по тестированию.
В процессе перехода на продуктовые команды были выработаны оптимальные размеры команд и соотношение ролей в них для нашей организации. В каждой команде по 10-15 человек: один тимлид, один продакт, один-два бизнес-аналитика, один-два системных-аналитика, два-три бэкенд-разработчика, два-три фронт-разработчика, два-три тестировщика.
В работе используем методику Scrum и основные активности: дейли, груминг, планирование, ретро, демо.
Дальше я расскажу, как мы выстроили прозрачные, понятные и удобные нам процессы, которые помогают эффективно работать такому большому количеству человек.
Кстати, раньше мы релизились один раз в месяц, а теперь переходим к релизам каждый спринт, т.е. каждые 2 недели. Мы долго шли к такому результату, и он получился благодаря сокращению регресионного тестирования с 10 до 7 дней, а также результатам работы команды, занимающейся техническим долгом. И теперь бизнес-заказчики могут оперативно получать свои доработки на проде через короткие промежутки времени.
Как наши команды работают в Jira
Каждая команда имеет свою метку (label) в Jira, которая определяет, к какой команде относится каждая заведенная задача:
Команда |
Метка (label) в Jira |
Личный Кабинет Ипотеки |
APIX-LKI |
Заявка и продукты |
APIX-A |
Сделка и выдача |
APIX-Z |
Сделка вне офиса |
APIX-DIGITAL |
Сопровождение |
APIX-S |
Единый Кредитный Конвейер |
APIX-EKK |
Задача может иметь две метки, если это эпик, в рамках которого каждая команда делает свою часть работ.
Иерархия задач
![](https://habrastorage.org/getpro/habr/upload_files/16d/78e/55b/16d78e55b8a66336d72cc04527ff0c07.png)
По количеству получается примерно следующее соотношение:
Каждая команда заводит 5-10 инициатив;
Каждая инициатива содержит от 3 до 10 эпиков;
Каждый эпик включает от 2 до 30 историй;
Каждая история может содержать по 1-3 подзадач на анализ, разработку, тестирование и большое количество дефектов.
В нашем проекте Jira создано много разных типов задач, это помогает вести работу в более прозрачном режиме, т.к. у каждого типа задачи свой workflow (рабочий процесс), что позволяет в моменте отслеживать детальные статусы каждой подзадачи или загрузку конкретного сотрудника.
Про workflow
Workflow – это рабочий процесс, который есть у каждого типа задач в Jira. Рабочий процесс представляет собой диаграмму возможных статусов этого типа задач и переходов между ними.
Пример:
![](https://habrastorage.org/getpro/habr/upload_files/c70/fef/5fd/c70fef5fd360ebc782b0a6dfc23e2ff9.png)
CAB (Change Advisory Board) – это комитет по изменениям, выполняющий проверку всех изменений, выкатываемых на прод в Банке. На комитете проверяются результаты тестирования, план выполнение работ, план отката и другие нюансы. В результате на прод устанавливаются только проверенные поставки, что сокращает количество сбоев и багов на бою.
Об основных типах задач, которые мы используем в своей команде (в действительности их чуть больше):
Инициатива
Тип задачи, основная цель которого объединить Эпики (дочерние задачи, более мелкие) в один крупный блок доработок, либо бизнес-направление, содержит максимально абстрактное описание границ планируемых доработок.
![](https://habrastorage.org/getpro/habr/upload_files/d5a/c39/2f4/d5ac392f4cbb8ca95d15cc398ea2e6a0.png)
Эпик
Данный тип задачи включает большой объем работ, который можно декомпозировать на несколько историй поменьше. Часто эпики объединяют истории нескольких команд. Эпик имеет более конкретные рамки и границы доработок, чем инициатива.
Выполнение эпика обычно занимает несколько спринтов, может доходить до нескольких кварталов.
Эпики связываются ссылками (link) с инициативой связью «Потомок от».
![](https://habrastorage.org/getpro/habr/upload_files/1bc/f0b/82f/1bcf0b82f278c9aa4d78070e97b64ca3.png)
История
Тип задачи, который имеет бизнес-ценность, это значит, что ее реализация и внедрение несет пользу для конечных пользователей. Данный тип задачи является неким аналогом фичи или доработки, используется для взятия в спринт и для поставки релиза на прод.
Истории связываются с эпиком через поле «Ссылка на эпик», у истории может быть только один эпик, а эпик в свою очередь может быть связан с несколькими историями.
![](https://habrastorage.org/getpro/habr/upload_files/fce/e67/7bf/fcee677bf39e81237d7895f3d5953d8f.png)
Рабочий процесс истории явно больше, чем у других типов, но именно такое количество статусов помогает нашим командам эффективно выполнять и контролировать задачи.
Например, тестировщику не нужно постоянно обращаться к разработчику, чтобы узнать, сделана ли задача или нет, а разработчику, в свою очередь, не нужно писать тестировщику, когда он сделал задачу, чтобы отдать её в тестирование.
Разработчик сделает задачу, история перейдет в статус "Готова к тестированию", что увидит тестировщик на Scrum-доске в Jira или email–отбивке.
Можно увидеть определенные этапы работы с историями:
Этап |
Статус |
Описание |
Backlog |
Backlog |
Начальное состояние, при заведении задачи в Jira, используется для дальнейшего планирования задачи из бэклога |
Бизнес-анализ |
Бизнес-анализ |
Первый этап работы с задачей – проработка бизнес-требований |
Дизайн |
Опциональный шаг, используется только при проектировании UI дизайнерами |
|
Системный анализ |
Готова к системному анализу |
Бизнес-анализ завершен, задача готова к взятию в системный анализ |
Системный анализ |
Второй шаг работы с задачей – проработка системных требований |
|
Груминг и оценка |
Готова к оценке |
Третий этап - обсуждение требований всей командой и оценка подзадач разработчиками и тестировщиками |
Разработка |
Готова к разработке |
Требования проработаны, оценки получены. В этом статусе находятся задачи, готовые к разработке |
Разработка |
Сама разработка |
|
Тестирование |
Готова к тестированию |
Задача разработана, то есть все подзадачи на разработку выполнены, можно переходить к тестированию |
Тестирование |
Тестирование |
|
Внедрение |
Готово к внедрению |
Задача протестирована, все баги исправлены, и она готова к поставке на прод |
Внедрено |
Задача установлена на прод |
Технический долг
Тип задачи, аналогичный истории, но используемый для реализации технических доработок, оптимизаций, рефакторинга, который не имеет прямую бизнес-ценность, но важен для технического развития системы.
Ошибки на продуктиве
Тип задачи, который используется для заведения багов (дефектов) с прода. Чаще всего такие типы задач создают коллеги из тех. поддержки по обращениям от пользователей.
Важно разделять баги и прод баги, чтобы понимать критичность ошибок именно на проде и отдельно — критичность багов, которые на тесте.
Релиз
Тип задачи, используемый для поставки и внедрения релиза или хотфикса на прод.
Да-да, для релизов мы используем свой тип задачи, со своим рабочим процессом, чтобы даже процесс поставки релиза или хотфикса на прод можно было отслеживать.
Подзадачи
В своей работе мы используем подзадачи, чаще всего они заводятся к типу "история" или же "технический долг", но бывают исключения из правил.
Декомпозиция истории на подзадачи важна, т.к. именно она позволяет получить прозрачность процесса в работе команды.
Для чего же нужны подзадачи
Если бы их не было, то было бы непонятно, что делает бэкенд-разработчик по конкретной истории, а что фронт, а тестирование? Процесс работы с историей, основным типом задач для работы команды, выглядел бы очень верхнеуровнево. Было бы невозможно оценить отдельно каждое направление, процент выполнения и много другое.
Подзадачи делятся на несколько типов и у каждого типа могут быть разные префиксы в названии:
Подзадача на анализ
Тип задачи, который используется для проведения анализа, чаще всего бизнес- или системного анализа, но бывает и для анализа разработки или тестирования.
В названии задачи указывается один из префиксов [BA] (бизнес-анализ), [SA] (системный-анализ) в зависимости от того сотрудник какой роли проводит анализ. Префикс служит для дальнейшей фильтрации таких задач.
Подзадача на разработку
Тип задачи в рамках которого разработчик реализует доработку, в описании задачи всегда должна быть указана постановка от системного или бизнес аналитика.
В названии указывается префикс [BE] (backend-разработка) или [FE] (frontend-разработка), также для фильтрации.
![](https://habrastorage.org/getpro/habr/upload_files/d88/76f/fc4/d8876ffc4a979dd2f46cbdbbf37d04c7.png)
Подзадача имеет отдельные статусы для разработки, проведения Code review и Ready for merger, чтобы детально понимать, по какой части истории уже написали код и нужно коллегам провести ревью, по какой провели ревью и можно мержить в девелоп, а какая уже смержена.
Подзадача на тестирование
Тип задачи, который используется для написания тест-кейсов и тестирования определенной функциональности, описанной в Истории (родительской задаче) или Техническом долге.
В названии указывается префикс [QA].
Подзадача: дефект
Тип задачи, который используется при заведении багов (дефектов) к конкретной истории или техническому долгу. Бага переводится на разработчика для исправления дефекта, а после исправления вновь возвращается автору задачи – тестировщику, чтобы проверить результат исправлений.
![](https://habrastorage.org/getpro/habr/upload_files/ea8/226/8f1/ea82268f10c4c79b387358810c1ddd82.png)
Доски
Также у каждой команды создана своя доска в Jira с нужными настройками: колонками, дорожками и фильтрами. Тут нет общих правил, каждая команда может кастомизироваться так, как ей удобно, главное, чтобы все дедлайны и поставленные планы были соблюдены.
Давайте рассмотрим в качестве примера доску команды ЛКИ (Личный Кабинет Ипотеки):
![](https://habrastorage.org/getpro/habr/upload_files/abd/1af/7e8/abd1af7e87c6ed9af8c68b7eb252d554.png)
Начнём с колонок:
Sprint backlog
В колонке располагаются все задачи в начальных статусах, которые взяли в текущий спринт. Именно из этой колонки каждый член команды берет задачи в работу во время спринта.
Blocked
Задача перемещается в эту колонку, если ее реализация заблокирована на текущий момент времени или она чего-то ожидает, причины могут быть разные:
Ожидаем ответ другого члена команды, который нельзя получить оперативно;
Ожидаем ответ от другой команды или системы;
Задача зависит от другой задачи, которую не взяли в реализацию;
Имеются какие-то технические проблемы, к примеру, со стендом и т.д.
In progress
Задача в процессе реализации. Обычно здесь располагаются задачи разработки либо аналитиков.
И другие задачи на разработку, например, баги на исправления.
Code Review
Колонка, используемая разработкой после того, как задача была разработана и по ней необходимо провести код-ревью. Когда скапливается определенное количество таких задач, команда разработки (бэкенд или фронтенд) собирается и совместно в онлайн-форме проводит ревью задач.
Ready for merge
Колонка, в которую задача на разработку помещается после проведения код-ревью. Означает, что задача готова к мержу в девелоп-ветку. Когда все подзадачи на разработку у одной истории находятся в данной колонке, это означает, что историю можно передавать в тестирование, за этим следит тимлид.
QA
Данная колонка аналогична In progress, но для тестировщиков: в ней отображаются все задачи тестирования. Также в эту колонку попадают баги, которые были исправлены, и по ним нужно провести ретест.
Done
Колонка с финальными статусами задач, которые были смержены, закрыты, поставлены в релизе и т.д.
Дорожки
Чаще всего в командах используются настройки Jira-досок либо по исполнителям (assignee) либо по историям.
Возможны оба формата, и они применяются в разных командах для проведения дейли.
Быстрые фильтры
В основном в командах используются фильтры: по исполнителям, по релизам, по командам. Всё зависит опять же от доски и потребностей: для разбора и анализа продбагов используются фильтры команд с их метками, для командной работы и реализации доработок используются по исполнителям.
Как доски Jira помогают в проведении дейли-митингов
У нас распределенные команды, поэтому дейли проводятся в онлайн-формате – тимлид либо ведущий дейли шарит доску.
Варианты использования доски для проведения дейли:
В случае дорожек по исполнителям и фильтрам по людям выбираем в фильтре конкретного сотрудника, который рассказывает, что делал, чем планирует заниматься и какие у него проблемы. На доске отображаются только его задачи, все разделены по колонкам, где наглядно видно актуальность данных.
Таким образом, исключаются задачи, которые влетают на сотрудника вне спринта и вне тимлида, а если влетели, то как раз их сразу видно и можно отработать.
![](https://habrastorage.org/getpro/habr/upload_files/e46/5fa/58c/e465fa58c3695b8cf04eaaf282137bd3.png)
В других командах дейли проводят по историям, в данном случае рассказывает не человек, а команда проходится по всем историям спринта, и исполнители подзадач рассказывают про статус, проблемы и т.д.
Цифровой профиль
На примере реализации доработок по интеграции с Цифровым профилем расскажу, как в реальности были декомпозированы задачи:
В рамках инициативы «Вход и регистрация» был создан эпик «Цифровой профиль», в описании общие формулировки и требования для формирования границ будущих доработок;
В эпике было заведено 14 историй, заводились они постепенно, не все сразу, по мере проработки требований. Первые истории были для запуска MVP на проде, а последующие для развития. В каждой из них детальное описание необходимых доработок;
Часть историй оперативно прошли этапы анализа и ушли в разработку разным командам, а другая часть ожидает своего приоритета относительно бэклога;
После завершения этапа разработки потребовалось совместное тестирование нескольких команд, для этого каждая из них в своей истории завела подзадачу на тестирование.
После исправления багов в обеих историях данные доработки были запланированы к поставке в релиз на прод.
Названия спринтов
Спринты называются меткой команды, далее — последние две цифры года, порядковый номер спринта текущего года и даты спринта.
Например: APIX-LKI 23.7 [23.1–3.2]
Даты проведения спринта указываются и в настройках спринта в Jira, но это не всегда удобно для бизнес-заказчиков, которые хотят понять какие доработки в какой временной период (спринт) будут взяты в работу. В таком случае, открыв нужную задачу, сразу будет видно, не только в каком спринте она будет взята в работу, но и его даты.
![](https://habrastorage.org/getpro/habr/upload_files/f96/700/6d5/f967006d5b5d5126617b82f5f58fceaf.png)
Груминг и оценка задач
Истории оцениваются по направлениям: бэкенд [BE], фронтенд [FE], тестирование [QA].
Системный аналитик приносит на груминг историю, которую он проработал, описал и про которую готов рассказать команде. После рассказа разработчики и тестировщики задают вопросы, и каждый сотрудник выбирает карточку с количеством часов, которое, по его мнению, необходимо потратить на реализацию задачи.
Бэкенд-разработчики указывают часы только на свою часть разработки и написание тестов, фронт-разработчики — на свою, и тестировщики тоже. Каждый сотрудник при этом не видит, что выбрал другой. Это нужно, чтобы каждый член команды понимал объем задачи, и если оценки слишком сильно отличаются, тогда стоит ещё раз обсудить постановку.
Вероятно, у кого-то меньше опыта и ему требуется больше времени на реализацию – это нормально. А может быть, есть проблемы с пониманием задачи, и тогда какие-то моменты стоит еще раз проговорить голосом.
Баги, недоступность стендов, коммуникация и другие активности не учитываются при оценке.
Полученные оценки указываются в подзадачах, каждая в соответствующих: бэк, фронт, тестирование.
Трекинг времени
Каждый сотрудник списывает потраченное время на конкретную подзадачу в Jira, списание времени в истории запрещено. Данное время в дальнейшем учитывается в аналитике работы команды: насколько команда в целом или кто-то конкретно точно оценивают задачи. Если не точно, то почему, сколько команда вырабатывает времени за спринт и т.д.
Вероятно, кто-то из читающих скажет про стори-поинты и спросит, почему же мы их не используем?
Отвечаю: на эту темы мы провели несколько встреч, и были разные мнения, но мы поняли, что нам удобно работать по человеко-часам, и такая работа выглядит более прозрачной для наших заказчиков.
Дополнительные задачи для коммуникаций
Помимо основных задач для реализации доработок в Jira можно/нужно завести задачи для общекомандных активностей, встреч, коммуникаций, передачи знаний, код-ревью, ретро и т.д.
Например, это может выглядеть так:
![](https://habrastorage.org/getpro/habr/upload_files/b1f/fae/024/b1ffae024b5531b36c10f69001f4c6ca.png)
Автоматизация Jira
В нашем проекте реализованы триггеры, например:
При переводе задачи типа "релиз" в финальный статус все задачи, где указана fix version (релиз), тоже переводятся в финальный статус. Таким образом мне как релиз менеджеру не приходится вручную проходиться по всему списку внедренных задач, чтобы вручную их перевести в финальный статус. Также это решает проблему, когда кто-то вручную перевел задачу в финальный статус, хотя её не внедряли на прод.
После перевода всех подзадач на разработку в статус Merged сама история автоматически переводится в статус "готова к тестированию". Это минимизирует забывчивость коллег переводить в нужный статус историю, а тестировщики получают отбивку и начинают тестирование.
Также мы используем плагин для Jira — BigPicture, и дашборды с rich-фильтрами, но об этом в другой раз.
Комментарии (8)
nagumanov174
13.01.2023 14:19+1Разработчик, просто помни это: https://macode.ru/
UnclShura
13.01.2023 14:38Это, кстати, единственно верная методология.
А про статью чтоб два раза не вставать - у таски для разработчика есть всего два состояния - "никто не смотрит" и "сделано". Если появляется "в работе" значит или декомпозиция сделана неправильно (задача слишком большая) или бюрократы захватили планету (по-моему это как раз вариант из статьи). Когда у таски есть готова к тестированию, готова к мерджу, смерджена... мне это напоминает сцену из фильма "Космические М...звоны" (он-же Космические Яйца):- "Приготовиться к перометке вперед!"
- "Есть приготовиться к перемотке вперед!"
- "Перемотка вперед!"
- "Есть перемотка вперед!"
Это они так видео перематывали :) Посмотрите на диаграмму "работа с историей" и поплачьте. Как-то проще надо быть.
Rarog_Igor
13.01.2023 15:11Понимаю долю иронии и сарказма)
Со стороны это выглядит так, но когда нужно управлять 120 сотрудниками, то такая схема работает.
Если говорить конкретнее - статусы: разработка, code review, ready for merge и merge устраивают самих разработчиков.
В статус code review переводятся задачи, отправленные на ревью команде, пока проходит этот процесс разработчику не нужно думать какие это были задачи, он спокойно берёт следующие в работу.
Статус ready for merge нужен для лидов, чтобы понимать когда задача выполнена и её можно будет мержить в девелоп.
Статус Merge - это просто финальный статус, означающий, что работа с задачей завершена.
Что касается Истории, то там реализована автоматизация, которая описана в статье, поэтому разработчику не нужно делать лишних действий, кроме своей подзадачи, далее JIRA всё сделает за него.
Мы постоянно оптимизируем процессы и вся команда активно в этом участвует, поэтому разработчики тоже довольны.
Elenberg11
13.01.2023 15:48+2Гипотетическая ситуация: Вы пришли на работу, Вам сказали: садись, пиши код, не буду мешать.
Ваши действия?
(???)Многие разработчики страдают мнением, что все эти смешные скрамы, канбаны, смузи придуманы только для того, чтобы им мешали писать код, а глупые менеджеры и аналитики сосали деньги из бухгалтерии и жрали печеньки.
В реальности же, все это нацелено как раз на то, чтобы разработчик писал код и не занимался всякой посторонней деятельностью.
Справедливости ради, манифест из ссылки работает в команде размером 3 человека. Когда руководитель команды/проекта может держать все в голове или у себя в блокнотике.
Расскажите про свой опыт, будет интересно почитать.
velipre_xella
16.01.2023 09:57Если не секрет, сколько часов уходит на задачу "Простой из-за отсутствия доступов"?
Elenberg11
Спасибо за статью!
С джирой никогда не работал и здесь у меня вопросы:
Есть ли у вас интеграции с фигмой/гитом? Как ведете документацию? Как все это выглядит в работе? И кто все это настраивает?
Rarog_Igor
Есть интеграция с гитом, все МРы и коммиты линкуются к подзадачам. На сколько мне известно, то в JIRA имеется интеграция с фигмой, но ей мы пока не пользуемся.
Вся документация ведётся в confluence (wiki), со ссылками на задачи JIRA и в задачах тоже указываются ссылки на страницы wiki. Если очень верхнеуровнево, то имеются следующие крупные разделы: бизнес анализ, системный, разработка, тестирование, релизы, организационная часть и т.д.
В разработке описаны все микросервисы: модель данных и методы.
Аналитика декомпозирована на функциональные блоки, которые в свою очередь делятся на более мелкие, где системный аналитик и описывает требования.
Фактическую настройку workflow, автоматизации и правил выполняют администраторы JIRA, а сами идеи - что и как должно работать, как удобно выстроить процесс - занимаются все члены команды) в основном конечно лиды и продакты.
Elenberg11
Спасибо за ответ! Жду развернутую статью по ведению проектной документации)