Jostain syystä blogosfäärissä (tyhmä sana, siksi juuri käytän sitä) on puhuttu viimeaikoina useissa eri paikoissa ketteristä menetelmistä. Esimerkkinä otetaan Perse-Janne (kuten lehdistö ko. jamppaa puhuttelee) ja MBnetin net.nyt. Kirjoittajat kyllä tietävät mistä asiassa on kyse, mutta monille lukijoille ketterät menetelmät eivät ole tuttuja tai edes kiinnostavia. Kuitenkin kandidaatintyöni käsittelee ketteriä menetelmiä, kuten myös tämä työnkuvani täällä LTY:llä, joten koin tarpeelliseksi itsekin sanoa jotain, selvittää hieman asioita ja kertoa ehkä jotain uuttakin.
Ketterät menetelmät ovat siis ohjelmistokehityksen tapoja, usein niitä kutsutaan ohjelmistotuotannon menetelmiksi. Ne poikkeavat perinteisistä (kutsutaan myös formaaleiksi) menetelmistä hyvin erilaisten lähtökohtien vuoksi. Softaa ei suunnitella kerralla loppuun, kehitystä tehdään iteraatioissa (pienissä ’hyppäyksissä’) ja kehityksen aikaista dokumentointia vähennetään tehokkaalla sisäisellä viestinnällä. Ja mikä tärkeintä, testausta tehdään koko ajan, periaatteessa joka yönä käännetään uusi toimiva (joskin ominaisuuksiltaan todennäköisesti vajaa) versio ohjelmasta.
Agile Manifesto vuonna 2001 toi menetelmät rysäyksellä suuremman yleisön tietoon. He esittelivät idean lyhyesti ja ytimekkäästi. On tärkeämpää tuottaa laadukas ohjelmisto ajoissa, kuin nyhrätä byrokratian kanssa ja tehdä samoja asioita yhä uudelleen. On parempi mukautua siihen, että ohjelmistovaatimukset muuttuvat, kuin yrittää runnoa väkisin muutosta vastaan.
Suomessa ensimmäisiä yrityksiä, joka on lähtenyt täysillä ketteriin menetelmiin mukaan, on F-Secure (lue juttu). Toki tuon tiedon ilmestymisen jälkeen löytyi ties minkä kiven alta puku-ukkoja, jotka väittivät olleensa ketteriä jo vuosikymmeniä, mutta unohdetaan heidät. VTT ajaa Suomessa voimakkaasti ketterien menetelmien kehitystä ja käyttöönottoa.
There’s no silver bullet kuuluu joku nörttiläppä. Ja oikeassa on. Valheellisesti uutisoinnissa annetaan sellainen käsitys, että ketterissä menetelmissä ei ole mitään ongelmia. On niissä. Mutta ongelmat ovat erilaisia kuin perinteisissä vesiputousmalliin pohjautuvissa. Ne ovat voitettavissa olevia.
Varsinkin näin tuoreen ideologian ja menetelmän (-tavan toimia) kanssa ovat ongelmina tietysti ihmisten asenteet, opitut tavat ja niiden pois oppiminen. Unohtaminen. Mikä ikinä olisikaan hyvä sana. Ihmisten vastuualueet ja työtavat muuttuvat merkittävästi, kun ohjelmistotiimi vaihtaa perinteisestä toiminnasta ketteriin menetelmiin. Tiimit ovat itseohjautuvia, projektipäällikkö ei ole enää se ruoskija, vaan se, joka huolehtii asiakaskommunikaatiosta, seuraa ohjelmiston kehitystä, mittaa sitä ja keskustelee ja palaveroi joka päivä ohjelmistokehittäjien kanssa. Ylipäätään koko ketterät menetelmät -ideologiaa kuvaa yhteisöllisyys ja yhteistyöhalu. Perinteiseen protect the barriers systeemiin ei haluta lähteä ja siihen yritetään löytää vastakeinoja.
Asiakkaan osuus koko projektissa kasvaa huomattavasti. Useimmat ketterät menetelmät (erilaisia menetelmiä jotka luokitellaan ketteriksi on useita, jopa kymmeniä. (ks. agile.vtt.fi)) haluaisivat pitää asiakkaan edustajan jatkuvasti läsnä (on-site). Tämä on toinen mittava ongelma. Kuinka moni asiakas on valmis lähettämään jonkun yrityksen keskijohdosta (koska asiakkaan edustajalla on oltava riittävästi valtaa tekemään päätöksiä) pitkiksikin aikaa ohjelmistoyritykseen. Lisäksi asiakkaan pitäisi olla yhteistyöhaluinen, eikä pitää prosessiin osallistumista pakollisena pahana. Tämä on ongelma, mutta esimerkiksi Mobile-D (ketterä menetelmä) ei vaadi asiakkaan jatkuvaa läsnäoloa.
Koodin tekemisessäkin on eroja. Extreme Programming (XP) esittää kahden koodaajan ideaa, eli koodia työstetään parityönä. Toinen varsinaisesti kirjoittaa ja toinen seuraa vierestä, antaa ideoita ja yrittää löytää virheet. Parikoodausta pidetään keskeisenä asiana ketterissä menetelmissä, vaikka se ei todellakaan ole sitä. Muita koodaamiseen liittyviä asioita ovat koodin omistajattomuus, eli kuka tahansa voi muokata mitä tahansa osaa ohjelmasta ilman massiivista sähköpostin lähettelyä. Se on helppoa, koska ketterissä menetelmissä painotetaan (suullisen) informaation liikettä, pyritään saamaan koko ohjelmistotiimi samaan avoimeen tilaan ja pidetään päivittäin edistymiskokouksia (kestoltaan noin 15min). Jotta kaikki tietäisivät mitä muut tekevät (tätä korosti myös Pirjo Ståhle tietojohtamisen kursseillaan).
Testaus on nostettu ajavaksi tekijäksi ohjelmistokehityksessä ketterissä menetelmissä. Ehkä suorastaan vallankumouksellinen idea kehittää ensin testit ja sitten ohjelmistot, jotka läpäisevät testit, on keskeisenä ketterissä menetelmissä. Tällä tavoin rajataan koodaajan innovaativisuutta väärässä paikassa (eli poistetaan featureviidakon mahdollisuus (featureviidakko = paljon ominaisuuksia, jotka ovat kehittäjän mielestä kivoja, mutta joista yhtäkään ei ole tunnistettu määrittelyssä / vaatimusten keräämisessä)) ja pysytään paremmin aikataulussa.
Yhteenvetona voidaan sanoa, että ketterät menetelmät ovat paljon kaikkea muuta kuin koodaustapojen muutos, joskin se muuttaa myös toteutustapaa. Testaus on tärkeää, johdon asema muuttuu ratkaisevasti, ohjelmistotiimille annetaan valtaa muuttaa oma-aloitteisesti toimintaansa parantaakseen tehoa ja niin edelleen. Perinteiset sudenkuopat, jotka johtuvat viime vaiheen testauksesta, pyritään välttämään jatkuvalla testauksella ja lyhyellä iteraatiovälillä.
Kirjoja ja julkaisuja ketteristä menetelmistä on kirjoitettu paljon ja niitä tulee kiihtyvällä vauhdilla. Jos kiinnostus tietää lisää heräsi, Google Scholar auttaa. Erityisesti voin suositella alkukatsaukseksi Abrahamssonin ja kumppaneiden julkaisua Agile software development methods