Ketteriä menetelmiä käytetään ohjelmistokehityksessä ja it-projektien läpiviemisessä. Ketterä kehittäminen eli agile development on vaihtoehto perinteiselle vesiputousmallille. Tyypillisesti ketterä kehitys tapahtuu sprinteissä, joiden aikana it-projektin tarpeiden määrittely tarkentuu. Nykyään projekteissa käytetään myös paljon ketterien menetelmien ja vesiputousmallin yhdistelmää.
Lean tuotanto tai toimintatapa on filosofia, joka pitää turhana mitä tahansa toimintaa paitsi suoraa arvonluontia asiakkaalle. Lean startup puolestaan viittaa toiminnan kehittämiseen nopearytmisellä tuotekehityssyklillä, jossa pyritään nopearytmiseen hypoteesin mittaamiseen ja todentamiseen ja sitä kautta onnistuneemman tuotteen kehitykseen ”leanisti” pienemmillä resursseilla.
1. Lean
Lean-termi tulee Lean Manufacturing mallista, jonka auto- ja elektroniikkavalmistaja Toyota teki kuuluisaksi. Kyse on periaatteista, joiden avulla saavutetaan laatua, nopeutta ja asiakasorientoituneisuutta. Leanissa eliminoidaan kaikki, mikä ei lisää arvoa ja työskennellään ainoastaan niiden asioiden parissa, jotka ehdottomasti on tehtävä sillä hetkellä.
Lean antaa paljon arvoa tiimin toimimiselle yksikkönä. Leanin mukaan meidän olisi aina katsottava omaa työtämme ylhäältä päin varmistuaksemme, että työskentelymme varmasti edistää kokonaisuutta. Esimerkiksi monilla johtajilla saattaa olla tarve optimoida yksilöiden työpanosta, mutta usein tällainen lähestymistapa ei saavuta haluttua lopputulosta. Ei ainakaan ohjelmistomaailmassa. Ihmisten ei tule luoda koodia vain koodaamisen vuoksi, vaan siksi, että koodia tarvitaan. Turha koodi luo vain lisää työtä tulevaisuudessa, koska sitä joudutaan todennäköisesti siistimään tai purkamaan.
Leanin mukainen lähestymistapa on kunnioittaa ihmisiä, jotka tekevän työn ja nämä ihmiset ovat myös ne, jotka osaavat tehdä sen. Tiimille tulee luoda puitteet toimia tehokkaasti ja luottaa heidän osaamiseensa halutun lopputuloksen saavuttamiseksi. Etenkin ohjelmistokehityksessä on kyse empiirisestä työstä ja työskentely kannattaa rakentaa ja jaksottaa niin, että kehitystiimi oppii jatkuvasti. Tästä syystä päätöksiä voidaan ja myös usein kannattaa viivästyttää viimeiseen mahdolliseen hetkeen, koska tietämys aiheen tiimoilta on usein silloin kasvanut.
Viimeiseksi voidaan todeta, että ohjelmistoa kannattaa kehittää rakentamalla laatua. Kehityspaketteja ei ole mahdollista tuottaa nopeasti, jos tiimi joutuu koko ajan ottamaan teknistä velkaa eli oikaisemaan silloin kun ei pitäisi. Tästä syntyy virheitä ja ongelmia tulevaisuudessa.
2. Ketterät menetelmät ja agile
Ketteristä menetelmistä on puhuttu ja kirjoitettu paljon viimeisen kymmenen vuoden aikana, mutta ne ovat todellisuudessa olleet olemassa jo paljon pidempään. Kyseessä on siis Toyota-leanin ajattelu- ja toimintatavan – kaiken turhan välttämisen – siirtymisestä ohjelmistokehitykseen. Termi scrum tulee monelle ensimmäisenä mieleen ketterästä kehityksestä puhuttaessa.
Alla oleva julistut ja periaatteet ovat lainausta ketterän kehityksen julistuksesta.
- Arvostamme yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja.
- Arvostamme toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota.
- Arvostamme asiakasyhteistyötä enemmän kuin sopimusneuvotteluja.
- Arvostamme muutokseen vastaamista enemmän kuin pitäytymistä suunnitelmassa.
- Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän.
Ketterän kehityksen periaatteet:
- Tärkein tavoitteemme on tyydyttää asiakas toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti.
- Otamme vastaan muuttuvat vaatimukset myös kehityksen myöhäisessä vaiheessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn edistämiseksi.
- Toimitamme versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai kuukauden välein, ja suosimme lyhyempää aikaväliä.
- Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä koko projektin ajan.
- Rakennamme projektit motivoituneiden ihmisten ympärille. Annamme heille puitteet ja tuen, jonka he tarvitsevat, ja luotamme siihen, että he saavat työn tehtyä.
- Tehokkain ja toimivin tapa tiedon välittämiseksi kehitystiimille ja tiimin jäsenten kesken on kasvokkain käytävä keskustelu.
- Toimiva ohjelmisto on edistymisen ensisijainen mittari.
- Ketterät menetelmät kannustavat kestävään toimintatapaan. Hankkeen omistajien, kehittäjien ja ohjelmiston käyttäjien tulisi pystyä ylläpitämään työtahtinsa hamaan tulevaisuuteen.
- Teknisen laadun ja ohjelmiston hyvän rakenteen jatkuva huomiointi edesauttaa ketteryyttä.
- Yksinkertaisuus – tekemättä jätettävän työn maksimointi – on oleellista.
- Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä.
- Tiimi tarkastelee säännöllisesti omaa tehokkuuttaan ja mukauttaa toimintaansa sen mukaisesti.
3. Yleiskatsaus Scrumiin
Scrum-termi viittaa rugbyn aloitusryhmitykseen. Ketterän kehityksen yhteydessä se tarkoittaa yleensä seisten pidettäviä lyhyitä kokouksia, joissa käydään läpi tulevan päivän tehtävät.
- Scrum on viitekehys, jossa tiimin jäsenet voivat ratkaista monimutkaisia ongelmia kehittäessään tuotteita luovasti ja tuottavasti mahdollisimman korkealla lisäarvolla.
- Scrum on helppo ymmärtää, mutta erittäin vaikea hallita hyvin.
- Ei ole tuotekehitysprosessi- tai tekniikka vaan viitekehys. Scrumin sisällä voi käyttää useita erilaisia menetelmiä ja prosesseja.
- Perustuu empirismiin. Empirismin mukaan tieto perustuu kokemukseen ja päätösten tekemiseen tunnettujen tosiasioiden pohjalta.
- Empiirisellä prosessinhallinnalla on kolme tukijalkaa: Läpinäkyvyys, tarkastelu ja sopeuttaminen.
3.1. Läpinäkyvyys
- Merkittävät tekijät määritellään ja sovitaan yhdessä, jotta tarkastelijoilla on yhteinen näkemys siitä mitä tarkastellaan.
- Merkittävien tekijöiden tulee olla helposti havaittavissa niille, jotka vastaavat lopputuloksesta.
- Kaikilla on yhteinen valmiin määritelmä ja yhteinen prosessiin viittava sanasto.
3.2. Tarkastelu
- Scrumin tekijöiden tulee tarkastella työn edistymistä sekä työn tuotoksia, jotta mahdolliset poikkeamat ja häiriötekijät osataan ottaa huomioon. Tarkastelu on siis sokean, putkikatseisen tekemisen vastakohta.
- Hyödyllisintä kun tarkastelua suoritetaan projektille sopivin väliajoin. Esimerkiksi ohjausryhmä tai viitekehyksen mukaiset palaverit.
3.3. Toimijat
Scrum-viitekehyksessä työskentelevillä ihmisillä on tietyt roolit. Scrum masterille on saatavissa koulutusta, mutta muut roolit eivät ole varsinaisia ammattinimikkeitä.
Tuoteomistaja (Product Owner):
- Vastuussa tuotteen arvon ja kehitystiimin työn maksimoimisesta.
- Vastuussa tuotteenkehitysjonosta.
- On aina yksi henkilö, ei komitea. Tuoteomistaja on usein liiketoiminnan edustaja.
Kehitystiimi:
- Koostuu ammattilaisista, jotka muuttavat tuotteen kehitysjonon tuotteeksi. Ainoastaan kehitystiimin jäsenet osallistuvat kehitykseen.
- Itseorganisoituvia ja monitaitoisia asiantuntijoita, joilla on kaikki tarvittava osaaminen ohjelmistotuotteen kehittämistä varten.
- Vastuu kehittämisestä on tiimillä yhteisesti.
Scrum master:
- Vastaa siitä, että kaikki ymmärtävät ja noudattavat viitekehystä.
- Tiimin palveleva johtaja.
- Scrum-tiimin lähettiläs ulospäin. Auttaa sopeuttamaan toimintatapoja, jotta niistä saadaan mahdollisimman suuri hyöty tiimille.
- Palvelee tuoteomistajaa.
- Palvelee kehitystiimiä.
- Palvelee organisaatiota.
3.4. Valmiin määritelmä
- Kun jokin osa tuotteesta on ‘valmis’, kaikkien on ymmärrettävä mitä ‘valmis’ tarkoittaa. Tätä varten suunnitellaan yhdessä Valmiin Määritelmä ja turvataan läpinäkyvyys.
- Auttaa kehitystiimiä hahmottamaan kehityskohtien haastavuutta ja työmäärää.
- Tavoitteena Valmiin Määritelmään perustuen toimittaa jokaisen sprintin päätteeksi julkaisukelpoinen osakokonaisuus tuotteeseen.
3.5. Sopeuttaminen
- Mikäli todetaan, että jotkin prosessin osat ovat hyväksyttyjen raja-arvojen ulkopuolella tulee prosessia tai käytettäviä menetelmiä säätää.
- Scrumissa on neljä muodollista kohtaa tarkasteluun ja sopeuttamiseen:
- Sprintin suunnittelupalaveri
- Päiväpalaveri
- Sprinttikatselmointi
- Sprintin retrospektiivi
SWOT-analyysi
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.
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ä.
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. Olen kirjoittanut lyhyehkön blogikirjoituksen määrittelyn ja arvioinnin haasteista.
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, 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.
Kirjoittajat: Joonas Koski, Scrum Master, W3 Group Finland Oy, LinkedIn: https://www.linkedin.com/company/w3-group-finland-oy
Palvelutarjoajat
1. Ketterien menetelmien tarjoajayritykset
Ketterien menetelmien tarjoajayritykset ite wikissä
Ketterien menetelmien tarjoajayritykset
Ketterien menetelmien referenssitoteutukset
Ketterien menetelmien julkaisut
