Scrum introduction in Norwegian for Software Engineering

1. Kort Introduksjon til Scrum
Amund Tveit
Høst 2010

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

3. Motivasjon: Scrum gjør deg smartere!
• http://www.psychologicalscience.org/media/releases/2008/smith.cfm
• http://jeffsutherland.com/scrum/2008/05/scrum-makes-you-smarter.html
☺

4. Programvareutvikling
Vannfallsmodell ➔ Scrum
Lange Planer ➔ Korte Iterasjoner

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

6. Scrum Analogy – PID regulator

7. Scrum Prosessen?

8. Scrum har mange nivå av iterasjoner

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

10. Product Backlog

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

19. Sprint Backlog

20. Sprint Planning på vegg

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

23. Daglig Sprint-møte

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
☺

26. Sprint

27. Scrumboard med burndown

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

29. LITT MER OM SCRUM

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

32. Håndtere ikke-funksjonelle Krav
• Ytelse
• Nøyaktighet/presisjon
• Portabilitet
• Gjenbrukbarhet
• Vedlikeholdbarhet
• Interoperabilitet
• Tilgjengelighet
• Brukbarhet
• Sikkerhet
• Kapasitet

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

34. Scrum til hjemmebruk..

35. ➔ Scrum hos dere?
• Diskusjon.