Mihin ketteryys katoaa?


2013-12-20, 12:13 Kirjoittanut Tero Ahonen

Kenelläkään ei ole niin ketterää sovelluskehitysprosessia kuin start-up -yrityksillä. Siinä kaikessa yksikertaisuudessaan saatu idea kehitetään ja siirretään tuotantoon. Kaikki toimii helposti ja sujuvasti, koska kehittäjät ovat samalla sekä ylläpitäjiä, että liiketoiminnasta vastaavia. Kuvassa 1 on start-up yrityksen sovelluskehitysprosessin sykli erittäin yksinkertaisesti kuvattuna.

 

Kuva 1: Start-up -yrityksen sovelluskehitysprosessin sykli

Mitä suuremmaksi start-up –yrityksen tuote tai palvelu kasvaa sitä hankalammaksi se operoiminen ja kehittäminen tulee. Uuden version tai korjausten asennuksen yhteydessä täytyy ottaa huomioon aktiiviset käyttäjät, tiedon eheys, jne. Tästä johtuen palvelun kasvamisen kanssa rinta-rinnan kasvaa myös yritys. Jokaiselle tontille palkataan kovia ammattilaisia, jotka pitävät kiinni omista jutuistaan kynsin ja hampain….”Minun pöydältä ei ainakaan menee mitään kökköä tuotantoon…” jne. Tästä seuraa lokeroitumista ja kehittäjä onkin hyvin nopeasti niin kaukana ylläpidosta sekä samalla liiketoiminnasta kuin vaan mahdollista on. Edellä kuvattu skenaario johtaa helposti kuvan 2 osoittamaan sovelluskehitysprosessin sykliin.

 

Kuva 2: ”Kypsän” yrityksen sovelluskehitysprosessin sykli

Kuvien 1 ja 2 laatikoiden välissä kuluva aika voi olla tunnista päiviin riippuen ideasta. Kuvan 1 prosessissa idea saadaan tuotantoon nopeasti vaikka aikayksikkönä olisikin päiviä. Jos kuvan 2 aika yksikkö on päiviä, niin idea vieminen tuotantoon voisi kestää kuukausia. Kuvassa 2 osaan laatikoista voi usein liittyä ulkopuolinen toimia, jolloin prosessi hidastuu entisestään.

Kun kuvan 2 tilanne on ollut jonkin aikaa päällä, niin yleensä huomataan että kilpailijat alkavat menemään omilla palveluilla vasemmalta ja oikealta ohi. Silloin yleensä tarkastellaan omia prosesseja ja mietitään mikä niissä on vialla. Lopputuloksena usein päädytään ketterämpään, jossa liiketoiminta ja kehittäjät ovat lähempänä toisiaan. Samalla myös sovelluskehitysprosessia tarkistetaan ja pyritään automatisoimaan prosessin eri vaiheita kuten testausta. Kokonaisuutena yrityksen sovelluskehitysprosessi pitäisi lyhentyä, tulla nopeammaksi ja tarjota parempilaatuisia lopputuloksia.

Vaikka sovelluskehitysprosessi on viilattu hipomaan täydellisyyttä, jää siitä hyvin usein uupumaan yksi erittäin tärkeä osa; tuotanto ja operointi. Tuotanto ja operointi ovat erittäin tärkeä osa sovellusta ja ilman hyvä operointia sovelluksesta ei saada kaikkea irti ja varsinkin poikkeustilanteet voivat olla hyvinkin haastavia.

Palvelu hukataan ja piilotetaan tuotantoon

Usein sovelluskehitysprosessi viedään hienosti läpi ja saadaan aikaiseksi viimeisintä huutoa oleva palvelu. Palvelu siirretään kolmannen osapuolen avulla tuotantoon ja tehdään hyvät sopimukset ja palvelutasomääritykset. Kaikki ovat tyytyväisiä kunnes sovelluksesta löytyy merkittävä virhe ja asialle pitäisi tehdä jotain. Kenelläkään ei ole mitään tietoa miten sovellus on tuotannossa käyttäytynyt, vienyt muistia, prosessoritehoja tai tietokantaresursseja. Sovelluksen käyttäytyminen tuotannossa on täysin musta laatikko sen toteuttaneille kehittäjille sekä myös liiketoiminnalle.

Usein testeissä ei näkynyt yhtään virheitä, koska sovelluksen käyttäytymistä tuotannossa on melko vaikea simuloida. Eli pitäisi päästä käsiksi tuotannossa olevaan sovellukseen ja saada tietoa mitä sovellus tuotannossa puuhailee. Se ei missään nimessä käy päinsä, koska operaattori haluaa, että sovellus toimii ilman pienintäkään riskiä häiriöistä. Operaattorille sovellus on ollut hyvä rahasampo, healthcheck.html on palauttanut 200 OK:ta, eikä mitään ei ole tarvinnut muutamaan kuukauteen tehdä. Kirsikkana kakun päällä on isohko lasku, jonka on saanut lähettää kerran kuussa vaikka ei ole mitään tehtykään.

DevOps

Ensin ketteryys katoaa byrokratiaan ja prosessin syövereihin ja sen jälkeen se katoaa tuotantoon ja opertointiin. Pienessä start-up yrityksessä kehittäjät ovat lähellä tuotantoa ja heillä on sinne hyvä näkyvyys. ”Kypsässä” yrityksessä tuotanto taas yritetään saada mahdollisimman kauas kehittäjistä. Tuotanto ja operointia pitäisi olla kiinteä osa sovelluskehitysprosessia. Nyt suurimmassa osassa projekteja tuotanto on peikko, joka aiheuttaa ylitöitä ja stressiä aina kun siellä jotain tehdään.

Kun kehittäjät ja tuotanto sekä operointia saadaan puhaltamaan yhteen hiileen ja tuotanto saadaan kiinteäksi osaksi kehitysprosessia, syntyy malli joka tottelee nimeä DevOps (Development and Operations). Kuvassa 3 yrityksen sovelluskehitysprosessin on DevOpsiin tukeutuen laitettu sellaiseen kuosiin, että kehittäminen on sujuvaa ja tuotantoon saadaan vietyä laadukasta koodia tehokkaasti.

Tuotanto ei ole mikään peikko vai ympäristö, jonne laadukas ja testattu koodi pitäisi pystyä viemään helposti ja mielellään automaattisesti.

 

Kuva 3: Sovelluskehityssykli kun tuotanto, operointi ja kehitys tekevät saumatonta yhteistyötä nojaten DevOps –malliin

Harjoitus: Minkälainen sovelluskehitysprosessi teillä on?

StoStaKee-harjoituksessa (Start, Stop, Keep / Aloita, Lopeta, Pidä) pyritään keräämään kaikilta sovelluskehitysprosessiin osallistuvilta henkilöiltä tehtävät, joita he haluaisivat aloittaa tekemään, lopettaa tekemästä tai jatkaa tekemistä. Tehtävät voisi kerätä vaikka post-it-lapulla Stop – Start – Keep –sarakkeisiin. Kun tehtävät on kerätty harjoitukseen osallistujat antavat äänensä niille tehtäville, jotka herättävät heissä suurimmat ”tunteet”. Harjoituksen tarkoitus on avata kaikille mitä tehtäviä prosessissa tapahtuu ja herättää keskustelua.

Lisää aiheesta voi lukea täältä http://newsroom.cybercom.com/devops-syntyy-ketterasta-sovelluskehityksesta-ja-hyvasta-operoinnista/


comments powered by Disqus