Tiimiakatemia on Jyväskylän Ammattikorkeakoulun yrittäjyyden huippuyksikkö

Scrumin perusteet

Kirjoitettu 31.08.16
Esseen kirjoittaja: Mikko Niemelä
Kirjapisteet: 3
Kirja: Scrum: The Art of Doing Twice the Work in Half the Time
Kirjan kirjoittaja: Jeff Sutherland
Kategoriat: 1. Oppiminen

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tutustuin Scrumiin ensi kertaa viime kevättalvella, kun sitä alettiin käyttää työkaluna Inton sisällä tiimin kehitykseen. Tietynlainen trendi näkyi Akatemialla ja useat tiimit käyttivät Scrumia tai jotain variaatioita siitä. Siinä vaiheessa luulin tietäväni homman perusperiaatteet ja lopulta kuinka väärässä olinkaan.

Viime kuussa osallistuin Reaktorin järjestämään Certified ScrumMaster – koulutukseen joka järjestettiin täällä meidän tiloissa Innovalla. Koulutukseen osallistui muutamia akatemialaisia ja suuri joukko it-alan opiskelijoita niin Jamkista kuin muualta Suomesta. Tämän hienon kurssin aikaansai siis Joona omalla kiinnostuksella aihetta kohtaan, GG WP!

Jeff Sutherlandin kirjaa “Scrum: The Art of Doing Twice the Work in Half the Time” lueskelin hieman valmistautuessani Certified ScrumMaster kokeeseen. Tämä essee toimii lähinnä itselleni kertauksena ja selvennyksenä siitä, mitä Scrum on. Aineistona toimii suurimmaksi osaksi Reaktorin kurssimateriaali ja muutama nettisivusto missä myös oppeja kertasin. Käytän käsitteistä englanninkielisiä termejä, sillä testi on englanniksi ja suomennokset ovat vähintäänkin kömpelöitä.

 

Mikä on Scrum?

 

Helppo määritelmä Scrumille on todeta sen olevan ketterä projektinhallintamenetelmä, joka soveltuu erityisen hyvin ohjelmistokehityksen puolelle.

Scrumin hyödyt tulevat esiin kun sitä käytetään monimutkaisten ja mukautuvien ongelmien ratkaisuun. Esimerkiksi ohjelmistokehityksessä tilanne voi olla usein se, että asiakas tietää mitä haluaa, mutta tekninen toteutus ja matka valmiiseen tuotteeseen on suuri tuntematon. Helpot asiat tehdään, siirrytään vaikeampiin toteutuksiin ja löydetään iso alue monimutkaisuutta helpon ja kaaoksen välillä. Siinä perusajatus.

Scrum toimii hyvin pitkälti Agile Manifeston mukaan, joka on ohjenuora ohjelmistokehitykseen. Sen pääperiaatteet ovat seuraavat:

Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja

Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota

Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita

Muutokseen reagoimista enemmän kuin suunnitelman noudattamista.

 

Roolit

Product Owner

PO on asiakkaan edustaja jolla on visio siitä mitä tullaan tekemään. Hän on vastuussa siitä, että kehitystyö menee siihen suuntaan, että se noudattaa määritettyjä kriteerejä ja vastaa siihen tarpeeseen johon ollaan lähdetty vastausta hakemaan. Product Owner osaa kokonaisuuden, markkinan, strategian ja arvonmäärittelyn ja julkaisun.

Tiimi

Tiimi toimii itseohjautuvasti ja heidän tehtävänsä on kehittää tuotetta kohti valmista versiota ja julkaisua. He ottavat työtehtäviä Product Backlogista ja toteuttavat osia valmiiksi. Yksinkertaisesti itseohjautuvan tiimin tehtävänä on tehdä tekninen toteutus saavuttaen Product Ownerin asettamat tavoitteet ja ominaisuudet.

ScrumMaster

ScrumMaster toimii fasilitaattorina ja hoitaa viestinnän Product Ownerin ja kehitystiimin välillä. Hänen tehtävänsä on johtaa ja ohjata toimintaa oikeaan suuntaan. Hänellä on hallussaan projektin kokonaiskuva ja vetää scrum-sparraukset ja suunnittelun yhdessä tiimin kanssa.

 

Scrumin toteutus ja keskeiset käsitteet

 

Sprint

Helposti sanottuna se on yksi “Scrum-kierto”, joka kestää maksimissaan 30 päivää. Yleensä sprintit ovat 1-2 viikon pituisia. Se sisältää seuraavat toimenpiteet: Product Backlog, Sprint Planning, Sprint Backlog, Daily Scrums, Retrospective ja Sprint Reviewn.

Product Backlog

PB on Product Ownerin työkalu joka sisältää listauksen toteutukseen tehtävistä asioista (toiminnallisuuksista, ominaisuuksista ym.). Product Backlogille itemit järjestetään tärkeysjärjestykseen sillä perustein, että saadaan MVP-versio tuotteesta.

Sprint Backlog

Tämä on lähes sama kuin ylläoleva selitys, mutta Sprint Backlogille valitaan itemit jotka ovat ajankohtaisia kyseisen sprintin sisällä.

Sprint Planning

Palaveri jossa käydään läpi tulevan sprintin tavoitteet ja päätetään sisältö. Yleensä Sprint Planning jaetaan kahteen osaan. Ensimmäisessä osassa PO esittelee viimeisimmän näkemyksen tuotteen roadmapista ja Product Backlogin. Kehitystiimi määrittelee mahdollisuudet ja sen milloin tietty item voidaan todeta valmiiksi (Definition of Done). Lisäksi tämä on paikka, jossa tiimiläiset voivat esittää kysymyksiä PO:lle. Toisessa osassa Sprint Planningia kehitystiimi jakaa Product Backlogin asiat pienempiin kokonaisuuksiin ja arvioi työmäärää. Lopuksi kehitystiimi päättää mitkä asiat otetaan Product Backlogilta tavoitteiksi tulevaan sprinttiin.

Daily Scrum

Sprintin läpi kehitystiimi ja ScrumMaster kokoontuvat Daily Scrumiin, joka on nopea 15-minuuttin tilannekatsaus joka keskittyy viestintään ja siihen miten homma on edennyt. Hyvä keino tähän on kysyä seuraavat kysymykset jokaiselta jäseneltä:

  • Mitä olen tehnyt edellisen Daily Scrumin jälkeen?
  • Mitä tulen tekemään ennen seuraavaa Daily Scrumia?
  • Mitkä esteet hidastavat minua?

 

Sprint Review

Yksittäinen sprintti päättyy kahteen tapaamiseen, Sprint Reviewin ja Retrospectiveen. Sprint Review keskittyy siihen mitä saatiin sprintin aikana tehtyä ja esittelee tulokset Product Ownerille. Review on myös tilanne johon voidaan ottaa mukaan henkilöitä tiimin ulkopuolelta, asiakkaan tj tai markkinointi ja myyntiosastot voivat osallistua kuulemaan missä mennään.

Sprint Retrospective

Retron tarkoitus on käydä läpi sitä miten asiat toteutettiin. Hyväksi todetut toimintatavat jaetaan ja käydään läpi mitä parannetaan seuraavalle sprintille. Eli Retrospectiven tarkoitus on reflektoida mennyttä sprinttiä ja tehdä pohja seuraavalle seuraavan sprintin suunnitteluun.

 

Mitä opin?

Nyt kun on saanut syvempää tietämystä aiheesta niin täytyy vain todeta, että Scrum ei välttämättä ole kovin hyödyllinen ympäristössä missä me sitä tiiminä yritimme toteuttaa. Onnistunut Scrum vaatii yhteisen maalin ja yhteisen käsityksen siitä mitä ollaan tekemässä. Toki hyviä puolia on Scrumin kokonaisvaltaisuus ja se, että se tuo selvyyttä yksilölle mitä olisi hyvä tehdä missäkin ajassa. Mutta periaatteessa jos jokaisella on omat maalit ja tehtävät sprintille niin Scrumin todellinen hyöty häviää. Keskiössä on itseohjautuva tiimi joka toimii pelaa samaan maaliin. Parhaimmillaankin Scrum voisi hyödyttää Intoa juuri tällä itseohjautuvuuden opettelulla ja ulottuvuudella. Yhteinen maali ja merkitys puuttuu meiltä ja en kauheasti usko, että sellaista enää viimeisenä syksynä lähdetään määrittämään. Jokaisella on omat maalinsa kuten opari ja työllistyminen.

Kurssi kesti kaksi päivää ja oli kokonaisuutena mahtava kokemus. En silti näe, että kouluttautuminen ScrumMasteriksi olisi tarpeellista, ellei aio työskennellä ohjelmistokehityksen parissa. Itseohjautuvuutta ja tavoitteiden asettemista voi harjoitella helpommin keinoin saavuttaen parempia tuloksia.

 

Keskustele artikkelista

Kirjoita kommentti

Kirjoita allaoleva koodi viereiseen kenttään roskapostin suodattamiseksi, kiitos!