Kui mõtled Jira tõhusale rakendamisele, siis alusta siit - 6 head praktikat Jira sõpradele

Jira kontseptsioonide kõrgeim tase on projekt, mis koondab pileteid (ära kirjeldatud töö ühik). Projekti ja selles sisalduvaid pileteid võiks vaadelda kui aktiivset püüdlust eesmärgini.

Enne Jira kasutuselevõttu tasuks eeltööna mõelda kõikidele organisatsiooni osapooltele – kes Jirat kasutama hakkaksid, millist infot nad peaksid sisestama ning mis on soovitud tulem.

Põhjalikud tööprotsesside kirjeldused ja nõudmiste kaardistus on hea vundament, mille peale luua erinevate osapoolte ootustele vastav töövahend.

Toome siinkohal näite TWNi põhjal - kasutame Jira Software projekte peamiselt nii tarkvaraarenduse tööprotsesside haldamiseks, tiimipõhiste tööde jälgimiseks aga ka värbamisprotsessi toetamiseks.

Kõik eelnevalt mainitud tööprotsessid on väga erinevate eesmärkidega, mis tähendab sisulisi erisusi Jira projektide ülesehituses.

Mõtestatud projektide loogika ja ülesehitus valguses jõuame Jira peakasutajani.

Just paindlikkus teeb Jirast väga võimeka tööriista, kuid siiski võib heade praktikate järgimine ajas muutuda keerukaks, kui erinevad osapooled seda oma äranägemise järgi haldavad.

Meie kliendid on oma peakasutajaid nimetanud Jira jumalateks. Nad võiks olla kogenud Jira administraatorid, kes:

• hoomavad Jirat kui tervikut;
• oskavad lõppkasutaja vajadusi tõlkida Jira kontseptsioonidesse;
• luua uusi ja hallata olemasolevaid projekte võimalikult optimaalsete seadistusega.

Enne uute nõudmiste koheset teostamist võiks peakasutaja võimalikult täpselt välja selgitada, mis on kasutaja takistused hetke lahenduse juures ja mida ta tulevikus saavutada soovib.

Muudatusi võib küllaltki lihtsalt mõne klikiga teostada, kuid probleemi ja eesmärgi defineerimine aitab suurt pilti arvestades luua skaleeritavat lahendust ja vähendada duplitseerivat tööd.

Optimaalse seadistamisega on tihedalt seotud ka järgnevad head praktikad – standardiseerimine, õiguste haldamine, töölaudade ja testkeskkonna rakendamine.

Kujutleme näitena tarkvaraarenduse projekte, mis juhul hallatakse loodavat tarkvara X ja Y erinevates projektides.

Tööprotsessi etapid (pileti elutsükli võimalik teekond) kirjeldatakse Jiras töövoogudena. Igale uuele Jira projektile omistatakse vaikimisi seadistustega muuhulgas ka individuaalne töövoog.

Juhul kui tarkvaraarenduse X ja Y projekti tööprotsessi etapid kattuvad ning muid erisusi ei nõuta, võiks siduda mõlema projekti külge ühe jagatud töövoo.

Kui projekte on tulevikus juba kümnetes või sadades, võimaldab sisuliselt sarnaste seadistuselementide standardiseerimine ja nende jagamine üle projektide vähendada halduskoormust ning süsteemi jõudlusprobleeme.

Kes projekti pileteid näeb ning mis tegevusi projektis teostada saab määratletakse õiguste skeemis. Konkreetsetele tegvustele saab õiguseid anda kasutaja, gruppide, aga ka rollide kaupa.

Kui Jira grupid on globaalsed ehk süsteemiülesed, siis rollid on projektipõhised. Alltoodud õiguste skeemi väljavõtte näite kohaselt on projekti ja selle piletite nägemise (Browse projects) õigus omistatud kahele rollile.

Näiteks kui Browse Projects õigusele omistatakse grupp, tagab see projekti piletite nähtavuse kõikidele kasutajatele, kes sinna gruppi kuuluvad (näiteks grupp kõikide organisatsiooni liikmetega).

Kui aga ei soovita, et kogu organisatsioon saaks selles projektis tegevusi teostada (näiteks piletite loomine, muutmine, suunamine jm) võib nendele õigustele omistada juba projektipõhised rollid.

Samuti võiks gruppe kasutada juhul, kui projektiga liituvad limiteeritud ajaks organisatsioonivälised kasutajad.

Lisades need kasutajad ühte gruppi ning omistades see grupp õiguste skeemis vajalikele tegevustele on ilmselt efektiivsem, kui hakata kõiki väliseid kasutajaid igas projektis ükshaaval rollidesse lisama.

Siiski toimib selline grupipõhine lähenemine vaid juhul, kui kõik grupi liikmed võivad saada samad õigused.

Jira töölaud on hea võimalus kuvada statistikat ja koondülevaadet projekti(de) erinevate kriteeriumite alusel.

Töölaudade rakendamine väldib info killustatust ning tagab seotud osapooltele vajaliku info ühel lehel. Jira töölaua vaatajate ja muutjate õigused on seadistatavad.

Töölaudadel kuvatakse infot vidinate (gadgets) kaupa, mille aluseks võivad olla JQL ehk Jira Query Language filtrid (salvestatud piletiotsingu päring) või projektid.

Näiteks on Assigned to me vidina aluseks vaikimisi filter „assignee = currentUser()“, mis kuvab töölauda vaatavale, sisselogitud kasutajale suunatud pileteid.

Näide Jira töölauast ja erinevatest vidinatest.

Üks paindlikumaid vidinaid on Filter results, mis kuvab andmeid soovitud filtri alusel. Filtrid võivad koosneda erinevatest funktsioonidest ning neid kombineerides on võimalik luua väga detailseid päringuid. Mõned näited:

• project = TEST AND issuetype = Task – kuvab kõik TEST projekti Task tüüpi piletid;
• created > startOfDay("-3d") - kuvab kõik piletid, mis loodi viimase kolme päeva jooksu;
• project in projectsWhereUserHasPermission("Edit Issues") AND status = Open – kuvab kõikide projektide piletid, kus kasutajal on piletite muutmise õigus ja piletid on Open staatuses;
• issuekey IN updatedBy("Mari Maasikas") - kuvab piletid, mida on uuendanud kasutaja Mari Maasikas;
• issue in linkedIssues(TEST-123,"is duplicated by") - kuvab kõik piletid, mis on lingitud piletiga TEST-123 lingi tüübiga “is duplicated by”.

Kuigi töölaua vidinaid on kümneid, on hea praktika vältida vidinate üleküllastumist ühe töölaua vaates.

Paljud Jira seadistuselemendid on omavahel seotud. Laiahaardeliste muudatused on enne live keskkonnas rakendamist mõistlik testkeskkonnas läbi katsetada, et veenduda muudatuste edukuses ja need vajadusel kasutajatega valideerida.

Jira Data Center puhul sisaldub üks testkeskkonna litsents (Developer license) põhitoote hinnas. Jira Cloud puhul saab tasuta testkeskkonna (sandbox) aktiveerida alates Premium plaanist.