Scrum käytännössä – ohjelmistokehitysprosessin seuranta ja arviointi
Varis, Antti (2026)
Varis, Antti
2026
All rights reserved. This publication is copyrighted. You may download, display and print it for Your own personal use. Commercial use is prohibited.
Julkaisun pysyvä osoite on
https://urn.fi/URN:NBN:fi:amk-202603305307
https://urn.fi/URN:NBN:fi:amk-202603305307
Tiivistelmä
Tämän havainnoivan opinnäytetyön tavoitteena oli perehtyä ketterän kehityksen ja erityisesti Scrumin teoriaan, sekä tutkia pienen ohjelmistoyrityksen kehitysprosessia mahdollisten kehitys- ja parannuskohtien löytämiseksi. Kyseessä oleva yritys on perustettu vuonna 2020 ja opinnäyte-työn kirjoittamishetkellä siinä työskenteli 6 vakituista työntekijää. Yritys valmistaa terveydenhuollossa käytettävää ohjelmistotyökalua.
Tietoperustassa keskitytään Scrumiin, joka on eniten käytetty ketterän kehityksen viitekehys. Sille on ominaista projektin jakaminen useampaan, yleensä samanmittaiseen jaksoon, joita kutsutaan sprinteiksi Ideologian ja arvojen lisäksi Scrumin teoria määrittelee varsin tarkasti mm. kehitystyöhön sisältyvät tapahtumat, tiimin koon, sen roolit sekä kehitystyön tuotokset. Onnistunut Scrumin soveltaminen käytäntöön ei kuitenkaan ole yksinkertaista ja se vaatii tiimiltä avointa suhtautumista työhönsä, sen tuomiin haasteisiin sekä rohkeutta priorisoida työskentelyä omatoimisesti.
Viiden viikon havainnointijakson aikana perehdyttiin syvällisesti Scrumin teoriaan sekä yrityksen ohjelmistokehitysprosessin yksityiskohtiin. Ensimmäisen kahden seurantaviikon aikana keskityt-tiin Scrumin tapahtumiin, seuraavat kaksi viikkoa kului Scrumin tuotosten parissa ja viimeinen viikko Scrum-tiimiin perehtyen.
Yrityksen ohjelmistokehityksen prosessissa havaittiin sekä yhtäläisyyksiä että eroja Scrum-teoriaan verrattuna. Ehkä merkittävin näistä eroista oli se, että yrityksessä pidetään säännöllisesti vain 2 erilaista kehitystyön tapahtumaa, kun teoria esittelee 4 erilaista tapahtumaa. Pidetyt tapahtumat ovat myös ajallisesti teorian suosituksia lyhyempiä. Tämä johtaa siihen, että yrityksessä käytetään kehitystyön tapahtumiin jopa 80-87 % vähemmän aikaa kuin mitä teoria suosittelee. Scrum-rooleihin liittyen merkittävä havainto oli se, että yrityksessä ei ole selkeää, nimettyä tuoteomistajaa, vaan tämän tehtävät on jaettu usealle henkilölle. Scrumin-tiimin muut roolit ja Scrumin tuotokset vastasivat varsin läheisesti Scrum-ohjetta.
Teorian ja tehtyjen havaintojen perusteella tunnistettiin kaksi kehityskohtaa. Kehitystyön tapahtumiin voisi käyttää enemmän aikaa esim. nykyisiä kehitystyön tapahtumia pidentämällä. Tämän lisäksi tuoteomistajan tehtävien keskittäminen yhdelle henkilölle toisi todennäköisesti selkeyttä koko tiimin työskentelyyn, sekä tehostaisi kommunikaatiota tiimin jäsenten välillä.
Tietoperustassa keskitytään Scrumiin, joka on eniten käytetty ketterän kehityksen viitekehys. Sille on ominaista projektin jakaminen useampaan, yleensä samanmittaiseen jaksoon, joita kutsutaan sprinteiksi Ideologian ja arvojen lisäksi Scrumin teoria määrittelee varsin tarkasti mm. kehitystyöhön sisältyvät tapahtumat, tiimin koon, sen roolit sekä kehitystyön tuotokset. Onnistunut Scrumin soveltaminen käytäntöön ei kuitenkaan ole yksinkertaista ja se vaatii tiimiltä avointa suhtautumista työhönsä, sen tuomiin haasteisiin sekä rohkeutta priorisoida työskentelyä omatoimisesti.
Viiden viikon havainnointijakson aikana perehdyttiin syvällisesti Scrumin teoriaan sekä yrityksen ohjelmistokehitysprosessin yksityiskohtiin. Ensimmäisen kahden seurantaviikon aikana keskityt-tiin Scrumin tapahtumiin, seuraavat kaksi viikkoa kului Scrumin tuotosten parissa ja viimeinen viikko Scrum-tiimiin perehtyen.
Yrityksen ohjelmistokehityksen prosessissa havaittiin sekä yhtäläisyyksiä että eroja Scrum-teoriaan verrattuna. Ehkä merkittävin näistä eroista oli se, että yrityksessä pidetään säännöllisesti vain 2 erilaista kehitystyön tapahtumaa, kun teoria esittelee 4 erilaista tapahtumaa. Pidetyt tapahtumat ovat myös ajallisesti teorian suosituksia lyhyempiä. Tämä johtaa siihen, että yrityksessä käytetään kehitystyön tapahtumiin jopa 80-87 % vähemmän aikaa kuin mitä teoria suosittelee. Scrum-rooleihin liittyen merkittävä havainto oli se, että yrityksessä ei ole selkeää, nimettyä tuoteomistajaa, vaan tämän tehtävät on jaettu usealle henkilölle. Scrumin-tiimin muut roolit ja Scrumin tuotokset vastasivat varsin läheisesti Scrum-ohjetta.
Teorian ja tehtyjen havaintojen perusteella tunnistettiin kaksi kehityskohtaa. Kehitystyön tapahtumiin voisi käyttää enemmän aikaa esim. nykyisiä kehitystyön tapahtumia pidentämällä. Tämän lisäksi tuoteomistajan tehtävien keskittäminen yhdelle henkilölle toisi todennäköisesti selkeyttä koko tiimin työskentelyyn, sekä tehostaisi kommunikaatiota tiimin jäsenten välillä.