- PVSM.RU - https://www.pvsm.ru -
В предыдущей [1] статье я рассказал, какие надстройки для Jira мы сделали, чтобы рабочий флоу стал максимально удобным, а тикет — исчерпывающе информативным. В сегодняшней статье мы решим другую задачу.
Дано:
Проблемы:
Очевидна проблема с прозрачностью процесса разработки. Когда проектов и направлений много, особенно остро ощущается потребность в некоем магическом инструменте, избавляющем от хаоса и дающем чёткую картинку. К сожалению, наш опыт показывает, что стандартные возможности Jira с этим не до конца справляются.
Знакомо? Давайте подумаем, что с этим можно сделать.
Я буду разбирать проблему на примере разработки в Badoo. Итак, как ведётся проектная работа? Какие стадии проходит проект? Из каких кусков состоит типичная новая фича, требующая участия нескольких команд?
Продуктовый менеджер (ПМ), придумав, что можно улучшить в продукте, создаёт в Jira тикет PROD с типом Project. Описание этого тикета состоит из единственной ссылки на страницу в Confluence [2] (аналог Wiki от Atlassian, который интегрирован с Jira). Эту страницу мы называем PRD (Product Requirements Document). Она является ключевым элементом разработки. По сути, это подробное описание того, что предстоит сделать в рамках проекта.
При создании этого документа ПМ плотно работает с дизайнером. Для этого создаётся ещё один тикет PROD с типом Design. В нём дизайнер размещает макеты, наборы иконок и т. д. Эти элементы потом вставляются в PRD для наглядности, а также используются инженерными командами в разработке.
Написав документ, ПМ выносит его на публичное обсуждение. Обычно в беседе участвуют другие ПМ, а также лиды инженерных команд. Обсуждение ведётся прямо в комментариях к PRD. Это удобно, потому что остаётся история переписки, а все заинтересованные участники получают уведомления при появлении новых комментариев. По результатам обсуждения в исходный PRD вносятся согласованные изменения.
Когда все нюансы выяснены, первоначальный PROD-тикет переводится в беклог ожидающих разработки. После этого один раз в неделю продуктовая команда сортирует этот беклог по приоритету в соответствии с целями компании, предполагаемому выхлопу и сложности реализации. Проекты, признанные наиболее перспективными, переходят на следующий этап — декомпозицию. Для этого создаётся специальный тикет MAPI (Mobile API) для команды системных архитекторов.
Тут важно отметить, что для более оперативного создания сопутствующих проекту тикетов, а также для исключения человеческого фактора (что-то забыли, неправильно слинковали или разметили) мы автоматизировали этот процесс. Так, например, корневой тикет проекта в шапке имеет две дополнительные кнопки.
Первая создаёт тикет для дизайнеров, вторая — для системных архитекторов. При этом новые тикеты автоматически заполняются нужными атрибутами: правильными метками, ссылкой на PRD, шаблоном описания, а главное — линкуются между собой.
Данная оптимизация флоу реализована на базе плагина Jira ScriptRunner [3], о котором я писал в предыдущей статье [1].
Получив новый MAPI-тикет с прикреплённым к нему PRD, системные архитекторы решают:
Довольно часто на этом этапе происходит изменение PRD. Архитекторы гораздо глубже вникают в детали реализации, чем это делалось при обсуждении PRD. Поэтому может выясниться, что для достижения бизнес-целей проекта можно, отказавшись от части первоначальных требований, значительно упростить разработку. Мы очень ценим такую инициативу.
Узнать больше о том, как у нас работает команда архитекторов, и ознакомиться с описанием нашего API можно из доклада [4].
Результатами работы системных архитекторов являются:
По клику откроется вот такой созданный нами интерфейс:
По нажатию кнопки внизу формы (на скриншоте её не видно) появятся нужные тикеты, которые автоматически будут прилинкованы к исходному MAPI-тикету. Тут стоит отметить, что все команды разработки у нас работают в собственном пространстве (проекте) Jira: команда бекенда — в SRV, команда Android — в AND, команда веба — в Web и т. д.
Интерфейс реализован на базе Jira REST API.
Таким образом, структуру проекта можно изобразить в виде следующей схемы:
В общем случае все команды могут работать над проектом параллельно, соприкоснувшись только на завершающем этапе интеграции, то есть клиентским командам необязательно ждать готового сервера, чтобы выполнить свою часть работы. Так как протокол взаимодействия детально описан, при разработке можно спокойно эмулировать ожидаемый ответ сервера и отлаживать клиентскую логику. Серверу тем более не требуется клиент при разработке — серверный программист просто реализует протокол и покрывает его тестами, эмулируя запросы клиента.
Как правило, запуск фичи происходит по такому сценарию:
Возможность синхронной работы над проектом — огромный плюс, который может значительно повысить эффективность разработки. Но здесь кроется риск: какие-то команды могут «писать в стол», то есть делать свою часть работы, которая никогда не будет востребована другими участниками проекта. Причин может быть несколько:
Как же нивелировать эти проблемы? Как сделать так, чтобы куски проекта не терялись, а команды уделяли должное внимание приоритетным проектам?
Что для решения этих проблем может предложить менеджеру проектов стандартный функционал Jira? Не так уж много:
Фильтр позволяет увидеть линейный список тикетов, полученных по произвольному JQL-запросу. Этот инструмент очень удобен для обслуживания беклога одной команды, но как применить его для качественного управления проектом, распределённым по разным командам, мне неизвестно. Максимум, что может сделать менеджер, — это вывести приоритезированный список корневых PROD-тикетов, а дальше нужно заходить в каждый, просматривая прилинкованные тикеты. Но это крайне неудобно и долго, особенно учитывая, что иерархия ссылок может быть многоэтажной. Более того, команда разработки может создать несколько дополнительных тикетов для решения первоначальной задачи, и их статус тоже надо отслеживать.
Для тех, кто не знает, как это устроено в Jira, поясню. В общем случае это список задач на основе определённого фильтра, сгруппированный по трём колонкам: «Беклог», «Задачи в разработке», «Завершённые задачи». Интерфейс позволяет повышать приоритет задач простым перетаскиванием мышкой тикета в списке. При этом меняется свойство Rank, по которому потом можно отсортировать тикеты в своих фильтрах.
Здесь у нас уже гораздо больше простора для применения инструмента в контексте решаемой задачи. ПМ может создать фильтр, который отберёт все задачи всех подразделений по нужному направлению. Сделать это можно, например, автоматически поставив тикетам соответствующие лейблы. Напоминаю, что все ключевые тикеты проекта у нас создаются с помощью соответствующего инструментария. Поэтому автоматически скопировать нужные лейблы корневого PROD-тикета во все производные тикеты — тривиальная техническая задача.
Мы используем канбан-доски для формирования и контроля беклогов инженерных команд. С помощью инструмента Swimlanes, доску можно сгруппировать по проектам, которые соответствуют инженерным командам. Таким образом, с помощью этого инструмента ПМ может следить за ходом своих проектов в разрезе разных команд, а также приоритизировать тикеты команд.
Схема продуктовой канбан-доски, на которой тикеты проектов ПМ сгруппированы по командам
Проблема заключается в том, что инструмент не предоставляет простой возможности группировать тикеты по исходным PROD-тикетам, то есть по фичам: хочется наблюдать за ходом каждого проекта по отдельности во всех инженерных командах.
Самым очевидным решением является использование электронных таблиц. Ведь можно сделать всё как душе угодно: удобно, красиво, информативно. Примерно вот так:
Можно видеть общий фронт работ по каждому проекту в одном месте. Можно делать различные пометки, вычёркивать выполненные тикеты и т. п. Всё здесь хорошо, за исключением одного жирного но: поддерживать актуальность подобных таблиц крайне сложно. Статусы тикетов постоянно меняются, создаются новые. Вносить вручную все изменения? Можно потратить на это весь день. Но мы же за эффективность, правда?
Почему бы нам не использовать удобство и наглядность электронных таблиц, добавив туда автоматическую синхронизацию с Jira? У нас есть для этого все возможности! Так мы решили создать дополнительный инструмент на базе Jira REST API, который автоматически поддерживает актуальное состояние информации и имеет удобный для нас интерфейс.
Требования к инструменту были следующие:
ПМ начинает работу с инструментом, создав собственное пространство (юнит), указав его название и JQL-запрос:
Далее происходит запрос к Jira для получения списка проектов по указанному JQL-запросу. Также с помощью ссылок в Jira находятся все производные тикеты инженерных команд. Результатом является примерно такая таблица:
Сверху находятся ссылки для переключения между юнитами.
Строки таблицы — это корневые PROD-тикеты юнита. В ячейках мы видим задачи проекта для конкретных инженерных подразделений. Заполнение происходит автоматически при соблюдении правил линкования тикетов проекта между собой. Зелёным помечены завершённые этапы, красным — неначатые, жёлтым — текущие.
Ссылки ведут на тикеты в Jira. Также можно получить краткую информацию о тикете, наведя курсор на ссылку:
С периодичностью раз в несколько минут происходит запрос к API Jira для получения актуального списка проектов по всем юнитам, для синхронизации списка производных тикетов, а также их текущих статусов.
Сортировка происходит простым перетаскиванием нужного проекта в желаемое место в списке:
Важно отметить, что с данным инструментом в Badoo работают не только продуктовые менеджеры, но и лиды инженерных команд. Ведь всем важно понимать, что происходит в продуктовых направлениях, какие команды продвинулись в реализации важных для компании проектов сильнее других, а какие отстают.
Jira «из коробки» предоставляет мощный функционал для управления структурой проекта и связями между тикетами. Существуют также плагины, которые значительно расширяют возможности JQL (например, позволяют использовать ссылки между тикетами и их типы для фильтрации тикетов). В нашем случае не хватало только возможности визуализировать всё так, как нам было нужно.
К счастью, Jira позволяет на базе своего API создавать удобные дополнительные инструменты, адаптированные под бизнес-процессы компании. Так, например, возникшую у нас проблему с прозрачностью ведения проектов по десятку продуктовых направлений мы смогли решить, приложив немного усилий и использовав дополнительные возможности этого трекера задач. В комментариях было бы интересно почитать, пробовали вы у себя сделать подобные надстройки или нашли другие решения под свои задачи.
Всем спасибо за внимание!
Автор: dsemenikhin
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/302614
Ссылки в тексте:
[1] предыдущей: https://habr.com/company/badoo/blog/424655/
[2] Confluence: https://www.atlassian.com/software/confluence
[3] ScriptRunner: https://scriptrunner.adaptavist.com/latest/jira/quickstart.html
[4] доклада: https://www.youtube.com/watch?v=3gBhkT0MijI
[5] Источник: https://habr.com/post/433540/?utm_campaign=433540
Нажмите здесь для печати.