Jarkko Järvenpää

Jarkko Järvenpää

Chief Sales Officer

jarkko.jarvenpaa@vincit.fi
+358 40 722 9656

TwitterLinkedIn

Perinteisesti ohjelmistoja on kehitetty vesiputousmallilla: ensin järjestelmä määritellään, sitten suunnitellaan, sen jälkeen toteutetaan ja lopuksi testataan. Tässä mallissa vaatimusten muuttaminen toteutustyön käynnistymisen jälkeen on vaikeaa ja kallista. Vesiputousmallin korvaajaksi alkoikin 2000-luvun alussa yleistyä ketterä kehittäminen ja varsin pian ketteryydestä tuli todellinen muotisana. On kuitenkin sangen yleistä, että ketteryydestä innostutaan ymmärtämättä kuitenkaan, mistä siinä on lopulta kyse. Tässä tekstissä avaan ketterän kehittämisen käsitettä ja miten toteutamme sitä työskentelyssä.

Ketterä kehittäminen tarkoittaa yksinkertaisesti sitä, että toteutettavaa järjestelmää ei yritetäkään määritellä kokonaisuudessaan ennen toteutustyön aloittamista. Ohjelmistokehityksessä tämä on mahdollista, sillä hyvin toteutetun järjestelmän toiminnallisuuteen voidaan tehdä suuriakin muutoksia koko sen elinkaaren ajan.

Scrum ja Kanban ovat tapoja hallinnoida ketterää projektia. Koska jokaisella yrityksellä on omat lähtökohdat ja tavoitteet liiketoiminnassa, tulee toimittajan osata mukauttaa toimintansa asiakkaan ja projektin tarpeiden mukaan. Tätä kannattaa ehdottamasti vaatia niin, että toimittaja kuvaa viimeistään tarjouksessaan toimintamallinsa. Jos et ymmärrä jotain termiä, kysy. Ei ole tavatonta, että toimittajan käsitys jostakin termistä eroaa huomattavasti esimerkiksi sen Wikipedia-kuvauksesta.

Ketterä kehittäminen vaatii backlogin

Backlog on priorisoitu lista käyttötapauksia ja toiminnallisuuksia, joita tuotteeseen on suunniteltu toteutettavan. Sen tehtävänä on rakentaa yhteinen näkemys projektin sisällöstä ja auttaa asiakasta arvioimaan ja priorisoimaan projektin toteutusta. Fyysisesti backlog voi sijaita sähköisessä työkalussa kuten Trellossa tai esimerkiksi Post-it-lapuilla. Ketterä kehitys on periaatteessa äärimmäisen yksinkertaista: backlogilta otetaan tehtävä työn alle. Kun tehtävä valmistuu, se kuitataan backlogiin. Tämän jälkeen otetaan seuraava tehtävä ja kuvio toistuu, kunnes projekti on valmis.

Backlog elää ja muuttuu huomattavasti projektin aikana. Aina ajan tasalla oleva backlog onkin ketterän projektinhallinnan perusedellytys. Projektin toteutus jaetaan yleensä kahden viikon pituisiin iteraatioihin eli sprintteihin. Kunkin iteraation jälkeen asiakas ja toteutustiimi kokoontuvat katselmointipalaveriin (sprint review), jossa käydään läpi edellisen iteraation tulokset ja suunnitellaan jatkoa. Sprintit voivat olla ajallisesti lyhyempi tai pidempikin riippuen siitä kuinka nopeasti backlog elää.

Tapaamiset kasvotusten ainakin projektin alkuvaiheessa tehostavat kommunikointia merkittävästi. Myös lyhyet päiväpalaverit ovat osoittautuneet mainioksi käytännöksi. Niissä asiakas ja toteutustiimi käyvät joka aamu 5-10 minuutin puhelinkeskustelun, jonka aikana käydään lyhyesti läpi edellisen päivän tapahtumat ja mahdollisesti ilmenneet ongelmat. Monet toimittajat hyödyntävät lisäksi projekteissaan yhteistä sähköistä keskustelukanavaa, jossa asiakkaan on mahdollista seurata toteutustiimin sisäisiä keskusteluja ja osallistua niihin.

Entä hinnoittelu ketterässä kehittämisessä?

Ketterässä kehittämisessä toimivin hinnoittelumalli on tiimin kokoon tai aikaan perustuva hinnoittelu. Joustavuuden säilyttämiseksi kannattaa myös sopia, että asiakas voi säätää tiimin kokoa sprinteittäin ja jopa päättää projektin jokaisen sprintin päätteeksi. Tämä saattaa kuulostaa karulta, mutta todellisuudessa asianmukaisesti ylläpidetty backlog ja säännölliset tapaamiset asiakkaan ja toimittajan välillä kertovat projektin päättymisestä jo hyvissä ajoin. Toisaalta äkkinäiset muutokset asiakkaan toimialalla saattavat tehdä projektin irrelevantiksi hyvinkin nopeasti. Halutessaan osapuolet voivat sopia kohtuullisen kertakorvauksen tällaisen tilanteen varalle. Ostajalle kuitenkin varoituksen sana liian hötkyilevästä menosta: jokaisen uuden asiantuntijan sisäänajaminen mukaan tekemiseen ja liiketoimintaasi on investointi, joten tempoilevat muutokset lyhyen aikavälin hyötyjen vuoksi eivät yleensä ole eduksesi. Tuloksena on yleensä heikompi toteutus ja alentunut motivaatio muussa tiimissä.

Kiinnostaako lukea lisää aiheeseen liittyen? Lataa alta Ohjelmistokehityksen ostajan pikaopas 2.0. Oppaasta löydät lisää neuvoja ja käytännön vinkkejä ohjelmistoprojekteihin.

Lataa ilmainen opas

Tykkäsitkö artikkelista?

Anna pienet aplodit!

Kommentit

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *