Suomalaisen IT-kentän tärkeä markkinapaikka IT-wiki on yhdessä Viestintäministeriön kanssa toimittanut joukkoistamalla (joukkoistuttanut?) mainion Digitalisaation oppaan. Kirjoitin sinne yleisesittelyn Ketteristä menetelmistä, josta tässä artikkelin SWOT-osuus.

Vahvuudet:

Määrittely ja varhainen arvon luonti:
Määrittelyä ei tehdä määrittelyn vuoksi. Perinteinen vesiputousmalli on hyvin haavoittuvainen asioille, joita ei pystytä projektin alussa tunnistamaan. Ne uhkaavat aikataulua ja budjettia. Lähes aina projekteissa tarpeet muuttuvat kesken projektin.
Agile ja Lean toteutustavat vastaavat näihin ongelmiin tarkentamalla projektin määrittelyä kokemuksen ja tiedon karttuessa. Kentältä ja loppuasiakkailta saatu palaute on äärimmäisen tärkeää. Tarkoituksena on tuottaa asiakkaalle arvoa mahdollisimman varhaisessa vaiheessa.



Tuottavuuden kasvu:
Projektin aikajanan ollessa pitkä, kiireen tuntu usein häviää ja aikataulut alkavat painaa projektin lopun lähestyessä. Tätä menetettyä aikaa ei loppuvaiheessa saa enää takaisin. Ihmisillä on usein tapana tehdä asiat viime tingassa. Järjestämällä työt muutaman viikon kehitysjaksoihin kokonaisuuden hallinnasta tulee huomattavasti helpompaa. Ketterässä kehityksessä siis hyödynnetään opiskelijan syndroomaa, jossa vasta deadlinen lähestyessä alkaa tapahtua. Tämä ei toki ole ainoa syy kehitysjakson pituudelle. Itseohjautuvat kehitystiimi pystyy sitoutumaan itse asettamaansa tavoitteeseen, koska arvioita ei tarvitse tehdä muutamaa viikkoa pidemmälle aikajaksolle. Tavoite ei siis saa vaikuttaa mahdottomalta saavuttaa.



Henkilöriskin minimointi
Avainhenkilön poistuminen projektista aina suuri riski, mutta vesiputousmallissa erityisen tuhoisaa. Ketterässä mallissa harjoitetaan tiedon jakamisen tekniikoita kuten pariohjelmointia, päivittäisiä lyhyitä tapaamisia ja tilanteen tarkastelua säännöllisin väliajoin. Ketterään tiimiin kuuluu usein myös useita henkilöitä, jolloin tieto on jakautunut useamman henkilön kesken. Kaikki tiiminjäsenet ovat avainhenkilöitä ohjelmistokehittäjistä liiketoiminnan edustajiin.



Aikatauluvirheet
Ohjelmistokehitystä on lähtökohtaisesti erittäin vaikeaa arvioida ja aikatauluttaa. Käyttäessä ketteriä menetelmiä koko kehitystiimi on itse mukana suunnittelussa ja arvioiden koostamisessa läpi projektin. Työskentelemällä lyhyissä kehitysjaksoissa tiimin todellinen velositeetti eli kehitysnopeus tulee esiin kaikille osapuolille. Todellinen etenemisvauhti alkaa siis muutamien kehitysjaksojen jälkeen hahmottua.



Määrittelyn vastuu ja ristiriidat
Ketterissä projekteissa pitäisi aina olla tuoteomistaja. Kyseessä on henkilö, joka on vastuussa tuotteen kehitysjonon sisällöstä ja kehitystiimin tuottaman työn arvon maksimoinnissa. Kyseinen henkilö on usein toimialan asiantuntija ja toimii välikätenä loppukäyttäjien, ohjausryhmän ja muiden projektin sidosryhmien välillä. Näin kehitystiimillä on aina yksi kontaktihenkilö, eikä projekti kärsi vaatimusten pirstaloitumisesta, jota perinteisissä projekteissa usein tapahtuu, jos mukana on useita määrittelijöitä eri intresseillä.

Heikkoudet:

Ketterän harjoittaminen oikeassa muodossa
Todellista ketterää mallia toteutetaan todella harvoin, mikä on sen suurin ongelma. Kyse ei ole vain sanasta ketterä tai siitä, että dokumentaatiolle annetaan pienempi arvo. Ei missään nimessä! Ketterässä kehittämisessä on formaalit säännöt ja viitekehys, mutta ne eroavat hyvin paljon perinteisestä mallista. Ketteryys on iteratiivista, mukautuvaa ja sitä tuetaan teknologioilla ja tekniikalla. Ketteryys ei varsinkaan tarkoita sitä, että ihmiset saavat tehdä mitä haluavat ja organisoituneisuus sekä prosessit puuttuvat.



Refaktoroimisen tarve
Tietämyksen kasvaessa refaktoroinnin tarpeet kasvavat. Huomataan, että joku kohta olisi pitänytkin tehdä toisella tavalla. Tämä on normaalia ohjelmistokehityksessä, mutta se voidaan tulkita myös heikkoudeksi. Mikäli kehitystiimin työ ei ole synkronoitua ja hyvin suunniteltua, törmätään järjestelmän eri osien yhdistämisvaiheessa tilanteisiin, joissa isoa osaa koodista täytyy muokata halutun lopputuloksen saavuttamiseksi.



Asiakasriippuvaisuus
Asiakastyöskentely ja tiivis yhteistyö ovat ehdottomasti Ketterän kehitystavan suurimpia etuja. Kuitenkin, jos asiakas ei ole riittävän sitoutunut projektiin, voidaan se tulkita myös heikkoudeksi. Ketterät kehitystiimin työskentelevät perinteistä projektiorganisaatiota huomattavasti tehokkaammin, mutta niihin liittyy paljon hallinnollista työtä. Asiakkaalta / tuoteomistajalta on löydyttävä kaikki tarvittava aika tiimin työn edistämistä varten. Muuten kehitystahti hidastuu ja arvon tuottaminen vähenee.



Kettärät menetelmät toimivat parhaiten samassa tilassa
Tästä voidaan olla montaa mieltä ja etätyöskentelyä varten kehitetyt työkalut ja ratkaisut kehittyvät koko ajan, mutta uskaltaisin silti todeta, että ketterät tiimit menestyvät parhaiten, jos koko tiimi työskentelee samassa tilassa. Ideaalitilanteessa myös liiketoiminnan edustaja ja tuoteomistaja työskentelevät samassa tilassa. Näin sisäinen viestintä paranee ja ongelmiin saadaan ratkaisut mahdollisimman nopeasti. Tämä ei aina kuitenkaan toteudu käytännön haasteiden vuoksi, ja siksi kommunikointiin ja yhteydenpitoon tuleekin kiinnittää erityistä huomiota.



 

Kirjoittaja: Joonas Koski
Scrum Master, Projektipäällikkö ja HR-asiantuntija

[email protected] / 0400 293 636

Tags: agile development, ketterä kehitys, lean development, scrum