Ohjelmistotuotannossa on pitkään tavoiteltu ratkaisuja, jotka olisivat helposti käyttöönotettavissa. Julkaisua saattavat kuitenkin hidastaa ohjelmiston laadun varmistuksen ja käyttöönoton työläys sekä keskeneräiset ominaisuudet. Aina valmiin ohjelmiston kehitysvaiheessa ollaan tekemässä tarkoituksella koko ajan valmista, jolloin voidaan julkaista uusi versio vaikka joka päivä. Ja kun sovellus on aina valmis, tuotteen ongelmat eivät häiritse loppukäyttäjää, vaikka sovelluskehitysprosessi olisikin vielä kesken. 

Aiemmassa blogipostauksessa väitettiin, että menestyvä ohjelmistotuote on aina keskeneräinen. Tässä ei tietenkään tarkoitettu että ohjelmistoa ei koskaan voitaisi käyttää, vaan että käytössä oleva ohjelmisto aina tarvitsee parannuksia ja lisäominaisuuksia. Sen sijaan asia on päin vastoin: menestyvää keskeneräistä ohjelmistoa täytyy pystyä käyttämään aina.

Vaikka ohjelmisto onkin aina keskeneräinen, se on myös aina valmis. Mitä tämä itseisristiriita oikeastaan tarkoittaa? Lyhykäisyydessään se tarkoittaa sitä että vaikka ohjelmisto on aina muutospaineiden alla, se täytyy aina olla valmis käytettäväksi ja mahdollisesti julkaistavaksi. Joistain tämä voi tuntua itsestään selvältä, mutta se vaatii sekä suunnittelulta että toteutukselta tarkkaa seurantaa ja osaamista että tämä oikeasti saavutetaan. Tarkastellaan lähemmin mitä meillä tarkoitetaan aina valmiilla ohjelmistolla ja mitä hyötyjä siitä on.

Miten ohjelmisto voi olla koko ajan valmis?

Perinteinen

• Ominaisuudet kehitetään erillään
• Manuaaliset stepit
• Testattava laajasti ja korjattava ennen julkaisua
• Ratkaisua ei pääse kokeilemaan helposti

Aina valmis

• Ominaisuudet toimivat koko ajan yhdessä
• Automaatiopainotteinen
• Aina valmis julkaistavaksi
• Uusinta versiota pääsee arvioimaan jatkuvasti oikeassa ympäristössä

Perinteistä ohjelmistoa voidaan kehittää tyytyväisenä ominaisuus kerrallaan ilman, että mietitään miten ne toimivat lopullisessa ajoympäristössä. Kun kokonaisuus halutaan julkaista, sille joudutaan tekemään laajat manuaaliset pystytystyöt ja testit, jotta saataisiin jokin kuva ratkaisun toimivuudesta – vaikka kyseessä olisi hyvin pienikin muutos. Monessa tapauksessa erilliset uudet ominaisuudet voivat nähdä toisensa ensimmäistä kertaa vasta, kun julkaisua ollaan tekemässä. Usein käyttöönotossa tulee yllättäviä ongelmia kun ajoympäristö onkin hyvin erilainen kuin mitä kehittäjien koneilla, tai kun uudet ominaisuudet eivät toimikaan yhdessä niin kuin ne toimivat erillään.

Aina valmis ohjelmisto on lähtökohtaisesti rakennettu siten, että sen toimivuutta ylläpidetään jatkuvasti. Kun uusia ominaisuuksia kehitetään, ne integroidaan vanhoihin ominaisuuksiin ja toisiin uusiin ominaisuuksiin lyhyin väliajoin. Ominaisuudet tulevat eloon erikseen pystytetyssä testausympäristössä samalla tavoin kuin ne olisivat menossa käyttöön loppuasiakkaalla. Kun ongelmia aina vääjämättä tulee, ne huomataan nopeasti ja korjataan heti. Olivatpa ne itse ratkaisussa tai siihen liittyvässä ajoympäristössä.

Ohjelmistotuotannossa vastaavaan lähestymistapaan on kyllä tähdätty jo jonkin aikaa. Esimerkiksi ketterässä kehityksessä käytetty ja vakiintunut Scrum pyrkii siihen, että jokaisen inkrementin aikana olisi käytettävä versio ohjelmistosta valmiina asiakkaalle. Viime aikoina DevOpsin myötä ammattilaisten keskuuteen on kehittynyt myös jatkuva julkaisu -termi (tai Continuous Delivery, CD), joka on käytäntö, jolla versio ohjelmistosta voidaan millä hetkellä tahansa ottaa käyttöön. Tästä hyvinä esimerkkeinä Martin Fowlerin kooste sekä Googlen yhteenveto konseptista. 

Silti monissa ohjelmistoprojekteissa on kiusaus viivästyttää työtä, jotka liittyy ominaisuuksien integraatioon, ajoympäristön pystyttämiseen ja olennaisten bugien korjaukseen. Yhtenä syynä tässä on se, että ominaisuuksien kehittäminen näyttää todella nopealta, kun ei tarvitse välittää ajoympäristöistä tai muiden kehittäjien ominaisuuksista. Todellisuudessa ongelmien löytymistä vain viivästetään, ja niiden ratkaiseminen on aina kalliimpaa mitä myöhemmin ne löydetään.

Ohjelmistoa pitää aina pystyä käyttämään ja sitä pitää käyttää

Toinen tapa kuvata aina valmista ohjelmistoa on, että sen pääversio ei koskaan saa olla rikki. Ja koska se ei ole milloinkaan rikki, ohjelmisto pystytään antamaan asiakkaalle käyttöön, kun tarve tulee. Lisäksi koska ohjelmistosta on aina olemassa versio, jonka tiedetään toimivan, siihen pystytään nopeasti tekemään parannuksia. Esimerkiksi, jos huomataan, että jokin ominaisuus onkin paljon tärkeämpi kuin mitä aiemmin ajateltiin, voidaan helposti priorisoida sitä työtä. Tämä mahdollistaa myös ongelmien nopean ratkaisun asiakasympäristöön asti ilman, että muut keskeneräiset ominaisuudet aiheuttaisivat hidastusta.

Mahdollisimman oikeanlainen ajoympäristö auttaa tuotteen omistajaa ja kehitystiimiä keskustelemaan parannuskohdista ja löytämään mahdollisia puutteita mahdollisimman aikaisessa vaiheessa.

Yksi olennainen osa aina valmiin ohjelmiston kehitysprosessia on, että jokin versio ohjelmistosta on aina jaossa jossain ajoympäristössä. Ideaalitilanteessa ohjelmisto pyörii palvelimella, jonne sekä kehittäjät että tuotteen omistaja pystyvät ottamaan yhteyttä. Tämä ympäristö tulisi olla mahdollisimman lähellä sitä ympäristöä, mihin loppukäyttäjille tarkoitettu julkaisu tehdään. Mahdollisimman oikeanlainen ajoympäristö auttaa tuotteen omistajaa ja kehitystiimiä keskustelemaan parannuskohdista ja löytämään mahdollisia puutteita mahdollisimman aikaisessa vaiheessa.

On tärkeää, että jaossa olevaa ohjelmistoa oikeasti käytetään. Kun kehitystiimi on rakentanut järjestelmän, johon voidaan ottaa yhteys ja kokeilla sen toimivuutta, täytyy sitä jatkuvasti käyttää kuin lopullista tuotetta käytettäisiin. Hyvässä tapauksessa ohjelmiston testiversiota käytetään mahdollisimman samalla tavoin, miten loppukäyttäjät sitä käyttäisivät. Parhaimmassa tapauksessa oikeat loppukäyttäjät alkavat käyttämään ohjelmistoa mahdollisimman aikaisessa vaiheessa.

Automaatio varmistaa, että ohjelmisto on oikeasti aina valmis

Aina valmiin ohjelmiston tekeminen ei ole kuitenkaan ilmaista: ohjelmisto pitää olla helposti paketoitavissa, ja sen vaadittu laatu täytyy olla varmistettavissa jokaisen pienenkin muutoksen yhteydessä. Nämä ovat työläitä ja hintavia tehdä ohjelmistokehittäjien ja -testaajien tekemänä joka kerta, kun halutaan uusi versio jonnekin pyörimään. Ja mehän halusimme uutta versiota käyttöön koko ajan. Tähän lääkkeeksi, ei kovin yllättäen, osoittautuu automaatio.

Automaatio pitää huolta, että jokainen muutos käy laadunvarmistusvaiheen ja julkaisuvaiheen läpi.

Modernit DevOps-käytännöt tuovat ohjelmiston käyttöönoton lähemmäksi kehitystä. Näitä käyttäen ohjelmiston kehitystä ei tehdä pitkään ilman, että jonkinlainen käyttöönotto sille tehdään automaattisesti. Automaatio pitää huolta, että jokainen muutos käy laadunvarmistusvaiheen ja julkaisuvaiheen läpi. Usein julkaisu tapahtuu ensin kehittäjätiimille tarkoitettuun ympäristöön, missä kaikki läheiset sidosryhmät pääsevät sitä käyttämään, mutta joissain lähestymistavoissa se voi mennä suoraan tuotantoonkin.

Monelle voi näyttää siltä, että julkaisuun tarvittavat askeleet voidaan tehdä nopeasti ja helposti käsinkin. Jos tarvittavaan automaatioon ei kuitenkaan panosteta, huomataan että samat virhealttiit asiat täytyy tehdä uudelleen monta kertaa. Helposti löytyy syitä minkä vuoksi kaikista muutoksista ei jakseta tehdä vaadittavaa laadunvarmistusta oikeassa ajoympäristössä ja ongelmien löytymiset siirtyvät vain tulevaisuuteen. Päädytään tekemään enemmän töitä ja saadaan huonolaatuisempi ratkaisu.

Kehitystiimin täytyy tarkoituksella kehittää aina valmista

Kaikkien muutoksien täytyy olla niin laadukkaita, ettei hävetä laittaa niitä asiakkaalle käyttöön.

Kuten kestävä kehitys yleensäkin, aina valmis ohjelmisto vaatii kehitystiimiltä tiettyä kurinalaisuutta sekä vaatimusta korkeasta laadusta. Jotta ohjelmisto olisi aina valmis, sen pitäisi olla aina niin laadukas, että sen uskaltaa antaa julkaistavaksi. Toisin sanoen on vältettävä houkutusta tehdä ”väliaikaista heikompaa” ohjelmistokehitystä, vaan kaikkien muutoksien täytyy olla niin laadukkaita, ettei hävetä laittaa niitä asiakkaalle käyttöön. Vaikka tuotetta ei hetken mielijohteesta aina julkaistaisikaan, koko ajan valmis tuote antaa luottoa sille, että se toimii. Kun tulee aika julkaista tuotteesta uusi versio, ollaan päästy kokeilemaan jo pidemmän aikaan että toiminnallisuus on mitä halutaan ja toimii laadukkaasti. 

Kehityksen alkuvaiheessa ratkaisussa ei välttämättä ole kaikkia ominaisuuksia valmiina, mutta vaikka se olisikin tyhjä sivu selaimessa, sen on hyvä pohja keskustelulle ja jatkokehitykselle. Alkuvaiheen versioissakaan ei saa olla käyttöä estäviä bugeja, ainoastaan puuttuvia toiminnallisuuksia. Suunnittelussa täytyy keskittyä aina ensin tärkeimpiin ominaisuuksiin ja saada ne toimimaan kokonaisuudessaan.

Meillä Monadilla tähdätään aina korkean laadun kestävään ohjelmistokehitykseen. Laadukkaaseen ohjelmistokehitykseen vaaditaan sen lisäksi, että itse ohjelmisto on tehty hyviä tapoja käyttäen, myös sitä että tehdään oikeita asioita ja ratkaistaan oikeita ongelmia. Tätä varten tarvitaan jatkuvaa kommunikaatiota ohjelmiston toteuttajan ja sen tilaajan välillä. Olennaisina työkaluina käytämme mahdollisuuksia esitellä tuotetta kehityksen aikana, pidämme sen jatkuvasti hyvällä laatutasolla ja mahdollistetaan ohjelmiston käyttöönotto silloin, kun se kaikille parhaiten sopii.