Sovelluskehitys ketterällä kehitysmetodilla on nykyään enemmän sääntö kuin poikkeus. Anders työskentelee pääasiassa ketterin menetelmin ja soveltaa eri menetelmiä hybrid-tyyliin, jos se nähdään tarpeelliseksi. Internet on pullollaan oppaita ketteriin projektimalleihin, mutta Andersin COO Jon Tarkiainen pureutuu tässä blogissa ketterän kehityksen periaatteisiin.
Jon on Andersilla vastuussa tuotannon toiminnasta ja hänellä on pitkän linjan kokemus projektijohtamiseen. Oulun yliopisto pyysi Jonin vierailijaluennoitsijaksi Projektijohtamisen peruskurssille, jossa Jon esitteli mm. ketterän ja perinteisen vesiputous kehityksen eroja ja erilaisten ketterien mallien soveltuvuutta erilaisiin projekteihin. Video on nähtävissä täällä. Tässä blogissa esitellään videossakin esiintyviä teemoja.
Mikä on projekti?
Oleellista sovelluskehityksessä on lähteä liikkeelle siitä, mikä on projekti. Projektia voisi kuvailla uniikiksi, kerran tehtäväksi asiaksi, jolla on alku ja loppu. Projekti voidaan toimittaa eri tavoin, joko perinteisellä vesiputousmallilla tai ketterin menetelmin.
Yhteistä kaikilla projekteilla on se, että niillä on kolme muuttujaa:
- Aika
- Raha
- Sisällön laajuus (scope)
Projekti voi olla joko sovelluksen kehittäminen tai laivan rakennus, mutta toimiva projektimalli on ääripäissä aika erilainen. Perinteisessä vesiputousmallissa projektin sisällön laajuus määritellään ennakkoon ja siihen ei kajota projektin aikana.
Esimerkiksi laivanrakennuksessa laivan pituus ja kansien määrä on lyöty lukkoon ennen projektin alkamista, eikä niitä voi muuttaa kesken kaiken. Kolmesta muuttujasta laajuus on lukittu, joten aika ja raha usein muuttuvat. Perinteinen projektimalli on välttämätön laivanrakennusprojekteihin, mutta miinuspuolena se ei jousta yllättävissä tilanteissa. Pitkissä projekteissa on se haaste, kun kristallipallosta ei voida ennustaa kaikkia tulevia yllätyksiä ja aikataulun venyminen on erittäin kallista.
Sovelluskehityksessä toimii eri lainalaisuudet, koska sisällön laajuutta voi matkan varrella muokata. Yllättävien tilanteiden sattuessa laajuutta voidaan supistaa, jolloin voidaan esimerkiksi pysyä tiukassa aikataulussa tai budjetissa, mikä voi olla elinehto esimerkiksi startupin julkaisuaikataulussa. Projektin aikana voidaan todeta, että työaika-arviot ovat olleet liian optimistisia tai jotain ominaisuutta ei voida tehdä koska kolmas osapuoli ei ole vielä valmis tai jotain muuta yllättävää tapahtuu. Silloin asiakkaan kanssa pitää priorisoida, mitkä toiminnallisuudet tehdään julkaisupäivään mennessä ja mitkä tehdään vasta sen jälkeen.
Ketteryyttä on myös se, että aikataulusta lipsutaan, jolloin projektin laajuus ja kustannukset pysyvät suunnitellussa. Ketteryys sovelluskehityksessä tarkoittaa ensisijaisesti joustavuutta, koska projektin kaikkia kolmea muuttujaa voidaan matkan varrella tarvittaessa säätää. Laivanrakennusesimerkkiin jos vertaa, niin laivasta ei voida vain jättää jotain kantta tekemättä, jotta pysytään aikataulussa.
Ketterän kehityksen menetelmät
Ketterään kehitykseen on muutamia yleisesti käytettyjä tapoja tehdä. Scrum-kehitys tarkoittaa sitä, että kehitystyö tehdään pienissä miniprojekteissa, sprinteissä, jotka kestävät tyypillisesti 1-3 viikkoa. Sprinttien sisältö sovitaan aina ensin tilaajan kanssa ja kehitystiimi antaa eräänlaisen lupauksen siitä, että he toimittavat sovitut toiminnallisuuden sprintin aikana. Toimituksen aikana, viimeistään toimituksen lopussa, asiakas testaa ja tarkistaa toiminnallisuuden ja antaa palautetta.
Nopean iteraatiosyklin ja avoimen kommunikaation avulla asiakas on koko ajan perillä, mitä projektissa tehdään ja pääsee varmistamaan, että tehdään oikeita asioita. Ketteryyden yksi suurimmista vahvuuksista on nimenomaan nopea palautesykli, mikä takaa sen, että mahdolliset väärinymmärrykset havaitaan nopeasti ilman että suurta vahinkoa on ehtinyt tapahtua.
Kanban-mallissa ei tehdä sprinttejä, vaan jatkuvia toimituksia. Asiakas tarkistaa kunkin toimituksen toimivuuden, jonka jälkeen kehitysryhmä siirtyy seuraavaan toiminnallisuuteen. Scrum-mallin sprintit toimivat projektin alkuvaiheessa paremmin, sillä kaikkia alkuvaiheen toiminnallisuuksia ei voida viedä tuotantoon.
Kanban toimii erinomaisesti projektin loppupäässä tai jatkokehitysvaiheessa, kun sovellukseen voidaan tuoda jatkuvasti uusia pieniä päivityksiä. Esimerkiksi moni sosiaalisen median alusta toimii Kanban-metodin perusteella, eli jopa joka päivä alustaan viedään uusia toiminnallisuuksia, jotka kehittävät sovellusta. Tällä ajatusmallilla sovellusta voidaan kehittää jatkuvasti kustannustehokkaasti.
KEHITYSTYÖN AUTOMAATIOTESTAUS
Mikä tapa sitten valitaankin, tulee testaus automatisoida mahdollisimman pitkälle, jotta aidosti päästään tilanteeseen missä lyhyessä syklissä voidaan tehdä asiakkaalle toimituksia. Continuous integration (jatkuva integraatio) on tapa missä jokainen koodimuutos laukaisee automaatiotestauksen millä pystytään varmistamaan, että tehty muutos ei riko jotain muuta sovelluksessa. Tämä vaatii luonnollisesti, että testikoodia kirjoitetaan kattavasti, joskus jopa enemmän kuin tuotantokoodia.
Hetkinen, sanoo asiakas. Tuplasti koodia! Eikö tuo ole turhan kallista? Eikö testausta voi tehdä joku asiakkaan työntekijä halvemmalla.
Vastaus on, että ei.
Loppujen lopuksi sovelluskehityksessä itse koodin kirjoittaminen on vain pieni osa tehtävää työtä. Suurin työ on ymmärtää mitä sovelluksen pitää eri tilanteissa tehdä ja mitä se ei saa tehdä. Toisin sanoen ymmärtää testitapaukset minkä pohjalta tuotantokoodi ja testikoodi sitten kirjoitetaan. Työtä minkä kehittäjän täytyy joka tapauksessa tehdä. Se että testauksen tekisi ihminen joka päivä käsin, jokaisen pienenkin muutoksen takia, on ajatuksena absurdi. Se minkä kone testaa tunnissa, kestää ihmiseltä päivä. Sehän se vasta kallista olisikin.
Loppusanat
Ketterän sovelluskehityksen toteutustapoja on monia, mutta tärkeintä on löytää yhteinen sävel tilaajan kanssa. Keskityn seuraavassa blogissani kommunikaation merkitykseen ja tilaajan vastuuseen ketterän kehityksen projekteissa.
Lue myös blogini Ketterän kehityksen myytti – trendien vaikutus projektijohtamiseen
Kirjoittaja:
Jon Tarkiainen
Chief Operative Officer
”A true Starwars fan”
