Ostaisitko tältä mieheltä DevOps-projektin?

DevOps – epämääräistä kokeilua ja ajan tuhlaamista vai varma tie laadukkaaseen lopputulokseen? Onnistunut DevOps-projekti vaatii uskallusta sekä toteuttajalta että tilaajalta.

devops.jpg

Kävin jokin aika sitten ensimmäisen lyhyen DevOps-kurssini. Vaikka IT-projektikokemusta on jo lähes 20 vuoden ajalta, olin ja olen edelleen vähän untuvikko DevOps-käsitteiden suhteen. Kuvittelinkin osallistuvani lähinnä ohjelmistokehityksen automaatiokurssille, jossa opeteltaisiin Continuous Integration, eli ohjelmakoodin jatkuvan päivityksen, sekä Continuous Deployment, eli jatkuvien tuotantoasennusten parhaita käytäntöjä. Mutta olinpa väärässä – tai vähintään tiedoiltani vajavainen. Kurssin sisältö avasikin uskomattoman laajan ja monipuolisen käsitteistön organisoitumisesta aina ohjelmaversioiden toimittamiseen asti.

Perinteisessä, vesiputousmallia noudattavassa, ohjelmistokehityksessä ongelmana on usein tuotteen huono laatu, käsin tehtävät tuotantoasennukset, epäselvä käsitys tuotteen kehityksen tilasta sekä harvoin ja epäsäännöllisin väliajoin tehdyt tuotantoasennukset. Kun kehittäjät, development, "Dev", ajavat muutosta ja uutta toimintaa, arvostaa käyttöpalvelu, tuotanto, "Ops", vakautta ja tasaisia oloja. Tästä seuraa psykologinen muuri, "wall of confusion", joka aiheuttaa vaikeuksia haitatessaan kommunikointia kehityksen ja tuotannon välillä, kun käyttöosasto saattaa joutua ratkomaan tuotannon ongelmia puutteellisin tiedoin tai toisaalta kehitysosasto jää vaille arvokkaita tuotannon kommentteja ja kokemuksia.

Yllä kuvattua ongelmaa astuu auttamaan DevOps, joka sisältää paitsi ennalta odottamani integraatio- ja jakelutekniikat, myös kokonaisen kulttuurin ja menetelmät organisoitumiseen. Kehitystyötä tehdään käyttäen ketteriä menetelmiä, jotka mahdollistavat nopean reagoinnin testauksen ja tuotannon havaintoihin, ja projektin edetessä toivottuun muotoon vähitellen rikastuvan tuotteen.

Virheitä ja epäonnistumisia ei pelätä, vaan joskus niitä jopa toivotaan: kenenkään ei anneta jatkaa epäonnistuvaa toimintaa liian pitkään, vaan ns. fail fast -periaate houkuttelee sekä kokeilemaan että tarvittaessa hylkäämään toimimattomaksi havaitut menetelmät ja ratkaisut. Epäonnistumisia kestävästä organisaatiosta käytetäänkin nimitystä "antifragile", joka voitaneen suomentaa särkymättömäksi organisaatioksi. Yhden asian ympärille kerätyt itseohjautuvat moniosaajatiimit, tiimien välinen vuorovaikutus ja rutiinitehtävien tehokas automaatio jättävät tilaa innovaatioille, edesauttavat työssä viihtymistä ja auttavat siten kohti laadukkaampaa lopputulosta.

DevOps ohjelmistoprojektin tilaajan näkökulmasta

Perinteisesti ohjelmistoprojektit ovat suunnitelmakeskeisiä. Projektin alkuvaiheessa vietetään pitkä aika määritellen haluttua toiminnallisuutta. Määrittely kuvaa projektin tuloksen hyvin yksityiskohtaisesti ja yksiselitteisesti ja siksi siitä kasvaa yleensä kunnioitettavan kookas dokumentti. Määrittelyn pohjalta projektin tulos voidaan toteuttaa yksinkertaisesti ja yksiselitteisesti.

Vaikka perinteisiin määrittelyihin perustuva ns. vesiputousmalli saattaa tuntua varmalta ja turvalliselta, ei projekti välttämättä etene suoraviivaisesti. Määrittelyn valmistuttua saatetaan todeta, ettei se vastaakaan alkuperäistä tarvetta tai sitten projektin toteutusvaihe saattaa osoittautua liian suureksi toteuttaa. Myös projektin aikana tehtyihin havaintoihin ja muuttuneisiin tarpeisiin on vaikea reagoida, kun määrittely on aloitettava alusta – ainakin osittain.

Ketterässä DevOps-maailmassa projektin tulos määritellään vain kevyesti. Toteutus on jaoteltu sovitun mittaisiin jaksoihin, sprintteihin, joista jo ensimmäisen tuloksena saadaan perustoiminnallisuudet toteuttava yksinkertainen versio. Tätä versiota kehitetään ja parannellaan kokemusten, havaintojen ja palautteen perusteella, kunnes valmiina on vaatimukset täyttävä valmis versio. Voi tuntua epävarmalta lähteä projektiin, jossa kärjistäen "kokeillaan niin kauan, että on valmista", mutta pienissä jaksoissa tehty kehitys auttaa projektin lopputulosta muotoutumaan juuri tarvittavan muotoiseksi.

DevOps-kulttuurin mukainen kehitys auttaa saavuttamaan paremman lopputuloksen vaatien samalla suurta vastuuta ja luottamusta kaikilta osapuolilta. Projektin tilaajasta ketterä kehitys voi tuntua epämääräiseltä kokeilulta ja ajan tuhlaamiselta, joten projektin toteuttajan on vakuutettava tilaaja sitoutumisestaan tilaajalle parhaaseen lopputulokseen. Tilaajan on uskallettava luottaa projektin toimittajaan, mutta toisaalta myös kannettava oma vastuunsa. Vaikka toteutus tehdään vaihe kerrallaan, on liiketoiminnan vaatimukset kuitenkin kartoitettava tarkkaan ja huolellisesti.

Ketterä toimintamalli korostaa projektin tilaajankin vastuuta: toteuttajille on annettava paitsi täsmälliset vaatimukset, myös tarkat havainnot ja toiveet kunkin version testihavaintojen perusteella. Tämä vaatii melkoisesti panostusta puolin ja toisin, mutta DevOpsin täysin toteutuessa auttavat korkealle tasolle viety automaatio ja nopeat versiotoimitukset keskittymään olennaiseen ja vapauttavat sekä antamaan että vastaanottamaan palautetta tehokkaasti.

On aivan luonnollista, että ohjelmistoprojekteja halutaan tilata tarkkaan määrittelemällä, arvioimalla työmäärää ja aikatauluttamalla ennustettavasti, mutta valitettavan harvoin tarkkakaan määrittely osuu kerralla oikeaan. Vaikka DevOps-käsitteistä puhuva ohjelmistotoimittaja saattaa vaikuttaakin vähän epämääräiseltä, takaavat ketterät menetelmät ja jatkuvat ohjelmistotoimitukset yleensä laadukkaamman lopputuloksen.

Lue lisää DevOps-aiheisia blogejamme >>

DevOps





Tilaa blogikirjoitukset sähköpostiisi


Viimeisimmät kirjoitukset



Seuraa meitä somessa

LinkedIn Twitter Facebook YouTube YouTube