Как сделать структуру в jira

Добавил пользователь Дмитрий К.
Обновлено: 05.10.2024

Екатерина Базылева, менеджер a1qa, сертифицированный Scrum-мастер и SAFe Agilist, рассказывает об инструментах JIRA, которые позволяют планировать Agile-проекты, управлять ими и отслеживать эффективность работы команды.

Как инструменты JIRA помогают выполнить работу по гибким методологиям?

В первую очередь эта статья будет полезна тем, кто:

Начнём. У каждого менеджера проекта есть to-do list из рабочих задач и, возможно, даже не один. У кого-то список состоит из множества мелких задач одного проекта, у кого-то включает несколько проектов.

Нередко выполнение задач зависает, при этом к ним постоянно добавляются новые. Мы периодически перебираем этот список и верим, что вот завтра, хотя нет, лучше в понедельник начнём разбирать его. Знакомо?

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

Для этого достаточно выполнить 5 шагов.

ШАГ 1 — Создание и настройка Agile Board

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

Вот так выглядит Agile Board по умолчанию:

Теперь настроим его под себя.

Настраиваем колонки (Columns). Они будут отражать жизненный цикл задач. При этом можно настроить произвольное количество колонок и дать им свои названия.

На борд можно добавить дорожки (Swimlanes), которые помогут структурировать задачи. Среди доступных вариантов можно выбрать дорожки по группе задач (Epics), по исполнителю (Assignee) или по задачам (Stories). Последний вариант особенно удобен, если активно используются подзадачи. Также дорожки можно настроить по собственным фильтрам (или вовсе обойтись без них).

Для того чтобы скрыть или, наоборот, показать специфические задачи, можно добавить быстрые фильтры (Quick Filters) и, например, отфильтровать только задачи на обновление тестовой документации или задачи конкретного QA-инженера. Фильтры задаются через JQL-запросы.

В конце нужно определиться, в каких единицах будут оцениваться задачи. Самые распространённые варианты – это стори-поинты (Story Points) и часы, но могут быть и другие единицы, предлагаемые JIRA.

ШАГ 2 — Упорядочение списка задач в бэклоге

В каждом из проектов создаём группы задач (Epics), которые будут отражать основные направления деятельности. Например, усовершенствование процессов, обновление тестовой документации, регрессионные тесты.
Можно также обозначить и релизы, т. е. сроки, к которым надо что-то завершить.
Сами задачи из to-do list станут пользовательскими историями (user stories), связанными с направлением работы и при необходимости привязанными к релизу.

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

Итак, мы создали и настроили Agile Board в JIRA и составили бэклог с задачами. Что же дальше?

ШАГ 3 — Планирование спринтов

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

Определяем продолжительность спринта. Решите, будет ли это неделя, две недели, месяц или другой период времени.
Считаем емкость (Capacity) команды на спринт.

Capacity – объем работы, который команда может сделать в течение спринта. Эта цифра учитывает доступность людей, а также тот факт, что люди будут работать над задачами спринта не всё своё время. Часть времени будет уходить на коммуникацию внутри команды и другие активности.

Например:
Размер команды – 2 специалиста, занятых полный рабочий день.
Продолжительность спринта – 2 недели.
Общее количество рабочих часов – 160. При этом мы знаем, что одному из инженеров нужно пройти тренинг по веб-сервисам (16 часов) и на коммуникацию по задачам у команды уходит 20% рабочего времени.
Итого, capacity на спринтовые задачи получится (160-16)*0,8=115,2 ч.

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

ШАГ 4 — Выполнение спринта

Настало время выполнить набранные задачи, т. е. завершить спринт.

На шаге 1 мы создавали и настраивали Agile Board. Теперь он поможет нам проследить, на каком этапе находится каждая из задач, кто и какую задачу выполняет.

Можно сразу назначить каждой задаче исполнителя. Если ваша команда достаточно самоорганизованная, то ребята могут сами брать себе задачу из списка свободных. Как только пользователь передвигает задачу в In Progress, он автоматически становится ее исполнителем.

Если вы регулярно логируете время и обновляете Remaining Time, то сможете использовать график сгорания, или график хода выполнения работ (Burndown Chart). Он покажет ваш прогресс по отношению к цели спринта и поможет оценить шансы на его успешное завершение.

Серая линия на графике показывает идеальный ход выполнения проекта.

Красная линия – объём незакрытых задач, зелёная – потраченное время. Если красная линия справа снизу встречается с серой в одной и той же точке – это лучший вариант развития событий.

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

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

ШАГ 5 — Завершение спринта, ретроспектива

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

Ретроспектива: на что обратить внимание?

Velocity – это скорость работы команды, тот объём, который команда может завершить за спринт. Завершить – это значит закрыть задачу и переместить ее в колонку Done.

Вот мы и выполнили последний шаг нашего Agile-проекта.

Как видите, 5 шагов к Agile действительно просты. Давайте ещё раз их перечислим:

Создать и сконфигурировать Agile Board.
Упорядочить задачи в бэклоге.
Запланировать спринт.
Выполнить спринт.
Провести ретроспективу.

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

06.12.2021 | Жилкин Игорь, Иванов Никита, г. Иркутск | 0

В прошлых JQL часть 1 и JQL часть 2, мы рассматривали внутренний язык Jira — JQL.

Возможности Jira позволяют создать доску типа Scrum или Kanban. Данные доски помогают эффективно управлять проектом. Рассмотрим создание досок типа Kanban.

Kanban — это гибкий инструмент управления проектами, предназначенный для визуализации работы, ограничения объема незавершенных работ и максимизации эффективности выполнения задач. Это помогает как agile командам, так и командам DevOps навести порядок в повседневной работе.

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

Основными элементы канбан-доски являются следующие пять компонентов: визуальные сигналы (1), столбцы (2), лимиты незавершенной работы (3), точка обязательства (4) и точка доставки (5).

С чего начать работу с канбан-доской? Конечно же с ее создания!

Для создания канбан-доски мы можем через просмотр всех досок нажать на кнопку “Создать доску” и у нас выскочит окошко с выбором доски Scrum или Kanban. Выбираем “Создание доски Kanban”.

Для него заранее создадим фильтр с названием “Покупка”, который поможет нам найти задачи в названии которых содержится слово “Купить”, созданные после 1 октября 2021 года и за авторством текущего пользователя, Марины (Marina7) и Алексея (Alex). Подумайте самостоятельно, как написать такой фильтр (ответ в конце статьи).

Нажимаем “Создать доску”. Поздравляю, у нас создалась доска на основе сохраненного фильтра!

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

Теперь рассмотрим на API составляющую Kanban-досок в Jira. Для простоты воспользуемся python с предустановленной библиотекой JIRA. С помощью нее найдем все доски, куда мы имеем доступ.

Для начала инициируем библиотеку:

Далее заполним необходимые данные:

Подключимся к серверу:

С помощью метода board() получим названия и id досок, к которым у нас имеется доступ. Непосредственно id используется как значение rapidView в ссылках на доску – так давайте создадим еще и ссылки на эти доски.

Также рассмотрим поиск задач с помощью JQL. Для начала объявим переменную jql с самим запросом. Пусть в запросе будут задачи, созданные текущим пользователем, где он не является исполнителем.

Далее с помощью search_issues найдем и запишем в переменную issues найденные задачи.

Самими часто используемыми дополнительными параметрами search_issues являются:

maxResults – устанавливаем числом максимальное количество задач, которое нам достаточно найти или ставим значение False, когда мы хотим найти все задачи;
expand – дополняем наш запрос дополнительной информацией по задаче, например, историей изменений (‘changelog’).
fields – тут можем указать список интересующих нас полей, другие при этом выгружаться не будут.

В переменных issues_1 и issues_2 хранятся объекты JIRA Issue.

Для отображения информации по объекту пройдемся по каждой найденной задаче и покажем некоторые значения полей при помощи цикла for.

Создавайте, практикуйтесь и повышайте эффективность своей работы!

Ответ: summary ~ Купить and reporter in (currentUser(), Alex, Marina7) AND created

Если вы хотите узнать подробнее о типах задач в Jira — вы в правильном месте.

В этой статье мы разберемся с определениями issue, эпик (epic), история (story), задача (task), под-задача (sub-task) и баг (bug), посмотрим зачем они нужны и как они связаны.

Что такое Issue в Jira?

Все задачи, созданные в Jira, называются issue (или “проблема”).

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

Проблема соответствует определенной части работы, которую нужно сделать.
Каждой проблеме присваивается уникальный ID, по которому ее можно легко найти.

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

Изначально в Jira есть 5 базовых типов проблем, но, при необходимости, их можно дополнять / изменять / удалять.

Что такое Эпик (Epic) в Jira?

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.

Для примера можем рассмотреть эпик “Разработать блог для сайта N”.

Под “разработать” может подразумеваться:

Проработать структуру блога

Создать дизайн

Разработать, протестировать блог

Подготовить аналитику

Подготовить начальный контент

Развернуть и запустить блог

…

Как мы видим, объем работ — большой. Количество людей, которые будут принимать участие в работе — большое. Время на реализацию — явно не 2 часа 🙂

Все характеристики эпика соблюдены)

Основное предназначение эпика — организация работ.

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

Из-за своего объема и абстрактности эпики всегда разбиваются на части, которые описывают более конкретные “шаги” для решения проблемы.

Эти части называются история и задача.

Если вы хотите разобраться в эпиках более детально:

Что такое История (Story / User Story) в Jira?

История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.

Она описывает реализуемую работу (или функционал) с точки зрения конечного пользователя и, обычно, имеет заголовок вида:
Как [тип клиента], [хочу/могу то-то], [чтобы делать что-то]

Если продолжить рассмотрение примера эпика Разработать блог для сайта “N”, можно выделить такие истории:

Как клиент, я могу связаться с суппортом компании, отправив заявку на странице /contact-us, чтобы решить возникшую проблему

Как BA, я могу разделить посетителей сайта на 2 группы и провести А/Б тест для главной страницы, чтоб увеличить конверсию страницы

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

…

Теперь части работы стали меньше и они — более понятные. Их можно смело отдавать командам на оценку!

Истории оцениваются командой в story points.
Также в них обязательно должны быть критерии приемки (acceptance criteria), благодаря которым команда сможет понять, что работа сделана до конца.

Написание хороших историй — это целая наука!

Если вы хотите разобраться в историях более детально:

Задача (Task) в Jira

Задача (task) — техническая задача, которую делает один из членов команды.

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

Продолжаем пример с блогом)

Задачи, которые помогут в реализации:

Создать репозиторий для проекта

Настроить testing/production окружения

Ежедневный просмотр логов ошибок

…

Как вы видите, задачи — это очень конкретные технические моменты, которые нельзя “преобразовать” в истории, так как ими занимается один человек.

Но, без таких задач — блог не получится завершить 🙂

Некоторые компании / команды оценивают задачи в часах

Как показывает моя практика — это пустая трата времени, сил и ожиданий.

Практически всегда оценка не совпадет с реальным временем выполнения, причем не важно, оценку делает Junior или Senior разработчик (у Senior отклонение меньше, но оно все равно есть)

Так, задачу оцененную в “два часа от силы” могут делать неделю, а задачу оцененную в “5 часов” — 30 минут 🙂

Вместо оценки задачи в часах — лучше просить разбивать задачу на под-задачи (о них — ниже)

разработчику будет проще, потому что он сможет более точно понять суть и объем задачи

менеджеру будет проще, потому что ход выполнения задачи будет перед глазами (в виде закрытых / открытых “кусочков”) и не нужно будет постоянно ходить к разработчику с вопросом “ну что там, когда будет готово?” и бесить его 😡🤬

Большое количество проблем с типом “задача” в беклоге может указывать на присутствие микро-менеджмента ☠️

В такой ситуации команда не участвует в проработке лучших вариантов решения реальных проблем!

Анализ и подготовка задач происходит “наверху”, задачи опускаются “вниз”, и чаще всего (ввиду не понимания корня проблемы) впоследствии ничего не решают!

Под-задача (Sub-task) в Jira

Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.

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

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

Например, для истории “Как клиент, я могу связаться с суппортом компании, отправив заявку на странице /contact-us, чтобы узнать больше о компании” под-задачи могут быть такими:

Создать страницу /contact-us (Backend)

Сверстать страницу /contact-us (Frontend)

Интегрировать верстку и форму (Frontend)

Интегрировать верстку и форму (Backend)

Подготовить тестовую документацию (QC)

Проверить страницу /contact-us (QC)

Создать и настроить почту для суппорта (Admin)

Баг (Bug) в Jira

Иногда, владельцу продукта сложно понять “суть” ошибки, приоритеты проставляются не правильно и баги “тонут” в беклоге. Это может приводить к постепенному ухудшению качества продукта.

Внедрение Zero Bug Policy помогает избавиться от этой проблемы раз и на всегда.

Создание отличных баг-репортов являеться ключевым навыком любого тестировщика.

У нас есть отдельная статья о багах и баг-репортах в которой есть пример баг-репорта в Jira и много чего интересного 🙂

Выводы

Типы задач в Jira

Приведенные типы задач лишь базовые!

Jira — очень гибкий инструмент! Она позволяет добавить новые типы задач, которые нужны именно Вам!

Существуют команды, которые собирают эпики в большие “мега” проекты. Или те, кто создают требования как тип задач, для более удобной связи требований — тестов — задач/багов.

Главное — не бояться разбираться в чем-то новом и постоянно экспериментировать! 🥼⚗️🧪

Удачи в Ваших проектах 🥳🤩

Что такое Epic в Jira?

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов

Что такое Story в Jira?

История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт

Что такое Task в Jira?

Задача (task) — техническая задача, которую делает один из членов команды

Что такое Sub-task в Jira?

Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды

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

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

у вас несколько инженерных команд (бекенд, IT Ops, iOS, Android, веб и т. д.), которые работают независимо друг от друга с отдельными беклогами;

у вас несколько продуктовых направлений, то есть, грубо говоря, один продуктовый менеджер ведёт несколько проектов по своему направлению, другой менеджер — по своему;

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

и, конечно, вы используете Jira!

участники процесса не понимают, из каких инженерных кусков состоит фича и что ещё необходимо сделать по проекту в текущий момент;

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

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

Знакомо? Давайте подумаем, что с этим можно сделать.

Структура проекта

Я буду разбирать проблему на примере разработки в Badoo. Итак, как ведётся проектная работа? Какие стадии проходит проект? Из каких кусков состоит типичная новая фича, требующая участия нескольких команд?

Идея и дизайн

Продуктовый менеджер (ПМ), придумав, что можно улучшить в продукте, создаёт в Jira тикет PROD с типом Project. Описание этого тикета состоит из единственной ссылки на страницу в Confluence (аналог Wiki от Atlassian, который интегрирован с Jira). Эту страницу мы называем PRD (Product Requirements Document). Она является ключевым элементом разработки. По сути, это подробное описание того, что предстоит сделать в рамках проекта.

Цели.
Здесь кратко описывается, чего мы хотим достичь, реализовав проект (увеличение прибыли, расширение охвата, иные метрики, на которые планируется повлиять и т. п.).

Описание.
Это самая объёмная часть PRD. Здесь описывается вся бизнес-логика фичи, рассматриваются все возможные кейсы. Здесь же размещаются элементы дизайна (то, как пользователь должен видеть фичу на каждом этапе взаимодействия с ней). Также здесь описываются все лексемы, которые могут быть показаны пользователю.

Требования к A/B-тесту.
Почти все новые фичи мы запускаем после проведения A/B-теста, чтобы иметь возможность проверить влияние нового функционала на небольшой группе пользователей (ведь оно может быть и негативным). В этой секции описываются все возможные группы теста и различия их логики для пользователя.

Требования к статистике.
Здесь фиксируется, какие действия пользователя и бизнес-показатели должны мониториться (нажатия кнопок, показы промоэкранов и т. д.).

При создании этого документа ПМ плотно работает с дизайнером. Для этого создаётся ещё один тикет PROD с типом Design. В нём дизайнер размещает макеты, наборы иконок и т. д. Эти элементы потом вставляются в PRD для наглядности, а также используются инженерными командами в разработке.

Когда все нюансы выяснены, первоначальный PROD-тикет переводится в беклог ожидающих разработки. После этого один раз в неделю продуктовая команда сортирует этот беклог по приоритету в соответствии с целями компании, предполагаемому выхлопу и сложности реализации. Проекты, признанные наиболее перспективными, переходят на следующий этап — декомпозицию. Для этого создаётся специальный тикет MAPI (Mobile API) для команды системных архитекторов.

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

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

Данная оптимизация флоу реализована на базе плагина Jira ScriptRunner, о котором я писал в предыдущей статье.

Декомпозиция

Получив новый MAPI-тикет с прикреплённым к нему PRD, системные архитекторы решают:

Довольно часто на этом этапе происходит изменение PRD. Архитекторы гораздо глубже вникают в детали реализации, чем это делалось при обсуждении PRD. Поэтому может выясниться, что для достижения бизнес-целей проекта можно, отказавшись от части первоначальных требований, значительно упростить разработку. Мы очень ценим такую инициативу.

Узнать больше о том, как у нас работает команда архитекторов, и ознакомиться с описанием нашего API можно из доклада.

Результатами работы системных архитекторов являются:

Появление полной технической документации по проекту (описание протокола взаимодействия клиента и сервера с привязкой к кейсам бизнес-логики, описанной в PRD).

По клику откроется вот такой созданный нами интерфейс:

По нажатию кнопки внизу формы (на скриншоте её не видно) появятся нужные тикеты, которые автоматически будут прилинкованы к исходному MAPI-тикету. Тут стоит отметить, что все команды разработки у нас работают в собственном пространстве (проекте) Jira: команда бекенда — в SRV, команда Android — в AND, команда веба — в Web и т. д.

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

Разработка и запуск

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

Как правило, запуск фичи происходит по такому сценарию:

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

ошибка проджект-менеджмента: менеджер может элементарно забыть правильно приоритизировать задачи команды разработки, то есть её участники даже не будут знать о том, что тикет надо взять в разработку как можно скорее.

Как же нивелировать эти проблемы? Как сделать так, чтобы куски проекта не терялись, а команды уделяли должное внимание приоритетным проектам?

Стандартные возможности Jira

Что для решения этих проблем может предложить менеджеру проектов стандартный функционал Jira? Не так уж много:

Фильтры

Фильтр позволяет увидеть линейный список тикетов, полученных по произвольному JQL-запросу. Этот инструмент очень удобен для обслуживания беклога одной команды, но как применить его для качественного управления проектом, распределённым по разным командам, мне неизвестно. Максимум, что может сделать менеджер, — это вывести приоритезированный список корневых PROD-тикетов, а дальше нужно заходить в каждый, просматривая прилинкованные тикеты. Но это крайне неудобно и долго, особенно учитывая, что иерархия ссылок может быть многоэтажной. Более того, команда разработки может создать несколько дополнительных тикетов для решения первоначальной задачи, и их статус тоже надо отслеживать.

Канбан-доски

Здесь у нас уже гораздо больше простора для применения инструмента в контексте решаемой задачи. ПМ может создать фильтр, который отберёт все задачи всех подразделений по нужному направлению. Сделать это можно, например, автоматически поставив тикетам соответствующие лейблы. Напоминаю, что все ключевые тикеты проекта у нас создаются с помощью соответствующего инструментария. Поэтому автоматически скопировать нужные лейблы корневого PROD-тикета во все производные тикеты — тривиальная техническая задача.

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

Схема продуктовой канбан-доски, на которой тикеты проектов ПМ сгруппированы по командам

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

Excel

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

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

Почему бы нам не использовать удобство и наглядность электронных таблиц, добавив туда автоматическую синхронизацию с Jira? У нас есть для этого все возможности! Так мы решили создать дополнительный инструмент на базе Jira REST API, который автоматически поддерживает актуальное состояние информации и имеет удобный для нас интерфейс.

Требования к инструменту были следующие:

возможность создавать списки проектов и производных от них тикетов по произвольным JQL-запросам (это нужно, чтобы любой ПМ мог создать собственное пространство (юнит), в котором он будет видеть только свои проекты и управлять ими);

новые проекты в Jira должны автоматически появляться в интерфейсе;

новые тикеты в проекте должны автоматически появляться в интерфейсе (то есть если команда разработки решает, что для реализации фичи требуется больше тикетов, то ПМ сразу это увидит в интерфейсе);

в зависимости от статуса тикетов цвета ячеек таблицы должны меняться (для быстрого понимания участниками статуса проекта);

возможность сортировки проектов (чтобы правильно их приоритизировать);

автоматическое скрывание реализованных проектов спустя две недели после завершения.

ПМ начинает работу с инструментом, создав собственное пространство (юнит), указав его название и JQL-запрос:

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

Сверху находятся ссылки для переключения между юнитами.

Строки таблицы — это корневые PROD-тикеты юнита. В ячейках мы видим задачи проекта для конкретных инженерных подразделений. Заполнение происходит автоматически при соблюдении правил линкования тикетов проекта между собой. Зелёным помечены завершённые этапы, красным — неначатые, жёлтым — текущие.

Ссылки ведут на тикеты в Jira. Также можно получить краткую информацию о тикете, наведя курсор на ссылку:

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

Сортировка происходит простым перетаскиванием нужного проекта в желаемое место в списке:

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

Выводы

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

Читайте также:


Как сделать раскрой в к3

Как сделать уголки на воротник рубашки

Как сделать перерасчет зарплаты за прошлый месяц

Как сделать роллы цунами

Как сделать координаты в автокаде