Привет, меня зовут Александр, я работаю 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.
Приступим. Первые два шага:
- Создаём новую страницу в Confluence.
- Добавляем в нее таблицу на два столбца.
- В первом пишем название нехорошей ситуации.
- Во второй вставляем макрос {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-а, который связан с нашим продуктом в продакшене. Получился один экран, на котором есть вся необходимая мне оперативная информация.
Надеюсь, эта статья окажется вам полезной, а подход, как и мне, — сэкономит драгоценное время.
Буду рад услышать дельные комментарии и ваши решения подобных проблем.