JIRA software od austrálskej firmy Atlassian, patrí medzi špičku taskovacích systémov. Ide o komplexnú aplikáciu, ktorú je možné customizovať do najmenších detailov a je jedno, či si developer, marketér, dizajnér, obchodník… Workflow si vie upraviť každý na mieru. Práve táto komplexnosť, hlavne na začiatku, vie niekoho odradiť a potrápiť. V prípade, že hľadáš len jednoduchý TO DO systém, JIRA nie je pre teba to pravé.

Prečo nevyvinúť a neinvestovať prostriedky radšej do vývoja vlastného riešenia? Prečo investovať peniaze do systému, s ktorým je očividne toľko práce? Určite je najjednoduchšie pracovať s aplikáciou, ktorá bola vytvorená na mieru firemným postupom. Ale oplatí sa investovať toľko hodín do systému, ktorý svoju životnosť môže mať nanajvýš pár rokov? Kto bude riešiť prípadné chyby a výpadky? Čo keď príde nový manažment s novými pravidlami a postupmi, investujeme ďalšie hodiny do úprav? Alebo sa budú musieť ľudia prispôsobovať možnostiam zavedeného systému?

Práve JIRA je systém, ktorý sa prispôsobuje ľuďom, a aj to bol dôvod, prečo sme jej u nás vo firme toľko rokov verní. Na začiatku jej bolo treba venovať určitú pozornosť a fáza prvotného setupu bola celkom náročná, ale teraz máme v rukách špičkový nástroj. Autori neustále pracujú na systéme a najmä v poslednej dobe vidíme každú chvíľu novú funkcionalitu. To je pri iných systémoch, alebo vlastných riešeniach, zriedkavý jav. Systém sa, bohužiaľ, nevyhýba občasným bugom či výpadkom, ale problémy sú väčšinou rýchlo vyriešené.

V tomto článku som napísal pár tipov, ktoré pomôžu demonštrovať možnosti JIRA a verím, že aspoň trochu priblížim, ako pomáha nám, nielen pri vývoji našej platformy RSHOP.

1. Dobre pripravené filtre

Pripravené filtre sú základ. Desiatky projektov, tisícky taskov… Rýchlo vyselektovať to potrebné je veľakrát kľúčové, aby ani najmenšia drobnosť neutiekla. Či je potrebné niečo reportovať alebo naplánovať, jediným správnym filtrom je možné veľmi rýchlo sa dopracovať k žiadanému výsledku. Preto odporúčam naučiť sa JQL (JIRA syntax na tvorbu filtrov) a potom vytvoriť sadu filtrov na tasky, ktoré sú najčastejšie vyhľadávané.

Ako príklad uvádzam pár filtrov, ktoré používame my:

V rámci jednej úlohy sa nám často stávalo, že pozostávala z viacerých krokov alebo podúloh, ktoré by sme potrebovali evidovať. Vytvárať na každý jeden krok subtask by bolo zbytočne zdĺhavé, ideálna bola možnosť vytvoriť si jednoduchý zoznam krokov priamo v tasku. Pre naše potreby sme našli plugin, ktorý nám žiadanú funkcionalitu do JIRY pridal.

Jednotlivé úlohy sa dajú zoraďovať podľa priority a rozdeľovať do skupín:

Ak ide o rozsiahlejšiu úlohu alebo je z nejakého dôvodu potrebné vytvoriť z nej samostatný task, plugin je aj na túto možnosť pripravený:

3. Vytvorenie workflow na mieru

Čo človek, oddelenie, firma, to iný proces. V JIRA okrem využitia predpripravených, je možnosť vytvoriť si workflow úplne na mieru. Dokonca je možné obmedziť workflow na projekt, prípadne na typ tasku, preto sú zbytočné obavy, že marketéri budú musieť pracovať s developerským workflow, alebo naopak.

Ak by som mal niečo z nášho workflow vypichnúť, tak sme sa “vyhrali” s procesmi ako:

Code Reviews

• Musí byť splnená podmienka, že task má vyplneného Reviewera.
• Po zmene stavu nastane automatické priradenie tasku Reviewerovi.
• Po ukončení Code Review, spätné priradenie tasku pôvodnému riešiteľovi.

Waiting stavy

• Task môže mať rôzne dôvody, kvôli ktorým sa nemôže na ňom pracovať.
• V prípade nejasností v zadaní, má stav “Waiting for Customer” a task je automaticky priradený zadávateľovi tasku.
• Ak napríklad Frontend developer potrebuje pomôcť so svojou úlohou od Backend developera, nastaví stav “Waiting for Backend”. Obdobne funguje aj Backend developer.

Deployments

• Nová “feature” väčšinou musí byť najskôr nasadená na testovaciu doménu. O nasadení je autor tasku (projekťák) informovaný stavom “Deployed to Test”.
• Po otestovaní a schválení funkcionality klientom tasku dáme stav “Ready for Production”.
• V prípade, že funkcionalita má ostať pre nejaké dôvody len na testovacej doméne, toto info dáme stavom “Waiting on Test”.
• Keď bola funkcionalita finálne nasadená na produkčný server, máme stav “Deployed to Production”.
• Vďaka tomuto flow vie náš projekťák jasne komunikovať klientovi, kde si vie funkcionalitu pozrieť, a či ju už môže používať aj v produkcii.

4. Využívať Kanban a/alebo Scrum board

Či byť agílny alebo vodopádový, je téma na samostatný článok, ale asi každý uzná, že každý jeden prístup k developmentu má svoje výhody a aj nevýhody. Každodenná zmena priorít, nedodanie rozpracovanej práce, nedodržanie termínov… Len pár problémov, ktoré rieši každá metodológia trochu inak.

V našom tíme fungujeme v mierne upravenom Scrume. Kvôli častým zmenám prioritizácie pre nás šprinty nepredstavujú konštantné bloky, ale ide skôr o prehľad naplánovanej práce a vyťaženosti developerov. Vďaka plánovaniu práce na týždenných intervaloch vieme určiť približne čo a koľko vieme dodať našim klientom. Jednotlivým taskom sa okrem priority, deadline-u a iných základných parametrov, definuje custom poľom aj o to, o aký typ developmentu ide. Čiže, ak napríklad Frontend developer potrebuje nový task, v šprinte si vyhľadá task, ktorý je určený práve pre Frontend developera. Nemôže sa stať, že by začal riešiť task, ktorý nie je v jeho silách dokončiť.

Počet stĺpcov boardu je vhodné držať na čo najmenšom čísle, aby bol čo najjednoduchší a najprehľadnejší. My sme napríklad skončili na čísle 6:

• Open/In progress,
• Waiting for Frontend,
• Waiting for Backend,
• QA/Code reviews,
• Waiting,
• Done.

Aby bolo možné tasky aj prioritizovať, dá sa využiť možnosť zoraďovania, ktorá je pri desiatkach taskov komplikovanejšia na udržiavanie. Najvhodnejší spôsob, ako nejaký task “vypichnúť”, je pre nás použitie tzv. swimlines. Ide o vertikálne rozdelenie jednotlivých stĺpcov v boarde, v rámci ktorého sa dajú vyselektovať tasky cez JQL. Takto si vieme napríklad dať na vrch boardu tasky, ktoré sú super urgentné, alebo majú blížiaci sa deadline, a dole tasky najmenej prioritné.

Na záver spomeniem aj možnosť rozdelenia (split) tasku priamo v boarde, ktorú často využívame, ak ide napríklad o rozsiahlejší task, alebo je nutné prácu rozdeliť medzi viacerých ľudí. Táto možnosť je tak trochu skrytá a zatiaľ sme sa k nej dopátrali len na stránke určenej na plánovanie šprintov.

5. Využívanie prepojenia s Bitbucketom

Keďže naše repozitáre máme v Bitbuckete, prepojenie s JIRA je špičkové. Priamo v tasku, v časti Development, je možnosť vytvoriť si novú branch, ktorá potom bude s taskom previazaná. To znamená, že uvidím napríklad informáciu, či task už prešiel cez Code review, či je už merged, alebo čo sa vlastne všetko programovalo, aby sa spätne zistilo, kde nastal problém. V rámci workflow je možné riešiť aj jednoduché automatizovanie. Napríklad pri Code review, po zamietnutí Pull Requestu, dostane developer task automaticky naspäť.

6. Automatizácia trackovania času

JIRA má v základe možnosť manuálneho pridávania času cez worklog. To je celkom nešťastné riešenie, keď chceme mať evidenciu času čo najpresnejšiu a človek je tvor zábudlivý. Preto používame plugin “Automate log work for Jira”, ktorý po začiatku práce na tasku kliknutím na stav “In progress”, na pozadí spustí časovač a ukončí sa, keď prácu na tasku ukončíme stavom “Stop progress”. Plugin automaticky vytvorí záznam o dĺžke práce.

7. Reportovanie času

Keď máme vďaka predošlému tipu čas riadne evidovaný, môžeme konečne vytvoriť dôveryhodné reporty, ktorými vyhodnotíme prácu zamestnancov, alebo stav projektov. Prednedávnom JIRA vydala reportovanie priamo v jadre, ale z mne neznámych dôvodov sú výsledky tohto reportu veľmi nepresné. Aj preto radšej využívame plugin “Time reports”, v ktorom je možné vytvoriť detailný report časov za nastavené obdobie. Report sa dá filtrovať podľa zamestnanca, projektu, ale aj v uloženom filtre v JIRE. Výsledky je možné zoskupovať až do dvoch úrovní. To znamená, že viem vytvoriť napríklad report, v ktorom budú zoskupené dáta podľa zamestnanca a projektu, na ktorom pracoval.

8. Tvorba dashboardov s užitočnými informáciami

Podstatu dashboardov určite chápe každý. Ich účelom je zobrazovať relevantné informácie na jednej stránke, aby sme sa nemuseli preklikávať cez viacero podstránok. Keďže pre každé oddelenie sú dôležité iné informácie, máme vytvorených viacero dashboardov – pre developerov, projekt manažérov, dokonca má každý možnosť vytvoriť si vlastný dashboard, podľa vlastných potrieb.

Dashboard pre developerov obsahuje napríklad:

• zoznam priradených taskov,
• kalendár s vyznačenými deadline-ami,
• rýchly prístup k taskom, na ktorých práve pracuje.

Dashboard pre projekt manažérov má:

• graf zobrazujúci vyťaženie jednotlivých developerov,
• burndown graf aktuálneho šprintu,
• tabuľku s odpracovanými hodinami jednotlivých developerov,
• tabuľku s odpracovanými hodinami na jednotlivých projektoch.

9. Automatizovať všetko, čo sa len dá

Pre cloudovú verziu JIRA konečne autori sprístupnili novú funkcionalitu, ktorá automatizáciu vyzdvihne na oveľa vyššiu úroveň, bez nutnosti inštalácie nových a drahých pluginov. Aj užívateľ bez programátorských zručností je schopný “vyklikať” užitočné automatizácie.

Postup je jednoduchý:

1. Vyberie sa “trigger”, ktorý má automatizáciu vyvolať, ako napríklad:

• vytvorenie tasku,
• zmena hodnoty v niektorom z polí,
• vytvorený komentár v tasku,
• začiatok šprintu,
• koniec šprintu,
• manuálne spustená automatizácia,
• naplánovaná automatizácia (raz za deň, mesiac…).

2. Vyberie sa podmienka, na ktoré tasky sa trigger má vyvolať.

• Tasky je možné obmedziť aj pomocou JQL.
• V prípade potreby je možné vyvolať alternatívnu akciu na tasky, ktoré nespĺňajú podmienku.

3. Nastaviť požadovanú akciu, ako napríklad:

• zmena hodnoty v poli,
• vytvorenie komentára,
• pridelenie tasku userovi,
• odoslanie e-mailu.

V prípade záujmu o otestovanie týchto možností, stačí pozrieť na stránku, kde je uvedených aj zopár užitočných príkladov.

Keďže táto funkcionalita ešte nie je dlho v obehu, zatiaľ ju využívame len na pár drobných automatizácií. Ale aktuálne je možné dosiahnuť napríklad:

• Nastavenie predvoleného času na typ tasku. (Máme max. 2 h na riešenie bugu.)
• Pripomienka na Code review. (Upozornenie, že task čaká na Code Review už dlhšie ako deň.)
• Automatické zvýšenie priority tasku podľa deadline-u. (Ak mám deň do deadline-u, zvýšim prioritu tasku na Blocker.)
• Pripomienka deadline-u. (Ak mám dva dni do deadline-u, odošlem e-mail s upozornením na blížiaci sa deadline.)
• Otvorenie zatvoreného tasku po odoslaní nového komentára. (V prípade otázky na už zatvorený task sa task znovu otvorí, aby sa nezabudlo na otázku odpovedať.)
• Zatvorenie duplikovaných taskov. (Ak bol nejaký task zadaný viacnásobne, označený duplikát sa zatvorí.)
• Zatvorenie tasku, ak sú všetky subtasky hotové. (Ak sa všetky subtasky dokončia, automaticky sa ukončí aj task hlavný.)
• Zatvorenie subtaskov, ak je hlavný task hotový.

Na záver k tomuto len spomeniem, že jednotlivé automatizácie je možné obmedziť na spustenie len v rámci:

• tasku,
• projektu,
• na celý systém.

Bohužiaľ, nejde o úplne free funkcionalitu, pretože v rámci bežného účtu je dostupných len 1000 volaní na mesiac, pričom 500 je pre samotnú JIRA a 500 pre Service Desk. Každé jedno spustenie automatizácie predstavuje 1 volanie. Čiže si treba poriadne premyslieť, čo je vlastne potrebné automatizovať. V prípade potreby, samozrejme, za poplatok, je možné si tento limit navýšiť.

Na záver mám jedno posledné odporúčanie – 10. nespomaľujte JIRA inštaláciou tisícok pluginov. Niektoré pluginy majú za následok spomalenie celého systému na také hodnoty, že si radšej pri otvorení tasku pôjdete najskôr spraviť kávu, potom raňajky… Preto treba každý jeden plugin inštalovať s rozumom. A ďalší, možno ešte príjemnejší, bonus, ani pricing potom nevyskočí na privysoké hodnoty :).