В предыдущей статье я рассказал, какие надстройки для 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 для наглядности, а также используются инженерными командами в разработке.
Написав документ, ПМ выносит его на публичное обсуждение. Обычно в беседе участвуют другие ПМ, а также лиды инженерных команд. Обсуждение ведётся прямо в комментариях к PRD. Это удобно, потому что остаётся история переписки, а все заинтересованные участники получают уведомления при появлении новых комментариев. По результатам обсуждения в исходный PRD вносятся согласованные изменения.
Когда все нюансы выяснены, первоначальный PROD-тикет переводится в беклог ожидающих разработки. После этого один раз в неделю продуктовая команда сортирует этот беклог по приоритету в соответствии с целями компании, предполагаемому выхлопу и сложности реализации. Проекты, признанные наиболее перспективными, переходят на следующий этап — декомпозицию. Для этого создаётся специальный тикет MAPI (Mobile API) для команды системных архитекторов.
Тут важно отметить, что для более оперативного создания сопутствующих проекту тикетов, а также для исключения человеческого фактора (что-то забыли, неправильно слинковали или разметили) мы автоматизировали этот процесс. Так, например, корневой тикет проекта в шапке имеет две дополнительные кнопки.
Первая создаёт тикет для дизайнеров, вторая — для системных архитекторов. При этом новые тикеты автоматически заполняются нужными атрибутами: правильными метками, ссылкой на PRD, шаблоном описания, а главное — линкуются между собой.
Данная оптимизация флоу реализована на базе плагина Jira ScriptRunner, о котором я писал в предыдущей статье.
Декомпозиция
Получив новый MAPI-тикет с прикреплённым к нему PRD, системные архитекторы решают:
- какая часть логики должна быть реализована на стороне сервера, а какая — на стороне клиента;
- какие команды должен посылать клиент и какие ответы от сервера он должен получать;
- какие лексемы должны быть «зашиты» в клиент, а какие — приходить со стороны сервера.
Довольно часто на этом этапе происходит изменение PRD. Архитекторы гораздо глубже вникают в детали реализации, чем это делалось при обсуждении PRD. Поэтому может выясниться, что для достижения бизнес-целей проекта можно, отказавшись от части первоначальных требований, значительно упростить разработку. Мы очень ценим такую инициативу.
Узнать больше о том, как у нас работает команда архитекторов, и ознакомиться с описанием нашего API можно из доклада.
Результатами работы системных архитекторов являются:
- Появление полной технической документации по проекту (описание протокола взаимодействия клиента и сервера с привязкой к кейсам бизнес-логики, описанной в PRD).
Скриншот части документации одной нашей ныне неактивной фичи
- Изменённый протокол (файл в формате Google Protocol Buffers) в репозиториях. Если для реализации фичи нужны новые команды или изменения старых, они будут доступны разработчикам всех команд.
- Тикеты для команд разработки и локализации. Для этого у нас есть специальный интерфейс, который позволяет создавать нужные тикеты сразу для всех задействованных команд. Он открывается по ссылке из MAPI-тикета.
По клику откроется вот такой созданный нами интерфейс:
По нажатию кнопки внизу формы (на скриншоте её не видно) появятся нужные тикеты, которые автоматически будут прилинкованы к исходному MAPI-тикету. Тут стоит отметить, что все команды разработки у нас работают в собственном пространстве (проекте) Jira: команда бекенда — в SRV, команда Android — в AND, команда веба — в Web и т. д.
Интерфейс реализован на базе Jira REST API.
Таким образом, структуру проекта можно изобразить в виде следующей схемы:
Разработка и запуск
В общем случае все команды могут работать над проектом параллельно, соприкоснувшись только на завершающем этапе интеграции, то есть клиентским командам необязательно ждать готового сервера, чтобы выполнить свою часть работы. Так как протокол взаимодействия детально описан, при разработке можно спокойно эмулировать ожидаемый ответ сервера и отлаживать клиентскую логику. Серверу тем более не требуется клиент при разработке — серверный программист просто реализует протокол и покрывает его тестами, эмулируя запросы клиента.
Как правило, запуск фичи происходит по такому сценарию:
- Сервер первый выкладывает свою часть функционала, прикрытую feature-флагом, в продакшен. Таким образом, данная логика остаётся незадействованной до тех пор, пока один из клиентов не начнёт присылать этот feature-флаг.
- Клиентские команды перед релизом в продакшен тестируют свою часть функционала уже на «боевом» сервере.
- По мере готовности разные клиенты выпускаются, начинают слать нужный feature-флаг и получать новый ответ сервера.
Возможность синхронной работы над проектом — огромный плюс, который может значительно повысить эффективность разработки. Но здесь кроется риск: какие-то команды могут «писать в стол», то есть делать свою часть работы, которая никогда не будет востребована другими участниками проекта. Причин может быть несколько:
- разные приоритеты у команд разработки; проблем обычно не возникает при работе над суперважными для компании проектами (они у всех на слуху и забыть о них сложно), а вот менее важные могут располагаться в локальном беклоге отдельной команды на последних местах;
- ошибка проджект-менеджмента: менеджер может элементарно забыть правильно приоритизировать задачи команды разработки, то есть её участники даже не будут знать о том, что тикет надо взять в разработку как можно скорее.
Как же нивелировать эти проблемы? Как сделать так, чтобы куски проекта не терялись, а команды уделяли должное внимание приоритетным проектам?
Стандартные возможности Jira
Что для решения этих проблем может предложить менеджеру проектов стандартный функционал Jira? Не так уж много:
- фильтры;
- канбан-доски.
Фильтры
Фильтр позволяет увидеть линейный список тикетов, полученных по произвольному JQL-запросу. Этот инструмент очень удобен для обслуживания беклога одной команды, но как применить его для качественного управления проектом, распределённым по разным командам, мне неизвестно. Максимум, что может сделать менеджер, — это вывести приоритезированный список корневых PROD-тикетов, а дальше нужно заходить в каждый, просматривая прилинкованные тикеты. Но это крайне неудобно и долго, особенно учитывая, что иерархия ссылок может быть многоэтажной. Более того, команда разработки может создать несколько дополнительных тикетов для решения первоначальной задачи, и их статус тоже надо отслеживать.
Канбан-доски
Для тех, кто не знает, как это устроено в Jira, поясню. В общем случае это список задач на основе определённого фильтра, сгруппированный по трём колонкам: «Беклог», «Задачи в разработке», «Завершённые задачи». Интерфейс позволяет повышать приоритет задач простым перетаскиванием мышкой тикета в списке. При этом меняется свойство Rank, по которому потом можно отсортировать тикеты в своих фильтрах.
Здесь у нас уже гораздо больше простора для применения инструмента в контексте решаемой задачи. ПМ может создать фильтр, который отберёт все задачи всех подразделений по нужному направлению. Сделать это можно, например, автоматически поставив тикетам соответствующие лейблы. Напоминаю, что все ключевые тикеты проекта у нас создаются с помощью соответствующего инструментария. Поэтому автоматически скопировать нужные лейблы корневого PROD-тикета во все производные тикеты — тривиальная техническая задача.
Мы используем канбан-доски для формирования и контроля беклогов инженерных команд. С помощью инструмента Swimlanes, доску можно сгруппировать по проектам, которые соответствуют инженерным командам. Таким образом, с помощью этого инструмента ПМ может следить за ходом своих проектов в разрезе разных команд, а также приоритизировать тикеты команд.
Схема продуктовой канбан-доски, на которой тикеты проектов ПМ сгруппированы по командам
Проблема заключается в том, что инструмент не предоставляет простой возможности группировать тикеты по исходным PROD-тикетам, то есть по фичам: хочется наблюдать за ходом каждого проекта по отдельности во всех инженерных командах.
Excel
Самым очевидным решением является использование электронных таблиц. Ведь можно сделать всё как душе угодно: удобно, красиво, информативно. Примерно вот так:
Можно видеть общий фронт работ по каждому проекту в одном месте. Можно делать различные пометки, вычёркивать выполненные тикеты и т. п. Всё здесь хорошо, за исключением одного жирного но: поддерживать актуальность подобных таблиц крайне сложно. Статусы тикетов постоянно меняются, создаются новые. Вносить вручную все изменения? Можно потратить на это весь день. Но мы же за эффективность, правда?
«А давайте скрестим!»
Почему бы нам не использовать удобство и наглядность электронных таблиц, добавив туда автоматическую синхронизацию с Jira? У нас есть для этого все возможности! Так мы решили создать дополнительный инструмент на базе Jira REST API, который автоматически поддерживает актуальное состояние информации и имеет удобный для нас интерфейс.
Требования к инструменту были следующие:
- возможность создавать списки проектов и производных от них тикетов по произвольным JQL-запросам (это нужно, чтобы любой ПМ мог создать собственное пространство (юнит), в котором он будет видеть только свои проекты и управлять ими);
- новые проекты в Jira должны автоматически появляться в интерфейсе;
- новые тикеты в проекте должны автоматически появляться в интерфейсе (то есть если команда разработки решает, что для реализации фичи требуется больше тикетов, то ПМ сразу это увидит в интерфейсе);
- в зависимости от статуса тикетов цвета ячеек таблицы должны меняться (для быстрого понимания участниками статуса проекта);
- возможность сортировки проектов (чтобы правильно их приоритизировать);
- автоматическое скрывание реализованных проектов спустя две недели после завершения.
ПМ начинает работу с инструментом, создав собственное пространство (юнит), указав его название и JQL-запрос:
Далее происходит запрос к Jira для получения списка проектов по указанному JQL-запросу. Также с помощью ссылок в Jira находятся все производные тикеты инженерных команд. Результатом является примерно такая таблица:
Сверху находятся ссылки для переключения между юнитами.
Строки таблицы — это корневые PROD-тикеты юнита. В ячейках мы видим задачи проекта для конкретных инженерных подразделений. Заполнение происходит автоматически при соблюдении правил линкования тикетов проекта между собой. Зелёным помечены завершённые этапы, красным — неначатые, жёлтым — текущие.
Ссылки ведут на тикеты в Jira. Также можно получить краткую информацию о тикете, наведя курсор на ссылку:
С периодичностью раз в несколько минут происходит запрос к API Jira для получения актуального списка проектов по всем юнитам, для синхронизации списка производных тикетов, а также их текущих статусов.
Сортировка происходит простым перетаскиванием нужного проекта в желаемое место в списке:
Важно отметить, что с данным инструментом в Badoo работают не только продуктовые менеджеры, но и лиды инженерных команд. Ведь всем важно понимать, что происходит в продуктовых направлениях, какие команды продвинулись в реализации важных для компании проектов сильнее других, а какие отстают.
Выводы
Jira «из коробки» предоставляет мощный функционал для управления структурой проекта и связями между тикетами. Существуют также плагины, которые значительно расширяют возможности JQL (например, позволяют использовать ссылки между тикетами и их типы для фильтрации тикетов). В нашем случае не хватало только возможности визуализировать всё так, как нам было нужно.
К счастью, Jira позволяет на базе своего API создавать удобные дополнительные инструменты, адаптированные под бизнес-процессы компании. Так, например, возникшую у нас проблему с прозрачностью ведения проектов по десятку продуктовых направлений мы смогли решить, приложив немного усилий и использовав дополнительные возможности этого трекера задач. В комментариях было бы интересно почитать, пробовали вы у себя сделать подобные надстройки или нашли другие решения под свои задачи.
Всем спасибо за внимание!
Автор: dsemenikhin
