Ketteryys on tullut jäädäkseen. Mutta onko se oikeasti parempi tapa kuin ”perinteinen” ohjelmistokehitys? Mielipiteitä on varmasti monia – itse vastaan ”juu ja ei”. Tai sillä kuuluisalla konsultin vastauksella ”se riippuu…”.
Mitä ohjelmistokehityksessä oikein pitää tehdä? Pitää selvittää
Nämähän ovat ihan niitä samoja juttuja, joita on AINA selvitetty.
Vanhassa vesiputousmallissa nämä kaikki piti saada kuvattua TÄYDELLISESTI heti kehittämisen alussa. Mutta kaikki, jotka ovat joskus tehneet vesiputousmallin mukaan, tietävät, etteihän se oikeasti mennyt noin. Toki yritettiin. Ja sitten kun suunniteltiin, huomattiin uusia juttuja tai ettei jokin toimi ja koodatessa viimeistään tuli muutoksia. Toki ikävintä oli, että jos vasta testausvaiheessa löytyi jokin iso perustavanlaatuinen väärinymmärrys tai puute. Silloin piti niiltä osin ”aloittaa alusta”. Mutta eihän KAIKKEA suinkaan aloitettu alusta.
Tästä syystä alettiinkin puhua iteratiivisesta vesiputouksesta 1990-luvulla. Tiedettiin jo valmiiksi, että kaikkea ei voida tietää heti ja maailma on monimutkaistunut. Iteratiiviset mallit kuten RUP (Rational Unified Process) kiinnittivät kuitenkin huomiota siihen, että arkkitehtuurin on syytä olla kunnossa. Siis ne rakennuksen perustukset ja kantavat rakenteet. Niinpä ohjeistettiin, että ensin pitää rakentaa arkkitehtuurin ydin ja koestaa se oikealla toteutuksella sekä testata. Ja vasta sitten sai lähteä kehittämään vaiheittain sen päälle. Korostettiin myös kommunikoinnin merkitystä.
Jos verrataan iteratiivista spiraalimallia ja Scrumin peruskuvaa, niin yllätys, yllätys, nehän ovat melkein samanlaiset!
Näin äkkipäätään sanoisin: lyhyemmät kehityskierrokset ja dailyt.
Kun iteratiivisissa kehitystavoissa puhutaan usein 2-3 kuukauden mittaisista kehityskierroksista, niin ketteryys puhuu 2-4 viikosta. Tuo lyhyempi kierroksen pituus tarkoittaa, että kerralla kehitettävät kokonaisuudet ovat pienempiä. Mutta toisaalta saadaan testitulokset ja palaute asiakkailta nopeammin. On kuitenkin hyvä muistaa, että moni asia ketteryyden taustalla juontuu markkinavetoisuudesta: tehdään pienin asiakkaille kelvollinen tuote. Nimittäin on tärkeämpää ehtiä esim. joulumarkkinoille vaikka vähän keskeneräisellä tuotteella kuin myöhästyä. Sitähän voi sitten jatkokehittää myöhemmin ja tuoda uusia piirteitä seuraaviin versioihin. Tällainen lähestymistapa ei kyllä moneen lakisääteiseen kehittämiseen kelpaa, mutta toki voidaan priorisoida, mitä pitää olla valmiina, kun laki astuu voimaan. Olen nähnyt kuinka erittäin laajoja ja monimutkaisia sovelluksia on yritetty kehittää kolmen viikon sprinteissä – ja aina ne sprintit vuotavat eli ei saada valmiiksi. Silloin pitäisi miettiä, onko se kolme viikkoa oikea pituus – auttaisiko pituuden muuttaminen neljään viikkoon?
Toisena mainitsin dailyt eli päivä- tai tilannepalaverit. Tämä on oikeasti hyvä juttu silloin, kun se saadaan toimimaan oikein. Perinteisemmän tavan projektien viikko- tai kuukausipalaverit helposti kestivät tunnin tai pari ja silloin käytiin menneitä asioita ja edelleen kiusaavia ongelmia läpi. Onnistunut daily kestää max 15 minuuttia ja siinä käydään juuri sen hetken tilanne läpi: mitä sain valmiiksi ja mitä otan seuraavaksi työn alle. Ei pitkiä pohdiskeluja. Jos minulla sattuu olemaan ongelma tai haaste, mainitsen siitä lyhyesti ja kysyn kuka voisi auttaa. Ei siis ruveta purkamaan sitä dailyssä vaan ihan erikseen. Kaikki pysyvät tilanteen tasalla ja työlista saadaan päivitettyä.
Nämä ovat sellaiset selkeät. Ketteryyteen kuuluu myös se, että sprintin alussa on määrittelyn/suunnittelun tarkennuspäivä, johon KAIKKI osallistuvat – siis sekä määrittelyä tehneet, toteuttajat ja testaajat. Ja matkan varrellakin voi kysyä ja tarkentaa. Eikä KAIKKEA tarvitse kirjoittaa tyhjentävästi, mutta on hyvä muistaa, että ylläpitoakin pitää tehdä. Ja onko silloin tämä sama porukka paikalla ja muistavatko kaikki autenttisesti, mitä silloin aikanaan sovittiin? Pitää siis miettiä, mikä on se dokumentaatio, jota tarvitaan, jotta ylläpito esim. kahden vuoden päästä onnistuu.
Meinasin unohtaa retrot eli retrospektiivit, joissa arvioidaan jokaisen sprintin jälkeen, missä onnistuimme ja mitä meidän pitäisi vielä kehittää. Nämä ovat hyödyllisiä, jos OIKEASTI arvioimme omaa toimintaamme ja opimme siitä – esim. mitoittamaan seuraavat sprintit oikein työmäärän suhteen. Kyllähän samantyyppistä on tehty perinteisessäkin projektissa, mutta vasta ihan projektin lopuksi. Silloin se ei hyödytä muita kuin kyseistä projektipäällikköä, joka toivottavasti saa vinkkejä, mihin kannattaa kiinnittää huomiota seuraavissa projekteissa. Ketteryydessä on mahdollisuus tehdä korjaavia liikkeitä jatkuvasti, jolloin ehkä kaikki oppivat.
Ketteryydessä ei siis ole kyse keisarin uusista vaatteista – ainakaan, jos emme unohda kaikkia hyviä käytäntöjä. Ja onhan maailmallakin tutkittu ja todettu, että ketterät projektit onnistuvat paremmin kuin perinteiset. Edellytyksenä on, että otamme molemmista ne hyvät asiat, jolloin saamme hyvän keitoksen aikaiseksi.
Kirjoittaja Tarja Raussi on nähnyt ja tehnyt ohjelmistokehitystä kolmella vuosikymmenellä, joten kokemusta erilaisista kehitystavoista löytyy. Ja sitä kautta ymmärrystä, että tietyt perusasiat pysyvät, vaikka tavat tehdä muuttuvat.