6.6.2013

Ketteryys haltuun: Ketterän kehityksen yleiset periaatteet

Ketteryys haltuun -artikkelisarjassa julkaistut muut osat:
Osa 2: Yleisimmät ketterät käytännöt
Osa 3: Scrum pähkinänkuoressa
Osa 4: Ketteryys haltuun: Miten ostan ketteriä IT-projekteja?

Ketteryys haltuun -artikkelisarjassa kerrotaan ketterän kehittämisen periaatteista ja käytännön menetelmistä. Ketterä kehittäminen on kerännyt yhä enemmän huomiota, mutta ilmiö ei ole lainkaan yksiselitteinen eikä ketterän kehittämisen soveltaminen käytännössä ole aina yksinkertaista. Tämän artikkelisarjan tavoitteena on avata peruskäsitteitä ja auttaa ymmärtämään mitä ketteryys ohjelmistokehityksessä tarkoittaa.

Neliosaisen sarjan ensimmäisessä osassa tarkastellaan ketteryyden periaatteita ja ketteryyden filosofiaa.

Ketterän kehittämisen periaatteet

Ketterän kehityksen maailmassa lähdetään siitä, että ei ole olemassa yhtä oikeaa tapaa saavuttaa haluttu lopputulos. Senpä vuoksi harvat ketterät menetelmät ovat tarkoin määriteltyjä ohjeistoja siitä, miten missäkin tilanteessa pitää toimia. Pakollisten käytäntöjen sijaan manifestin taustalla on kokoelma periaatteita, joita noudattamalla uskotaan päästävän hyvään lopputulokseen.

Seuraavassa on esiteltynä kaikille ketterille malleille yhteiset periaatteet. Se, mitkä käytännöt ovat oikeita missäkin tilanteessa, riippuu monesta tekijästä. Näitä voidaan kuitenkin pitää yleisperiaatteina jotka liittyvät useimpiin ketteriin menetelmiin.

  • Asiakastyytyväisyys: tärkein tehtävämme on pitää asiakas tyytyväisenä toimittamalla nopeasti ja jatkuvasti arvokas sovellus.
  • Hyväksy muutos: toivotamme tervetulleeksi muuttuvat vaatimukset, myös projektin loppupuolella.
  • Julkaise aikaisin ja usein: toimita toimiva sovellus usein, parin viikon – parin kuukauden välein. Pyri mahdollisimman nopeaan toimitussykliin.
  • Toimiva sovellus on ensisijainen edistymisen mittari.
  • Tasainen tahti: ketterät prosessit suosivat kestävää kehitystä. Rahoittajien, kehittäjien ja käyttäjien on pystyttävä ylläpitämään tasaista työtahtia jatkuvasti.
  • Tiivis yhteistyö: toteuttajien ja liiketoiminnan tuntijoiden on toimittava yhdessä päivittäin koko projektin ajan.
  • Suora keskustelu välillisen viestinnän sijaan: Tehokkain kommunikointikeino on kasvokkain keskustelu.
  • Luottamus tekijöihin: rakenna projektit motivoituneiden yksilöiden ympärille. Anna heille ympäristö ja heidän tarvitsemansa tuki ja luota että he tekevät työnsä.
  • Tekninen loistokkuus: jatkuva tekniseen laatuun ja hyvään suunnitteluun panostaminen parantaa ketteryyttä.
  • Yksinkertaisuus – tekemättä jätetyn työn määrän maksimointi – on olennaista.
  • Itseohjautuvuus: parhaat arkkitehtuurit, vaatimukset ja suunnitelmat kehittyvät tiimeistä, jotka organisoivat itse toimintansa.
  • Itsetarkastelu: tiimi pysähtyy miettimään säännöllisin väliajoin, kuinka tulla vielä tehokkaammaksi ja säätää toimintatapojaan sen mukaisesti.

Ketteryys käytännössä

Periaate 1: Ennakkomäärittelyä ei tule tehdä liikaa

Ketterän kehityksen ideologiassa lähdetään siitä, että myönnetään se, minkä me kaikki olemme usein kalliisti joutuneet toteamaan: kaikkien vaatimusten kirjaaminen etukäteen ei useinkaan onnistu. Vaikka siinä näennäisesti onnistuttaisiinkin, projektin aikana törmätään kuitenkin moniin määrittelyn puutteisiin, muutostarpeisiin ja väärinymmärryksin.

Kärjistetysti voikin todeta, että mitä vähemmän osaamme sanoa toteutettavan tietojärjestelmän yksityiskohdista ennakkoon, niin sitä todennäköisemmin projektissa kannattaa soveltaa ketteriä menetelmiä.

Edelleen kärjistäen voisi sanoa, että esimerkiksi tuntikirjausjärjestelmän ostaminen jollekin liiketoimintayksikölle voi hyvinkin olla projekti jonka vaatimukset osataan määritellä ennakkoon hyvin tarkoin. Jos taas samaiselle liiketoimintayksikölle halutaan tehdä uudenlainen asiointikanava jonka kautta asiakkaat voivat seurata tilauksiaan, tehdä lisätilauksia ja osallistua tuotteen suunnitteluprosessiin, niin ennakkomäärittely on todennäköisesti parhaimmillaankin vain ns. “hienosti kirjoitettu arvaus”. Tämä ei tarkoita sitä, että ennakkomäärittely olisi turhaa jälkimmäisessä tapauksessa, mutta ketterän kehittämisen periaatteiden mukaan sekin aika ja raha olisi tehokkaampaa käyttää toteutusprosessin aikana.

Periaate 2: Toteutus aloitetaan vaikeimmista ja tärkeimmistä asioista

Toinen keskeinen teema on keskittyminen tekemään koko ajan korkeimman prioriteetin ominaisuuksia. Perinteisissä malleissa, missä toimintojen priorisointi jätetään vain ohjelmoijien päätettäväksi, toteutetaan usein ensin helpot toiminnot, jotta voidaan osoittaa projektin edistymistä. Näin projektin loppuvaiheessa on tekemättä vaikeimmat, suuririskisimmät toiminnot. Usein nämä olisivat asiakkaalle juuri niitä kaikkein tärkeimpiä. Perinteisiin menetelmiin verrattuna priorisoidun listan kautta toimiminen parantaa myös hankkeen ennustettavuutta kun vaikeisiin asioihin keskitytään heti alusta alkaen.

Periaate 3: Ohjelmistoa ei tehdä palasina, vaan iteratiivisesti jatkuvasti parantaen ja testaten

Kolmantena ketteryyden teesinä pidetään koko ohjelmiston elinkaaren läpikäyntiä useita kertoja. Monissa perinteisen vesiputousmallin projekteissa törmätään käyttöönottovaiheessa moniin yllättäviin ongelmiin. Ketterissä menetelmissä projekti jaetaan pienempiin paloihin siten, että kaikki projektissa tarvittavat vaiheet on käyty läpi moneen kertaan. Näin vältytään ikäviltä yllätyksiltä projektin loppuvaiheessa. Tämänkaltaista inkrementaalisuutta on toki tehty ohjelmistokehityksessä jo pitkään, mutta ketterässä kehityksessä inkrementaalisuutta täydennetään vielä yleensä iteratiivisuudella. Tällöin ohjelmiston kaikkia osia parannetaan iteraatioissa useita kertoja ennenkuin järjestelmä annetaan käyttöön loppukäyttäjille. Tätä voidaan pitää erityisesti laatua parantavana menetelmänä.

Periaate 4: Testaus ei ole erillinen vaihe projektin lopussa, vaan jatkuva toiminto

Neljäntenä seikkana on mainittava jatkuva laadunvarmistus ja testaus. Perinteisesti testaus on ajoitettu projektin loppuun, hetkeen, jolloin ei enää olisi aikaa tehtä korjauksia. Jakamalla projekti pienempiin paloihin ja käymällä kaikki vaiheet läpi useasti varmistutaan siitä, että deadlinen koittaessa on jotain valmiina, ja kaikki mitä on valmiina, on jo testattua ja hyväksi todettua. Ketterissä menetelmissä laadunvarmistus ja testaus on yleensä automatisoitu siten, että tiimillä on koko ajan tarkka käsitys ohjelmistossa olevista virheistä tai poikkeamista. Monet ovat myös sitä mieltä, että ketteryyttä ei voi aidosti soveltaa ilman automaattisen testauksen ja laadunvarmistuksen käyttöä osana ohjelmistokehitysprosessia.

Periaate 5: Ennakkomäärittelyssä käyttäjätarinat ovat teknisiä yksityiskohtia tärkeämpiä

Ketterät menetelmät suosittelevat vaatimusten määrittelyyn yleensä käyttäjätarinoita. Menetelmät eivät poikkea olennaisesti perinteisistä vaatimusmäärittelytekniikoista, vaan olennainen ero on lähinnä alkuvaiheen prosessin laajuudessa. Ketterissä menetelmissä yksityiskohtaisen vaatimusmäärittelyn sijasta suositaan käyttäjätarinoita jotka keskittyvät siihen miksi järjestelmä on liiketoiminnallisesti tärkeä – ei siihen miten järjestelmän halutaan täsmällisesti toimivan.

Toisaalta on hyvä tiedostaa, että ketterät menetelmät ovat syntyneet nimenomaan toteutusvaiheen ohjaukseen ja ketterät menetelmät eivät ota sen laajemmin kantaa siihen, että onko jokin tietojärjestelmähanke ylipäätään järkevä toteuttaa vai ei. Ketterien menetelmien halu päästä nopeasti toteuttamaan järjestelmää ei siis tarkoita sitä, että esitutkimus tai perinteinen hankevalmistelu pitäisi unohtaa. Ketterien menetelmien viesti alkuvaiheen tekemiselle on vain, että yksityiskohtainen järjestelmän vaatimusmäärittely ja suunnittelutyö on tehokkaampaa tehdä iteratiivisesti toteutusvaiheen aikana kuin paperityönä ennakkoon.

Usein on edelleen järkevää tehdä määrittelytyötä myös ennakkoon varsin paljon, mutta yksityiskohtaista järjestelmän suunnittelua ei kannata koskaan tehdä liian aikaisin. Esimerkiksi hankevalmistelun aikana on usein hyvin tärkeätä määritellä järjestelmää sen verran, että kaikki sidosryhmät ymmärtävät mitä tavoitellaan. Tällöin käyttäjätarinat ja esimerkiksi kevyt prototyyppi voivat olla juuri sitä mitä kaivataan.

Yhteenveto: Ketterien menetelmien yleisesti tunnustetut vahvuudet ovat erityisesti toteutusvaiheen tekemisen tehostamisessa. Ketterät menetelmät myös pitävät huolen siitä, että toteutusvaiheessa ei ajauduta väärille urille tai käytetä rahoja epäolennaisten toimintojen hiomiseen. Ketterän kehityksen ytimessä ovat myös monenlaiset jatkuvan testauksen ja laadunvarmistuksen käytänteet. Nämä varmistavat sen, että mitä tahansa saadaankin valmiiksi, niin lopputulos on toimivaa. Kritiikkiä ketterät menetelmät ovat eniten saaneet siitä, että ne eivät ota kantaa siihen miksi tietojärjestelmähanke ylipäätään on olemassa tai miten johdetaan pitkän tähtäimen kehitystä. Täten esitutkimuksia ja hankevalmisteluja ei saa unohtaa vaikka ketterästi haluaakin tehdä projektinsa. 


Artikkeli pohjautuu Sinisen Meteoriitin menetelmäarkkitehti Sami Poimalan tuottamiin koulutusmateriaaleihin ja artikkeleihin. Artikkelin on julkaistuun muotoon viimeistellyt ja täydentänyt Sinisen Meteoriitin konsultti Perttu Tolvanen.

Perttu Tolvanen on sisällönhallinnan konsultti. Pertulla on kokemusta laajoista portaaliprojekteista, joissa on sovellettu ketterän kehittämisen menetelmiä. Perttu Tolvanen työskentelee Sinisessä Meteoriitissa ja auttaa asiakkaita hankkeistuksessa, vaatimusmäärittelyissä ja teknologiavalinnoissa.

Sami Poimala on kokenut menetelmäarkkitehti ja ohjelmistokehittäjä. Sami on työskennellyt vuosia ketterän kehittämisen parissa Sinisessä Meteoriitissa ja myös kouluttanut paljon esimerkiksi Sinisen Meteoriitin henkilökuntaa ketterän kehittämisen saloihin.

Sininen Meteoriitti on SharePoint-toteutuksiin erikoistunut ohjelmistoyritys, jonka projekteissa on hyödynnetty ketteriä menetelmiä jo vuosia.

Aiheesta lisää

Ketteryys haltuun: Scrum pähkinänkuoressa Ketteryys haltuun -artikkelisarjassa julkaistut muut osat: Osa 1: Ketterän kehityksen yleiset periaatteet Osa 2: Yleisimmät ketterä...
Ketteryys haltuun: Yleisimmät ketterät käytännöt Ketteryys haltuun -artikkelisarjassa julkaistut muut osat: Osa 1: Ketterän kehityksen yleiset periaatteet Osa 3: Scrum pähkinä...
Ketteryys haltuun: Miten ostan ketteriä IT-projekteja?   Ketteryys haltuun -artikkelisarjassa julkaistut muut osat: Osa 1: Ketterän kehityksen yleiset periaatteet Osa 2: Yleisimmät ketterät käytä...