Ketterän kehityksen myytti – trendien vaikutus projektijohtamiseen 

Ketterän kehityksen myytti – trendien vaikutus projektijohtamiseen 

tammi 31, 2019 Anders Innovations

Esittelyssä Jon Tarkiainen, Andersin melko tuore Chief Operations Officer, intohimoinen Star Wars -fani ja sivutoiminen muusikko. Pitkän linjan ammattilainen on nähnyt projektijohtamisen trendit usealta vuosikymmeneltä ja hän avaa nyt, mikä on tänä päivänä toimivin tapa työskennellä.

Ketteryyden synty 

Ketterä kehitys alkaa olla käsitteenä tuttu jo hyvinkin monelle sovelluskehityksen kanssa töitä tekevälle. Kun oma urani alkoi yli 20 vuotta sitten ei koko termiä ollut oikeastaan edes olemassa. Scrum, agile, agile manifesto ja muut ketteryyteen kuuluvat termit alkoivat nousta suuremman yleisön tietouteen noin 15 vuotta sitten. Alkuun ketteryys oli koodihipstereiden puuhastelua mitä kukaan ei ottanut vakavasti, varsinkaan vesiputousmalliin ja GANTT kaavioihin tottuneet projektipäälliköt.  

Nopeasti kuitenkin huomattiin, että tuossa ketteryydessä on paljon järkeä, eikä se olekaan vain suunnittelematonta tekemistä (mitä se ei edes ikinä ole ollutkaan).

Moni sen ajan projektipäällikkö löysikin itsensä äkkiä Scrum Master -kurssilta ihmettelemässä, että mikä ihmeen backlog, mikä ihmeen sprintti ja miten niin, että tiimi itse muka valitsee, mitä milloinkin tehdään.  

Ikävän useassa yrityksessä ensimmäinen kosketus ketteryyteen menikin pahasti pieleen. Ongelmia syntyi, kun ei osattu muuttaa omaa toimintaa ja ajattelua pois perinteisestä vesiputousprojektista. Pikkuhiljaa se oikea ketteryys on kuitenkin saanut enemmän ja enemmän jalansijaa. Harvemmin enää törmää organisaatioon, joka ei sanoisi olevansa edes jollain tapaa ketterä, kun kysytään sovelluskehityksestä. 

Jonin tarina 

Oma ensimmäinen kosketukseni ketterään kehitykseen on noin vuodelta 2005 - sen jälkeen en ole oikeastaan muuta kaivannutkaan. Varsinkin, kun ketterää kehitystä tekevä yhteisö kehittyy koko ajan ja mukaan tulee uusia aspekteja kuten; jatkuva parantaminen, lean, tiimidynamiikka, TDD, BDD, DevOps, jne.  

Nykyään ketteryys on paljon laajempi käsite kuin projektin aikana tapahtuva koodaustyö ja jokaisella on oma näkemyksensä siitä, mitä ketteryys on. Haluaisin tehdä muutaman noston sellaisista asioista, mitkä eivät ehkä ihan ensimmäisenä tule mieleen, kun mainitaan sana ketteryys. Nämä ovat olleet itselleni tärkeitä asioita, kun puhutaan ketteryydestä. 

Ketteryyden osa-alueista 

Tiimit 

Nykyisin softaa tehdään tiimeissä ja tiimi on hyvin keskeinen käsite ketteryydessä. Itse pidän hyvin tärkeänä, että tiimi toimii hyvin yhteen ja tiimin dynamiikka toimii hyvin. Bruce Tuckman esitteli tiimidynamiikan vaiheet (forming, storming, norming, performing) jo aikoja sitten. Ne olisivat ehkä jääneet unholaan, jos ei ketterän sovelluskehityksen yhteisö olisi näitä nostanut jälleen pinnalle. Jokaisen Scrum Masterin ja projektipäällikön olisi hyvä ymmärtää nämä vaiheet, jotta voi optimoida tiimin tuottavuutta sekä vähentää konflikteista johtuvaa kitkaa. 

Testaus 

Vesiputousmallissa ensin määritellään, sitten koodataan ja lopuksi testataan. Aluksi ketteryys toi mukaan iteraatiot, missä sama sykli käytiin läpi useampaan kertaan projektin aikana. Tämä oli hyvä muutos oikeaan suuntaan. Saatiin palautetta useammin ja nopeammin. Seuraava askel oli testien automatisointi ja jatkuva integraatio. Palautesykli lyheni entisestään. Sitten tuli TDD, eli kirjoitetaan testi ennen kuin koodataan riviäkään tuotantokoodia. Tällä saatiin yksikkötestit tehtyä etupainotteisesti valmiiksi.

Nykyään voidaan mennä vielä pidemmälle ja kirjoittaa kokonaisia featureita testeinä ennen koodaamista. Päästään siis tilanteeseen missä määrittelydokumentti on myös testausdokumentti. Lähes tulkoon kaikki testaaminen voidaan tehdä valmiiksi ennen kuin tuotantokoodia kirjoitetaan ja jokainen muutos käy läpi kaikki testit. Tarkoittaako tämä sitä, että testaajia ei enää tarvita? Vastaus on ei, sillä testaajia tarvitaan edelleen. Heidän ei enää tarvitsee tehdä testausta manuaalisesti, vaan sen hoitaa kone. Testaajia tarvitaan miettimään testitapauksia, varsinkin negatiivisia testitapauksia. He tekevät tiiviisti töitä tuoteomistajan ja koodarin kanssa implementoinnin alussa (the three amigos). 

Läpinäkyvyys projektiin 

Ketteryyden tuoma suurin vahvuus projektipäällikölle on ehkä aikainen näkyvyys edistymiseen ja mahdollisuus muuttaa ja reagoida asioihin, kun siihen tulee tarve. Tämä on oikeastaan koko ketteryyden ydin, mutta silti se helposti unohtuu. Unohtuu ehkä siksi että se ei tule mitenkään ilmaiseksi, kun sanoo olevansa ketterä. Edistymistä täytyy seurata ja toimitus täytyy pilkkoa pieniin kokonaisuuksiin, jotta aikainen reagointi on mahdollista. Burndownit ja burnupit ovat näihin oiva työkalu, mutta niiden rakentamiseen ja ylläpitoon on hyvä nähdä vähän vaivaa. Myös siksi, että ne helpottavat myös asiakkaalle tehtävää raportointia. 

Yksinkertaisesti kaunista 

Viimeisenä nostona tuon asioiden yksinkertaisena pitämisen. Ei kannata tehdä asioita “varmuuden vuoksi” tai “voi olla, että tarvitaan myöhemmin”. Toisaalta ei myöskään tule tehdä tietoisia päätöksiä, jotka sulkevat ovia tulevaisuudessa. Asioiden yksinkertaisena pitäminen on yllättävän haastavaa, koska loppujen lopuksi ketteryydessä on kyse ennustamisesta ja kompromissien tekemisestä. Erityisesti arkkitehtuuria suunniteltaessa on syytä olla varovainen, ettei yksinkertaista liikaa.  

Vanha viisaus “hours of planning can save you weeks of programming” on hyvä pitää mielessä ja käyttää suunnitteluun aikaa.

Mitä paremmin asian suunnittelee, sen yksinkertaisempana sen pystyy pitämään. Yksinkertainen on kaunista, sitä on helppoa jatkokehittää ja sen on myös asiakkaalle kustannustehokkaampaa.

- Jon Tarkiainen, Chief Operations Officer 

Andersin oma Star Wars -elokuvien triviatietäjä ja tulevan Anders-bändin maestro.