Scrum – for Norsk Navigasjon Amund Tveit amund@atbrox.com Atbrox AS

amund@atbrox.com - http://atbrox.com Kort om meg Tidligere Google News for iPhone (Scrummaster) http://googlenewsblog.blogspot.com/2008/05/google-news-now-available-on-your.html 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 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com 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 amund@atbrox.com - http://atbrox.com

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  © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

Programvareutvikling Vannfallsmodell  Scrum Lange Planer  Korte Iterasjoner © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com 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 amund@atbrox.com - http://atbrox.com

Scrum Analogy – PID regulator © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com Scrum Prosessen? © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

Scrum har mange nivå av iterasjoner © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com 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 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com Product Backlog © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

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 amund@atbrox.com - http://atbrox.com

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 amund@atbrox.com - http://atbrox.com

Problemer med planlegging – 2/2 Estimater blir tolket som forpliktelser Er i praksis tupler av (estimat, sannsynlighet) © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

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

amund@atbrox.com - http://atbrox.com 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 amund@atbrox.com - http://atbrox.com

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 amund@atbrox.com - http://atbrox.com

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 amund@atbrox.com - http://atbrox.com

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 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com Sprint Backlog © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

Sprint Planning på vegg © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com 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 amund@atbrox.com - http://atbrox.com

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 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com Daglig Sprint-møte © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com 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 amund@atbrox.com - http://atbrox.com

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 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com Sprint © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

Scrumboard med burndown © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com  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 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com LITT Mer OM SCRUM © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com 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 amund@atbrox.com - http://atbrox.com

Scrum Verktøy ScrumWorks Symphonical Agilo Kanskje mitt en vakker dag? www.symphonical.no 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 amund@atbrox.com - http://atbrox.com

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 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com 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 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com Scrum til hjemmebruk.. © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com  Scrum Bøker Har med et sample bøker © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com  Scrum hos dere? Diskusjon. © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com

amund@atbrox.com - http://atbrox.com Takk for meg! © Atbrox AS 2009 amund@atbrox.com - http://atbrox.com