×

Удобный health-check мониторинг беклога в Jira

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

Эта статья будет полезна в первую очередь Project Manager-ам, Scrum Master-ам, проектным аудиторам, а также другим специалистам, которые хотят понимать, что те договоренности, по которым команда должна работать с беклогом проекта в Jira, выполняются максимально точно. Речь пойдет о чистой воды мониторинге и контроле, на который, к сожалению, не всегда хватает времени и желания.

Для внедрения подхода нужен хотя бы небольшой опыт работы с Confluence и поисковыми запросами в Jira (JQL), а также, собственно, наличие обоих продуктов — Confluence и Jira — в вашей корпоративной инфраструктуре. Без этого читать текст ниже нет смысла.

Мы будем идти по шагам — от проблем к их решению, постепенно улучшая это самое решение, получив нечто похожее на health-check мониторинг в Zabbix, где, нажав один раз F5, вы сможете получить сжатую и полезную информацию по проблемам в вашем беклоге или убедиться в их отсутствии.

Какие проблемы решаем

Рассмотрим несколько проблем, которые поможет решить подход, описанный ниже.

Исполнение договоренностей и правил, связанных с беклогом. Вы договорились с членами вашей команды, например, бизнес-аналитиками, ввести и использовать новое поле, отвечающее, скажем, за статус согласования требований с заказчиком — некий «Approval status».

Допустим, это кастомное поле имеет ряд значений и логика его использования отличается для различных состояний («Status») задач. Например, не должно быть ситуации, что «Story» уже сделана, а «Approval Status» = «Waiting for the customer’s decision».

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

Как за считанные секунды проверить, что то или иное поле используется командой корректно для нескольких сотен элементов беклога? А если таких полей много + есть их различные комбинации?

Заглядывание в историю. К великому счастью, Jira помнит о каждом переходе задачи из статуса в статус (поле «Status»), а также об изменении поля «FixVersion».

Как насчёт того, чтобы отслеживать те самые нехорошие переходы «справа-налево», в частности, отклоненные тестировщиками задачи и bug fix-ы? Или, например, несанкционированное изменение «FixVersion» для элемента беклога?

Проработка ситуаций, которые требуют внимания PM-а / Scrum Master-а. Было бы здорово иметь в одном месте несколько ссылочек на подборку «проблемных» элементов беклога, например, список багов, на фикс каждого из которых ушло больше 20 часов.

Есть JQL выборки, но что, если их много?

Те, кто знаком с расширенным поиском в Jira, знают, что все, что описано выше, можно получить, построив запросы с использованием встроенного в Jira языка запросов JQL. Освоить его не составляет труда — у Atlassian чудесная документация.

Например, вот часть реального запроса, который показывает элементы беклога, которые не должны быть взяты в работу без согласования с заказчиком через поле «Approval Status»:

project = XYZ AND («Approval Status» NOT IN («Tech auto-approved», Approved) OR «Approval Status» IS EMPTY) and type IN («Story», «Change request») AND Status != Open

Итак, вы напилили выборки, а теперь вопрос: что с ними делать? Почти все они не смогут отображаться так, как вам нужно в виджетах Jira.

Держать отдельное окно браузера, где их проклацывать время от времени? Сохранить их в «избранное» браузера и открывать все эти выборки по понедельникам? Я так делал. Есть вариант получше.

Сохранить все выборки в виде фильтров и подписать на e-mail уведомления от Jira, если возвращаемые результаты изменились. Тоже вариант, но тоже так себе.

Пилим дашборд в Confluence

Можно выделить две группы проблем, которые мы хотим вскрыть с помощью JQL выборок:

  • Что-то не должно случаться никогда. Как только случилось, вы должны узнать об этом и проблема должна быть устранена, например, через выставление правильного значения в каком-то поле. Выборка после этого должна возвращать 0 issues.
  • Что-то может случаться время от времени. Вам просто нужно пойти и посмотреть, например, на тот самый баг, которые девелопер фиксил, влогав в него больше 20 часов. Вы каким-то образом отмечаете этот баг, и он тоже пропадает из вашего мониторинга.

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

Приступим. Первые два шага:

  1. Создаём новую страницу в Confluence.
  2. Добавляем в нее таблицу на два столбца.
    • В первом пишем название нехорошей ситуации.
    • Во второй вставляем макрос {JIRA} с JQL запросом и со следующими настройками.

После этого накидываем еще различных выборок. Для беклога моего проекта с более чем 4,500 issues я использую 20 выборок. Некоторые из них содержат в себе по факту несколько логически связанных выборок, объединённых через OR. Получаем что-то такое:

Сохраняем. Получаем результат: что-то хорошо (0 issues), а что-то — требует внимания. Забегая наперёд, скажу, что я помечаю звёздочкой выборки, которые приходится обновлять после каждого релиза. Остальные — постоянные.

Теперь у нас есть страница в Confluence, обновив которую мы увидим, что хорошо, а что плохо. Ведь при обновлении страницы Confluence обратится к Jira и перестроит ссылки во втором столбце, предоставив нам актуальную картину.

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

  • Добавляю к ним метку «checked_by_pm».
  • Для того, чтобы такая задача ушла из выборки, я добавляю к выборке:

... AND (labels not in (checked_by_pm) OR labels is EMPTY)

Уже хорошо. В принципе можно здесь и остановиться, но можно ещё лучше.

Видеть только проблемы

Если мы исправили все наши проблемы, то нам не хотелось бы видеть 10...20 строк с «0 issues». Для того, чтобы их скрыть, понадобится недорогой, но чертовски практичный плагин Table Filter and Charts for Confluence. Он позволяет настроить таблицу так, что в режиме просмотра не будут отображаться строки с «0 issues», что позволяет значительно уменьшить место, которое занимает эта таблица.

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

Обратите внимание на filtration pane вверху таблицы

Как работать с этой таблицей

Мои рекомендации по этой специальной страничке простые:

  • Пользоваться ею каждый день и исправлять нехорошие ситуации, о которых она сигнализирует.
  • Постоянно расширять количество выборок. Ввели с командой новое правило или получили требование от руководства — новая выборка. Кто-то по любой причине нарушает договорённости — выборка. Нехороший тренд по какому-то из наборов issues — выборка.
  • Сообщить коллегам об этой странице и смотреть на неё вместе каждую неделю на регулярных синках.
  • Внедрить в вашу систему мониторинга. Я, к примеру, рядом с этой таблицей прямо в том же документе вывел виджет из Jira — workload команды, чтобы понимать загрузку команды. Также я поместил всё это рядом с дашбордом Zabbix-а, который связан с нашим продуктом в продакшене. Получился один экран, на котором есть вся необходимая мне оперативная информация.

Надеюсь, эта статья окажется вам полезной, а подход, как и мне, — сэкономит драгоценное время.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




9 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Здравствуйте, Александр. Спасибо за статью. Только один вопрос — почему бы не обойтись одной только Jira с ее кастомными dashboards с n гаджетов Favorite Filters?
И еще там «из коробки» есть даже чуть более полезный Two-Dimensional Filter Statistics Gadget, позволяющий использовать две размерности.

Максим, признаюсь, я вообще не знал про «Favourite filters». Спасибо. Да это очень похоже на то, что я сделал, но у этого виджета есть два недостатка.
— Его нельзя лего расшарить с коллегами, чтобы они устранили проблемы без моего вовлечения. С Confluence это работает значительно проще. Это касается и других страниц, созданных мною, на которые подтягиваются данные из Jira.
— Опять-таки — отображение строк с «0 issues». Я предпочитаю видеть только проблемы. Мы активно используем этот плагин для скрытия второстепенной информации из таблиц.

А вообще, наверное мне просто нравится работать с данными из Jira через Confluence. Как бы странно не звучало, но я вообще не пользуюсь виджетам в самой Jira.

Пожалуйста )

  1. Виджет расшарить нельзя, но можно расшарить сам фильтр, во-первых, а можно расшарить сразу весь дашборд. Это очень удобно, когда в команде появляется новый сотрудник — одним движением у него р-раз — и девовский/тестерский/менеджерский дашборд с настроенными фильтрами. JQL ведь позволяет использовать currentUser в запросах.
  2. Для проблемных индикаторов очень удобно использовать круговые диаграммы, там нулевые сектора схлопываются.

Я не настаиваю, просто делюсь своим опытом тоже.

пм — циклум, дев — циклум, либо где то устаревшая информация, либо в циклуме не приветствуется обмен опытом )) просто забавно.

— Алло, это полиция?
— Да.
— Меня похитили инопланетяне!
— Вы пьяны?
— Да, так совпало.

Циклум здоровый, тут на этаже не всех знаешь, что уж говорить про дева с одного проекта и ПМ с другого. Сейчас я дев, у меня на проекте TFS, а опыт ПМствования и Jira я вспоминаю долгими вечерами, утирая ностальгическую слезу.

«Просто забавно» © я.

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

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

пм — циклум, дев — циклум

DevOps, как культура взаимодействия :-)

Удобный способ если есть Confluence.

Почти все они не смогут отображаться так, как вам нужно в виджетах Jira.

Есть другие примеры кроме тех что в статье? Потому что мне фильтров, виджетов и дешбордов хватает для большинства подобных задач. Исключение — сложная агрегация и визуализация, для этого есть API и export.

Ну, все эти выборки безусловно очень project-specific, поэтому возможно многие из них неактуальны для вас, Александр. Из тех, что не влезли в пример выше, использую такие prntscr.com/kzrrps

Підписатись на коментарі