Kuinka visualisoida sprintin tila JIRAssa?

Valittu projektimalli on usein ratkaisevassa asemassa projektin onnistumisen kannalta. Siksi me Druidilla vannomme ketteryyden ja Scrumin nimeen. Scrum edellyttää, että kaikki tehtävä työ kasataan yhteen paikkaan, jotta sitä voidaan hallinnoida järkevästi. Vaikka tämä onnistuisi ihanan hipsteristi seinällä ja paperilapuilla, olemme päätyneet käyttämään insinöörimäisempää JIRA-projektinhallintaohjelmistoa. Se mikä hipsteriydessä hävitään, voitetaan monin verroin takaisin erilaisilla näkymillä, kattavalla raportoinnilla ja muilla hyödyllisillä ominaisuuksilla.

Vakioasetuksilla JIRA luo Scrum-projektille kaksi näkymää: backlog-näkymän sekä näkymän aktiiviseen sprinttiin. Lisäksi työnkulku on yksinkertaisesti mallia “To Do → In progress → Done”. Monille tämä riittää…vai riittääkö? Testataanpa.

Backlog-näkymässä luodaan tarinoita, annetaan pisteet, kasataan sprintti ja käynnistetään se. Tarinoille lisätään (tekniset) alitehtävät. Toistaiseksi kaikki on kunnossa. Näkymä vaihdetaan aktiivisen sprintin puolelle. Otan yhden tarinoista tekoon. Näen helposti, mitä alitehtäviä tarinalla on ja missä tilassa ne ovat. Yksi kerrallaan alitehtävät valmistuvat, kunnes kaikki on tehty. Story on valmis!

Eipäs kun hetkinen… Pitäähän valmistunut tarina kierrättää vertaisarviossa, jotta työn tekninen laatu voidaan varmistaa. Ja toki tuoteomistaja haluaa tarkastaa erillisessä testausympäristössä, että tarinan vaatimukset täyttyvät ennen hyväksymistä. Hmm… Pitäisikö näistä tehdä erilliset alitehtävät? Jokaiselle tarinalle? Kuulostaa toistuvalta käsityöltä.

Oikea ratkaisu on noudattaa hyvän ohjelmistoarkkitehtuurin kultaista sääntöä: luo mallinnettava kokonaisuus järjestelmän tarjoamilla ominaisuuksilla, jolloin järjestelmä “ymmärtää”, mitä olet tekemässä. Tässä tapauksessa tarkoituksena on mallintaa tarinoiden matka alusta loppuun, joten ensimmäinen askel on laajentaa JIRA-projektin työnkulku kattamaan kaikki mahdolliset vaiheet. Tarvittavat askeleet vaihtelevat projekteittain. Tässä yksi esimerkki:

• Sprint Backlog (Kehitystyötä ei aloitettu)
• In progress – Frontend (Frontend-kehitystyö käynnissä)
• In progress – Backend (Backend-kehitystyö käynnissä)
• Development Done (Kehitystyö valmis)
• Peer Review & Deployment (Toisen kehittäjän vertaisarviointi)
• Acceptance testing (Tuoteomistajan hyväksymistestaus)
• Done (Story tehty ja hyväksytty)

Tässäkin asiassa kannattaa toimia ketterästi. Ensimmäinen versio tehdään parhaan tiedon mukaan ja sen jälkeen vaiheita muutetaan saadun kokemuksen perusteella. (Pro tip: Projektin workflowksi kannattaa valita “Simplified Workflow”, jolloin muutosten tekeminen on helpompaa.)

Kun työnkulku on kunnossa, tehdään taikuuksia näkymille. Aktiivisen sprintin näkymän tulee edelleen toimia kuin aiemminkin, jotta kehittäminen sujuu mahdollisimman helposti. Siksi näkymässä ei tarvita kuin neljä ensimmäistä askelta (Sprint Backlog–Development Done). Sen lisäksi luodaan uusi näkymä, joka kulkee meillä nimellä Review. Review-näkymän tehtävänä on näyttää sprintin tila yhdellä silmäyksellä sekä mahdollistaa työn käsittely tarinatasolla, jota putken loppupäässä tarvitaan. Lisäksi haluamme niputtaa ensimmäiset neljä askelta (Sprint Backlog–Development Done) yhteen sarakkeeseen nimeltä Develop, sillä siellä työskennellään alitehtävien parissa ja nyt olemme kiinnostuneita itse tarinoista.

Katso tarkemmat asennusohjeet videosta:

Lopputuloksena tarinoiden kulku on mallinnettu JIRAan, eikä niiden tiloja tarvitse enää arvuutella tai muistella. Lisäksi kaikkien – jopa projektin ulkopuolisten tahojen – on helppo tarkistaa, miten sprintti menee.

Visualisointi auttaa myös hahmottamaan pullonkauloja: jos esimerkiksi nähdään, että tarinoita kertyy jatkuvasti vertaisarviointisarakkeeseen, kehitysprosessia tulee muuttaa vertaisarviointia suosivaan suuntaan. Poikkeuksia tapahtuu, mutta jatkuvat sumat kielivät yleensä puutteellisesta prosessista. Onneksi Scrumiin sisäänrakennetuissa retrospektiiveissä asia voidaan nostaa esille ja korjausehdotusta on helppo lähteä kokeilemaan. Näkymät näyttävät suoraan, onnistuiko kokeilu vai ei.

Pari tunnettua ongelmaa:

– Sprintin päätteeksi tarinat ovat Done-tilassa, mutta niiden alitehtävät jäävät Development Done -tilaan. Ennen sprintin sulkemista alitehtävät on käytävä siirtämässä Done-sarakkeeseen. Homman voi hoitaa kerralla kaikille alitehtäville etsimällä ne Issue Navigatorilla ja muuttamalla tila Bulk edit -työkalulla. Korjauksen voi myös hoitaa ohjelmallisesti JIRAn omalla skriptikielellä, mutta emme ole vielä menneet niin pitkälle.

– Review-näkymässä pitää erikseen painaa Only stories -filtteri päälle. Jos klikkailu ärsyttää, pikaratkaisuna näkymän voi lisätä selaimen kirjanmerkkeihin ja tuoda kirjanmerkkityökaluriville. Me kehittäjät käytämme Grease Monkey -skriptejä, jotka ohjelmallisesti lisäävät oikeanlaiset linkit selaimiimme.