Ketterästä ohjelmistokehityksestä kestävään kehitykseen

Kestävä kehitys on hieno termi. Siitä tajuaa heti, että kyseessä on jotain tavoittelemisen arvoista varsinkin, jos pysähtyy pohtimaan mahdollisia vaihtoehtoja. Kuka hitto haluaisi lähtökohtaisesti kestämätöntä kehitystä?

Brundtlandin komissio määritteli kestävän kehityksen vuonna 1987 seuraavasti:  “Kestävä kehitys on kehitystä, joka tyydyttää nykyisen yhteiskunnan tarpeet tekemättä myönnytyksiä tulevien sukupolvien kustannuksella”.

Eficoden historian aikana olemme havainneet, että jotkin menetelmät ohjelmistokehityksessä tuottavat hyviä tuloksia ja toiset eivät. Tietyntyyppiset virheet havaitaan vasta, kun aikaa varsinaisesta toteutusvaiheesta on kulunut. Myöhään havaitut virheet yleensä maksavat paljon.

Ensin ohjelmistokehitystä pelastamaan tulivat ketterät menetelmät, Scrum, Extreme Programming ja Kanban. Ne ratkaisivatkin joitakin perinteisen ohjelmistokehityksen ongelmista: ketterästi tehdyt ohjelmistot yleensä lopulta toimivat täsmälleen siten kuin tilaaja haluaa. Jäljelle jäi kuitenkin kaikenlaisia hankaluuksia. Ohjelmistokehitys on edelleen kallista ja erityisesti pitkäaikainen ylläpito on vaikeaa. Päivitysten, jatkokehityksen, bugikorjausten ja uusien asennusten yhteydessä syntyy yhä uusia yllätyksiä, jotka maksavat paljon ja vievät aikaa. Suurin ongelma on se, että ketterät menetelmät eivät ota huomioon käyttö-, ylläpito- ja asennusvaiheita ohjelmistoa kehitettäessä. Kestävä ohjelmistokehitys palvelee liiketoimintaa pitkällä aikavälillä.

Se...

• vähentää toistuvaa työtä siirtämällä sitä ihmisiltä automaatiolle. Virheet vähenevät ja suurempi osa ajasta voidaan käyttää uusien asioiden luomiseen

• tarjoaa jatkuvaa palautetta kehitysprosessin etenemisestä. Regressiot ja muut piilevät ongelmat saadaan kiinni ennen kuin ne aiheuttavat liiketoimintariskejä

• lyhentää muutosten läpimenoaikaa, eli aikaa muutostarpeesta päivitetyn järjestelmän käyttöön saamiseen

• parantaa tehtävien toistettavuutta. Yleinen ongelma ohjelmistojen käytössä on tuntemattomien muuttujien vaikutus toimintaan: ensin kaikki toimii ja toisella hetkellä ei, eikä kukaan tiedä miksi.

Vuoden 2010 tienoilla DevOps-termin käyttö alkoi yleistyä. Konsepti yhdistää ohjelmistokehityksen ja ylläpidon toimintatapoja yhtenäiseksi menetelmäjoukoksi, jota kuvaa hienosti aikaisemmin viljelemäni ajatus: mitä voidaan dokumentoida, voidaan automatisoida. DevOps on siis menetelmä kestävän ohjelmistokehityksen tavoitteiden saavuttamiseksi.

DevOpsin mahdollistaa yhdistelmä ajattelutapaa, menetelmiä ja työkaluja, jotka keskittyvät seuraaviin käytännön tavoitteisiin:

• Kehitystiimi ja operointitiimi auttavat toisiaan toteuttaakseen liiketoiminnan tavoitteita.

• Laadunvarmistus automatisoidaan mahdollisimman pitkälle.

• Arkkitehtuurissa pyritään selkeisiin, pieniin kokonaisuuksiin.

• Automaatio pitää huolen siitä, että ympäristöjen tila tiedetään aina.

• Käyttö ja valvonta koostuvat automaattisista prosesseista, jotka ilmoittavat kun ihmisten tarvitsee puuttua asiaan.

Menetelmän hyödyt alkavat näkyä, kun järjestelmää kehitetään tai käytetään pidempään. DevOpsin suomenkielinen nimitys voisikin olla kestävä ohjelmistokehitys: menetelmä joka varmistaa, että ohjelmisto saadaan toimintakuntoon nopeasti ja jonka kehitystä voidaan jatkaa aina tehokkaasti sekä laadukkaasti, turhaa työtä alusta alkaen välttäen.

Älä tee mitään turhaa. Yritä maksimoida mahdollisuutesi tulevaan laiskotteluun.