2. Innhold
• Scrum oversikt
• Produkteier/Produktbacklog/User stories
• Sprintplanlegging og estimering
• Sprint/Progresjon
➔ Dere utfører en Scrum simulering
• Litt mer om scrum
➔ Diskutere Scrum-utfordringer hos dere
5. Scrum bakgrunn
• Toyota (lean production)
– Arbeidere følte seg produktive 80% av tida vs
20% hos amerikanske bilprodusenter
• Kjerneverdier (agile manifesto)
1. Individer og interaksjon >> prosesser & verktøy
2. Fungerende produkter >> omfattende
dokumentasjon.
3. Kundesamarbeid >> kontraktsforhandling
4. Respondere til endring >> følge en (fastlagt)
plan
9. Rolle: Produkteier
• PO er en Bruker-Proxy
– Utviklingsleder
– Salgsfolk
– Domene eksperter
– Marketing group
– Tidligere brukere
– Kunden selv (bestiller)
– Support/kursholdere
– Biz/system Analyst
Anbefaling ➔ velg en med reell inflytelse
11. Product Backlog ~ En (levende) plan
• Visdomsord om planer å ha i mente
– Planlegging er alt. Planer er ingenting.
– Ingen plan overlever kontakt med fienden
• Feltmarskalk Helmuth G. Von Moltke (Preussian,
18xy)
• Om programvareprosjekter
– Feature-creep – 64% av egenskaper inkludert i
produkter er aldri/sjelden brukt (2002)
– Overskridelser – gjennomsnittlige prosjekter
overskrider tidsbruken med 100% (dobling!)
12. Problemer med planlegging – 1/2
1. Planlegginer på aktivitetsnivå istedet for
levert egenskap
2. Aktiviteter slutter ikke tidlig (Parkinsons lov)
3. Treghet smitter nedover planen (asymmetri)
4. Aktiviteter er ikke uavhengige
5. Multitasking fører til forsinkelser
1. Produktivitet faller fra 80% til 40% ved 5 tasks
6. Egenskaper ikke utviklet i prioritert
rekkefølge
1. ”alt er viktig” syndromet
13. Problemer med planlegging – 2/2
7. Estimater blir tolket som forpliktelser
– Er i praksis tupler av (estimat,
sannsynlighet)
14. Product Backlog (PB)
En User Story per rad, og i hver kolonne:
• Beskrivelse
• Kostnad (kompleksitet)
• Verdi
• Avhengigheter (helst ikke)
15. User Stories for PB
Ønskede egenskaper:
1. Uavhengige
2. Forhandlbare
3. Verdifulle for bruker eller produkteier
4. Estimerbare
5. Små
6. Testbare
7. Koplet til en brukerrolle
16. Hvordan få inn user stories?
• Intervjue brukere
• Spørreskjema til brukere
– Indirekte spørring ved eksperimentering
• Observere brukere
– Automatisk innhenting
• Workshops/spikes
17. Akseptansetesting av user stories
• PO skriver krav (på baksiden av user story)
• Test-Drevet Utvikling
• Automatisk:
– FIT/FitNesse
– Selenium (web)
18. Estimering av user stories
• Produkteiermøte
• Hvem er med
• Type estimering (poker planning) og
håndtering av ”uteliggere”
• Estimering i tid eller story points
• Skalaer
• Nedbryting av stories
21. Sprint planlegging
• Beregn hvor mange ressurser man har
tilgj.
• (evt. Historisk velocity)
• Ulike praksiser:
– Man velger tasks etterhvert
– Man pre-committer til tasks
22. User Story ➔ Sprint oppgaver
Hvorfor bryte ned User Stories?
1. Parallelisering av utvikling av en story
– F.eks. for utviklere med ulik spesialitet
2. Får fram ikke-selvfølgelige oppgaver
– En endring kan kreve endringer andre steder
(f.eks. i installasjonsprogram)
3. Får koplet story til tidlig arkitektur
24. Daglig sprint-møte
• Hva har du gjort siden forrige møte?
• Hva skal du gjøre til neste gang?
• Har du noen problemer?
• Oppdatere Scrumboard (på rundgang)
25. Progresjonsmåling/varsling – 1
• Burndown – mest vanlig
– Hvor mye av StoryPoints får
man gjort
– Skal gå nedover
• Burnup – mindre vanlig
– Akkumulert estimert
• Hvilken kurve? Psykologi
☺
28. ➔ Sprint Simulering
• 60 minutter, simulere 6-dagers sprint
• Product Backlog – implementere
algoritmer:
– Søk i tabell
– Sortering av tabell
– Innsetting og søk i binært tre
– Innsetting og finne korteste vei i en graf
• Form team
30. Scrum – Dataflyt
• Typisk arbeidsflyt
– Product backlog i regneark
– Sprint backlog på whiteboard (og oppdatering i
regneark)
– Kode i versjonskontroll
– Tester kjøres på å cont.build boks
– Systemet kjøres i produksjon
• ”Perfekt” arbeidsflyt
– Alt integrert, kopling mellom kode og user stories
➔ produkteier mer integrert del av team og mulighet
til mer læring (har alle data samlet for analyse)
31. Problemer med User Stories
• For små
• Avhengighet mellom de
• Sukkerpåstrøing
• For mange detaljer
• UI-detaljer for tidlig
• For lang tidshorisont
• For mye splitting av
stories
• Kunden har problemer
med prioritere
• Kunden vil ikke (forplikte)
seg til å skrive og
prioritere historien
33. Scrum ting å tenke på..
• Skalering – flere team
– Meta-scrum, avhengigheter
• Automatisering
– Deployment
– Live eksperimentering
• Versjonskontroll-type og code review gjør
stor forskjell
– Google-erfaring