Scrum

Riikka Karhu

Opiskelen toista vuotta tietojenkäsittelyä ammattikorkeakoulussa. Nyt kevätlukukaudella olemme päässeet tutustumaan Scrum-työskentelyyn. Ainakaan itse en ollut aikaisemmin kuullut scrumista juuri mitään enkä usko, että kovin moni muukaan kurssilla oleva. Sen lisäksi, että meille kurssilla kerrottiin mitä Scrum on, olemme päässeet luomaan omaa webbisovellusta Scrumin käytäntöjen mukaisesti. Sanana Scrum on oikeastaan mahdoton kääntää suomeksi, joten on yksinkertaisempi avata mitä termi oikein tarkoittaa.

Scrum on ohjelmistokehitysmenetelmä, viitekehys, jonka avulla ohjelmistokehityksestä pyritään tekemään mahdollisimman kevyttä ja ketterää. Sitä on hyödynnetty alalla jo 1990-luvun alusta lähtien. Scrum voi pitää sisällään erilaisia prosesseja ja tekniikoita, riippuen kovasti yrityksestä, jossa ohjelmistokehitystä tehdään. Sen on tarkoitus tehdä tuotehallinnon ja -kehityksen menetelmien vaikutuksia näkyviksi, jotta menetelmiä voitaisiin parantaa. Scrum hyödyntää iteratiivis-inkrementaalista eli toistavaa ja lisäävää lähestymistapaa, jotta voidaan optimoida ennustettavuus ja minimoida mahdolliset riskit.

Scrum koostuu scrum-tiimistä, tapahtumista, tuotoksista ja säännöistä. Nämä osat ovat kaikki merkityksellisiä Scrumin onnistumisessa. Sääntöjen tarkoituksena on sitoa yhteen tiimien roolit, tuotokset ja tapahtumat sekä ohjata niiden välistä vuorovaikutusta. Vuorovaikutuksen ja kommunikoinnin merkitystä ei voi Scrumissa korostaa liikaa, sillä niiden avulla pystytään minimoimaan riskit entisestään sekä välttyä mahdollisilta konflikteilta.

Scrum-tiimi
Scrum-tiimit päättävät hyvin pitkälle itse millä tavalla työtä tekevät; ulkopuolelta ei tule ohjausta. Tiimeistä löytyy kaikki tarvittava osaaminen ja ne on suunniteltu joustavuuden, luovuuden ja tuottavuuden optimoimiseksi.

Product Owner eli tuoteomistaja on asiakas, joka tilaa tuotteen. Hän on miettinyt etukäteen, minkälaisen ohjelmiston tarvitsee ja mitä ominaisuuksia siinä tulee olla. Tuoteomistajan vastuulla on maksimoida sekä tuotteen että kehitystiimin työn arvo. Hän myös vastaa kehitysjonon hallinnasta. Käytännössä tämä tarkoittaa sitä, että tuoteomistaja pitää huolen siitä, että vaadittavat työt tehdään siinä järjestyksessä, joka mahdollistaa tavoitteiden saavuttamisen parhaalla tavalla. Tuoteomistaja ei osallistu varsinaiseen ohjelmistokehitykseen, mutta saa tuoda ilmi toiveitaan.

Kehitystiimi koostuu ammattilaisista, joiden tehtävänä on toteuttaa tuotteen kehitysjonon sisältö toimivaksi kokonaisuudeksi. Kehitystiimi valtuutetaan hoitamaan omaa työtään, eli tiimi saa sisäisesti päättää kuinka kehitysjonon sisältö muutetaan toimivaksi lopputuotteeksi. Jäsenillä voi olla erityisosaamisia, mutta koko tiimi on vastuussa työn laadusta. Tiimille annetaan siis paljon valtaa ja vastuuta, mikä liittyy varsinaiseen kehitystyöhön. Tällä tavalla luodaan tiimille sellaiset edellytykset, jotka parantavat suorituskykyä ja tuottavuutta. Tiimin koko ei saa olla liian pieni, jotta osaamista ja aikaa löytyy. Liian iso tiimi aiheuttaa sekavuutta ja vaatii enemmän koordinointia. Tästä syystä ihanteellinen kehitystiimin koko vaihtelee kolmen ja yhdeksän henkilön väliltä, riippuen täysin tilatun tuotteen vaatimuksista.

Kolmas Scrumin keskeinen rooli on scrum-mestari, jonka vastuulla on se, että kaikki ymmärtävät ja käyttävät Scrumia. Scrum-mestari on scrum-tiimin palveleva johtaja ja hän toimii apuna scrum-tiimille. Scrum-mestari pitää huolen, että tiimi ei joudu tekemään turhaa työtä. Hän kommunikoi tuoteomistajan ja tiimin välillä sekä dokumentoi tehtyä työtä.

Sprintti
Scrum-työskentelyssä tuoteomistajalta saatu tehtävä jaetaan osiin, jotka valmistetaan maksimissaan kuukauden kestävissä sprinteissä, kehitysprosessin aikana jokainen sprintti on yhtä pitkä. Sprintin aikana ei ole tarkoitus tehdä muutoksia valmiiseen suunnitelmaan eikä kehitystiimiin, vaan sen tavoitteena on tuoda tuotteen kehitysjono lähemmäksi laajempaa tavoitetta ja kokonaisuutta. Kukin sprintti alkaa suunnittelupalaverilla, johon osallistuu koko scrum-tiimi. Palaverissa käydään läpi se, mitä sprintin aikana on tarkoitus toteuttaa ja miten toteutus tapahtuu. Sprintin aikana kukin päivä käynnistetään lyhyellä, noin 15 minuutin mittaisella palaverilla, Daily Scrumilla. Daily Scrumissa kehitystiimi käy keskenään scrum-mestarin kanssa läpi ne asiat, joita kukin on tehnyt ja mitä tulee tekemään. Palaveri antaa tiimille mahdollisuuden kertoa scrum-masterille mikäli työn aikana on ilmennyt joitakin ongelmia. Jokaisen sprintin lopussa järjestetään sprint-review eli demo, jossa kehitystiimi esittelee valmiin lopputuloksen tuoteomistajalle. Jos jotain osiota ei ole saatu valmiiksi, se siirretään seuraavan sprinttiin.

Tuotokset
Olen jo maininnut kehtysjonon, joka on yksi Scrumin tuotoksista. Kyseessä on lista, jossa määritellään kaikki se, mitä tuotteessa saatetaan tarvita. Lista toimii scrumtiimin lähteenä tuotteen vaatimuksille ja muutoksille. Kehitysjono kehittyy sitä mukaa kun tuote ja ympäristö kehittyvät, joten kyseessä ei ole valmis tuotos.

Kehitysjono pitää sisällään kaikki ne ominaisuudet, toiminnot, vaatimukset, parannukset ja korjaukset, jotka on tarkoitus toteuttaa tuoteversioihin. Näihin kohtiin liitetään monesti hieman tarkempi kuvaus, järjestys ja työmääräarvio. Kohdat järjestetään prioriteetin, riskin ja välttämättömyyden perusteella; ylemmälle listatut kohdat kuvaavat välittömiä kehitystarpeita, eli niitä on ehditty suunnitella eniten.

Kehitysjonon kohdista koostetaan tehtävälista, mikä toimii kehitystiimin ennusteena sille, mitä toiminnallisuuksia seuraavaan tuoteversioon sisällytetään. Tehtävälista tekee näkyväksi sen työn, minkä kehitystiimi kokee tarpeelliseksi saavuttaakseen sprintin tavoitteen. Tehtävälistasta tulee tehdä mahdollisimman yksityiskohtainen, jotta Daily Scrumissa nähdään selvästi työn edistyminen.

Tuoteversio on kehitysjonon kohtien summa, jotka on saatu sprinttien aikana valmiiksi. Kyseessä on "valmis" versio tuotteesta. Tämä tarkoittaa sitä, että tuote on scrumtiimin näkökulmasta "valmis". Kehitysjonon kohdat on käyty läpi ja ohjelman toiminnallisuus on testattu. Tuoteomistaja päättää viime kädessä hyväksyykö hän tuotteen.

Lopuksi
Puolentoista sprintin jälkeen voin todeta, että olen itse pitänyt Scrum-työskentelystä. Ainakin meidän tiimi on toiminut todella hyvin yhteen, olemme kommunikoineet keskenämme ja apua on saanut aina tarvittaessa. Ainakin itse olen oppinut uutta. Voin sanoa, että tämän tapainen tiimityöskentely on paljon mielekkäämpää kuin yhteisen raportin kirjoittaminen tai muu vastaava. En usko, että koulussa saa parempaa kuvaa työelämästä, kuin tehdä pientä projektia työelämän oikeita menetelmiä käyttäen.

Lisää tietoa Scrumista tarjoaa Reaktorin erittäin hyvä Scum-opas: http://reaktor.fi/osaaminen/scrum/

Paljon asiaa ilman kuvia. Pienenä kevennyksenä ja asiaan millään tavalla liittymättä Buddy-Christ: