Зручний 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 («auto Tech-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-а, який пов'язаний з нашим продуктом в продакшені. Вийшов один екран, на якому є вся необхідна мені оперативна інформація.

Сподіваюся, ця стаття виявиться вам корисною, а підхід, як і мені, — заощадить дорогоцінний час.

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

Опубліковано: 28/09/18 @ 07:00
Розділ Різне

SEO Блог