Blogi

Ketterä ohjelmistokehitys ja sen menetelmät

Ketterät menetelmät tuovat ohjelmistokehitykseen nopeutta ja joustavuutta muutoksille. Nämä toimintamallit sopivat tietynlaisiin kehityshankkeisiin, mutta eivät syrjäytä muita menetelmiä. Onnistuakseen ketterät menetelmät edellyttävät pelisääntöjä tiimiltä, projektilta ja asiakkaalta. Käymme tässä läpi ketterän ohjelmistokehityksen onnistumisen edellytykset.

Ketteriä (agile) menetelmiä on useita. Niitä yhdistää ajatus nopeista, projektin edetessä tarkentuvista kehityssykleistä, joita usein kutsutaan sprinteiksi. Luonteenomaista on myös läpinäkyvyys ja valmius tehdä tarvittaessa nopeita muutoksia. Tavoitteena on tehdä toimiva ratkaisu lyhyessä ajassa.

Keskeistä on myös ajatus siitä, että ohjelmistokehittäjien ja liiketoiminnan edustajien tulee tehdä yhteistyötä läpi koko hankkeen. Tavoitteena on vastata bisnestarpeisiin ja niiden muutoksiin sekä mahdollistaa tiheä päivityssykli, jos liiketoiminnan luonne ja loppuasiakkailta saatu palaute sitä edellyttävät.

Tärkeässä roolissa on kehittämisfilosofia, jonka mukaan uutta (ohjelmisto)ratkaisua luotaessa tavoitteena on sujuva ja tehokas järjestelmä. Tämä tarkoittaa yrityksen nykyisen järjestelmän ja nykyisten prosessien haastamista — miksi siirtää vanha kömpelö prosessi ohjelmistoksi, kun kenties koko vanhentunut työnkulku kannattaisi suunnitella uudestaan.

On hyvä huomata, että ei ole olemassa yhtä oikeaoppista tyyliä tehdä ketterää ohjelmistokehitystä. Siksi kehitysprojekteissa onkin tärkeää ymmärtää jo ennen starttia, mitä ohjelmistokehitystiimi ketteryydellä tarkoittaa ja miten se sitä käytännössä toteuttaa. Ketterän ohjelmistokehityksen menetelmät eivät kaikki ole keskenään helposti yhteensopivia, joten kehittäjätiimin ja asiakastiimin odotuksia ja toimintatapoja on hyvä käydä läpi ennen hankkeen alkua.

Mistä ketterässä ohjelmistoke­hi­tyk­ses­sä on kysymys?

Ketterät menetelmät ovat kurinalainen ja systemaattinen tapa suunnitella, luoda ja testata ohjelmistoja niin, että työ tehdään nopeiden iteraatiokierrosten kautta. Agile-maailman nimikkeisiin ei kannata hukkua, mutta monista termeistä on tullut lähes yleiskielisiä järjestelmäkehittäjien ja konsulttien käyttäminä.

Monille on tuttu 1-4 viikon mittaisten kehityssprinttien ketju. Jokaista sprinttiä ennen scrumtiimi päättää sprintin tavoitteet ja tehtävänjaon. Tiimi vastaa siitä, että tavoitteet toteutuvat, ja käyttää myös hyvin itsenäistä päätäntävaltaa työtavoistaan. Tiimi esittelee saavutuksensa sprinttikatselmuksissa, joissa tuoteomistaja (product owner) arvioi etenemistä ja onnistumista. Luonnollisesti tiimi myös arvioi omaa toimintaansa ja hienosäätää sitä tarpeen mukaan.

Scrumtiimi koostuu tuotteen omistajasta, kehitystiimistä ja scrum masterista. Perinteisestä projektijohdosta poiketen, scrum master ei toimi esimiehenä, vaan fasilitoi työtä, poistaa esteitä, viestii joka suuntaan ja ylläpitää ketterien menetelmien noudattamista. Käytännössä isommissa hankkeissa on tästä syystä myös aina erillinen asiakasvastaava tai projektipäällikkö, joka vastaa klassisessa mielessä ohjelmistokehitysyrityksen ja asiakasyrityksen välisestä asiakassuhteesta liiketoimintatasolla.

Muutosjoustavuudesta huolimatta ketterä ohjelmistohanke vaatii ratkaisun omistajalta selkeän vision toteutettavasta kokonaisuudesta. Tavoitteen on oltava kirkas.

Asiakas osallistuu ketteriä menetelmiä käytettäessä useammin ja enemmän projektin seurantaan ja projektinaikaisiin muutoksiin kuin perinteisemmässä niin kutsutussa vesiputousmallissa (waterfall), jossa on kenties vain muutama kommentointi- ja hyväksyntäkierros koko hankkeen aikana.

Asiakkaalla on ketterässä kehitysmallissa iso vastuu. Asiakkaan puolella täytyy olla kehitettävälle ratkaisulle yksi selkeä omistaja (product owner) ja hänen on osallistuttava projektiin aktiivisesti. Tämä rooli edellyttää ajankäyttöä ja päätöksentekokykyä. Asiakkaalla on iso merkitys määrittelytyössä ja backlogin, eli työtä ohjaavien tuotevaatimusten ja niihin liittyvien muutosten priorisoinnissa.

Tosiasiassa ketterien menetelmien esittäminen täysin vastakkaisena vaihtoehtona vesiputousmallille ei tee oikeutta kummallekaan toimintatavalle. Ensinnäkin agile ei ole aina vaihtoehto. On tilanteita, joissa klassinen waterfall-malli on toimivin tai esimerkiksi tilaajalle tutuin ja helpoin toimintatapa. Toiseksi vesiputousmallikin pitää sisällään paljon erilaisia nyansseja ja on kehittynyt vuosien varrella. Kokeneet toimijat voivat myös yhdistää ketteriä menetelmiä ja klassista vesiputousmallia erityisesti laajemmissa hankekokonaisuuksissa.

Ketterät ohjelmistokehi­tys­me­ne­tel­mät vaativat kokemusta

Ketterät menetelmät vaativat kokemusta. Osaava ohjelmistokehityksen tiimi osaa välttää niitä tyypillisiä haasteita, joita ensi kertaa ketteriä menetelmiä soveltavat tiimit kohtaavat:

  • Pilkkoutumisansa: Isoissa hankkeissa ketterät menetelmät johtavat joskus hajanaiseen kokonaisuuteen, kun kehitys tapahtuu osissa ja välttämättä kukaan ei katso ratkaisun yhtenäisyyden ja saumattoman toimintalogiikan perään. Kokenut tiimi osaa välttää tämän ansan.
  • Muutosansa: Ketteriin menetelmiin sisäänrakennettu filosofia nopeista muutoksista ja reagointikyvystä voi johtaa väärissä käsissä siihen, että tavoitteita ja vaatimusmäärittelyä muutetaan projektin sisällä jatkuvasti. Syntyy paljon toimintaa ja vähän valmista. Tässä auttaa selkeä tavoitemäärittely.
  • Resurssiansa: Ketterät menetelmät eivät ole taikatemppu, jolla pystyttäisiin ratkomaan vaikeita ongelmia minimaalisilla resursseilla. Ketteryys ei ole oikopolku. Isot ongelmat voidaan pilkkoa pieniksi paloiksi, mutta resursseja ne silti edellyttävät. Vaativat työt edellyttävät riittävästi aikaa ja asiantuntijoita menetelmästä riippumatta. Osaava konsultti on realistinen työmääräarvioissaan.
  • Legacyansa: Yrityksen olemassa olevaa prosessia ei aina kannata suoraan siirtää uudeksi tietojärjestelmäksi. Ensin on viisasta pohtia, voisiko prosessia sujuvoittaa suunnittelemalla se uudestaan. Moni ohjelmistoratkaisu kytkeytyy liiketoiminnan kehittämiseen ja silloin oikea lähtökohta on miettiä ensin arvovirtoja ja yrityksen toimintojen läpileikkaavia prosesseja – vasta sitten koodata ratkaisu ketteriä menetelmiä käyttäen.
  • Itseohjautuvuusansa: Ketterän ajattelun omaksuneet ohjelmistokehitystiimit ja asiakasyrityksen tiimit ovat kyllä itseohjautuvia työssään. Ne tarvitsevat silti kirkkaan, ylimmän johdon tukeman tavoitteen. Itseohjautuvuus ei ole sitä, että tiimi keksii itse tavoitteensa.

Project-IT:n asiantuntijoilla on vahva osaaminen ketterästä kehittämisestä eri rooleissa. Kokeneet asiantuntijamme ovat olleet mukana vakiinnuttamassa ketterän kehittämisen asemaa organisaatioissa ja toteuttaneet useita hankkeita ketteriä menetelmiä hyödyntäen.

Käytännön kokemus ja useat osa-alueen sertifikaatit ovat osoituksena asiantuntijoidemme laaja-alaisesta osaamisesta alueella. Ammattilaisemme ovat soveltaneet asiakasorganisaatioissa kattavasti eri menetelmiä, kuten SAFea, Leania, Agilea, Scrumia sekä iteratiivista ja inkrementaalista kehitystä.

Jos haluat kuulla aiheesta lisää, olethan yhteydessä!

Ville Luukkonen
050 355 9014
ville.luukkonen@project-it.fi

Jaa artikkeli:

Lataa IT-ostamisen ABC -opas!

Asiantuntijoiden kanssa yhteistyössä kirjoitettu IT-ostamisen ABC pitää sisällään paljon käytännönläheisiä ohjeita IT-ostamiseen.

  • Kenttä on validointitarkoituksiin ja tulee jättää koskemattomaksi.