Scrum

Scrum on 1990–luvun puolessa välissä kehitetty ketterä kehittämismenetelmä (Schwaber, 1995), joka toi ideoita teollisuuden prosessikontrolliteoriasta ohjel-mistokehityksen käyttöön. Se korostaa joustavuutta, mukautuvuutta ja tuotta-vuutta. Sen sanottiin soveltuvan etenkin pienten, mielellään 3–10 henkilöstä koostuviin tiimeihin. Scrumin on sanottu olevan kevyt ja helppo ymmärtää, mutta vaikea taitaa. (Schwaber & Sutherland, 2013.) Menetelmä tarjoaa etenkin projektin johtamisen käytäntöjä enemmän kuin muut ketterät menetelmät (Conboy, 2009).

Scrumissa kehittämisprosessi on jaettu kolmeen vaiheeseen, esipelivaihee-seen (engl. pregame phase), peli/kehitysvaiheeesipelivaihee-seen (engl. development phase) sekä loppupelivaiheeseen (engl. postgame phase). Kehitys etenee iteratiivisesti sekä inkrementaalisesti. (Abrahamsson ym., 2002.) Kuviossa 8 on esitetty Scru-min prosessimalli Abrahamssonin ym. (2002) esityksen mukaisesti. Tämä esitys noudattaa Schwaberin (1995) kuvausta. Myöhemmissä esityksissä (esim.

Schwaber & Sutherland, 2013) ei Scrumin prosessia ole vaiheistettuna kuvattu.

Esipelivaiheessa on kaksi alavaihetta, suunnitteluvaihe ja arkkitehtuu-rin/korkeamman tason suunnittelu. Tuotteen kehitysjono (engl. Product Backlog) on projektin työlista, johon muodostetaan rakenne priorisoiduista vaatimuksis-ta. Sitä ylläpidetään koko projektin aikana muun muassa lisäämällä uusia kehi-tettäviä ominaisuuksia ja muuttamalla vanhoja. Samalla suunnitellaan kehitys-jonon avulla myös korkeamman tason ja arkkitehtuurin mallinnukset. Tämän lisäksi esipelivaiheen aikana määritellään projektitiimi, työkalut, muut resurssit, koulutustarpeet ja hyväksymisen johtaminen. (Abrahamsson ym., 2002.)

Kehitysvaiheessa ohjelmistoa kehitetään sprinteissä, joiden suositeltu kesto on kahdesta neljään viikkoa. Sprintin aikana tarkkaillaan erilaisia ympäristölli-siä ja tekniympäristölli-siä muuttujia, joita ovat muun muassa aikaikkuna, laatu, vaatimuk-set, resurssit ja toteutusteknologiat. Sprinttien aikana tehdään ohjelmistoon uu-sia ominaisuukuu-sia tai parannellaan jo olemassa olevia, valittavien tehtävien va-likoituessa Sprintin työlistaan (engl. Sprint Backlog) tuotteen kehitysjonosta. (Ab-rahamsson ym., 2002.) Sprintin aikana ei tehdä muutoksia, jotka vaikuttavat sen tavoitteisiin, eikä sen laatutavoitteita lasketa, ja kehitystiimin koostumus pide-tään samana. Tarvittaessa työlistaa voidaan muuttaa ja tarkentaa, mikäli rat-kaistava ongelma tullaan tämän avulla ymmärtämään paremmin. (Schwaber &

Sutherland, 2013.)

Loppupelivaiheeseen tullaan kun on yhteisymmärrys ympäristötekijöiden suhteen, kuten vaatimusten saavuttamiseen pääsemisestä. Tällöin sprintin työ-lista on tyhjä ja voidaan tehdä muita tarpeellisia toimintoja, joita voivat olla

muun muassa integrointi, dokumentaatio ja järjestelmätestaus. (Abrahamsson ym., 2002.)

KUVIO 8 Scrumin prosessi (Abrahamsson ym., 2002, 28)

Scrum-tiimissä on kolmenlaisia henkilörooleja. Scrum–mestari (engl. Scrum Mas-ter) on hallinnollinen henkilö, jonka vastuulla on projektin ja sprinttien etene-minen Scrumin käytäntöjen, arvojen ja sääntöjen mukaisesti. Samalla hän myös toimii tiimiä palvelevana johtajana ja pyrkii maksimoimaan tiimin työn arvon.

Kehitystiimi (engl. development team) koostuu ohjelmistoalan ammattilaisista.

Tiimi tuottaa kehitettävää ohjelmistoa inkrementeissä, jolloin ominaisuus siir-tyy työlistasta valmiiksi. Kehitystiimi on itseorganisoituva. Tämä tarkoittaa muun muassa sitä, että tiimi itse päättää kuinka se valitsee ominaisuudet tuot-teen kehitysjonosta, ja miten se toteuttaa ne valmiiksi. Tiimin jäsenet toimivat eri rooleissa sen sisällä ja samat henkilöt voivat suorittaa esimerkiksi ohjelmoin-tia ja testausta. Tuoteomistaja (engl. product owner) on henkilö, joka on vastuussa tuotteen kehitysjonon ylläpidosta ja sen priorisoinnista. Tämän lisäksi hän on vastuussa tuotteen kehitysjonon sisällön selvittämisestä ja läpinäkyvyydestä kehittäjätiimille, sen selvyydestä eli mitä tulee tehdä seuraavaksi sekä tiimin työn arvon varmistamisesta. Tuoteomistaja voi esimerkiksi olla työntekijä koh-deorganisaatiosta, jolle ohjelmistoa ollaan kehittämässä. Scrum korostaa lä-pinäkyvyyttä, ja erilaisten tuotosten (engl. artifact) kuten sprintin työlistan ja tuotteen kehitysjonon tulee olla mahdollisimman läpinäkyviä. Scrum-mestarin tulee työskennellä tuoteomistajan, kehitystiimin ja muiden asianomaisten

kans-sa ja varmistua siitä, että tuotokset todella ovat läpinäkyviä kaikille. (Schwaber

& Sutherland, 2013.)

Scrumissa järjestetään erilaisia tapahtumia. Suunnittelupalaveri (engl. sprint planning meeting) koostuu kahdesta osasta. Ensimmäisessä osassa tuoteomistaja esittelee tuotteen kehitysjonon, jonka jälkeen kehittäjätiimi itse päättää, mitkä tullaan valitsemaan sprintin työlistaan. Tämän jälkeen sprintille asetetaan konkreettinen tavoite, joka antaa kehittäjätiimille konkreettisen näkökulman miksi sprintin inkrementtiä ollaan kehittämässä. Toisessa osassa tiimi itseor-ganisoituu ja suunnittelee miten valittu työ tullaan toteuttamaan, neuvotellen tarvittaessa tuoteomistajan kanssa sprintin työlistasta. (Schwaber & Sutherland, 2013.)

Päiväittäinen Scrum (engl. Daily Scrum) on päivittäinen palaveri, jonka ai-kana kehittäjätiimi kokoontuu johonkin tilaan enintään 15 minuutiksi. Palave-rissa tiimi tahdistaa keskinäiset työnsä asettaen suunnitelman ja ennustuksen mitä seuraavan 24 tunnin aikana tullaan tekemään. Päivittäisessä Scrumissa tiimin jäsenet kertovat muun muassa, mitä on saatu aikaan viimeisen 24 tunnin aikana sekä mitä ongelmia on kehityksessä ollut. (Schwaber & Sutherland, 2013.)

Kohdassa 2.1.2 jäsennettiin menetelmä eri näkökulmien mukaisesti osiin (vrt. Kuvio 2). Samaa jäsennystä noudattaen on taulukossa 1 esitetty tiivistelmä Scrum-menetelmästä.

TAULUKKO 1 Scrum jaettuna osiin

Menetelmän osa Scrum

Tausta 1990-luvun puolessa välissä kehitetty menetelmä, joka tuo ideoita teollisuuden prosessikontrolliteoriasta ohjelmisto-kehitykseen

Lähestymistapa Ketterä lähestymistapa Empiirinen lähestymistapa Periaatteet Ketterän kehittämisen periaatteet

Soveltaminen Alun perin tarkoitettu pienille, 3–10 henkilöstä koostuville kehitystiimeille, mutta nykyään sovelletaan myös laajem-missa projekteissa

Prosessi Iteratiivinen prosessimalli, jossa esipelivaihe, kehitysvaihe ja loppupelivaihe seuraavat toisiaan

Roolit Scrum-mestari, kehittäjä, tuoteomistaja

Käytäntöjä Suunnittelupalaveri, päivittäinen palaveri, sprinttikatsel-mus, sprintin retrospektiivi, tuotteen kehitysjono, sprintin kehityslista, edistymiskäyrä, valmiin määritelmä

Sprintin lopussa järjestetään sprinttikatselmus (engl. Sprint Review), jossa tuote-omistaja katsoo, mikä osa työstä on ”valmista”, ja mikä ei ole ”valmista”. Val-miin määritelmä (engl. definition of done) voi vaihdella Scrum-tiimien välillä, mut-ta tiimin sisällä tulee olla jaettu ymmärrys siitä, mitä valmiilla kehitysjonon teh-tävällä ja inkrementillä tarkoitetaan. Sprinttikatselmuksessa tiimi ja eri

sidos-ryhmät tutkivat kehitettyä tuoteversiota keskustellen ja antaen palautetta. Tar-vittaessa tämän jälkeen tehdään muutoksia tuotteen kehitysjonoon. Scrumin jokaisessa vaiheessa tulisi olla mahdollista arvioida työmäärä, joka on jäljellä päämäärän saavuttamiseksi. Tuoteomistajan tulee tarkkailla jäljellä olevaa työ-määrää vähintään jokaisen sprinttikatselmuksen aikana. Tätä voidaan graafises-ti tarkastella edistymiskäyrän (engl. burndown chart) avulla. Sprintin retrospektii-vissä (engl. sprint retrospective) Scrum–tiimi tarkastelee omaa työskentelyään ja kehitysprosessiaan ja tarvittaessa tekee muutossuunnitelman toiminnan paran-tamiseksi. (Schwaber & Sutherland, 2013.)