SlideShare a Scribd company logo
1 of 13
Scrum on projektinhallinnan viitekehys, jota käytetään yleisesti ketterässä
ohjelmistokehityksessä. Vaikka Scrum on kehitetty erityisesti ohjelmistoprojektien
hallintaan, sitä voidaan soveltaa myös yleisesti projektinhallinnassa.
Ensimmäisinä idean Scrumin kehitysprosessista kuvasivat 1986 Hirotaka Takeuchi ja Ikujiro
Nonaka. Teoksessaan Takeuchi ja Nonaka kuvaavat uudenlaisen, holistisen lähestymistavan
tuotekehitykseen, jossa yksi ainoa monitaitoinen (engl. cross-functional) ryhmä suorittaa
kehitysprosessin alusta loppuun vaiheistuksella, joka on vahvasti lomittunut.
Ryhmän toimintaa verrataan rugby-joukkueeseen, jossa koko ryhmä pyrkii etenemään
yksikkönä ja toimimaan tiiviissä yhteistyössä. Myös menetelmän nimi (engl. scrum) viittaa
rugbyn aloitusryhmitykseen. Nimi on myös sittemmin jäänyt käyttöön johtuen
menetelmän yhtäläisyyksistä rugby-joukkueeseen ja sen toimintaan; molemmat ovat
erilaisiin tilanteisiin sopeutuvaisia, nopeita ja itseohjautuvia.
Scrum: projektinhallinta
Scrum: työskentelytapa
Scrumissa työskennellään toistavasti ja lisäävästi (engl. iterative-incremental)
ennustettavuuden optimoimiseksi ja riskien kontrolloimiseksi. Tavoitteena oleva tuote
kehittyy pikkuhiljaa täydellisemmäksi ja valmiimmaksi useiden kehitysjaksojen aikana.
Kehitysjaksoa kutsutaan sprintiksi (engl. Sprint). Sprintti on 1-4 viikon mittainen aikaraja,
jonka sisällä tuotetaan “valmiin” määritelmän täyttävä, käyttökelpoinen ja potentiaalisesti
julkaisukelpoinen tuoteversio. Jokaisen sprintin sisältö sovitaan sprintin
suunnittelupalaverissa ennen sprintin aloitusta, ja toteutettaviksi valitaan sellaisia tuotteen
kehitysjonon kohtia, joilla on sillä hetkellä suurin merkitys projektin onnistumiselle.
Sprintin lopuksi järjestetään sprinttikatselmus, jossa kehitystiimi esittelee sprintin
konkreettiset saavutukset (esim. ohjelmiston uusimman version) tuoteomistajalle sekä
mahdollisille sidosryhmien edustajille palautteen saamiseksi ja ymmärryksen lisäämiseksi
kehityksen tilasta. Ennen seuraavan sprintin aloittamista pidetään vielä sprintin
retrospektiivi, jossa tarkastellaan prosessin näkökulmasta mikä sprintin aikana sujui hyvin
ja mitä voitaisiin parantaa seuraavassa sprintissä.
Scrum: roolit 1
Scrum-kehityksessä käytetään yhtä tai useampaa scrumtiimiä (engl. scrum team).
Scrumtiimi koostuu tuoteomistajasta, scrummasterista ja kehitystiimistä. Scrumtiimi
päättää kunkin sprintin tavoitteet ja tehtävät, ja vastaa yhdessä siitä, että asetettuihin
tavoitteisiin päästään. Scrumtiimi on itseohjautuva ja monitaitoinen, ja sillä on valta
päättää omista työmenetelmistään.
Yksi scrumtiimin jäsen toimii tuoteomistajana (engl. product owner). Tuoteomistaja vastaa
tuotteen arvon ja kehitystiimin työn arvon maksimoimisesta. Käytännössä tämä tapahtuu
määrittelemällä tuotteen vaatimukset sekä järjestämällä tuotteen kehitysjono yhteistyössä
scrumtiimin kanssa. Tuoteomistaja on yksi henkilö, ei komitea. Tuoteomistaja voi
hyödyntää komiteoita tai edustaa sellaisen toiveita tuotteen kehitysjonon kautta.
Tuoteomistaja tuntee tuotteen liiketoimintaa ja edustaa asiakkaita ja käyttäjiä.
Tuoteomistaja varmistaa, että scrumtiimi toteuttaa jokaisessa sprintissä sellaisia
vaatimuksia, jotka ovat tuotteen onnistumisen kannalta keskeisimpiä. Tuoteomistaja
hyväksyy sprinttikatselmuksessa edellisen sprintin tuoteversion ja osallistuu sprintin
suunnittelupalaveriin varmistaakseen, että kehitystiimi ymmärtää sprinttiin valittavat
tuotteen kehitysjonon kohdat riittävällä tarkkuudella. Tuoteomistaja myös auttaa
kehitystiimiä ymmärtämään vaatimuksia ja tarvittaessa tarkentaa sprinttiin valittujen
vaatimusten toteutustapaa sprintin aikana.
Scrum: roolit 2
Toinen scrumtiimin rooleista on kehitystiimi (engl. development team). Kehitystiimi koostuu
ammattilaisista, jotka muuttavat sprinttiin valitun tuotteen kehitysjonon sisällön
potentiaalisesti julkaisukelpoikseksi “valmiiksi” tuoteversioksi jokaisessa sprintissä.
Ainoastaan kehitystiimin jäsenet osallistuvat tuoteversion kehitykseen. Kehitystiimit ovat
monitaitoisia sisältäen kaiken tarvittavan osaamisen potentiaalisesti julkaisukelpoisen
tuoteversion kehittämiseksi. Kehitystiimin jäsenillä voi olla erityistä osaamista tai erilaisia
työn painopisteitä, mutta vastuu kehityksestä kuuluu koko kehitystiimille yhdessä.
Kolmas scrumtiimin rooli on scrummaster (engl. scrum master). Scrummaster vastaa siitä,
että kaikki ymmärtävät ja käyttävät Scrumia. Scrummasterit tekevät tämän varmistamalla,
että scrumtiimit pitäytyvät Scrumin teoriassa, käytännöissä ja säännöissä. Scrummaster on
scrumtiimin palveleva johtaja. Toisin kuin perinteisellä esimiehellä, scrummasterilla ei ole
scrumtiimin jäseniin suoraa määräysvaltaa, vaan hän vaikuttaa scrumtiimiin Scrum-
prosessin kautta. Scrummasterin tehtävät koostuvat suurelta osin ryhmän työskentelyä
haittaavien esteiden poistamisesta ja ryhmän valmentamisesta itseohjautuvuuteen.
Scrummaster tarkkailee työn etenemistä, ja jos sprintin tavoitteiden saavuttaminen alkaa
näyttää epätodennäköiseltä, hän kommunikoi kehitystiimin ja tuoteomistajan kanssa
tilanteen korjaamiseksi tai sprintin sisällön kaventamiseksi. Scrummaster myös suojaa tiimiä
ulkopuoliselta hälyltä, kuten sprintin aikana pyydetyiltä uusilta vaatimuksilta, ja tekee
kaikkensa turvatakseen tiimilleen työrauhan.
Scrum: tuotokset
• Tuotteen kehitysjono (engl. product backlog) on järjestetty lista kaikesta, mitä tuotteessa saatetaan
tarvita, sekä ainoa lähde tuotteeseen toteutettaville vaatimuksille ja muutoksille. Tuoteomistaja
vastaa tuotteen kehitysjonosta mukaan lukien sen sisältö, saatavuus ja järjestäminen. Tuotteen
kehitysjono ei ole koskaan valmis, vaan se kehittyy, kun tuote sekä ympäristö kehittyy.
Julkaisusuunnitelmaksi kutsutaan kehitysjonoa, joka sisältää kaikki tuotteen kehitysjonosta
seuraavaan julkaisuun valitut kohdat (engl.product backlog Item) sekä alustavasti suunnitellun
määrän sprinttejä julkaisun toteuttamiseen.
• Sprintin tehtävälista (engl. sprint backlog) koostuu sprintin suunnittelupalaverissa valituista
tuotteen kehitysjonon kohdista sekä suunnitelmasta niiden toteuttamiseksi. Sprintin tehtävälista on
kehitystiimin antama ennuste siitä, mitä toiminnallisuutta seuraavaan tuoteversioon tulee
sisältymään sekä tarvittavista tehtävistä toiminnallisuuden toteuttamiseksi. Sprintin tehtävälista
määrittää ja tekee näkyväksi kaiken työn, jonka kehitystiimi kokee tarpeelliseksi kehittääkseen
tuotteen kehitysjonon kohdat “valmiiksi” tuoteversioksi ja saavuttaakseen sprintin tavoitteen.
Tuoteomistaja ei voi sprintin aikana vaihtaa kehitysjonon kohtia toisiin. Kehitystiimi voi sen sijaan
milloin tahansa muuttaa, lisätä tai poistaa sprintin tehtäviä varmistaakseen, että sprintin tavoite ja
valitut tuotteen kehitysjonon kohdat toteutuvat.
• Edistymiskäyrä (engl. burndown chart) kuvaa tuotteen tai sprintin jäljelläolevaa työmäärää.
• Tuoteversio (engl. increment) on summa kaikista tuotteen kehitysjonon kohdista, jotka ovat
valmistuneet sprintin ja aiempien sprinttien aikana. Sprintin lopussa siinä valmistuneen
tuoteversion tulee olla “valmis”, joka tarkoittaa, että se täyttää scrumtiimin “valmiin” määritelmän
ja on käyttökelpoisessa kunnossa, riippumatta siitä, päättääkö tuoteomistaja julkaista sen.
Scrum: tapahtumat 1
Scrumissa käytetään ennaltasovittuja tapahtumia luomaan säännöllisyyttä ja minimoimaan muiden
kuin Scrum-palavereiden tarve. Scrumin tapahtumat ovat aikarajattuja eli jokaisella niistä on
maksimipituus. Tämä varmistaa sen, että suunnittelulle varataan riittävästi aikaa, mutta
suunnitteluprosessissa ei pääse syntymään hukkaa.
• Sprintti (engl. sprint) on scrumin ydin, enintään kuukauden pituinen tai sitä lyhyempi aikaraja, jonka
sisällä tuotetaan “valmiin” määritelmän täyttävä, käyttökelpoinen ja potentiaalisesti
julkaisukelpoinen tuoteversio. Sprinteillä on sama pituus koko kehityksen ajan. Uusi sprintti alkaa
välittömästi edellisen päätyttyä.
• Sprintin suunnittelupalaveri (engl. sprint planning meeting) on palaveri, jossa suunnitellaan sprintin
aikana tehtävä työ. Tämä suunnitelma luodaan yhteistyössä koko scrumtiimin kesken. Sprintin
suunnittelupalaverin pituus rajataan enintään kahdeksaan tuntiin kuukauden mittaiselle sprintille.
Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa. Esimerkiksi kahden viikon sprintille
varataan enintään neljä tuntia.
• Päiväpalaveri (engl.daily scrum) on enintään 15 minuutin mittainen aikarajattu palaveri, jossa
kehitystiimi tahdistaa keskinäiset työnsä ja luo suunnitelman seuraaville 24 tunnille. Tämä tapahtuu
tarkastelemalla edellisen päiväpalaverin jälkeen tehtyä työtä ja ennustamalla, mitä voidaan
toteuttaa ennen seuraavaa päiväpalaveria. Päiväpalaverissa jokainen kehitystiimin jäsen kertoo
vuorollaan 1) Mitä olen tehnyt viime päiväpalaverin jälkeen, 2) Mitä aion tehdä ennen seuraavaa
päiväpalaveria, ja 3) Onko työni etenemisellä esteitä. Päiväpalaveri ei ole raportointia, vaan
kehitystiimin oma tapaaminen, jonka tarkoitus on optimoida työpäivän arvo ja todennäköisyys sille,
että kehitystiimi pääsee sprintin tavoitteeseen. Mikäli keskustelua halutaan jatkaa 15 minuutin
jälkeen, on tarkoituksenmukaista sopia erillinen palaveri, vaikka välittömästi päiväpalaverin jälkeen.
Scrum: tapahtumat 2
• Tuotteen kehitysjonon työstö (engl. product backlog grooming) tarkoittaa yksityiskohtien,
työmääräarvioiden ja kehitysjonon kohtien keskinäisen järjestyksen lisäämistä. Kyseessä on toistuva
prosessi, jossa tuoteomistaja ja kehitystiimi lisäävät yhteistyössä yksityiskohtia tuotteen
kehitysjonoon. Työstön aikana tuotteen kehitysjonon kohtia katselmoidaan ja arvioidaan. Niitä
voidaan kuitenkin päivittää milloin tahansa muulloinkin tuoteomistajan toimesta tai toiveesta.
Työstöön käytetään yleensä enintään 10% kehitystiimin kapasiteetista. Kehitystiimi vastaa kaikista
työmääräarvioista. Tuoteomistaja voi vaikuttaa kehitystiimiin auttamalla sitä ymmärtämään
vaatimuksia ja tekemään kompromisseja.
• Sprinttikatselmus (engl. sprint review) on sprintin lopussa pidettävä epämuodollinen palaveri, jossa
tarkastellaan kehitetty tuoteversio ja sopeutetaan tarvittaessa tuotteen kehitysjonoa.
Sprinttikatselmuksen aikana scrumtiimi ja sidosryhmät selvittävät yhteistyössä, mitä sprintissä
kehitettiin. Perustuen tähän tietoon ja mahdollisiin sprintin aikana tuotteen kehitysjonoon tehtyihin
muutoksiin osallistujat keskustelevat siitä, mitä voitaisiin kehittää seuraavaksi. Kehitystiimin
esittämän tuotedemon tavoitteena on saada palautetta, edistää keskustelua ja luoda realistinen
pohja seuraavan sprintin suunnittelupalaverille. Sprinttikatselmus rajataan enintään neljään tuntiin
kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa.
• Sprintin retrospektiivi (engl. sprint retrospective) antaa scrumtiimille tilaisuuden tarkastella
työskentelyään ja tehdä suunnitelman kehitysprosessin parannuksille, jotka toteutetaan seuraavassa
sprintissä. Sprintin retrospektiivi pidetään sprinttikatselmuksen jälkeen ja ennen seuraavan sprintin
suunnittelupalaveria. Palaveri rajataan enintään kolmeen tuntiin kuukauden sprintille. Lyhyemmille
sprinteille varataan suhteessa vähemmän aikaa.
ROOLI HALUAISIN ETTÄ TOIVE KOSKA
PERUSTELU
OHJAAJANA HALUAISIN ETTÄ VOISIN LISÄTÄ
OPISKELIJAN SUORAAN KURSSILLE KOSKA
NÄIN VOISIN OHJATA OPISKELIJAA
MA TI KE TO PE
KÄYNNISTYS DAILY STAND-UP DAILY STAND-UP DAILY STAND-UP DAILY STAND-UP
GROOMING PLANNING POKER TIIMI, RETRO JA DEMO
MA TI KE TO PE
DAILY STAND-UPDAILY STAND-UP
eDelfoi Development
https://groups.google.com/forum/?fromgroups#!forum/edelfoi-development

More Related Content

Similar to Scrum delfoi

Scrumin nykytila ja kehitys
Scrumin nykytila ja kehitysScrumin nykytila ja kehitys
Scrumin nykytila ja kehitysSovelto
 
Julkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @MearraJulkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @MearraMarko Taipale
 
Sysartin palvelun toimitusmalli
Sysartin palvelun toimitusmalliSysartin palvelun toimitusmalli
Sysartin palvelun toimitusmalliSysart Oy
 
Talent Base Case: MTV Elämyksiä Varten - mtv.fi verkkopalvelukehitys
Talent Base Case: MTV Elämyksiä Varten - mtv.fi verkkopalvelukehitysTalent Base Case: MTV Elämyksiä Varten - mtv.fi verkkopalvelukehitys
Talent Base Case: MTV Elämyksiä Varten - mtv.fi verkkopalvelukehitysLoihde Advisory
 
Agile ClearCase Rwsug.fi 2009
Agile ClearCase Rwsug.fi 2009Agile ClearCase Rwsug.fi 2009
Agile ClearCase Rwsug.fi 2009mteinonen
 
Opas ketterän ohjelmistokehityksen ostajalle
Opas ketterän ohjelmistokehityksen ostajalleOpas ketterän ohjelmistokehityksen ostajalle
Opas ketterän ohjelmistokehityksen ostajalleJyrki Hakala
 
Pikkusovellusten päivittämisen parhaat käytännöt SCCM-maailmassa -webinaari
Pikkusovellusten päivittämisen parhaat käytännöt SCCM-maailmassa -webinaariPikkusovellusten päivittämisen parhaat käytännöt SCCM-maailmassa -webinaari
Pikkusovellusten päivittämisen parhaat käytännöt SCCM-maailmassa -webinaariTeemu Tiainen
 
Ketterät vaatimukset - käyttäjätarina ja visio
Ketterät vaatimukset - käyttäjätarina ja visioKetterät vaatimukset - käyttäjätarina ja visio
Ketterät vaatimukset - käyttäjätarina ja visioKaroliina Luoto
 
Pragmatic Agile - Aamiaistilaisuus
Pragmatic Agile - AamiaistilaisuusPragmatic Agile - Aamiaistilaisuus
Pragmatic Agile - AamiaistilaisuusNitor
 
Talent Base: KAPO™-menetelmä
Talent Base: KAPO™-menetelmäTalent Base: KAPO™-menetelmä
Talent Base: KAPO™-menetelmäLoihde Advisory
 
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3MP-Plan Oy
 
AgileJKL Meetup 2016 - Antti Vartiainen
AgileJKL Meetup 2016 - Antti VartiainenAgileJKL Meetup 2016 - Antti Vartiainen
AgileJKL Meetup 2016 - Antti VartiainenDigia Plc
 
Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä
Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissäScrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä
Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissäJyri Vuorinen
 
Testaus 2013 Antti Auer Kettera hyväksymistestaus
Testaus 2013 Antti Auer Kettera hyväksymistestausTestaus 2013 Antti Auer Kettera hyväksymistestaus
Testaus 2013 Antti Auer Kettera hyväksymistestausTieturi Oy
 
Imuryhmän esitys - Apps4sust-ohjelman valmistelu 10072013
Imuryhmän esitys - Apps4sust-ohjelman valmistelu 10072013Imuryhmän esitys - Apps4sust-ohjelman valmistelu 10072013
Imuryhmän esitys - Apps4sust-ohjelman valmistelu 10072013Mikko Järvilehto
 

Similar to Scrum delfoi (20)

Scrumin nykytila ja kehitys
Scrumin nykytila ja kehitysScrumin nykytila ja kehitys
Scrumin nykytila ja kehitys
 
Julkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @MearraJulkishallinnon IT-hankinnat @Mearra
Julkishallinnon IT-hankinnat @Mearra
 
Avoimen tuotteen hallinta
Avoimen tuotteen hallintaAvoimen tuotteen hallinta
Avoimen tuotteen hallinta
 
Sysartin palvelun toimitusmalli
Sysartin palvelun toimitusmalliSysartin palvelun toimitusmalli
Sysartin palvelun toimitusmalli
 
Talent Base Case: MTV Elämyksiä Varten - mtv.fi verkkopalvelukehitys
Talent Base Case: MTV Elämyksiä Varten - mtv.fi verkkopalvelukehitysTalent Base Case: MTV Elämyksiä Varten - mtv.fi verkkopalvelukehitys
Talent Base Case: MTV Elämyksiä Varten - mtv.fi verkkopalvelukehitys
 
Agile ClearCase Rwsug.fi 2009
Agile ClearCase Rwsug.fi 2009Agile ClearCase Rwsug.fi 2009
Agile ClearCase Rwsug.fi 2009
 
Julkisen
Julkisen Julkisen
Julkisen
 
Opas ketterän ohjelmistokehityksen ostajalle
Opas ketterän ohjelmistokehityksen ostajalleOpas ketterän ohjelmistokehityksen ostajalle
Opas ketterän ohjelmistokehityksen ostajalle
 
Pikkusovellusten päivittämisen parhaat käytännöt SCCM-maailmassa -webinaari
Pikkusovellusten päivittämisen parhaat käytännöt SCCM-maailmassa -webinaariPikkusovellusten päivittämisen parhaat käytännöt SCCM-maailmassa -webinaari
Pikkusovellusten päivittämisen parhaat käytännöt SCCM-maailmassa -webinaari
 
Talent Base KAPO-malli
Talent Base KAPO-malliTalent Base KAPO-malli
Talent Base KAPO-malli
 
Ketterät vaatimukset - käyttäjätarina ja visio
Ketterät vaatimukset - käyttäjätarina ja visioKetterät vaatimukset - käyttäjätarina ja visio
Ketterät vaatimukset - käyttäjätarina ja visio
 
Pragmatic Agile - Aamiaistilaisuus
Pragmatic Agile - AamiaistilaisuusPragmatic Agile - Aamiaistilaisuus
Pragmatic Agile - Aamiaistilaisuus
 
Talent Base: KAPO™-menetelmä
Talent Base: KAPO™-menetelmäTalent Base: KAPO™-menetelmä
Talent Base: KAPO™-menetelmä
 
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
Lyhyt Opas Tietojärjestelmän Hankintaan v 0.3
 
AgileJKL Meetup 2016 - Antti Vartiainen
AgileJKL Meetup 2016 - Antti VartiainenAgileJKL Meetup 2016 - Antti Vartiainen
AgileJKL Meetup 2016 - Antti Vartiainen
 
Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä
Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissäScrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä
Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä
 
Johdanto leaniin ja ketterään tietotyöhön
Johdanto leaniin ja ketterään tietotyöhönJohdanto leaniin ja ketterään tietotyöhön
Johdanto leaniin ja ketterään tietotyöhön
 
Testaus 2013 Antti Auer Kettera hyväksymistestaus
Testaus 2013 Antti Auer Kettera hyväksymistestausTestaus 2013 Antti Auer Kettera hyväksymistestaus
Testaus 2013 Antti Auer Kettera hyväksymistestaus
 
Imuryhmän esitys - Apps4sust-ohjelman valmistelu 10072013
Imuryhmän esitys - Apps4sust-ohjelman valmistelu 10072013Imuryhmän esitys - Apps4sust-ohjelman valmistelu 10072013
Imuryhmän esitys - Apps4sust-ohjelman valmistelu 10072013
 
Racket MOOC jakso 7
Racket MOOC jakso 7Racket MOOC jakso 7
Racket MOOC jakso 7
 

More from Hannu Linturi

XAMK: Delphi prosessin neljä vaihetta 2018
XAMK: Delphi prosessin neljä vaihetta 2018XAMK: Delphi prosessin neljä vaihetta 2018
XAMK: Delphi prosessin neljä vaihetta 2018Hannu Linturi
 
eDelphi-prosessi neljässä vaiheessa
eDelphi-prosessi neljässä vaiheessaeDelphi-prosessi neljässä vaiheessa
eDelphi-prosessi neljässä vaiheessaHannu Linturi
 
DARE 2030 - oppimisen tulevaisuusksissa
DARE 2030 - oppimisen tulevaisuusksissaDARE 2030 - oppimisen tulevaisuusksissa
DARE 2030 - oppimisen tulevaisuusksissaHannu Linturi
 
TVA: teesi, paneeli ja manageri
TVA:  teesi, paneeli ja manageriTVA:  teesi, paneeli ja manageri
TVA: teesi, paneeli ja manageriHannu Linturi
 
TVA: teesi, paneeli ja manageri
TVA:  teesi, paneeli ja manageriTVA:  teesi, paneeli ja manageri
TVA: teesi, paneeli ja manageriHannu Linturi
 
TVA: Oppimisen tulevaisuus 2030-case
TVA:  Oppimisen tulevaisuus 2030-caseTVA:  Oppimisen tulevaisuus 2030-case
TVA: Oppimisen tulevaisuus 2030-caseHannu Linturi
 
TVA: Oppimisen tulevaisuus 2030-case
TVA:  Oppimisen tulevaisuus 2030-caseTVA:  Oppimisen tulevaisuus 2030-case
TVA: Oppimisen tulevaisuus 2030-caseHannu Linturi
 
TVA: oppimisen tulevaisuuksissa-opintojakso
TVA: oppimisen tulevaisuuksissa-opintojaksoTVA: oppimisen tulevaisuuksissa-opintojakso
TVA: oppimisen tulevaisuuksissa-opintojaksoHannu Linturi
 
TVA: oppimisen tulevaisuuksissa-opintojakso
TVA:  oppimisen tulevaisuuksissa-opintojaksoTVA:  oppimisen tulevaisuuksissa-opintojakso
TVA: oppimisen tulevaisuuksissa-opintojaksoHannu Linturi
 

More from Hannu Linturi (20)

Delfoi-pedagogiikka
Delfoi-pedagogiikkaDelfoi-pedagogiikka
Delfoi-pedagogiikka
 
Delfoi-pedagogiikka
Delfoi-pedagogiikkaDelfoi-pedagogiikka
Delfoi-pedagogiikka
 
XAMK: Delphi prosessin neljä vaihetta 2018
XAMK: Delphi prosessin neljä vaihetta 2018XAMK: Delphi prosessin neljä vaihetta 2018
XAMK: Delphi prosessin neljä vaihetta 2018
 
eDelphi-prosessi neljässä vaiheessa
eDelphi-prosessi neljässä vaiheessaeDelphi-prosessi neljässä vaiheessa
eDelphi-prosessi neljässä vaiheessa
 
OEF-skenaariot 2035
OEF-skenaariot 2035OEF-skenaariot 2035
OEF-skenaariot 2035
 
DARE 2030 - oppimisen tulevaisuusksissa
DARE 2030 - oppimisen tulevaisuusksissaDARE 2030 - oppimisen tulevaisuusksissa
DARE 2030 - oppimisen tulevaisuusksissa
 
TVA-paja 24.03.2017
TVA-paja 24.03.2017TVA-paja 24.03.2017
TVA-paja 24.03.2017
 
TVA-paja 24.03.2017
TVA-paja 24.03.2017TVA-paja 24.03.2017
TVA-paja 24.03.2017
 
TVA: eDelphi 2017
TVA: eDelphi 2017TVA: eDelphi 2017
TVA: eDelphi 2017
 
TVA: eDelphi 2017
TVA: eDelphi 2017TVA: eDelphi 2017
TVA: eDelphi 2017
 
TVA: teesi, paneeli ja manageri
TVA:  teesi, paneeli ja manageriTVA:  teesi, paneeli ja manageri
TVA: teesi, paneeli ja manageri
 
TVA: teesi, paneeli ja manageri
TVA:  teesi, paneeli ja manageriTVA:  teesi, paneeli ja manageri
TVA: teesi, paneeli ja manageri
 
TVA: Oppimisen tulevaisuus 2030-case
TVA:  Oppimisen tulevaisuus 2030-caseTVA:  Oppimisen tulevaisuus 2030-case
TVA: Oppimisen tulevaisuus 2030-case
 
TVA: Oppimisen tulevaisuus 2030-case
TVA:  Oppimisen tulevaisuus 2030-caseTVA:  Oppimisen tulevaisuus 2030-case
TVA: Oppimisen tulevaisuus 2030-case
 
TVA: Dynamo-case
TVA: Dynamo-caseTVA: Dynamo-case
TVA: Dynamo-case
 
TVA: Dynamo-case
TVA:  Dynamo-caseTVA:  Dynamo-case
TVA: Dynamo-case
 
TVA: oppimisen tulevaisuuksissa-opintojakso
TVA: oppimisen tulevaisuuksissa-opintojaksoTVA: oppimisen tulevaisuuksissa-opintojakso
TVA: oppimisen tulevaisuuksissa-opintojakso
 
TVA: oppimisen tulevaisuuksissa-opintojakso
TVA:  oppimisen tulevaisuuksissa-opintojaksoTVA:  oppimisen tulevaisuuksissa-opintojakso
TVA: oppimisen tulevaisuuksissa-opintojakso
 
Humak 2017
Humak 2017Humak 2017
Humak 2017
 
Xamk 2017-avaus
Xamk 2017-avausXamk 2017-avaus
Xamk 2017-avaus
 

Scrum delfoi

  • 1.
  • 2. Scrum on projektinhallinnan viitekehys, jota käytetään yleisesti ketterässä ohjelmistokehityksessä. Vaikka Scrum on kehitetty erityisesti ohjelmistoprojektien hallintaan, sitä voidaan soveltaa myös yleisesti projektinhallinnassa. Ensimmäisinä idean Scrumin kehitysprosessista kuvasivat 1986 Hirotaka Takeuchi ja Ikujiro Nonaka. Teoksessaan Takeuchi ja Nonaka kuvaavat uudenlaisen, holistisen lähestymistavan tuotekehitykseen, jossa yksi ainoa monitaitoinen (engl. cross-functional) ryhmä suorittaa kehitysprosessin alusta loppuun vaiheistuksella, joka on vahvasti lomittunut. Ryhmän toimintaa verrataan rugby-joukkueeseen, jossa koko ryhmä pyrkii etenemään yksikkönä ja toimimaan tiiviissä yhteistyössä. Myös menetelmän nimi (engl. scrum) viittaa rugbyn aloitusryhmitykseen. Nimi on myös sittemmin jäänyt käyttöön johtuen menetelmän yhtäläisyyksistä rugby-joukkueeseen ja sen toimintaan; molemmat ovat erilaisiin tilanteisiin sopeutuvaisia, nopeita ja itseohjautuvia. Scrum: projektinhallinta
  • 3. Scrum: työskentelytapa Scrumissa työskennellään toistavasti ja lisäävästi (engl. iterative-incremental) ennustettavuuden optimoimiseksi ja riskien kontrolloimiseksi. Tavoitteena oleva tuote kehittyy pikkuhiljaa täydellisemmäksi ja valmiimmaksi useiden kehitysjaksojen aikana. Kehitysjaksoa kutsutaan sprintiksi (engl. Sprint). Sprintti on 1-4 viikon mittainen aikaraja, jonka sisällä tuotetaan “valmiin” määritelmän täyttävä, käyttökelpoinen ja potentiaalisesti julkaisukelpoinen tuoteversio. Jokaisen sprintin sisältö sovitaan sprintin suunnittelupalaverissa ennen sprintin aloitusta, ja toteutettaviksi valitaan sellaisia tuotteen kehitysjonon kohtia, joilla on sillä hetkellä suurin merkitys projektin onnistumiselle. Sprintin lopuksi järjestetään sprinttikatselmus, jossa kehitystiimi esittelee sprintin konkreettiset saavutukset (esim. ohjelmiston uusimman version) tuoteomistajalle sekä mahdollisille sidosryhmien edustajille palautteen saamiseksi ja ymmärryksen lisäämiseksi kehityksen tilasta. Ennen seuraavan sprintin aloittamista pidetään vielä sprintin retrospektiivi, jossa tarkastellaan prosessin näkökulmasta mikä sprintin aikana sujui hyvin ja mitä voitaisiin parantaa seuraavassa sprintissä.
  • 4. Scrum: roolit 1 Scrum-kehityksessä käytetään yhtä tai useampaa scrumtiimiä (engl. scrum team). Scrumtiimi koostuu tuoteomistajasta, scrummasterista ja kehitystiimistä. Scrumtiimi päättää kunkin sprintin tavoitteet ja tehtävät, ja vastaa yhdessä siitä, että asetettuihin tavoitteisiin päästään. Scrumtiimi on itseohjautuva ja monitaitoinen, ja sillä on valta päättää omista työmenetelmistään. Yksi scrumtiimin jäsen toimii tuoteomistajana (engl. product owner). Tuoteomistaja vastaa tuotteen arvon ja kehitystiimin työn arvon maksimoimisesta. Käytännössä tämä tapahtuu määrittelemällä tuotteen vaatimukset sekä järjestämällä tuotteen kehitysjono yhteistyössä scrumtiimin kanssa. Tuoteomistaja on yksi henkilö, ei komitea. Tuoteomistaja voi hyödyntää komiteoita tai edustaa sellaisen toiveita tuotteen kehitysjonon kautta. Tuoteomistaja tuntee tuotteen liiketoimintaa ja edustaa asiakkaita ja käyttäjiä. Tuoteomistaja varmistaa, että scrumtiimi toteuttaa jokaisessa sprintissä sellaisia vaatimuksia, jotka ovat tuotteen onnistumisen kannalta keskeisimpiä. Tuoteomistaja hyväksyy sprinttikatselmuksessa edellisen sprintin tuoteversion ja osallistuu sprintin suunnittelupalaveriin varmistaakseen, että kehitystiimi ymmärtää sprinttiin valittavat tuotteen kehitysjonon kohdat riittävällä tarkkuudella. Tuoteomistaja myös auttaa kehitystiimiä ymmärtämään vaatimuksia ja tarvittaessa tarkentaa sprinttiin valittujen vaatimusten toteutustapaa sprintin aikana.
  • 5. Scrum: roolit 2 Toinen scrumtiimin rooleista on kehitystiimi (engl. development team). Kehitystiimi koostuu ammattilaisista, jotka muuttavat sprinttiin valitun tuotteen kehitysjonon sisällön potentiaalisesti julkaisukelpoikseksi “valmiiksi” tuoteversioksi jokaisessa sprintissä. Ainoastaan kehitystiimin jäsenet osallistuvat tuoteversion kehitykseen. Kehitystiimit ovat monitaitoisia sisältäen kaiken tarvittavan osaamisen potentiaalisesti julkaisukelpoisen tuoteversion kehittämiseksi. Kehitystiimin jäsenillä voi olla erityistä osaamista tai erilaisia työn painopisteitä, mutta vastuu kehityksestä kuuluu koko kehitystiimille yhdessä. Kolmas scrumtiimin rooli on scrummaster (engl. scrum master). Scrummaster vastaa siitä, että kaikki ymmärtävät ja käyttävät Scrumia. Scrummasterit tekevät tämän varmistamalla, että scrumtiimit pitäytyvät Scrumin teoriassa, käytännöissä ja säännöissä. Scrummaster on scrumtiimin palveleva johtaja. Toisin kuin perinteisellä esimiehellä, scrummasterilla ei ole scrumtiimin jäseniin suoraa määräysvaltaa, vaan hän vaikuttaa scrumtiimiin Scrum- prosessin kautta. Scrummasterin tehtävät koostuvat suurelta osin ryhmän työskentelyä haittaavien esteiden poistamisesta ja ryhmän valmentamisesta itseohjautuvuuteen. Scrummaster tarkkailee työn etenemistä, ja jos sprintin tavoitteiden saavuttaminen alkaa näyttää epätodennäköiseltä, hän kommunikoi kehitystiimin ja tuoteomistajan kanssa tilanteen korjaamiseksi tai sprintin sisällön kaventamiseksi. Scrummaster myös suojaa tiimiä ulkopuoliselta hälyltä, kuten sprintin aikana pyydetyiltä uusilta vaatimuksilta, ja tekee kaikkensa turvatakseen tiimilleen työrauhan.
  • 6. Scrum: tuotokset • Tuotteen kehitysjono (engl. product backlog) on järjestetty lista kaikesta, mitä tuotteessa saatetaan tarvita, sekä ainoa lähde tuotteeseen toteutettaville vaatimuksille ja muutoksille. Tuoteomistaja vastaa tuotteen kehitysjonosta mukaan lukien sen sisältö, saatavuus ja järjestäminen. Tuotteen kehitysjono ei ole koskaan valmis, vaan se kehittyy, kun tuote sekä ympäristö kehittyy. Julkaisusuunnitelmaksi kutsutaan kehitysjonoa, joka sisältää kaikki tuotteen kehitysjonosta seuraavaan julkaisuun valitut kohdat (engl.product backlog Item) sekä alustavasti suunnitellun määrän sprinttejä julkaisun toteuttamiseen. • Sprintin tehtävälista (engl. sprint backlog) koostuu sprintin suunnittelupalaverissa valituista tuotteen kehitysjonon kohdista sekä suunnitelmasta niiden toteuttamiseksi. Sprintin tehtävälista on kehitystiimin antama ennuste siitä, mitä toiminnallisuutta seuraavaan tuoteversioon tulee sisältymään sekä tarvittavista tehtävistä toiminnallisuuden toteuttamiseksi. Sprintin tehtävälista määrittää ja tekee näkyväksi kaiken työn, jonka kehitystiimi kokee tarpeelliseksi kehittääkseen tuotteen kehitysjonon kohdat “valmiiksi” tuoteversioksi ja saavuttaakseen sprintin tavoitteen. Tuoteomistaja ei voi sprintin aikana vaihtaa kehitysjonon kohtia toisiin. Kehitystiimi voi sen sijaan milloin tahansa muuttaa, lisätä tai poistaa sprintin tehtäviä varmistaakseen, että sprintin tavoite ja valitut tuotteen kehitysjonon kohdat toteutuvat. • Edistymiskäyrä (engl. burndown chart) kuvaa tuotteen tai sprintin jäljelläolevaa työmäärää. • Tuoteversio (engl. increment) on summa kaikista tuotteen kehitysjonon kohdista, jotka ovat valmistuneet sprintin ja aiempien sprinttien aikana. Sprintin lopussa siinä valmistuneen tuoteversion tulee olla “valmis”, joka tarkoittaa, että se täyttää scrumtiimin “valmiin” määritelmän ja on käyttökelpoisessa kunnossa, riippumatta siitä, päättääkö tuoteomistaja julkaista sen.
  • 7. Scrum: tapahtumat 1 Scrumissa käytetään ennaltasovittuja tapahtumia luomaan säännöllisyyttä ja minimoimaan muiden kuin Scrum-palavereiden tarve. Scrumin tapahtumat ovat aikarajattuja eli jokaisella niistä on maksimipituus. Tämä varmistaa sen, että suunnittelulle varataan riittävästi aikaa, mutta suunnitteluprosessissa ei pääse syntymään hukkaa. • Sprintti (engl. sprint) on scrumin ydin, enintään kuukauden pituinen tai sitä lyhyempi aikaraja, jonka sisällä tuotetaan “valmiin” määritelmän täyttävä, käyttökelpoinen ja potentiaalisesti julkaisukelpoinen tuoteversio. Sprinteillä on sama pituus koko kehityksen ajan. Uusi sprintti alkaa välittömästi edellisen päätyttyä. • Sprintin suunnittelupalaveri (engl. sprint planning meeting) on palaveri, jossa suunnitellaan sprintin aikana tehtävä työ. Tämä suunnitelma luodaan yhteistyössä koko scrumtiimin kesken. Sprintin suunnittelupalaverin pituus rajataan enintään kahdeksaan tuntiin kuukauden mittaiselle sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa. Esimerkiksi kahden viikon sprintille varataan enintään neljä tuntia. • Päiväpalaveri (engl.daily scrum) on enintään 15 minuutin mittainen aikarajattu palaveri, jossa kehitystiimi tahdistaa keskinäiset työnsä ja luo suunnitelman seuraaville 24 tunnille. Tämä tapahtuu tarkastelemalla edellisen päiväpalaverin jälkeen tehtyä työtä ja ennustamalla, mitä voidaan toteuttaa ennen seuraavaa päiväpalaveria. Päiväpalaverissa jokainen kehitystiimin jäsen kertoo vuorollaan 1) Mitä olen tehnyt viime päiväpalaverin jälkeen, 2) Mitä aion tehdä ennen seuraavaa päiväpalaveria, ja 3) Onko työni etenemisellä esteitä. Päiväpalaveri ei ole raportointia, vaan kehitystiimin oma tapaaminen, jonka tarkoitus on optimoida työpäivän arvo ja todennäköisyys sille, että kehitystiimi pääsee sprintin tavoitteeseen. Mikäli keskustelua halutaan jatkaa 15 minuutin jälkeen, on tarkoituksenmukaista sopia erillinen palaveri, vaikka välittömästi päiväpalaverin jälkeen.
  • 8. Scrum: tapahtumat 2 • Tuotteen kehitysjonon työstö (engl. product backlog grooming) tarkoittaa yksityiskohtien, työmääräarvioiden ja kehitysjonon kohtien keskinäisen järjestyksen lisäämistä. Kyseessä on toistuva prosessi, jossa tuoteomistaja ja kehitystiimi lisäävät yhteistyössä yksityiskohtia tuotteen kehitysjonoon. Työstön aikana tuotteen kehitysjonon kohtia katselmoidaan ja arvioidaan. Niitä voidaan kuitenkin päivittää milloin tahansa muulloinkin tuoteomistajan toimesta tai toiveesta. Työstöön käytetään yleensä enintään 10% kehitystiimin kapasiteetista. Kehitystiimi vastaa kaikista työmääräarvioista. Tuoteomistaja voi vaikuttaa kehitystiimiin auttamalla sitä ymmärtämään vaatimuksia ja tekemään kompromisseja. • Sprinttikatselmus (engl. sprint review) on sprintin lopussa pidettävä epämuodollinen palaveri, jossa tarkastellaan kehitetty tuoteversio ja sopeutetaan tarvittaessa tuotteen kehitysjonoa. Sprinttikatselmuksen aikana scrumtiimi ja sidosryhmät selvittävät yhteistyössä, mitä sprintissä kehitettiin. Perustuen tähän tietoon ja mahdollisiin sprintin aikana tuotteen kehitysjonoon tehtyihin muutoksiin osallistujat keskustelevat siitä, mitä voitaisiin kehittää seuraavaksi. Kehitystiimin esittämän tuotedemon tavoitteena on saada palautetta, edistää keskustelua ja luoda realistinen pohja seuraavan sprintin suunnittelupalaverille. Sprinttikatselmus rajataan enintään neljään tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa. • Sprintin retrospektiivi (engl. sprint retrospective) antaa scrumtiimille tilaisuuden tarkastella työskentelyään ja tehdä suunnitelman kehitysprosessin parannuksille, jotka toteutetaan seuraavassa sprintissä. Sprintin retrospektiivi pidetään sprinttikatselmuksen jälkeen ja ennen seuraavan sprintin suunnittelupalaveria. Palaveri rajataan enintään kolmeen tuntiin kuukauden sprintille. Lyhyemmille sprinteille varataan suhteessa vähemmän aikaa.
  • 9.
  • 10.
  • 11. ROOLI HALUAISIN ETTÄ TOIVE KOSKA PERUSTELU OHJAAJANA HALUAISIN ETTÄ VOISIN LISÄTÄ OPISKELIJAN SUORAAN KURSSILLE KOSKA NÄIN VOISIN OHJATA OPISKELIJAA
  • 12. MA TI KE TO PE KÄYNNISTYS DAILY STAND-UP DAILY STAND-UP DAILY STAND-UP DAILY STAND-UP GROOMING PLANNING POKER TIIMI, RETRO JA DEMO MA TI KE TO PE DAILY STAND-UPDAILY STAND-UP