Ketterän tuotekehityksen opas

Tuoteajattelu on lähestymistapa, jonka avulla digitaalisia palveluja voidaan toteuttaa ja hallita kokonaisuutena, yksittäisten ominaisuuksien sijaan. Tuoteajattelu tähtää palvelun vaikuttavuuteen ja toteutuksen tavoitteellisuuteen. Tuotteen ensisijainen tarkoitus on tuottaa arvoa asiakkaalle, ratkomalla jotakin arjen haastetta. Tuoteajattelu varmistaa, että toteutetun tuotteen ominaisuudet vastaavat asiakkaiden tarpeisiin.

Esimerkiksi Helsingin kaupungilla hel.fi-tuoteperhettä johdetaan tuoteajattelun avulla. Kaupungilla on valtava määrä erilaisia palveluja ja asiakkaita, joiden tarpeisiin hel.fi-sivuston tulee vastata. Tuoteajattelun avulla tunnistetaan ominaisuustarpeiden kaupunkiyhteinen minimitoteutus ja suunnataan kehittäminen käyttökokemuksen kannalta tärkeimpiin kokonaisuuksiin.

Palvelun kehittämistä johtaa tuoteomistaja.

Tuoteomistajan ydintehtäviä ovat tuotevision muodostaminen ja palvelun ominaisuuksista ja sisällöistä koostuvan kehitysjonon priorisointi. Roolissa on keskeistä moninaiset vuorovaikutussuhteet mm. johdon, sidosryhmien, kehitystiimien ja asiakkaiden kanssa. Roolin tehtävänä on tehdä päätöksiä käytännön tasolla: mitä tavoitteita asetetaan, mikä on tärkeää, mitä tehdään ensin, ja mikä on riittävän hyvä. Tuoteomistaja ohjaa monialaista kehitystiimiä kohti minimi- eli MVP-toteutusta ja vastaa myös palvelun jatkuvasta kehittämistä.

Tuoteomistajan rooli kehittyy kaupungilla. Erityisesti digitaalisten palvelujen kehittäminen vaatii tuoteomistajan roolin. Henkilö, joka käytännön tasolla vastaa palvelun kehittämisen ohjaamisesta, on tuoteomistajaroolissa, vaikka nimikkeenä olisikin esimerkiksi projektipäällikkö.

Palvelun kehittämisen eri vaiheissa tuoteomistajalla on tukenaan kehitystiimi, johon tyypillisesti kuuluu eri alojen osaajia mm. hankinnoista, palvelumuotoilusta, käyttöliittymäsuunnittelusta, ICT-arkkitehtuurista ja ohjelmistokehityksestä.

Ketterässä toteutusvaiheessa kehitystiimin roolit varmistavat ohjelmistokehityksen tehokkuuden. Scrum master eli scrummari on kehitystiimin valmentaja, jonka tehtävään kuuluu kehityssprinttien tapahtumien vetäminen ja kehitysjonon jalostamisen tuki. Usein scrummarilta saa apua myös kehityksen työkalujen (Jira ja Confluence) hyödyntämiseen.

Ohjelmistokehittäjien ja muotoilijoiden yhteistyön hiominen on tärkeä onnistumisen edellytys toteutusvaiheessa. Helsingin kaupungin parhaat käytännöt liittyvät uusien ominaisuuksien kuljettamiseen suunnittelusta toteutukseen.

Kehitystiimissä tarvitaan usein myös arkkitehtia tai teknologia-asiantuntijaa isompien tuotevalintojen tueksi. Saavutettavuuden varmistamiseksi kehitystiimin kannattaa tuoda viikottain saavutettavuusasiantuntijoille tuotoksia arvioitavaksi.

• Tee tiimisi kanssa työtapasopimus
• Kirjaa palvelun dokumentaatio Confluenceen
• Käynnistä sprinttitapahtumat ja kehitä tiimin toimintatapoja
• Ohjaa palvelun toteutuksen laatua ja suuntaa
• Seuraa toteutuksen etenemistä ja työn tehokkuutta
• Julkaisuvalmistelut ja palvelun määräystenmukaisuus
• Laadi suunnitelma jatkuvalle kehittämiselle

Tee heti aluksi tiimin kanssa sopimus rooleista ja työtavoista. Näin varmistat, että kaikki tietävät, miten on tarkoitus toimia. Muistakaa palata työtapoihin säännöllisesti ja sopikaa muutoksista, jos ne ovat teistä tarpeen. Sovitut asiat pysyvät hyvin mielessä, jos esim. tulostatte ne huoneentauluksi seinälle.

Sopikaa ja laittakaa kalenteriin ne ajanjohdat, jolloin teette työtä yhdessä. Näin varmistatte aloittavana tiiminä, että kaikkia kehittämiseen tarvittavia asioita, niin kehittämistä kuin sitä tukevia tehtäviäkin, edistetään kehityssyklin aikana.

Ketterää työtapaa käytetään silloin, kun ei ole ennalta täysin selvää, miten jokin asia kannattaa toteuttaa. Asiakas on viime kädessä se taho, joka määrittelee miten hyvin toteutus on onnistunut. Tästä seuraa se, että haluatte tiiminä kysyä asiakkailta mahdollisimman usein palautetta. Ja jotta voisitte kysyä palautetta usein, teidän pitää toteuttaa toimivia järjestelmän osia usein.

Kahden viikon syklit tehtynä ”scrum-menetelmää” noudattaen ovat hyvä lähtökohta. Tämä tarkoittaa sitä, että tiimi valitsee kahden viikon välein mitä tehdään seuraavaksi ja myös sitä, että kahden viikon välein on luontevaa ottaa asiakkaalta palautetta. Kaikkia asiakkaita ei tähän välttämättä tarvitse osallistaa näin usein, mutta miettikää se tapa, jolla saatte aitoa palautetta auttamaan työjonon priorisointia ja muita päivittäisiä päätöksiä silmällä pitäen.

Sprintin työjonolle valitaan sprint-suunnittelussa sen verran työtä, kuin tiimi uskoo pystyvänsä sprintin aikana toteuttamaan. Varautukaa varsinaisen kehittämisen lisäksi myös tekemään työjonon jalostamista. Tämä on tuoteomistajan vastuulla, mutta koko tiimin osaaminen kannattaa ehdottomasti käyttää tähän työhön.

Tiimin on tarkoitus tuottaa palvelun omistajalle hyötyä nopeilla sykleillä. Esitelkää omistajalle, mitä teitte jokaisen syklin jälkeen. Kysykää häneltä palautetta ja toimikaa seuraavan syklin suunnittelussa palautteen vaatimalla tavalla.

Samalla tavalla, kun haluatte saada asiakkaalta ja omistajalta palautetta palvelun toimivuudesta, haluatte miettiä tiimin kesken omien työtapojenne toimivuutta. Käyttäkää työmääräarvioita ja seuratkaa miten hyvin pystytte ennustamaan ennen sprinttiä paljonko tiiminä saatte työtä tehdyksi. Arvioikaa arviointinne tarkkuutta, seuratkaa miten tiimin tehokkuus ja ennustettavuus paranee.

Arvioikaa säännöllisesti, sprinttien jälkeisissä retrospektiiveissä miten työskentely sujui. Mikä toimi, mitä tulee korjata. Pitäkää toimivat asiat ja nostakaa korjattavia asioita työjonolle samanarvoisiksi tekemisiksi, kuin asiakkaalle tehtävät toiminnallisuudet.

Mitatkaa ainakin työmääräarvioiden toteutumista. Kuinka paljon tiiminä arvioitte yhdessä sprintissä ehtivänne tehdä ja mikä oli todellisuus. Katsokaa myös sprintiltä toiselle jatkuvaa trendiä, kehityttekö tiiminä.

Yleisesti mitatkaa vain sellaisia asioita, joiden mittaamisen jälkeen aiotte tehdä päätöksen. Jos mittaamisen taustalla ei ole päätöksentekoa, mittaaminen on usein toiminnan kehittämisen kannalta hukkaan heitettyä aikaa.

Hyödynnä käyttäjätarinakarttaa välineenä, kun hahmotat kehittämäsi palvelun kokonaisuutta ja kun rajaat toteutuksen eri versioita, kuten minimituotteen.

Käyttäjätarinakartta palvelee tuoteomistajaa kokonaisuuden ymmärtämisessä ja siitä tuotteen julkaisuversioita kuten minituotetta rajattaessa. Se auttaa myös kommunikaatiossa eri projektiryhmien välillä yksikön johdosta kehittäjiin.

Ideana on lyhyesti kuvata palvelun käyttäjien käyttötarpeet käyttöpolkuina palvelun läpi ja jaotella jokainen käyttöpolun askel sen jälkeen eritasoisiin teknisiin toteutuksiin, yksinkertaisin ylös ja monimutkaisin alimmaiseksi. Sen jälkeen palvelun eri versioita voidaan rajata esim. vetämällä vaakaviiva kaikkien käyttäjän askelien ylimmän eli karkeimman toteutuksen alle ja päättämällä että tämä muodostaa minimipalvelun.

Käyttäjätarinakartan voit rakentaa joko:

• Kortteina työskentelytilan seinälle,
• PowerPoint-muodossa (Käyttäjätarinakartta-työpohja pptx) (vaatii hel.fi-tunnukset),
• Confluence Whiteboardsissa, jonka sivupohjista löytyy valmiiksi “Käyttäjätarinan kaavio” tai
• Yhteistyöskentelyalusta Mirossa, josta löytyy sille kaksi eri pohjaa (templates -> haku ”user story mapping)

Kun tarvitset apua näiden työkalujen käyttöönotossa, ota yhteyttä Kehittämisen tukeen.

Retrospektiivit eivät ole yleensä suoraan tuoteomistajan velvollisuus, koska yleensä niiden pitämisestä huolehtii tiimissä Scrum Master. On kuitenkin tuoteomistajan vahva etu, että retrospektiivit pidetään, koska niiden varassa on tiimin toimintatapojen parantaminen. Alla olevat vinkit voi siis toimittaa tiimin Scrum Masterille tai ottaa itse käyttöön esimerkiksi laajemmissa kehitysprojekteissa.

Retrospektiivien perussäännöt

• Pidä retrot säännöllisesti, mielellään jokaisen kehityssyklin jälkeen.
• Tunnista aina ainakin yksi parannuskohde ja varmista, että se tulee tehtyä. Kovin montaa parannuskohdetta ei kannata olla työn alla yhtä aikaa.
• Jos retrot eivät tunnu toimivan, etsi syy ja ratkaisu tilanteen korjaamiseen. Älä lopeta retrojen pitämistä – ne ovat se tapa, jolla kehitytään

Alla on tyypillisiä retrojen haasteita ja parannuskeinoja niihin. Retrospektiiviohjeet antavat vinkkejä retron vetämiseen ja haasteiden ratkaisemiseen. Huom! Tyypillisesti retroja vetää tiimin Scrum Master. Sinun on kuitenkin hyvä olla hereillä siitä, että jatkuvaa toimintatapojen parantamista tapahtuu.

Hyväksymistestausta tehdään sitä mukaa, kun tiimi saa toteutettua toiminnallisuuksia. Tuoteomistaja on suuressa roolissa hyväksymistestauksessa, mutta myös muuta organisaatiota voidaan osallistuttaa testaamaan. Testaaminen ei siis ole jotain, joka tapahtuu lopuksi, vaan sitä tehdään jatkuvasti ja siihen kannattaa varautua jo ennen kehittämisen aloittamista. Ohessa lista asioista, joita on hyvä ottaa huomioon:

1. Varmista, että saat käyttäjien tarpeen kiinni jo projektin alussa, määrittelyvaiheessa
   Tämä on tärkeää, jotta voitte sitten testata vastaako toteutettu palvelu aidosti käyttäjien tarpeeseen (sen sijaan, että toteutettu toimii teknisesti täydellisesti, mutta ei vastaa tarpeeseen).
2. Kirjoita tarve käyttäjätarinoihin ja varmista, että Jiran tiketeillä on hyväksyntäkriteerit
   Hyväksymiskriteerien tulee aidosti kuvata niitä perusteita joilla hyväksymistestaus tullaan sitten aikanaan hyväksymään tai hylkäämään. Tämä auttaa kehittäjiä tekemään käyttäjälle toimivaa järjestelmää.
3. Suunnittele mitä asioita testataan missäkin vaiheessa
   Jos järjestelmäsi on laajempi, harkitse kannattaisiko sitä testata ja julkaista käyttäjille osa kerrallaan. Kehittämisen tiekarttaa auttaa myös tämän testauksen jaksottamisessa.
4. Varmista, että hyväksyntätestaukselle löytyy tekijät ja että heillä on oikeasti aikaa tehdä testaus
   Testaajilla on hyvä olla ainakin perusymmärrys siitä miten testattavan palvelun tulisi toimia ja pääsy yhteisiin hyväksymiskriteereihin.
5. Käy testaajien kanssa läpi se miksi testataan ja miten testaus tulee toteuttaa, jotta sen tuloksiin voidaan luottaa
   Selkeät testien kuvaukset ja helppo raportointi auttaa laadukkaaseen tulokseen, mutta on hyvä varmistaa myös testaajien laadukas ja systemaattinen toiminta.
6. Varmista että hyväksymistestauksen tehtävät ovat selkeästi kuvattu ja että testatut asiat on helppo kuitata käsitellyiksi
   Suunnittele tehtävät siten, että ne kattavat järjestelmän toiminnan niin kattavasti, että testauksen jälkeen voidaan luotettavasti päättää voidaanko järjestelmä ottaa käyttöön. Kiinnitä myös huomiota siihen, että korjaustarve on helppo kuvata ja kohdentaa oikeaan toiminnallisuuteen (Xray voi olla työkalu tähän Jirassa, mutta myös Excel-lista voi olla ihan toimiva ratkaisu).
7. Varmista että se ympäristö, jossa testaus tehdään, mahdollistaa kaiken tarvittavan testauksen
   Usein tuotantoympäristössä on enemmän dataa ja suurempi skaala. Pyri siihen, että testausympäristö on tarpeeksi tuotantoympäristön kaltainen. Varmista myös, että testausta tekevillä henkilöillä on pääsy ympäristöön ja tarvittava tuki.
8. Sovi tunnistettujen ongelmien korjauksen prosessi ja se miten nämä uudelleen testataan käyttäjien toimesta
   Varsinkin laajemmissa järjestelmissä tämä on usein tarpeen. Sopikaa myös miten päätetään, että ollaan saavutettu tavoiteltu laatutaso.
9. Dokumentoi testauksen tulokset ja mahdolliset muut huomiot testaajilta
   Dokumentoi huolellisesti testauksen ympäristö, testaajien käyttämät koneet ja selaimet yms. Mikäli tuotantoon siirtyessä testauksesta huolimatta ilmenee ongelmia, näin voidaan helpommin palauttaa ne tilanteet, joissa toimivuus todennettin. Testauksen hyvä dokumentointi helpottaa myös jatkokehitystä ja sen testaamista.