Jira ei ole vain devaajille - kolme yksinkertaista tapaa käyttää sitä laajemmin

Törmään usein työssäni asenneongelmaan, jota esiintyy Atlassian-käyttäjäorganisaatioissa: Jirahan on vain softadevaajien työkalu. Näin ollen sovelluksen käyttö siiloutuu pahimmillaan vain kehitystiimeille ja organisaatio luopuu tietoisesti erittäin vahvan tiimikollaboraatiotyökalun tarjoamista synergiaeduista muissakin toiminnoissa kuin kehityksenohjauksessa.

Esittelen tällä kertaa muutamia esimerkkejä Jiran käytöstä vähän yllättävissäkin käyttötarkoituksissa, joilla organisaation hankkimista Jira-lisensseistä saa hyötyä monille erilaisille tiimeille.

• Lomakalenteri

• Riskienhallinta

• Vaatimustenhallinta

Lomakalenteri

Jira Software Cloud -ympäristöissä on mahdollista käyttää Jira Work Management Cloud -sovelluksen projektipohjia. Näistä minimaalisen Task Management -pohjan päälle voi rakentaa näppärän lomakalenterin tiimille. Kun se on käytössä, voi lomia tuoda integraatioilla Jirasta muihin näkymiin ja esimerkiksi lomien alkamisesta lähettää automaattisia hälyjä vaikka Slackiin.

Jira Work Managementin Calendar-näkymä toimii näppäränä lomakalenterina. Lomat ovat Jira-tikettejä. Päivää painamalla voi merkitä uuden loman. Lomakalenterin kustomoinnit normaalista minimaalisesta Task Managementista ovat hyvin kevyitä. Lomat ovat tikettejä, joille merkitään vain otsikko, alkupäivä ja loppupäivä.

Työvuomääritelmässä lomatiketti voi olla tiloissa “loma tulossa”, “loma meneillään” ja “loma mennyt”. Muutokset työvuon läpi tapahtuvat Jira Automationilla ilman käyttäjän toimenpiteitä, eli loma tarvitsee vain kerran syöttää ja sen jälkeen järjestelmä hoitaa loput.

Kun lomat on syötetty Jiraan tiketteinä, niiden nostaminen esimerkiksi tiimin Dashboardille on helppoa. JQL-lausekkeella voidaan tuoda vain tulossa olevat tai meneillään olevat lomat. Toinen käyttötapa voi olla tuoda henkilön tulevat lomat Confluenceen henkilön kotisivulle.

Lomakalenterin käynnistäminen yllä näkyvällä tavalla vie noin tunnin kokeneelta Jira-ylläpitäjältä.

Riskienhallinta

Vaikka Jiraan on saatavilla monia lisäosia riskienhallintaan, kuten suositut Risk Register ja Risk Manager, ei yksinkertaiseen riskienhallintaan kuitenkaan tarvita lisäosaa. Päinvastoin lisäosat käytännössä tuovat riskienhallinnan matriisinäkymän ja dokumenttipohjaisen raportointimahdollisuuden - mikäli näitä ei tarvita, on kustannustehokkaampaa toteuttaa riskienhallinta Jiraan ilman lisäosaa.

Suosittelemme riskienhallinnan toteuttamista omalle kanban-projektilleen, kuten Risk Management -niminen projekti. Sinne kannattaa luvittaa kaikki kehittäjät, jotka työskentelevät siinä kehitysmallissa, jonka riskejä hallitaan ko. projektilla. Vaihtoehtoisia toimintatapoja on upottaa riskienhallintamalli kaikille kehitystiimien Jira-projekteille, tai luoda riskienhallintaprojekteja useita, joilla on monia tiimejä kattavia hallinta-alueita.

Riskienhallinnan tavanomainen vuokaavio riskille on organisaation vapaasti määriteltävissä. Erilaisia malleja on pilvin pimein, mutta ohessa on yksi esimerkki.

Jira Cloudin perusominaisuuksiin kuuluu kyky rajoittaa etenemää prosessissa esimerkiksi tiettyihin henkilöihin, tai vaatia tiettyjen tietojen täyttämistä tietyissä vaiheissa. Riskissä seurattavia tietoja voi syöttää Jiraan ns. custom-kenttiin ilman mitään lisäosia. Kenttiä voi vapaasti luoda yleisen hallintapaneelin kautta.

Kun riskit on hallittu Jirassa, voi niitä kytkeä kehittämiseen ns. issue linkeillä. Ominaisuus kuuluu Jiraan. Kun kytkökset on olemassa, voi siihen perustuen laatia raportointia, kuten kysyä Jiralta: Mitä riskejä kuuluu seuraavan kolmen kuukauden aikana kehitettäviin aiheisiin? Kuka niiden mitigoinnista vastaa?

Koska näitä kyselyjä voi muodostaa Jiran hauilla, voi riskienhallinnan koosteita tuoda esimerkiksi Jiran dashboardille, tai myös Jirasta ulos Exceliin tai Power BI:hin. Yksinkertaisen riskienhallintaprojektin toteuttaminen vie kokeneelta Jira-adminilta tunnin tai pari.

Vaatimustenhallinta

Jiralla voi toteuttaa yksinkertaisen vaatimustenhallintaketjun ilmankin pitkää ja raskasta kehitysmallin uudistusta. Vaatimustenhallinta koostuu tässä esimerkissäni neljästä pääkomponentista: tukiprojekti, vaatimustenhallintaprojekti, kehitysprojekti sekä vapaaehtoinen lisäosa ketjun visualisointiin hierarkiana.

Vaatimustenhallinta voi olla Jirassa vaikka ilman tuki- ja kehitysprojekteja. Vaatimustenhallinnan ideana on merkitä tiketeiksi asiakkailta (tyypillisesti sisäisiä tai ulkoisia loppukäyttäjiä) tulevia kehitys- sekä muutospyyntöjä.

Lisäosilla toteutetaan Jiraan puunäkymä, jossa ketjutettuja Jira-tikettejä voi tarkastella helposti yhdestä paikasta. Ilman lisäosaa ketjut näkyvät tiketeillä ja niitä voi selata edestakaisin, mutta niistä ei saa yhtä koontinäkymää. Lisäosia hierarkioiden visualisointiin on monia. Niiden toiminnot ja käyttöliittymä vaihtelevat yksinkertaisesta monimutkaiseen, ja hinta seuraa mukana.

Tässä esimerkissä käytän edullisinta Hierarchy for Jira -lisäosaa. Vertailu valinnaisten vaatimustenhallintaketjujen visualisointiin käytettävien lisäosien vuosihinnoista. Hinnat on laskettu 200 käyttäjän Jira Software Cloud -ympäristölle:

• Hierarchy for Jira 2 000 USD
• Panorama Hierarchy and Structure 2 250 USD
• Requirements for Jira (R4J) 2 400 USD
• Structure 3 400 USD
• Big Picture Enterprise 11 000 USD
• Advanced Roadmaps* 11 000 USD

* Advanced Roadmapsin (Atlassianin tarjoama ominaisuus) hinta tulee Jira Software Cloud Standardin päivittämisestä Premiumiin. Jos ympäristö on valmiiksi Premium, Advanced Roadmaps on ilmainen. Premiumin mukana saa myös muita etuja, kuten tuotantoa vastaavan testiympäristön ja paremman asiakastuen Atlassianilta.

Kaiken keskiössä on vaatimus, joka on tavallinen Jira-tiketti. Sille voi määrittää mitä tahansa customkenttiä, joissa voi säilyttää organisaation vaatimuksille tärkeänä pitämää attribuuttitietoa. Suosittelen vaatimuksien säilyttämistä erillisellä vaatimustenhallintaprojektilla, jotta kehitysbacklogit kuvastavat niitä töitä, joita kehitystiimit ovat sitoutuneet tekemään. Vaatimustenhallintaprojekti voi olla yksittäinen, joka kattaa koko organisaation vaatimuslistan jaoteltuna kategorioihin, tai vaatimustenhallintaprojekteja voi olla useita, esimerkiksi tiimi- tai teknologiaperusteisesti.

Kuvassa REQ-projekti on vaatimustenhallinta Requirement Management. CS on tuki (Customer Support), CB on kehitystiimin projekti. Lisäosa koostaa puunäkymän parent- ja child-linkityksistä.

Vaatimus elää yksinkertaisen elinkaaren läpi. Se luodaan vaatimuslistalle, sieltä se otetaan jalostettavaksi, minkä aikana tarvittava attribuuttitieto kerätään ja tehdään päätös kehittämisestä, ja lopuksi vaatimus siirretään kehitykseen. Siirto kehitykseen voi tapahtua konkreettisesti Jirassa siirtona, tai jos haluaa säilyttää koko ketjun tuesta vaatimuksenhallinnan kautta kehitykseen, voi kehitystiketin tehdä käsin tai kloonaamalla vaatimuksesta.

Kun vaatimus lisätään vaatimuslistalle (esimerkiksi kloonaamalla tukitiketistä), se linkitetään alkuperäiseen tikettiin child-relaatiolla. Kun vaatimus lopulta etenee kehitykseen, se linkitetään kehitystikettiin parent-linkityksellä.

Jira Automationin avulla jalostuksen läpikäynyt vaatimus voidaan automaattisesti siirtää kehitystyölistalle. Voi esimerkiksi toteuttaa alasvetovalikon, jossa kehitystiimi valitaan vaatimuksen jalostusvaiheessa, ja automaatio luo sinne tiketin automaattisesti kun vaatimus päätyy kehitysvalmiiseen tilaan Jirassa. Linkityksillä koko ketjun saa näkymään puunäkymäksi.

Säilyttämällä koko ketjun palaset systeemissä ja pitämällä niiden välisesti linkitykset voimassa, saa ikään kuin ilmaiseksi useita prosessietuja organisaation tukeen ja kehitykseen:

• Tukiorganisaatio tietää miten pyydettyjen ominaisuuksien kehittäminen etenee.
•  Asiakas (loppukäyttäjä) tietää myös miten pyytämiensä ominaisuuksien kehittäminen etenee.
• Kehitystiimit tietävät miksi, missä kontekstissa ja millä alkuperäisillä vaatimuksilla heiltä pyydetyt uudet ominaisuudet täytyy toteuttaa. Kehittäjä voi seurata jopa koko ketjun alkupäähän asti, mikäli tämä on käyttöoikeuksien puolesta sallittua.
• Muutoshallintaorganisaatio voi vaatimustenhallinnan tontilla vaikuttaa välillisesti kehityksen suuntaan toimimalla suodattimena asiakaspyyntöjen ja kehityslistan välissä.
• Tuesta, vaatimuksenhallinnasta, sekä tulevasta kehityksestä voi muodostaa erikseen raportteja.
• Yksinkertaisen muutoshallintaketjun toteuttaminen Jiraan vie vain muutaman tunnin. Tärkeintä on suunnitella sen istuvuus organisaation toimintaan, ja käydä läpi muutoshallintaprosessi tiimien välillä niin, että kaikki ketjun osasiin liittyvä data Jirassa on jatkossa ajan tasalla.

Jira joustaa monenlaiseen tekemiseen

Yllä oli vain muutama esimerkki siitä, miten Jiran käyttämät mekanismit taipuvat monenlaisen liiketoiminnan hallintaan ja visualisointiin. Jira ei ole siis vain softadevauksen työkalu.

Tässä artikkelissa en mennyt vielä yleisen liiketoiminnan funktioihin, joita Atlassian itse on viime aikoina integroinut osaksi tuotteitaan. Mainittakoon kuitenkin sieltä softadevauksen ulkopuolelta, että Jiraan on viime aikoina saatu mm. CMDB-ominaisuudet, ja vaikka JSM on ollut erinomainen alusta Master Data -tukiprosesseihin alusta asti, niin viime aikoina siihen on saatu Forms-ominaisuus, jolla voi rakentaa dynaamisia Master Datan tukipyyntölomakkeita käyttämättä kolmannen osapuolen lisäosia.

Jutussa mainitsemani toteutukset onnistuvat keneltä vain kohtuullisen kokeneelta Atlassian-ylläpitäjältä, mutta mikäli aiheet jäivät kiinnostamaan ja kaipaatte niiden toteuttamisessa apua, tulemme mielellämme tueksenne suunnittelemaan ja toteuttamaan niitä.