Matka visiosta kehityksen aloittamiseen

Edellisessä kirjoituksessa käsiteltiin visio-dokumenttia IT-innovaatiopalvelumallissa ja pyrittiin havainnollistamaan visiota esimerkin avulla. Tässä kirjoituksessa esitellään mitä tapahtuu myönteisen rahoituspäätöksen  jälkeen ennen kehityksen aloittamista. Aikajänteeltään tässä kirjoituksessa esitettävät asiat  kestävät yhdestä kahteen viikkoon.

Prosessi visiosta kehityksen aloittamiseen

Product owner koulutus idean keksijälle

Myönteisen rahoituspäätöksen jälkeen asiakas eli idean keksijä/omistaja perehdytetään Scrum ja product owner toimintamalliin koulutuksen avulla. Koulutus on räätälöity IT-innnovaatiopalvelumallia varten. Koulutuksessa ei käsitellä pelkästään Scrum ja product owner toimintaa yleisellä tasolla vaan jo koulutuksen aikana mietitään, miten asiakkaan omaa ideaa voidaan työstää toimivaksi palveluksi.

Vision jalostaminen

Koulutuksen jälkeen visio työstetään eri näkökulmista, jotta myöhemmin on helpompaa esimerkiksi tehdä priorisointia eri ominaisuuksien välillä. Vision jalostaminen tehdään yhden tai kahden workshopin avulla. Workshoppeihin osallistuu asiakas/product owner, product  owner tutor-henkilö ja mahdollisesti yksi tai useampi tiimin jäsen.

Lopputuloksena syntyy hieman pidemmälle jäsennelty visio, joka voidaan kuvata esimerkiksi Lean canvas muodossa.

Lean canvas

Samalla pyritään tunnistamaan myös erilaiset käyttäryhmät palvelulle ja hieman miettämään heidän tarpeitaan ja arvostuksiaan. Yksinkertaisuuden vuoksi tämä tehdään vain tärkeimmille käyttäjäryhmille. Lopputuloksena syntyvät kuvaukset käyttäryhmistä ja heidän tarpeistaan sekä arvostuksistaan. Yksi hyvä kuvaustapa käyttäjäryhmille on käyttäjäpersoonat. Käyttäjäpersoonat ovat erittäin hyödyllinen apuväline ominaisuuksien ja käyttöliittymän suunnittelun yhteydessä. Niiden avulla on helpompi samaistua siihen, miltä palvelu näyttää käyttäjän näkökulmasta.

Käyttäjäpersoonat ovat tyypillisesti yhden A4:n kokoisia kuvauksia tyypillisestä käyttäjäryhmän edustajasta. Persoona-dokumentteja on hyvä pyrkiä elävöittämään sopivan kuvan avulla. Persoonakortissa, joka liittyy sähköiseen ostoslistaan voi  esimerkiksi olla seuraavia asioita:

  • Nimi = Maija Tutkija
  • Ikä  = 40 v
  • Koulutus = Tekniikan tohtori
  • Ammatti = Tutkija
  • Asuinkunta = Espoo
  • Asumismuoto = Rivitalo josta on noin kolmen kilometrin matka lähimpään ostoskeskukseen
  • Perhe = Aviomies Mikko joka toimii asiantuntijana VTT:llä, poika Joonas 12 vuotias peruskoululainen, ja tytär Johanna 9 vuotta
  • Harrastukset: Pilates ja lukeminen
  • Rooli: Perheen äiti, joka pitää huolen siitä, että perhe syö ekologisesti ja terveellisesti. Käy myös usein kaupassa vaikka myös Joonas ja Mikko osallistuvat ostosten tekemiseen.
  • Arvostaa: Ekologisuutta, vapaa-aikaa perheen ja harrastusten parissa
  • Tavoittelee: Professorin paikkaa, lisää laatuaikaa harrastustensa ja perheensä kanssa

Teemojen ja Epic:ien löytäminen ja kuvaaminen

Tarkennetun vision ja tunnistettujen roolien/persoonien avulla muodostetaan kokonaiskuva toteutettavasta palvelusta. Tätä varten järjestetään yksi tai kaksi workshoppia joissa keskitytään tärkeimpien teemojan ja epic:ien tunnistamiseen ja kuvaamiseen.

Teemoilla tarkoitetaan niitä osakokonaisuuksia joista palvelu koostuu. Esimerkiksi sähköisen ostoslistan yhteydessä teemoja voisivat olla vaikka:

  • Perheen www-käyttöliittymä
  • Ostoksen tekijän mobiilikäyttöliittymä
  • Satunnaisen ostospäivittäjän mobiilikäyttöliittymä

Epic:eillä puolestaan tarkoitetaan käyttäjätarina muodossa esitettyjä käyttäjätarpeita karkealla tasolla. Esimerkkejä sähköisen ostolistan epic:eistä ovat:

  • Ostostentekijänä haluan tulostaa ostolistan jotta voin ostaa oikeat tavarat kaupasta.
  • Satunnaisena ostoslistan päivittäjänä haluan lisätä helposti  lisätä tavaroita ostolistaan, jotta saan kaupasta tarvitsemani tavarat.

Lisää tietoja teemoista, epiceistä ja tarinoista löytyy mm. täältä.

Tämän työvaiheen lopputuloksena syntyy lista teemoista ja niiden kuvaukset sekä lista tärkeimmistä epiceistä kuvattuna käyttäjätarina muodossa.

Backlogin priorisointi ja  tärkeimpien tarinoiden kuvaaminen

Kun tärkeimmät tarpeet on kuvattu karkealla tasolla (epic) niin seuraava tehtävä on laittaa ne prioriteetti järjestykseen. Ketterässä kehityksessä vaatimukset kootaan product backlogiin. Product backlog on prioriteetti järjestyksessä oleva lista ominaisuuksista joita palveluun halutaan toteutettavan. Prioriteetti listan kärkipäässä olevat asiat on kuvattu tarkemmin (käyttäjätarina plus tukeva materiaali kuten käyttöliittymäkuvat) ja kauempana kärjestä olevat asiat on kuvattu karkemmalla tasolla (epic).

Backlogi rakennetaan priorisoimalla aikaisemmin tunnistetut tärkeimmät epic:t. Äle ole huolissasi listan ei tarvitse olla kattava,  vaan voit lisätä koska tahansa uusia ominaisuuksia tai priorisoida vanhoja uudelleeen.

Priorisoinnin jälkeen tärkeimmät epic muodossa olevat käyttäjätarpeet pilkotaan hieman yksityiskohtaisemmin kuvattuihin käyttäjätarinoihin. Tarkoituksena on pilkkoa tarpeeksi tärkeimpiä epic:jä käyttäjätarinoiksi, jotta tiimi saa kahdelle ensimmäiselle sprintille tehtävää.

Pilkkomisen jälkeen on usein vielä hyödyllistä miettiä priorisointia uudelleen ja varmistaa siten, että listan kärkipäässä olevat asiat ovat oikeasti ne kaikkein tärkeimmät asiat.

Epic:ien priorisointi ja pilkkominen pienemmiksi käyttäjätarinoiksi muodostaa ensimmäisen version product backlogista ja siihen päästään yleensä  jo tehdyn pohjatyön avulla  yhdellä tai kahdella workshopilla.

Ensimmäisen julkaisun suunnitteleminen

Työmää-arviot (alustavat) ensimmäinen julkaisu ja rahoituksen waterline

Tähän asti olemme keskittyneet vision jalostamiseen ja backlogin tuottamiseen. On kuitenkin tärkeää muistaa, että kehitykseen käytettävät resurssit ovat aina rajalliset, joten julkaisujen suunnitteleminen ja palvelun roadmap ovat iso osa product ownerin roolia. Julkaisuja voi suunnitella vain jos käyttäjätarinoiden ja epic:ien työmäärät ovat ainakin karkealla tasolla tiedossa. Ketterässä kehityksessä on selkeä työn jako product ownerin ja muun tiimin välillä:

  • Product owner tekee päätökset siitä millaisia ominaisuuksia tehdään ja mikä on niiden keskinäinen prioriteettijärjestys.
  • Tiimi arvioi ominaisuuksien työmäärät ja päättää itse kuinka moneen tarinaan se sitoutuu jokaisessa sprintissä.

Tärkein tehtävä julkaisun suunnittelemisssa on löytää pienin ja yksinkertaisin mahdollinen määrä toiminnallisuuksia, jotka julkaisemalla palvelu kuitenkin tuottaa hyötyä käyttäjille. Tämän ensimmäisen julkaisun määrittely on product ownerin vastuulla. Hänen kannattaa kuitenkin hyödyntää päätöksenteossaan tiimin arvioita siitä kuinka työläitä eri ominaisuudet ovat ja kuinka monta tarinaa he pystyvät toteuttamaan aina yhden sprintin aikana.

Tiimin ja product ownerin keskustelun tuloksena syntyy karkea arvio siitä mitä ominaisuuksia ensimmäiseen julkaisuun tulee ja koska se tehdään (ensimmäinen julkaisu tehdään aina mahdollisimman aikaisessa vaiheessa). Lisäksi tiimi arvioi muiden kuin ensimmäiseen julkaisuun tulevien epicien työmäärät karkealla tasolla, jotta product owner saa käsityksen siitä, mitä on mahdollista saada aikaiseksi hänellä käytössä olevan rahoituksen puitteissa. Tämän tiedon avulla hän pystyy uudelleen priorisoimaan ominaisuuksia. Nämä arviot täydentyvät koko ajan kehityksen edetessä, tässä on  kyseessä vasta ensimmäiset karkeat arviot.

“Good to go” tarkistus

Ennen varsinaisen kehityksen aloittamista on vielä hyvä kerrata jo tehty työ ja varmistaa, että se muodostaa riittäävän pohjan varsinaisen kehityksen aloittamiselle ja että asiakas/product owner on sitä mieltä, että se on varmasti hänen näkemyksensä mukainen.

Ovatko visio ja backlog nyt valmiit?

Eivät ole, niitä kehitetään vielä eteenpäin ennen kehittämisen aloittamista ja  toimintamalliin kuuluu kiinteänä osana, että niitä kehitetään ja päivitetään koko projektin keston ajan.

Ketterään kehitysmalliin kuuluu, että hyödynnetään mahdollisimman tehokkaasti matkan varrella saatava palaute kuten käyttäjien kommentit ja palvelun käytön tilostotiedot.

Tässä postauksessa kuvattujen tuotosten lisäksi on monia muitakin jotka tukevat ketterää kehitystä. Yksi tärkeimmistä on hahmotelmat käyttöliittymästä. Käyttöliittymäprototyyppien tekemistä ei ole kiinnitetty mihinkään tiettyy vaiheeseen vaan sitä tapahtuu koko kehityksen ajan. Jos product ownerilla on kuitenkin selkeä näkemys palvelun käyttöliittymästä niin se kannattaa piirtää koska se tehostaa vision kommunikointia tiimille.

Tämän postauksen ovat kirjoittaneet Teemu Toivonen (Aalto IT:n sovelluspalvelualueen päällikkö) ja Miikka Roine (Aalto IT, Senior Web Specialist). Päivitämme tätä blogia säännöllisesti, mutta pyrimme saamaan tänne myös jonkun vierailevan kynän välillä.

Posted by Teemu

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *