Me Biitillä vannomme ketterän kehittämisen nimeen. Haluan nyt avata tätä lähestymistapaa kaikille niille, joille sana “agile” ei ole entuudestaan tuttu. Scrum. Kanban. Epic. Sprint. Ketterään kehittämiseen tutustuessa törmää moniin hankalalta kuulostaviin sanoihin, mutta yritän tässä tekstissä avata aihetta mahdollisimman ymmärrettävällä tavalla.
Kirjoittaja: Nicholas Holmberg
Lähdetään liikkeelle perusasioista. Miten me lähestymme ketterää kehitystä?
Meille ketteryys tarkoittaa sitä, ettemme suunnittele kaikkea etukäteen valmiiksi yksityiskohtia myöten, vaan määrittelemme aina projektille selkeän tavoitteen ja piirrämme sille suuntaviivat. Tärkeintä on siis ymmärtää, mitä tavoitellaan ja lähteä sen jälkeen liikkeelle pienin askelin. Näitä askelia kutsutaan sprinteiksi.
Jokainen sprint pyrkii tuottamaan toimivan ja hieman pidemmälle viedyn kokonaisuuden asiakkaan kosketeltavaksi. Tavoitteena on viedä jokaisella iteraatiolla ratkaisua pidemmälle niin pitkään, että lopputulos täyttää asiakkaan sille asettamat tarpeet. Emme siis yritä saada kaikkea valmiiksi kertarysäyksellä.
Lyhyiden kehityssyklien vahvuus on siinä, että pystymme tarvittaessa tekemään palautteen pohjalta muutoksia nopeasti sekä hyödyntämään kaikkea matkan varrella opittua. Kuten tapaan sanoa, niin kaikkea ei tarvitse miettiä valmiiksi ennen matkalle lähtöä.
Agile vai vesiputousmalli?
Olet ehkä kuullut joskus käsitteestä “vesiputousmalli”. Se on vastakohta ketterälle kehitysmenetelmälle, sillä projektityössä sillä tarkoitetaan lähestymistapaa, jossa kehitettävän ratkaisun yksityiskohtaiseen suunnitteluun käytetään ennen varsinaisen kehitystyön käynnistystä merkittävästi aikaa ja vaivaa. Vesiputousmallissa suunnitelman muokkaaminen matkan varrella ei ole tavoiteltua.
Vanhassa maailmassa tämä oli se projektimalli, jota IT-projektit usein noudattivat. Silloin toki järjestelmätkin olivat paljon kömpelömpiä kuin nykyään.
”Tällainen kiveen hakattu toimintamalli ei ole tarpeen Salesforce-kehityksessä”
Tällainen kiveen hakattu toimintamalli ei ole tarpeen Salesforce-kehityksessä, sillä Salesforcen vahvuus on nimenomaan siinä, että järjestelmää voidaan hyödyntää osana järjestelmäsuunnittelua, sillä suuntaa-antavan toiminnallisuuden kuvaaminen järjestelmään on näppärää. Miksemme siis antaisi muutoksille sijaa?
Pystymme ketterästi toimimalla esimerkiksi esittelemään vaivattomasti asiakkaalle, miltä järjestelmän käyttöliittymä voisi näyttää. Vesiputousmalli ei perinteisesti rakennu tällaisen havainnollistavan jatkuvan iteroinnin varaan. Järjestelmää harvoin koeponnistetaan suunnitteluvaiheen aikana. Agilessa mallissa asiakkaat pääsevät näkemään ja kokemaan järjestelmän toiminnallisuuksia heti. Kumpi kuulostaa sinusta houkuttelevammalta vaihtoehdolta?
Ketteryys tarkoittaa myös sitä, että pystymme minimoidaan epäonnistumisen riskit hyödyntämällä kykyä katselmoida ja parantaa ratkaisua moneen otteeseen. Tähän tarkoitukseen järjestelmän demoaminen on tärkein yksittäinen työkalu. Demo on osa kehitysprosessia, sen on tarkoitus herättää keskustelua ja tuoda asiakkaalle askel askeleelta näkemystä siitä, miten valmis ratkaisu voisi toimia.
Vesiputousmallia noudattamalla on mahdollista ajautua tilanteeseen, jossa vasta projektin jälkeen huomataan, että lopputulos on kaukana parhaasta mahdollisesta, sillä projektin osapuolten ymmärrystä ratkaisusta ei ole kyetty tuomaan samalle viivalle tarpeeksi ajoissa.
Ketterillä menetelmillä jo pitkähkö historia
En nyt tässä tekstissä sukella sen syvemmälle ketterien kehitysmenetelmien periaatteellisiin sääntöihin tai manifesteihin, mutta kaikkien IT-projektien parissa työskentelevien on kuitenkin hyvä ymmärtää, että ketterillä menetelmillä on takanaan värikäs ja jo melko pitkä historia. Agile ei siis ole mikään ohimenevä trendi-ilmiö. Sen menetelmien oikeellisuudesta ja eroavaisuuksista ollaan tiukasti montaa mieltä.
”Agile ei siis ole mikään ohimenevä trendi-ilmiö.”
Vaikka ketteriä menetelmiä on jo hyödynnetty hyvän aikaa, niin olen silti työssäni huomannut, että ne ovat monille edelleen melko vieraita. Moni asiakas on projektin aluksi suoraan kysynyt, mistä agilessa kehittämisessä on kyse. Joistakin asiakkaista on jopa tuntunut vieraalta, kun projektin alussa ei edes tiedetä tarkasti, missä vaiheessa projektia kukin kokonaisuus saadaan valmiiksi.
Tyypillisesti huolenaiheet liittyvätkin juuri siihen epävarmuuteen, jota avoimeksi jäävät asiat herättävät. Ajaudummeko me projektin aikana väkisin sivuraiteille, jos emme nyt suunnittele kaikkea tarkasti? Voimmeko aloittaa rakentamisen, vaikka emme ole kuvanneet prosessejamme kattavasti? Saammeko me lopulta lainkaan sitä, mitä projektilta halusimme? Mitä kaikkea tämä lähestymistapa meiltä vaatii?
Mitä lähestymistapa vaatii asiakkaalta?
Tiedän, että se vaatii uskallusta ja rohkeutta lähteä mukaan kumppanin ketterään hössötyksen. Varsinkin, jos siitä ei ole aiempaa kokemusta.
Uskallan kuitenkin luvata, että nykyisin ketterillä menetelmillä päästään parempaan lopputulokseen kuin vesiputousmallilla. Niin kuin TLC 90-luvun listahitissä sanoo “don’t go chasing waterfalls”.
Mitä taas vaatimuksiin tulee, niin asenne ratkaisee. On tärkeää osata suhtautua muutoksiin avoimesti, sillä ne kuuluvat olennaisena osana ketterään kehittämiseen.
Lisäksi on tärkeää ymmärtää, että asiakas on projektitiimissä avainpelaajan roolissa. Asiakkaan on sitouduttava olemaan tiiviisti mukana suunnittelemassa ja päättämässä, mitä ominaisuuksia ratkaisuun kehitetään ja mikä on niiden tärkeysjärjestys
Asiakkaan puolelta on löydyttävä henkilö, joka pystyy olemaan tiiviisti mukana projektissa ja tekemään juoksevia päätöksiä. Lisäksi on hyvä saada mukaan päätöksentekijöiden lisäksi loppukäyttäjiä, jotta projektin aikana voidaan kerätä palautetta oikeilta ihmisiltä. Tämän syvemmälle asiakkaan ei tarvitse agilen maailmaan sukeltaa. Avoimella suhtautumisella ja sitoutumisella pääsee jo pitkälle.
Senior Consultant & Team Lead, Biit Oy
