Kui mõtled Jira tõhusale rakendamisele, siis alusta siit - 6 head praktikat Jira sõpradele
NB! Juhime tähelepanu, et Atlassiani tooteid arendatatakse tempokalt. Artiklis välja toodud tooteomadused võivad ajas muutuda.
Jira kui töövahendi rakendamisel ja haldamisel tasub silmas pidada mõningaid parimaid praktikaid, kui mõelda keskkonnale, mis on skaleeritav, optimaalsete administreerimiskuludega ja samal ajal ka kasutajasõbralik lõppkasutajale.
Järgnevas postituses toome teieni valiku TWNi Atlassiani tiimi nägemusest, mis puudutab Jira häid praktikaid. Käesolev ei kujuta endast rangeid reegleid, aga pigem soovituslikku mõtteainet.
Mõtestatud projektide loogika ja ülesehitus
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.
Jirat haldav peakasutaja
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.
Jagatud seadistuselemendid ja standardiseerimine
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.
Standardiseerimist ja projektide-ülest jagamist võiks võimalusel rakendada ka teiste Jira seadistuselementide puhul (piletitüüpide, ekraanide, väljade, õiguste ja teavituste skeemid).
Mõeldes ka kasutussõbralikkusele - kui näiteks projekti erinevate piletitüüpide juures täidetakse hulk samade nimedega väljasid, võiksid need väljad ekraanidel olla esindatud samas järjekorras.
Nii oleks kasutaja vaatest info sisestamine võimalikult intuitiivne ja sujuv tegevus.
Projekti õiguste haldamine
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.
Kes nendesse rollidesse kuulub, on ära määratletud juba individuaalselt konkreetse projekti raames.
Näide Jira õiguste skeemi Browse Projects õigusest.
Õiguseid võib vastavalt vajadusele kombineeritult jagada nii rollide kui ka gruppide põhiselt.
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.
Töölauad statistikaks ning koondülevaateks
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.
Testkeskkond suuri muudatusi hõlmavate lahenduste testimiseks
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.
Make Jira great (again)
Tööprotsesside kandmisel Jirasse ei ole õigeid või valesid reegleid, sest konkreetne lahendus on individuaalne ning mis töötab ühele, ei pruugi sobida teisele.
Mõtestatud eeltöö abil tekib visioon soovitud terviklahenduse osas mis omakorda suunab juba alguses mõtlema ka sellele, mis viisil nõudmisi lahendada.
Kui sageli piisab standardfunktsionaalsusest, siis teatud juhtudel on hoopis mõistlikum integreerida erinevaid Atlassiani tooteid (näiteks Confluence või Jira Service Management) ja/või rakendada pistikprogramme.
