SCRUM Marcus Bendtsen Institutionen för datavetenskap
2 Metodik 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
3 Software development lifecycle & Waterfall Requirements Design Implementation Verification Maintenance
4 Ingen vet vad de vill ha. 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
5 En agil metodik 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
6 SCRUM 1986 - Takeuchi och Nonaka 1990 - Schwaber 2001 - Schwaber och Beedle - Agile Software Development with Scrum
7 Roller Kunder Utvecklare Product owner Scrum master
8
9 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
10 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
11 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 konton Skapa en knapp för att öppna formuläret.
12 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
13 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?
14 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
15 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
17 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
18 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.
19 Burndown chart 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 600 450 300 150 550 / 800 = 68.75% (ny velocity) 0 Dag 1 Dag 2 Dag 3 Dag 4 Dag 5 Dag 6 Dag 7
SCRUM i TDDD82
21 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
22 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. (Sprint 1 är ingen äkta sprint)
23 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