Kun puhumme VALAn ohjelmistokehityspalveluista, sana laatulähtöinen on aina esillä. Mitä kummaa se nyt sitten ihan käytännössä oikein tarkoittaa? Entä miten rakennetaan laatulähtöinen ohjelmistokehityksen kulttuuri, joka tukee liiketoiminnan asettamia tavoitteita? Pyrimme vastaamaan näihin kysymyksiin mahdollisimman hyvin tässä kirjoituksessa. 

Laatulähtöinen ohjelmistokehitys

Kuten sanottua, käytämme tätä sanaparia kun kuvailemme VALAn ohjelmistokehityspalveluita ja ammattiosaajista puhuttaessa käytämme monesti termiä laatulähtöinen ohjelmistokehittäjä. Kerromme nyt tarkemmin mitä laatulähtöisyys tarkoittaa, ensin yleisesti ja sitten VALAn osalta. 

Mitä on laatulähtöinen ohjelmistokehitys

Laatulähtöisen ohjelmistokehityksen ytimessä on ymmärtää se, mitä ohjelmistolla halutaan saavuttaa, kuka sitä käyttää ja ennen kaikkea, että millaista laatua tarvitaan jotta nämä käyttäjät onnistuvat näissä tavoitteissa!

Laadun ymmärtäminen ei ole vain tuoteomistajan tai liiketoiminnan tms. “johdon” vastuulla, vaan ihan jokaisen, joka ohjelmiston kehitykseen osallistuu. Mutta miksi muka? Eikö se riitä, että laitetaan tekniset speksit kuntoon, joiden pohjalta kehitystiimin on helppo suorittaa ilman turhaa liiketoiminnallista asiaa sekoittamassa pakkaa? Vastaus on kieltävä. Jos ohjelmistokehittäjä (mukaan lukien testaaja) ei tiedä mihin tarkoitukseen toiminto tulee, hän tekee luovat ratkaisunsa hatarien tietojen pohjalta, ja arvailut menevät helposti vikaan. Ja jos käy vielä niin, ettei ohjelmistokehittäjä pääse kuulemaan asiakaspalautteita tai seuraamaan tuotannon metriikoita, tämä ymmärrys ei edes ajan saatossa kehity, eikä laadun paranemisesta voi elätellä kovin realistia toiveita.

Kun iso kuva ja laatutavoitteet ovat tiedossa, jokainen voi omalla työllään pyrkiä edistämään niitä joka päivä. Toisin sanoen laatu ja sen varmistaminen kuuluu ihan jokaiseen osaan ohjelmistokehitysputkessa. Laadun rakentaminen ohjelmistoon ei siis ole vain yksi vaihe muiden joukossa saatika yhden henkilön vastuualuetta, vaan jokaisella on omistajuus ohjelmiston laatuun omalta osaltaan toimintatapoja jatkuvasti parantaen. Jos laadussa on ongelma, koko kehitystiimillä on ongelma yhdessä ratkottavaksi. 

Esimerkki laatulähtöisestä ohjelmistokehityksestä VALAssa

VALAn tekemissä ohjelmistoprojekteissa tai vaikkapa QA auditoinneissa käy helposti ilmi, että laatuymmärrys, rehellinen kommunikaatiokulttuuri ja laadunvarmistuksen hyvät käytännöt ovat merkittävässä roolissa projektin onnistumisen kannalta.

Kehitämme VALAssa jatkuvasti työskentelytapojamme, jotta laatu saadaan esille ja keskeiseksi tekijäksi mahdollisimman aikaisessa vaiheessa ohjelmiston kehittämistä. Seuraavassa on esimerkki laatulähtöisestä kehittämisestä vaihe vaiheelta, mutta yksittäisten vaiheiden pituus voi olla ohikiitävä hetki nopeassa julkaisusyklissä tai perinteisemmän projektimallin mukaan kestää useita päiviä (toivottavasti ei kuitenkaan viikkoja).

Laatulähtöinen kehittäminen alkaa siitä, että uusia toimintoja speksatessa joku softan devaamiseen orientoitunut on mukana tarkentamassa tekniset tehtävät. Myös testaamiseen orientoitunut on mukana, ei pelkästään suunnitellakseen testaustehtävät vaan myös varmistaakseen, huomioidaanko esimerkiksi eri käyttäjien tarpeet, vaihtoehtoiset polut ja tavallisten sudenkuoppien ohittaminen.

Laatulähtöisessa koodaamisessa keskeistä on tehdä puhtaan ja luettavan koodin ohella sopivat yksikkötestit ja valmistella muita testaustasoja. Sellaista valmistelutyötä voi olla esimerkiksi rajapintatestien tekeminen tai käyttöliittymää hyödyntävän testiautomaation uusien testikeissien koodaaminen niin pitkälle kuin mahdollista. Tämän lisäksi sekä testattavan järjestelmän koodi että testiautomaatiokoodi katselmoidaan sovittuja koodauskäytäntöjä vasten peilaten.

Kun uusi ohjelmistoversio sitten tehdään,  se viedään yleensä testiympäristöön, jossa ajetaan automatisoitu smoke-testaus nopean palautteen saamiseksi. Jos smoke-testaus on onnistunut, ajetaan kattavammat regressiotestit; joko kaikki olemassaoleva tai vain muutokseen liittyvä testiautomaatio. Toisin sanoen jos testejä on paljon ja aikaa vähän voidaan optimoida testiajoja niin että ne kohdistuvat  vain muuttuneisiin toiminnallisuuksiin. Keskeneräiset automatisoidut testit voi nyt myös viimeistellä olemassa olevaa toimintoa vasten. Myös olennaiset ei-toiminnalliset testit tehdään, kuten suorituskyky- tietoturva ja saavutettavuustestit. Tässä vaiheessa myös tutkiva testaus on oikea bugien sampo, jota hyödyntämällä laatupoikkeamat löytyy etukäteen tarkasti suunniteltua manuaalitestausta tehokkaammin. Laatukeskeisessä testauksessa tärkeintä kuitenkin on, että testauksessa keskitytään laatutavoitteiden ja riskien kannalta olennaisimpiin asioihin.

Kun riittävät testit on tehty ja tarpeelliset bugit korjattu, on hyvä käydä softa läpi käyttäjäryhmiä edustavien henkilöiden kanssa järjestämällä heidän kanssaan hyväksymistestauksen, betatestauksen tai vaikkapa systeemidemon ja palautteen keruun. Tällä varmistetaan käyttäjien tarpeiden ottaminen huomioon joko heti tai seuraavissa julkaisuissa.

Tämän jälkeen ohjelmistoversio voidaan julkaista kaikille, mikä on perinteisesti ollut se ohjelmistokehityksen jännittävin vaihe, mutta jos laatuprosessit ovat kunnossa ja julkaisu on riittävän pitkälle automatisoitu, tämä on aivan tavallinen vaihe muiden joukossa. Luonnollisesti julkaisun jälkeen yhä tarvitaan varmistusta siitä, että kaikki meni kuten pitikin; tehdään julkaisutestaus ja monitoroidaan logeista heti tiiviisti tuotantokäytön onnistumisia ja mahdollisia virhetilanteita.

Tuotannon käytöstä syntyy arvokasta tietoa logeihin, virheraportteihin asiakaspalautekanaviin, joita analysoimalla on hyvä lähteä suunnittelemaan seuraavia toimintoja ja viilaamaan niiden toteutustapaa. Näin seuraava ohjelmistopäivitys palvelee käyttäjiä vielä paremmin.

Kuten kuvauksesta käy ilmi, laatulähtöisyys on mukana ohjelmistokehityksen kaikissa vaiheissa.

Laatulähtöisen ohjelmistokehityskulttuurin rakentaminen

Sukelletaanpa siis asian ytimeen, eli siihen, miten sinäkin voit rakentaa omaan tiimiisi laatulähtöisen ohjelmistokehityksen kulttuuria. 

Demingin ympyrä

Niin kutsuttu Demingin ympyrä on mielestämme hyvä kuvaamaan laatulähtöisen kehityskulttuurin kypsymistä. Demingin ympyrässä on neljä osa-aluetta tai vaihetta: Plan, Do, Check ja Act. Näiden kaikkien vaiheiden sisällyttäminen ohjelmistokehitykseen auttaa saavuttamaan laatulähtöisen kehityskulttuurin. Alla kuvan jälkeen tarkemmin Demingin Ympyrän vaiheista. 

Syöksykierre

Ohjelmistokehitys voi olla hetken aikaa – esimerkiksi konseptointivaiheessa – vain suunnittelua (Plan) ja Toteutusta (Do).

Hyvin nopeasti kuitenkin pitäisi saada palaute mukaan sykliin, muuten joudutaan syöksykierteeseen. 

Jos tällaisella mallilla mennään tuotantoon, niin pian ollaan tulipalotunnelmissa. Asiakkaat soittelevat virheistä, ja tiimi tahkoaa päivästä toiseen kovemmalla tahdilla saadakseen bugikorjausten lisäksi myös uusia toiminnallisuuksia vanhan, epävakaan ohjelmiston päälle. Laatu on epätasaista ja devaajan taidoista kiinni. 

Rutiinityö

Paremmassa tilanteessa ollaan jo, kun suunnittelun ja tekemisen jatkoksi otetaan tarkistus (Check), eli tiimin eri osapuolen kuin toiminnon kehittäjän tekemä testaus ja asiakashyväksyntätestaus. Näin laadusta saadaan hyvä käsitys jo ennen tuotantoonvientiä.

Yleisesti tällainen on ihan ok tilanne, mutta pitkäjänteinen laadun kehittäminen vielä puuttuu. Tekeminen on aina samalla tavalla tehtävää Rutiinityötä, jolloin tiimin toiminta tai tuotteen laatu eivät kehity.

Jatkuva Parantaminen

Kun saadaan mukaan neljäs osa, eli reflektoidaan kierroksen tuloksia (Act), saadaan aikaan jatkuvan parantamisen kulttuuri.

 Tätä voi tehdä kahdella tavalla:

1. Tiimissä sisäisesti, esim ketterien tiimien retrospektiivipalavereissa, joissa kehitystiimin jokainen jäsen miettii parannettavia toimintamalleja yhdessä
2. Tai etsimällä parantamiskohteita käyttäjän näkökulmasta, eli tuodaan tuotanto ja kehitys lähemmäs toisiaan. Analysoidaan esim. tuotannosta kerättyä palautetta, jotta selviää esimerkiksi mihin asioihin asiakkaat ovat tyytyväisiä, ja minkälaisia tuotevalintoja haluamme tehdä seuraavaksi palvellaksemme heitä paremmin.

 Tästä seuraa:

• Motivaatio, luottamus ja tunne asioihin vaikuttamisesta paranee
• Ymmärrys asiakkaan tarpeista kirkastuu koko organisaatiossa
• Myös onnistumisia voi juhlia!
• Laatu paranee pitkässä juoksussa kestävällä tavalla, niin että tiimi voi hyvin

Demingin ympyrän sisäistämällä ollaan jo pitkällä. Laatulähtöinen kehityskulttuuri on kuitenkin paljon muutakin. Selvennämme tätä seuraavaksi kuuden kannustavan ajatuksen kautta.

Laatulähtöisen kehityskulttuurin kuusi ajatusta

01 – Laatutavoitteet tiedossa

Tiimin tulee tietää liiketoiminnan tavoitteista johdetut laatutavoitteet. Eli tiedetään millaista laatua halutaan tehdä. Ei siis pelkästään pyritä ohjelmiston virheettömyyteen, vaan varmistetaan tärkeimmät laadun osa-alueet, joita tässäkin oppaassa on käsitelty. 

02 – Mokaaminen on ystävä

Mokaaminen ei haittaa! Tärkeintä on uskaltaa tuoda virheitä esiin, jotta voidaan oppia niistä tiiminä. Mitä aikaisemmin virheet huomataan, sen edullisempaa niiden korjaaminen on. Tärkeää onkin miettiä, mitä voimme tehdä yhdessä paremmin, ettei mokista koidu hankalia seuraamuksia ja saamme kiinni virheistä aikaisemmin?

03 – Pienet parannukset

Ei yritetä muuttaa koko maailmaa kerrallaan. Kulttuuri muuttuu pienin askelin. Mieluummin yksi asia hyvin kuin monta huonosti. Valitaan yksi tärkeä asia kerrallaan, saadaan se vakiintumaan organisaatioon ja vasta sitten siirrytään seuraavaan. 

04 – Tiimissä on voimaa!

Tärkeää on ottaa kaikki mukaan tekemiseen ja kaikkien tulee tietää laatutavoitteet. Yksi ihminen ei yksinään voi toteuttaa laatulähtöisyyttä. Myös johdon tulee antaa tuki, eli luotetaan tiimin ammattitaitoon ja annetaan sen tehdä päätöksiä. 

05 – Jokainen on muutosagentti

Kulttuurin pitää mahdollistaa, että jokainen yksilö voi edistää muutosta. Kun yksilö huomaa, että tietty asia voitaisiin tehdä paremmin, tulee hänen voida viestiä tästä hyvillä mielin, riippumatta omasta roolista organisaatiossa. On hyvä miettiä ihan päivittäin, että mitä juuri minä voisin tehdä tämän tietyn asian eteen, että kulttuuri muuttuisi. 

06 – Maalaisjärki mukana

Paljon puhutaan DevOpsista, Agilesta, Leanista jne., kaikissa näissä on sama perusajatus – käytetään maalaisjärkeä siinä, että päästään yhteiseen tavoitteeseen, jossa käyttäjät saavat käyttöönsä sopivaa softaa ilman pitkiä odotteluaikoja. Tähän taas päästään pitämällä tuotannosta kantautuva palautesykli pienenä, jolloin tiedetään koko ajan, ollaanko oikealla tiellä. 

Loppusanat

Tiedät nyt perusteet laatulähtöisen ohjelmistokehityskulttuurin luomisesta. Seuraavaksi haluat ehkä pureutua testauksen johtamiseen laajemmin. Alla tiukkaa asiaa testaamisen johtamisesta liiketoiminnan näkökulmasta, kolmessa eri formaatissa. 

Webinaari

Opas

Blogikirjoitus

• Blog
|
• Ohjelmistokehitys
|
• Yrityskulttuuri