Scrum – for Norsk Navigasjon

Scrum – for Norsk Navigasjon
Amund Tveit Atbrox AS

amund@atbrox.com - http://atbrox.com
Kort om meg Tidligere Google News for iPhone (Scrummaster) Hvite sider på google.no/maps (leder Scrum-team) Sertifisert Scrummaster (av Jeff Sutherland) Sw-erfaring fra forsikring (Storebrand), telecom (IBM) Dr.ing datateknikk (parallell/inkrementell maskinlæring) Nå Scrummaster (innleid deltid til) Trondheimsfirma Gründer (utv. av cloud/søk programvare) © Atbrox AS 2009 -

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 © Atbrox AS 2009 -

Motivasjon: Scrum gjør deg smartere!
 © Atbrox AS 2009 -

Programvareutvikling
Vannfallsmodell  Scrum Lange Planer  Korte Iterasjoner © Atbrox AS 2009 -

Scrum bakgrunn Toyota (lean production) Arbeidere følte seg produktive 80% av tida vs 20% hos amerikanske bilprodusenter Kjerneverdier (agile manifesto) Individer og interaksjon >> prosesser & verktøy Fungerende produkter >> omfattende dokumentasjon. Kundesamarbeid >> kontraktsforhandling Respondere til endring >> følge en (fastlagt) plan © Atbrox AS 2009 -

Scrum Analogy – PID regulator
© Atbrox AS 2009 -

Scrum Prosessen? © Atbrox AS 2009 -

Scrum har mange nivå av iterasjoner
© Atbrox AS 2009 -

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 s 57 – User Stories applied bok © Atbrox AS 2009 -

Product Backlog © Atbrox AS 2009 -

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!) © Atbrox AS 2009 -

Problemer med planlegging – 1/2
Planlegginer på aktivitetsnivå istedet for levert egenskap Aktiviteter slutter ikke tidlig (Parkinsons lov) Treghet smitter nedover planen (asymmetri) Aktiviteter er ikke uavhengige Multitasking fører til forsinkelser Produktivitet faller fra 80% til 40% ved 5 tasks Egenskaper ikke utviklet i prioritert rekkefølge ”alt er viktig” syndromet © Atbrox AS 2009 -

Problemer med planlegging – 2/2
Estimater blir tolket som forpliktelser Er i praksis tupler av (estimat, sannsynlighet) © Atbrox AS 2009 -

Product Backlog (PB) En User Story per rad, og i hver kolonne: Beskrivelse Kostnad (kompleksitet) Verdi Avhengigheter (helst ikke) © Atbrox AS 2009 -

User Stories for PB Ønskede egenskaper: Uavhengige Forhandlbare Verdifulle for bruker eller produkteier Estimerbare Små Testbare Koplet til en brukerrolle ”user stories applied” – kapittel 2 – writing stories Uavhengighet (i størst mulig grad) mindre prioriterings og planleggingsproblematikk Hvis de ikke er uavhengige er de kanskje ikke brutt godt nok ned? Forhandlbare For mye detaljer gir inntrykk av at alle detaljer er løst Detaljene kan fjerne fokus fra overordnet user story mål Verdifull for brukere eller produkteier/bestiller Noen ting er kanskje ikke synlig for bruker (f.eks. Driftssituasjon, sertifisering) Ønsker ikke stories som kun er av verdi for utviklere (f.eks. Klassehierarki/teknologivalg..) Estimerbare Kan skyldes: manglende domene eller teknisk kunnskap (hos utv.) eller at historien er for stor Små Kan skyldes: sammensatte historier (ikke-atomiske) eller komplekse (ikke ferdig-jobbet/diskutert) Testbare For å vite om målet for user storien er oppnådd Bruker-rolle Hvem er historien for? Hvilke typer brukere finnes? Eksemplifiser (kvinne 30 år med høy utdanning) – P4 © Atbrox AS 2009 -

Hvordan få inn user stories?
Intervjue brukere Spørreskjema til brukere Indirekte spørring ved eksperimentering Observere brukere Automatisk innhenting Workshops/spikes © Atbrox AS 2009 -

Akseptansetesting av user stories
PO skriver krav (på baksiden av user story) Test-Drevet Utvikling Automatisk: FIT/FitNesse Selenium (web) FIT = Framework for Integrated Test – spreadsheet with tests.. Kapittel 6 – i user story boka © Atbrox AS 2009 -

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 © Atbrox AS 2009 -

Sprint Backlog © Atbrox AS 2009 -

Sprint Planning på vegg
© Atbrox AS 2009 -

Sprint planlegging Beregn hvor mange ressurser man har tilgj. (evt. Historisk velocity) Ulike praksiser: Man velger tasks etterhvert Man pre-committer til tasks (planning a release – i user story boka til Mike Cohn) © Atbrox AS 2009 -

User Story  Sprint oppgaver
Hvorfor bryte ned User Stories? Parallelisering av utvikling av en story F.eks. for utviklere med ulik spesialitet Får fram ikke-selvfølgelige oppgaver En endring kan kreve endringer andre steder (f.eks. i installasjonsprogram) Får koplet story til tidlig arkitektur S 111 user story boka © Atbrox AS 2009 -

Daglig Sprint-møte © Atbrox AS 2009 -

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) © Atbrox AS 2009 -

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  © Atbrox AS 2009 -

Sprint © Atbrox AS 2009 -

 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 © Atbrox AS 2009 -

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) © Atbrox AS 2009 -

Scrum Verktøy ScrumWorks Symphonical Agilo Kanskje mitt en vakker dag?
Agilo Kanskje mitt en vakker dag?

Potensielle Problem 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 S 157 user story bok Sukkerpåstrøing = unødv. features © Atbrox AS 2009 -

Håndtere ikke-funksjonelle Krav
Ytelse Nøyaktighet/presisjon Portabilitet Gjenbrukbarhet Vedlikeholdbarhet Interoperabilitet Tilgjengelighet Brukbarhet Sikkerhet Kapasitet S177 user story bok Gjør de numeriske/statistiske, f.eks. 80% av søk vil returnere innen mindre enn 2 sekunder. ++ © Atbrox AS 2009 -

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 © Atbrox AS 2009 -

Scrum – for Norsk Navigasjon

Liknende presentasjoner

Presentasjon om: "Scrum – for Norsk Navigasjon"— Utskrift av presentasjonen:

Liknende presentasjoner

Om prosjektet

Tilbakemelding

Logg inn

Logg deg på via sosiale nettverk:

Scrum – for Norsk Navigasjon

Liknende presentasjoner

Presentasjon om: "Scrum – for Norsk Navigasjon"— Utskrift av presentasjonen:

Liknende presentasjoner

Om prosjektet

Tilbakemelding