#Jira

Не любити Jira - це таке кліше, що навіть не знаю, чи є люди, котрим вона подобається. На мою думку, тут немає провини конкретно Джіри. Проблема, в моїх очах, в тому, що це інструмент для комунікації, а не організації особистих задач. Jira має бути всім для всіх, та через це безповоротно втрачає простоту та прямолінійність, особливо для посади розробника, якому від Джіри потрібний тільки список особистих задач.

Відповідь в тому, щоб робити цей список задач поза межами Джіри (або іншого командного тасктрекера). Я, власне, так і роблю, але синхронізація власноруч не розвʼязує задачу повноцінно та головне, вчасно. В минулому я намагався побороти Джіру через її інтеграцію в VS Code, проте чого там не вистачало — це простого додавання та редагування задач.

Проте, якщо потрібно тільки створити список задач на основі Джіри, то можу порадити доповнення Obsidian Agile Task Notes. Тільки мені того не вистачає (та чи здатний я обминути нагоду зробити інтеграцію власноруч?) Тому роблю своє. Хочу на 95% працювати з Jira тільки через Obsidian - в тому числі редагувати.

Поки розповім про дизайн. По-перше, весь сенс існування такого інструменту — це зведення Jira до мінімального потрібного інтерфейсу. Власне витягнути список задач та відобразити його у Markdown - зрозуміло як. З обовʼязкових полів — тільки код задачі — але також, мабуть, треба бачити назву та статус. Причому статус має передаватись як маркер списку, а значить, необхідно спочатку задати переклад статусів з Jira в маркери — бо в кожному проєкті статуси свої.

Звідки задачі брати? На моєму досвіді, краще залишити це на волю користувача та запросити вказати запит JQL для отримання списку. Списків буде більше одного — як я це робив у VS Code. Тому напевно цей запит має бути в метаданих документа; тоді можна скористатись API Obsidian для пошуку всіх документів, в яких встановлений потрібний ключ метаданих, щоб оновлювати в них списки задач.

Як створювати задачі? Логічно, що якщо додаєш в список в Obsidian новий пункт, то він має зʼявитись в Jira. Створити задачу просто, якщо знаєш всі її атрибути (це не тільки назва, але й принаймні проєкт, епік, власник). Що робити, щоб не питати все це кожного разу (окрім, зрозуміло, назви?) Можна прямо в тих самих метаданих поруч з запитом для наповнення списку вказувати набір атрибутів, що будуть призначені новим задачам.

Як редагувати задачі? Тут головна функція — це зміна статусу; далі редагування назви та нотаток. (При проєктуванні треба памʼятати, що для менш частих задач завжди можна скористатися Джірою напряму; а нам важливо не перевантажити інтерфейс.) Зміна статусу — знов через маркери задачі. Редагування назви — хочеться вірити, що вийде (бо щоб отримати назву, доведеться очистити рядок задачі в Markdown від номера задачі та інших атрибутів.) Нотатки — треба дивитись; можливо, вийде розташовувати нотатки як вкладений в задачу зміст Markdown, але це не точно.

Далі буде.

Як я писав, Jira рідкісний комбайн у світі менеджерів задач. Та, якщо взяти за аксіому, що ніхто не любить програми для організації задач, то принаймні Jira дає потужні механізми для їх впорядкування.

Сьогодні накрутив базовий механізм відображення задач з Jira в Obsidian. Як і планував, запит до Jira у вигляді JQL сидить в метаданих до документа. Це надає можливість будувати не один, а скільки потрібно списків задач. Окрім банального списку поточних задач, через JQL можна побудувати списки проблемних задач, які потребують уваги. Наприклад: задачі, які мають змерджений PR, але чомусь не були закриті:

(assignee=currentUser() or creator=currentUser()) and development[pullrequests].all>0 and development[pullrequests].open=0 and status not in (closed, cancelled)

Мабуть, в кожного свій перелік проблем, тому й зручно мати JQL, який можна підстроїти під себе. З екрана пошуку через JQL можна відразу перейти до масового редагування, щоб, наприклад, перевести всі готові задачі в правильний стан.

Робити пакетні зміни через Obsidian немає сенсу, а от пакетне створення задач, мабуть, так. Мене завжди дратує вносити багато задач в Jira - до кожної доводиться вказувати ті самі атрибути (власника, наприклад). Приємніше підготувати список задач в Markdown, а потім імпортувати (причому проставити автоматично проставити однакові атрибути). Зокрема, так поки плануєш список, можна повертатись до попередніх задач, якщо несподівано змінюється розуміння. Прямо в Jira переробляти вже створені задачі завжди біль.

Так що наступним чином спробую зробити імпортувальник нових задач з Obsidian в Jira.

Походивши з тиждень з мрією приховати Jira в Obsidian, дійшов висновку, що це одна з таких ідей, які в голові виглядають простими, але як почнеш втілювати, то зовсім не зрозуміло, як. (Тому, взагалі, краще ідеї проєктів перевіряти практикою, хоч мінімально.)

Скористався цим імпульсом, щоб подолати неприязнь та знайти спосіб користуватися Джірою так, щоб це було зручно.

Зокрема, класичний канбан мене не влаштовує, оскільки а) ця форма винайдена та зручна для команди, а не для окремої особи та б) щоб працював канбан, треба, щоб задачі вже були впорядковані, а моя головна проблема як раз з тим, що вони розповзаються. Наприклад: добре що в канбані є фільтр “Мої задачі”. Але що якщо я забув призначити задачу на себе? Або не вказав правильно епік, коли створював? І так далі.

Що мені подобається в Jira, так це мова запитів JQL. З нею можна знайти ті задачі, які потрібні. А потім з пошуку можна легко робити масове редагування. От тільки робити кожен раз новий пошук не дуже зручно.

Улюблені запити можна зберегти у вигляді фільтрів. Але ще зручніше потім зробити з фільтрів дашборд. Для дашбордів є два гаджети, які мене зацікавили: це “Filter Results” та “Filter Counts”. Перший виводить таблицю результатів фільтра, а другий — тільки кількість. Кількість дуже зручно використати як раз для виявлення проблемних задач (а з гаджета можна легко перейти до результатів пошуку.)

От з таким дашбордом я спробую користуватись Джірою як постійним інструментом планування особистої роботи.

Для масового імпорту задач є вбудований імпорт з CSV. Та якщо в тебе є просто список пунктів задач, то це технічно є CSV з одним стовпчиком, та його можна імпортувати вбудованими засобами. Єдине, чого не вистачає — це, щоб так само легко імпортувати нотатки. Може, тут дійсно варто зробити більш обмежений інструмент для імпорту з Markdown.

Останнє: Jira краще працює в Google Chrome. Я великий фанат Safari, проте обʼєктивно в Хромі інтерфейс реагує швидше. Це теж важливо для безболісного користування.

ОК, ще більше заглиблююся в переконанні, що власні, доморощені MCP підіймають роботу з агентом до наступного рівня ефективності.

Вчора треба було почистити беклог в Jira. Я вже не раз писав про свої спроби щось там оптимізувати. Найкращим поки підходом був набір збережених запитів JQL - мої відкриті задачі, задачі, що очікують тощо. Мені залишалося пройтися по нім та опрацювати.

Але навіть так, робота з Jira залишалася нудним та неприємним обовʼязком. Тому (і це починає бути патерном), відкриваю Cursor і кажу: ось в мене є acli, давай, проаналізуй все що мене стосується.

Він поколупав документацію до acli всілякими викликами acli jira --help і так далі. Потім витягнув десь ті ж самі результати, що і я раніше. Але різниця в тому, що LLM на ходу може згрупувати ці результати, оформити, та робити над ними дії. Так, перше, що я зробив — це сказав “переведи все, що в Ready for Release понад місяць, у Closed”. (Інфраструктурні задачі самі не закриваються.) І оце вже дійсно потужно!

Поробив ще трохи, а потім кажу — ми тут розібралися, як працювати з Jira через acli, збережімо інструкцію в файл. (Це дуже корисний хід, часто так роблю.) А потім думаю… ну якщо вже інструкція є — зроби з неї кілька команд. То й зробив на кшталт /jira-my-tasks і так далі.

От сиджу сьогодні з тими командами, але річ у тім, що команди (наскільки я знаю) запускаються явно мною, а не агентом в процесі інших операцій. Тож, нарешті, кажу “а тепер — роби з команд MCP!” Ну то й він зробив малесенький MCP на Python, який вміє робити ті самі виклики acli.

І тепер, нарешті, я можу писати складні запити, як-от “створи для цього чату задачу у відповідному епіку”. Та агент здатний перелічити епіки, знайти той, що найбільше має сенс, та вкласти в нього задачу. Круть! А якщо мені щось не подобається, я можу швидко внести зміни простим текстом.

Ще тут висновок. LLM найкраще розкриваються там, де багато контексту, складна послідовність дій. Поки ти робиш одиничні зміни — може так виглядати, що LLM це зайве ускладнення, та, певно, так воно і є. Тому раджу пробувати задачі вищого порядку — сміливіше!