Kort Introduksjon til Scrum

Amund Tveit Høst 2010

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

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

☺

Programvareutvikling

Vannfallsmodell ➔ Scrum

Lange Planer ➔ Korte Iterasjoner

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

Scrum Analogy – PID regulator

Scrum Prosessen?

Scrum har mange nivå av iterasjoner

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

Product Backlog

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!)

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

Problemer med planlegging – 2/2

7. Estimater blir tolket som forpliktelser – Er i praksis tupler av (estimat,

sannsynlighet)

Product Backlog (PB)

En User Story per rad, og i hver kolonne: • Beskrivelse • Kostnad (kompleksitet) • Verdi • Avhengigheter (helst ikke)

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

Hvordan få inn user stories?

• Intervjue brukere • Spørreskjema til brukere – Indirekte spørring ved eksperimentering

• Observere brukere – Automatisk innhenting

• Workshops/spikes

Akseptansetesting av user stories

• PO skriver krav (på baksiden av user story) • Test-Drevet Utvikling • Automatisk: – FIT/FitNesse – Selenium (web)

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

Sprint Backlog

Sprint Planning på vegg

Sprint planlegging

• Beregn hvor mange ressurser man har tilgj.

• (evt. Historisk velocity) • Ulike praksiser: – Man velger tasks etterhvert – Man pre-committer til tasks

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

Daglig Sprint-møte

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)

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 ☺

Sprint

Scrumboard med burndown

➔ 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

LITT MER OM SCRUM

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)

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

Håndtere ikke-funksjonelle Krav

• Ytelse • Nøyaktighet/presisjon • Portabilitet • Gjenbrukbarhet • Vedlikeholdbarhet • Interoperabilitet • Tilgjengelighet

• Brukbarhet • Sikkerhet • Kapasitet

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

Scrum til hjemmebruk..

➔ Scrum hos dere?

• Diskusjon.