scrum - idatddd82/slides/scrum.pdf · 2020-01-21 · scrum i tddd82 scrum/marcus bendtsen 21 • ni...

SCRUMMarcus Bendtsen Institutionen för datavetenskap

SCRUM/Marcus Bendtsen

Metodik

2

• Systematiskt tillvägagångssätt för att “garantera” utfallet

• Metodiken behöver passa kontexten och tillgängliga resurser

• Verifiering av metodiken genom teoretiska eller praktiska resultat

Software development lifecycle & Waterfall

3

Implementation

Requirements

Design

Verification

Maintenance


Ingen vet vad de vill ha….

4

• Det är väldigt svårt som kund att från första början förklara vad det är man behöver

• När produkten är klar kanske man inser att den borde haft helt andra funktioner

• Det är dyrt och svårt att gå tillbaka och ångra sig gällande funktioner när produkten är klar


En agil metodik

5

• Vi behöver ett tillvägagångssätt, en metodik, som inte kräver att man behöver veta hur slutprodukten ska se ut innan man börjar utveckla

• En agil metodik där vi arbetar iterativt och låter produkten ta form genom att gå fram och tillbaka i software development lifecycle


SCRUM

6

• 1986 - Takeuchi och Nonaka

• 1990 - Schwaber

• 2001 - Schwaber och Beedle - Agile Software Development with Scrum


Roller

7SCRUM/Marcus Bendtsen

Kunder Utvecklare

Product ownerScrum master

Product backlog


• Kunder fyller på product backlog med user stories

• En user story beskriver den förväntande funktionaliteten av en del av programmet

När en användare klickar på “Lägg till” så ska ett formulär visas med de fält som behövs för att skapa ett nytt konto

Sprint backlog


• I början av varje sprint så prioriterar kunden (product owner) alla user stories i product backlog

• Utvecklarna estimerar hur mycket tid som varje user story kräver för att göras klart

• Product owner väljer sedan vilka user stories som utvecklarna ska arbeta på i nästa sprint, och flyttar därmed dessa user stories från product backlog till sprint backlog

Sprint


• Utvecklarna tar sedan de user stories som ligger i sprint backlog och bryter ner till tasks, och anger hur mycket tid som krävs för varje task

• En task är något som måste genomföras för att en user story ska bli klar, de har ofta teknisk karaktär

Skapa ett HTML formulär för att lägga till kontonSkapa en knapp för att öppna formuläret….

SCRUM board


• Alla user stories i sprint backlog och tasks skrivs ner på post-it lappar och sätts upp på en SCRUM board

• Stories, ToDo, In Progress, Testing, Sprint End

SCRUM meeting


• Varje morgon träffas hela teamet och har ett stående 5-10 minuters möte

• SCRUM master frågar tre frågor, som besvaras i tur och ordning av varje team medlem

• Var gjorde du igår? Vad ska du göra idag? Finns det något som hindrar dig?

SCRUM demo


• När sprinten är slut så träffas kunder och utvecklare

• Utvecklare visar vad de har gjort, och demonstrerar produkten

• Kunderna har nu möjlighet att lägga till nya user stories

• Den nya sprinten börjar med samma procedur som tidigare, prioritera, estimera, bryt ner i tasks…

SCRUM övrigt


• Om man får slut med user stories under en sprint så kontaktar man kunden och frågar vilken user story från product backlog de vill att man ska plocka in

• Om man inte hinner klart med en user story så placeras den på product backlog igen, man får diskutera med kunden vad man vill göra med dessa

Tidsestimering - Velocity - Burndown chart

Hur estimerar man tid för user stories och tasks?


• Inte enkelt, men man lär sig med erfarenhet• Bestäm en minsta enhet, t ex 1 timme• Låt varje medlem i gruppen rösta hur många enheter som krävs• Om det finns extrema konflikter, t ex någon säger 1 timme och någon

annan säger 12, så diskutera varför man inte är överens• Om det inte finns allt för stora skillnader i tid så ta ett medelvärde

Hur många timmar ska man planera?


• Varje individ i gruppen som jobbar heltid ger 40 timmar• En grupp med 5 personer har därför 200 timmar att planera per vecka• Om en sprint sträcker sig över 4 veckor har man alltså 800 timmar att planera

• Kan man verkligen utnyttja varenda timme?• Nej, speciellt inte om man par-programmerar• Man måste ha en buffer med tid som går åt till att t ex konfigurera utvecklingsmiljön och ha möten• Velocity = Hur många procent av den totala tiden kommer man kunna planera, en bra utgångspunkt är

75%.

• Därför planerar man 40 * 5 * 4 * 0.75 = 600 timmar den första sprinten, och sedan så justerar man velocity inför nästa sprint.

Burndown chart


0

150

300

450

600

Dag 1 Dag 2 Dag 3 Dag 4 Dag 5 Dag 6 Dag 7

• Dag för dag uppdaterar man hur många timmar det är kvar att genomföra, dvs totala summan av tasks som inte är färdiga

• I slutet av sprinten (i bilden är det bara en vecka) räknar man ut den faktiska velocity och använder i nästa sprint

• 550 / 800 = 68.75% (ny velocity)

SCRUM i TDDD82

SCRUM i TDDD82


• Ni har ingen kund, men SCRUM kan användas ändå

• Ni skriver user stories, ni tidsestimerar och prioriterar och ni väljer vilka user stories som skall finnas med i sprint backlog• Kursledningen kommer ha åsikter och be er att justera dessa vid

demonstrationstillfällena

• Ni demonstrerar för kursledningen och använder s k acceptanstest för att bevisa att en user story är genomförd

SCRUM i TDDD82


• Ni ska spendera 20-25% av er tid till projektet i kursen, t ex:• Sprint 1 : 22%• Sprint 2 : 25%• Sprint 3 : 20%• Sprint 4 : 22%

• Om ni är 8 i gruppen har ni alltså 40 * 8 * 4 * 0.25 = 320 timmar som ni ska planera för sprint 2. Om ni använder 75% velocity så ska ni välja user stories med totalt 240 timmar. (Under Sprint 1 har ni inga user stories).

SCRUM i TDDD82


• Skapa user stories som kombinerar ett icke-funktionellt krav med ett funktionellt krav (se backlog dokument)

• Placera alla user stories under Product Backlog i dokumentet

• När ni planerar en sprint flyttar ni user stories till “planerade”

• När ni demonstrerar en user story flyttar ni den till “genomförda”

www.liu.se

scrum - idatddd82/slides/scrum.pdf · 2020-01-21 · scrum i tddd82 scrum/marcus bendtsen 21 • ni...

Documents