En introduksjon til Scrum <ditt navn> <dato>

En introduksjon til Scrum Presentert av <deg> <dato>

Vi taper stafetten Hirotaka Takeuchi og Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, januar 1986. “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.” would be nice to include a quote from Wicked Problems here

Scrum på 100 ord Scrum er en smidig prosess som lar oss fokusere på å levere høyest mulig forretningsverdi på kortest mulig tid. Scrum lar oss raskt og regelmessig inspisere fungerende programvare (i perioder fra to til fire uker). Bedriften setter prioritetene. Teamene organiserer seg selv for å finne den beste måten å levere den høyest prioriterte funksjonaliteten. I hver periode fra to til fire uker – en sprint – kan alle se fungerende programvare, og avgjøre om det kan slippes eller om man skal fortsette å utvikle det i en sprint til.

Scrums opprinnelse Jeff Sutherland Ken Schwaber Mike Beedle Innledende scrum på Easel Corp i 1993 IDX og 500+ folk bruker Scrum Ken Schwaber ADM Presenterte Scrum på OOPSLA 96 med Sutherland Forfatter av tre bøker om Scrum Mike Beedle Scrum-mønstre i PLOPD4 Ken Schwaber og Mike Cohn Stiftet Scrum Alliance i 2002, opprinnelig innenfor Agile Alliance

Scrum har blitt brukt av: Microsoft Yahoo Google Electronic Arts Lockheed Martin Philips Siemens Nokia IBM Capital One BBC Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

Scrum har blitt brukt til: Kommersiell programvare Intern utvikling Kontraktsutvikling Prosjekter med avtalt pris Finansielle applikasjoner ISO 9001-sertifiserte applikasjoner Innebygde systemer 24x7 systemer med krav til 99.999% oppetid Joint Strike Fighter Dataspillutvikling FDA-godkjente, livskritiske systemer Kontrollsystemer for satellitter Websider Programvare for håndholdte enheter Mobiltelefoner Nettverksapplikasjoner Applikasjoner fra uavhengige programvareleverandør Noen av de største applikasjonene i bruk

Kjennetegn Selvorganiserende team Produktene utvikles i “sprinter” (perioder på to til fire uker) Krav blir presentert som punkter på en liste (product backlog) Ingen spesifikke tekniske arbeidsmåter blir foreskrevet Bruker produktive regler for å skape et smidig miljø for å levere prosjekter Én av de ”smidige prosessene”

The Agile Manifesto – et sett med verdier Prosesser og verktøy Personer og samspill fremfor Omfattende dokumentasjon Programvare som virker fremfor Kontraktsforhandlinger Samarbeid med kunden fremfor Å følge en plan Å reagere på endringer fremfor Kilde: www.agilemanifesto.org

Et prosjekts støynivå Anarki Kompleks Krav Vanskelig Enkelt Teknologi Langt unna avtale Anarki Kompleks Krav Vanskelig Kilde: Strategic Management and Organizational Dynamics av Ralph Stacey i Agile Software Development with Scrum av Ken Schwaber og Mike Beedle. Enkelt Nær avtale Teknologi Nær sikker Langt unna sikker

Scrum 24 timer Sprint 2-4 uker Return Sprint-mål Potensielt leverbart produktinkrement Sprint backlog Return Cancel Gift wrap Coupons Cancel Gift wrap Coupons Product backlog

Alt sett i sammenheng Bilde tilgjengelig på www.mountaingoatsoftware.com/scrum

Sprintene Scrum-prosjekter utvikles i en serie av sprinter Tilsvarende iterasjoner i Extreme Programming Typisk varighet er to til fire uker, eller maks én kalendermåned En fast varighet fører til bedre rytme Produktet designes, kodes og testes i løpet av sprinten

Sekvensiell kontra overlappende utvikling Krav Design Kode Test I stedet for å gjøre en ting om gangen... ...gjør Scrum-team litt av alt hele tiden Kilde: “The New New Product Development Game” av Takeuchi og Nonaka. Harvard Business Review, januar 1986.

Ingen endringer i løpet av en sprint Planlegg varigheten på en sprint i forhold til hvor lenge du kan binde deg til å ikke gjøre endringer i en sprint

Scrum-rammeverket Roller Seremonier Artefakter Produkteier ScrumMaster Teamet Roller Sprint-planlegging Sprint-gjennomgang Sprint-retrospekt Daglige scrum-møter Seremonier Product backlog Sprint backlog Burndown-diagram Artefakter

Scrum-rammeverket Roller Seremonier Artefakter Produkteier ScrumMaster Teamet Roller Sprint-planlegging Sprint-gjennomgang Sprint-retrospekt Daglige scrum-møter Seremonier Artefakter Product backlog Sprint backlog Burndown-diagram

Produkteier Definerer produktets funksjonalitet Avgjør sperrefrist og innhold Er ansvarlig for produktets lønnsomhet (ROI) Prioriterer funksjonalitet i forhold til markedsverdi Justerer funksjonalitet og prioritet ved hver iterasjon, etter behov Aksepterer eller forkaster arbeidsresultater

ScrumMaster Representerer ledelsen ovenfor prosjektet Ansvarlig for å opprettholde Scrum-verdier og -metoder Fjerner hindringer Passer på at teamet er funksjonelt og produktivt Muliggjør tett samarbeid mellom rollene og funksjonene Skjermer teamet fra eksterne inngrep

Teamet Normalt 5-9 personer Tverrfunksjonelt: Utviklere, testere, interaksjonsdesignere osv. Medlemmene bør være på heltid Kan være unntak (f.eks. databaseadministrator) Teamene er selvorganiserende Ingen titler er ideelt, men sjelden en mulighet Teamsammensetning bør kun endres mellom sprinter

Scrum-rammeverket Roller Seremonier Artefakter Produkteier ScrumMaster Teamet Roller Sprint-planlegging Sprint-gjennomgang Sprint-retrospekt Daglige scrummøter Seremonier Product backlog Sprint backlog Burndown-diagram Artefakter

Sprint-mål Sprint backlog Sprint-planleggingsmøte Sprint-prioritering Teamets kapasitet Sprint-prioritering Analysere og evaluere produkt backlog Velge sprint-mål Sprint-mål Produkt backlog Forretnings- betingelser Sprint-planlegging Bestem hvordan sprint-målet kan nås (design) Lag sprint backlog (oppgaver) fra punkter i product backlog (user stories / funksjonalitet) Estimere sprint backlog i timer Gjeldende produkt Sprint backlog Teknologi

Sprint-planlegging Teamet velger punkter fra product backlog de kan binde seg til å fullføre En sprint backlog blir opprettet Oppgavene blir identifisert og hver av dem blir estimert (1-16 timer) Gjøres i fellesskap, ikke av ScrumMaster alene Design på et overordnet nivå blir vurdert Som en ferieplanlegger vil jeg se bilder av hotellet. Kode forretningslogikklaget (8 timer) Kode brukergrensesnittet (4) Skriv testklasser (4) Kode foo-klassen (6) Oppdatere ytelsestester (4)

Daglig scrum-møte Parametre Ikke for problemløsing 15-minutter Stående Ikke for problemløsing Hele verden er invitert Bare teammedlemmer, ScrumMaster og produkteier kan prate Hjelper til å unngå andre unødvendige møter

Alle svarer på 3 spørsmål Hva gjorde du i går? 1 Hva skal du gjøre i dag? 2 Hindrer noe deg i arbeidet? 3 Det er ikke statusrapportering til ScrumMaster Det er forpliktelser ovenfor kolleger

Sprint-gjennomgang Teamet presenterer det som ble utført i sprinten Gjøres ofte som en demo av ny funksjonalitet eller underliggende arkitektur Uformelt 2 timer forberedelsestid Ingen PowerPoint-sider Hele teamet deltar Inviter hele verden

Sprint-retrospekt Regelmessig vurdering av hva som fungerer og ikke fungerer Typisk 15 - 30 minutter Gjøres etter hver sprint Hele teamet deltar ScrumMaster Produkteier Teamet Eventuelt kunder og andre

Begynne / Slutte / Fortsette Hele teamet møtes og diskuterer hva de vil: Begynne å gjøre Slutte å gjøre Dette er kun én av mange måter å gjøre sprint-retrospekt på. Fortsette å gjøre

Scrum-rammeverket Roller Seremonier Artefakter Produkteier ScrumMaster Teamet Roller Sprint-planlegging Sprint-gjennomgang Sprint-retrospekt Daglige scrummøter Seremonier Product backlog Sprint backlog Burndown-diagram Artefakter

Dette er product backlog Krav En liste over alt ønsket arbeid i prosjektet Beskrevet slik at hvert punkt har verdi for produktets brukere eller kunder Prioriteres av produkteier Reprioriteres før hver sprint Dette er product backlog

Product backlog-eksempel Punkter Estimat La en gjest lage en reservasjon 3 Som en gjest vil jeg kansellere en reservasjon 5 Som en gjest vil jeg forandre datoen på en reservasjon Som en hotellansatt vil jeg kjøre en omsetningsrapprt (inntekt-per-tilgjengelig-rom) 8 Forbedre feilhåndtering ... 30 50

Sprint-målet En kort beskrivelse over hva som har fokus i denne sprinten Biovitenskap Støtte nødvendig funksjonalitet for genetiske studier. Databaseapplikasjonen Applikasjonen skal kjøre på SQL Server i tillegg til Oracle. Finansielle tjenester Støtte flere tekniske indikatorer enn ABC med sanntidsdata.

Håndtere sprint backlog Personer tar på seg arbeid etter eget ønske Arbeid er aldri avtalt/utpekt Estimert gjenstående arbeid oppdateres daglig Ethvert teammedlem kan legge til, fjerne eller endre oppgaver i sprint backlog Nye oppgaver vil oppdages underveis i sprinten Hvis arbeidet er uklart kan man definere en oppgave i sprint backlog med et høyere estimat og dele det opp senere Oppdater gjenstående arbeid etterhvert som man vet mer

En sprint backlog Oppgaver Man Tirs Ons Tors Fre Kode brukergrensesnitt Legg til feilregistrering 8 10 16 8 16 12 4 12 16 8 4 11 8 8 Kode mellomlaget Teste mellomlaget Skriv online-hjelp Skriv foo-klassen

Et sprint burndown-diagram Timer

Oppgaver Man Tirs Ons Tors Fre 8 4 12 16 8 10 16 7 11 8 16 8 12 Kode brukergrensesnitt 8 4 12 16 8 10 16 7 11 8 Kode mellomlaget 16 Teste mellomlaget 8 Skriv online-hjelp 12 50 40 30 Timer 20 10 Man Tirs Ons Tors Fre

Skalerbarhet Normalt 7 ± 2 personer per team Faktorer i skalering Skalerbarhet gjennom team av team Faktorer i skalering Applikasjonstype Teamets størrelse Teamets spredning Prosjektets varighet Scrum har blitt brukt på flere prosjekter med 500+ deltakere

Skalering gjennom Scrum of scrums

Scrum of scrums of scrums

Hvor kan man finne ut mer www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com

Litteratur om Scrum Agile and Iterative Development: A Manager’s Guide av Craig Larman Agile Estimating and Planning av Mike Cohn Agile Project Management with Scrum av Ken Schwaber Agile Retrospectives av Esther Derby og Diana Larsen Agile Software Development Ecosystems av Jim Highsmith Agile Software Development with Scrum av Ken Schwaber og Mike Beedle Scrum and The Enterprise av Ken Schwaber User Stories Applied for Agile Software Development av Mike Cohn Det finnes mange ukentlige artikler på www.scrumalliance.org

Lisensvilkår Du har lov til: På følgende vilkår: å dele - å kopiere, distribuere og spre verket å remikse - å bearbeide verket På følgende vilkår: Navngivelse - Du skal navngi opphavspersonen og/eller lisensgiveren på den måte som disse angir (men ikke på en måte som indikerer at disse har godkjent eller anbefaler din bruk av verket) Ingenting i lisensen skader eller begrenser opphavsmannens ideelle rettigheter For mer informasjon, se http://creativecommons.org/licenses/by/3.0/

Presentation by: Mike Cohn Kontaktinformasjon Presentation by: Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110 You can remove this (or any slide) but you must credit the source somewhere in your presentation. Use the logo and company name (as at bottom left, for example) or include a slide somewhere saying that portions (or all) of your presentation are from this source. Thanks.