Transcript scrum

Scrum
Commitment (sitoutuminen)
Focus (keskittyminen)
Openness (läpinäkyvyys)
Respect (kunnioitus)
Courage (Rohkeus)
Menetelmälliset periaatteet
• Tuotoksena iteraation jälkeen
julkaisukelpoinen ohjelma
• Pieninä palasina (inkrementaalinen)
• Kierros kierrokselta parempi (iteroiva)
• Tiivis kommunikaatio ja yhteistyö eri
toimijoiden välillä
Scrumin vaiheet
Definion of done
Valmiin määritelmä
Product Backlog
Tuotteen kehitysjono
Refining (työstö)
Vision
Visio
Sprint Burndown Chart Capacity
sprintin edistymiskäyrä Kapasiteetti
Sprint Planning
Sprintin suunnittelu
Sprint Goal
Sprintin tavoite
Daily Scrum
Päiväpalaveri
Sprint Backlog
Sprintin tehtävälista
Sprint Review
Sprinttikatselmus
Sprint Retrospective
Sprintin retrospektiivi
Päivä
Sprint (esim.2…4 vkoa)
Increment
Tuoteversio
Scrum Team (= PO+SM+DT ) Scrumtiimi
Chicken
Product Owner
Tuoteomistaja
Scrum Master
Scrummaster
Development Team
Kehitystiimi
Lopetus
• Scrum Team, scrumtiimi
Roolit
– Development Team +Scrum Master+ Product Owner
• Development Team, kehitystiimi
– Toteuttaa itsellisesti valitsemansa tehtävät
•
•
•
•
Itseorganisoituva ja itseohjautuva
Ihannekoko 7+-2 henkilöä
Yhteinen vastuu yksilönä, tiimin etu edelle
”omistaa” Sprint Backlogin
• Scrum Master
– Hallitsee Scrum-prosessin
•
•
•
•
Puuttuu ajoissa esteisiin ja poistaa ne (24 h)
Suojaa kehitystiimiläisiä ulkopuolisilta häiriöiltä
Dokumetoi Scrum-prosessia
Ei varsinaista määräysvaltaa kehitystiimiläisiin
• Product Owner, tuoteomistaja
– hallitsee tuotteen ja tuottavuuden (liiketoimintanäkökulman)
•
•
•
•
Asiakkaan nimeämä ja edustaja
Vastuussa projektin markkina-arvosta
”omistaa” Product Backlogin
Päättää viimekädessä sprinttien ja projektin kohtalosta
Scrum-tapahtumat
• Sprint Planning Meeting, Sprintin suunnittelu
– Team, Scrum Master ja Product Owner tapaavat uusien
User Storyjen työn alle ottamiseksi
• Daily Scrum, Päivän Scrum
– Team ja Scrum Master tapaavat työn esteiden
poistamiseksi
• Sprint Review, Sprintin katselmointi
– Team esittelee valmiit tuotokset Product Ownerille, joka
antaa palautetta tuotoksesta
– Tarkistetaan, että Product backlog on ok
• Retrospective, Retrospektiivi
– Scrum Team kehittelee prosessia (ja tuotetta?)
•
Sprint Planning Meeting, Sprintin
suunnittelupalaveri
OSA 1
–
–
–
–
–
(Product Backlog tarkistetaan, kuuluisi kai Review-tapahtumaan)
Product Owner esittelee päivitetyn Product Backlogin
Sovitaan Sprintin päämäärä (Sprint Goal)
Kehitystiimi päättää seuraavan sprintin kapasiteettinsa nopeuteensa (Velocity) perustuen
Valitaan seuraavan Sprintin toteutukset Product Backlogin Items (User Stories, Features, Epics)
• valintakriteerinä Product Ownerin määrittämä järjestys (Order) (liiketoiminnallinen arvo ja riskitaso)
• kehitystiimi tekee varsinaisen valinnan
– Suunnittelukokouksen alkuosaan osallistuvat ainakin Product Owner, Scrum Master ja
kehitystiimi. Kanat eli esimerkiksi asiakas ja asiantuntijat (mm. nörttipomo) saavat osallistua.
•
OSA 2
– Pilkotaan tuotteen kehitysjonosta (Product Backlog) valitut käyttäjätarinat ym. sopiviksi
sprintin tehtävälistan tehtäviksi (Task of Sprint Backlog).
•
•
–
–
–
–
Pilkkoessaan tuotteen kehitysjonon kohtia (PBL Items) SBL-Taskeiksi, pitää ottaa huomioon Scrumtiimin (PO+SM+DT) määrittelemä
”Valmiin” käsite. Usein ohjelmistokehityksessä, käyttäjätarinan valmiiksi saattamiseen tarvitaan useita vaihejakomallin vaiheita,
esimerkki julkaisukelpoisesta toimituserän tehtävistä.
Jokainen sprintin tehtävälistan kohdan tulisi pystyä tekemään saman työpäivän (työrupeama) aikana (yksilö/pari/ryhmätyönä).
Kehitystiimi miettii menetelmät
Kehitystiimi pisteyttää (0, ½, 1,2,3,5,8,13,ääretön,?,kahvikuppi) Items (Taskit) ns. Scrum Plan Poker-pelillä
Kehitystiimi sitoutuu toteuttamaan näin muodostuneen Sprint Backlogin ja se ”lukitaan”
Suunnittelukokouksen loppuosaan osallistuu ainakin Scrum Master ja Team. Product Owner
tavoitettavissa
Suunnittelukokouksella on Time-Box eli ennalta sovittu aikaraja, usein max. 2h/Sprint-viikko
Daily Scrum, päivän scrum
• Tavoitteena
– Kehitystiimiläisten keskinäinen tietoisuus Sprintin tilasta ja
työskentelyn synkronointi
– Työn teon esteiden kertominen
• Max. 15 min. yleensä seisten Scrum Master kysyy
tiimiläisiltä
•
•
•
Mitä olet tehnyt edellisen Daily Scrum -kokouksen jälkeen?
Mitä aiot tehdä seuraavaan Scrum-kokoukseen mennessä?
Mikä on hankaloittanut työtäsi?
• Scrum Master tekee pikapäätöksiä esteiden poistamiseksi
• Sovitaan tarvittavat tapaamiset (työkokoukset)
• Muut kuin kehitystiimiläiset ja Scrum Master saavat olla
kanoina mukana.
Sprint Review, sprintin katselmointi
• Esitellään Product Ownerille, asiakkaalle/sidosryhmille työn
tulokset
– Kaikki halukkaat saavat osallistua
•
•
•
•
•
•
•
Vastataan yleisön kysymyksiin
Keskittyy tuotteeseen
Pyritään helpottamaan toimituserän käyttöönottoa
Katselmoidaan vain valmiit tuotteen osat
Kerrotaan Sprint Backlogin valmiusaste (mitkä kesken, mikä %)
Mietitään jatkotoimenpiteet
Tehdään pohjatyö seuraavalle sprintille
• Product Backlogin päivitystarve (erityisesti kanojen näkökulmasta,
jotka nyt saavat poikkeuksellisesti puhua ;-)
• Arvioidaan tuotteen seuraava julkaisuaika
Retrospective, Retrospektiivi
• Analysoidaan ja kehitetään erityisesti prosessia
– Ks. muistiinpanot
• Sprintin edistymiskäyrän (Sprint Burndown
Chart) analyysi
-
Tarkennettu nopeus (Velocity) eli montako pistettä tiimi
pystyi tekemään
– Seuraavan sprintin nopeus (montako pistettä tiimi tekee)
• Product Backlogin päivittäminen (tiimin näkökulma)
– Mm. palautetaan kesken jääneet tehtävät jäljellä olevine
pisteineen uudeksi kohdaksi tuotteen kehitysjonoon” (ellei
tätä jo tehty sprintin katselmoinnissa)
• Mukana Team, Scrum Master ja Product Owner
Artifacts (tuotokset)
• Scrum-dokumentit
• Elävät koko ajan, ei varsinaista historointia
• Tuotteen kehitysjono (Product Backlog)
– User Story –kortit/rivit
• (Julkaisun tehtävälista (Release Backlog))
• Sprintin tehtävälista (Sprint Backlog)
• Edistymiskäyrät (Burndown Chart)
– Jäljellä olevat käyttäjätarinat/tehtävät
– Esim. Product Burndown, Release Burndown Chart,
Sprint Burndown Chart
User Story, käyttäjätarina
• "Käyttäjänä haluan toiminnallisuuden xxx,
koska saavutamme sillä hyödyn zzz."
”As a [role], I want to [goal], so I can [reason].”
• Vastaa kysymyksiin Kuka haluaa mitä ja miksi
tämä asia on tärkeä.
• Usein kirjoitetaan 150x100 kokoiselle kortille
– Id, tarina, kirjoittaja, pvm, (tarinapisteet)
• Käyttäjätarinat kootaan Product Backlogiin
jatkojalostusta varten
Product Backlog, Tuotteen kehitysjono
• Backlog on tuotteen sen hetkinen priorisoitu (järjestetty)
”vaatimuslista” monimutkaisuuspisteineen
• ”Vaatimukset” eli Product Backlogin kohdat (Items) voivat olla
–
–
–
–
tuotteen ominaisuuksia (feature)
käyttäjätarinoita (user story)
-teemoja (themes)
Epiikkeja (epic) eli suuria epämääräisiä toiveita , jotka protoiltava
toteutuskelpoisiksi
• Ylläpidetään paljon sprintin ulkopuolella/rinnalla, päivitetään
(Grooming) koko ajan
• 10% sprintin ajasta menee kehitysjonon ylläpitoon
• Ennen Sprintin suunnittelukokousta PO priorisoi (järjestää)
kehitysjoon
• Product Owner (PO) omistaa Product backlogin
Sprint Backlog, Tehtävälista, esimerkkejä
US#
Sija
Tehtävä
Pisteet
Tila
Tekijät
US1
1
UI
2
Done
TJ, RR
API
3
Ongoing
RR
US2
2
DB
8
data
3
Ongoing
User story
Työn alla pt
Val
mis
# Prior.
tehtävänimi
suunnitelt
u
jäljellä
US1
5
UI
2
1
API
3
0
x
DB
1
0
x
TJ
…
US2
3
…
ict2tn007 – by Anne Valsta
Sprint Backlogin rivit ova
Tehtäviä (Task). Tehtävät ovat
Pilkottuja osia Product
backlogin kohdista (Item)
28.8.2010
Vähennä tehtäviä
Pyydä lisää PO:lta
käyttäjätarinoita
•
•
Excel-tauluna (2
erilaista)
Seinätauluna (mukana
edistymiskäyrä)
13
Task
Tehtäväkortti, esimerkki
(mukaellen Anne Valsta)
User story _________
Sprintti _____
Tehtävä
Pisteet__________
______________________________________________
______________________________________________
Menetelmät ____________________________________
________________________________________
________________________________________
Huomaa _______________________________________
________________________________________
Tekijä ______________
Valmis _____________ Toteutunut työmäärä ______h
28.8.2010
ict2tn007 - Anne Valsta
14
Burndown Chart
edistymiskäyrä
Julkaisun edistymiskäyrä
velocity
20pt/sprint
sum_pt
106pt
sprints
6
sprint
est(pt) real(pt)
0
velocity
kokemuksesta edellisistä sprinteistä
sum/release
valittujen käyttäjätarinoiden tarinapisteet yhteensä
roundup(sum_pt/velocity)
capasity
106
106
120
1
86
95
100
2
66
64
3
46
45
4
26
28
5
6
80
60
est(pt)
6
40
real(pt)
-14
20
0
-20
1
2
3
4
5
6
7
Kehitystiimin nopeus (Velocity)
• Product Backlogista kehitystiimi valitsee
seuraavaan sprinttiin suurin piirtein saman
tarinapistemäärän kuin ehtivät tehdä
edellisessä sprintissä.
• Tulevan sprintin kapasiteettia laskettaessa
otetaan huomioon scrumtiimin mahdolliset
sitoutumisen vaihtelut (lomat, tiimiläisten
muut työt, atk-ongelmat jne.)
• Tätä pistemäärää per sprintti kutsutaan
kehitystiimin nopeudeksi (engl. velocity)
tarinapistettä per sprintti.
(0. Sprint)
• Ns. pikasprintti, jossa ”harjoitellaan”
• Pikasprintin avulla saadaan myös tietoa
kehitystiimin nopeudesta (Velocity)
Aloita!
• luo visio (jokainen kirjoittaa oman visionsa tuotteesta,
pareittain jne)-> visio jätetään luokan seinälle
• kirjoita käyttäjätarinat -> PB seinälle tai Exceliin
• priorisoi käyttäjätarinat markkina-arvon ja riskitason
mukaan
• määritä tarinan koko (pisteytä)
• täydennä/uudelleenjärjestä PB:tä
• luo tarvittaessa RB (julkaisun kehitysjono)
• suunnittele sprintin SB (alussa ehkä nollasprintti ja
lyhyitä sprinttejä seinätauluna)
• aloita sprintti
LIITE. Vaihejakomalli
liittyy Scrum-käsitteeseen Definition-of-Done)
(Ns. vesiputousmalli)
Esitutkimus, nykytilanteen kartoitus,
projektin tarve, kannattavuusvertailut,
korvaavat kehitysehdotukset
Määrittely ja kuvaus
toiminnan kuvaus
tietosisältö
rajapinnat(käyttäjät)
vaatimukset toiminnalle
Arkkitehtuuri
infrastruktuuri
tietovarastot
Tietoliikenne
suojaukset, varmistukset
Tekninen suunnittelu
määrittelyn tarkennus
ohjelmiston suunnittelu
Tekninen toteutus
hankinnat
ohjelmointi
dokumentointi
Testaus
Koulutus
Käyttöönotto kertarysäyksellä
Ylläpito
Poisto
Diaan: Sprintin suunnittelu