En introduksjon til Scrum <ditt navn her> <dato>

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

Vi taper stafettløpet Hirotaka Takeuchi og Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review, januar 1986. “‘Stafettløp’-tilnærmingen til produktutvikling…kan sammenstøte med mål som maksimal hastighet og fleksibilitet. En helhetlig eller ‘fotball-lik’ tilnærming, hvor et team prøver å komme i mål som en enhet ved å spille ballen frem og tilbake, kan kanskje tjene dagens konkurrerende krav.” would be nice to include a quote from Wicked Problems here

Scrum på 100 ord Scrum er en smidig prosess som tillater oss å fokusere på å levere høyest mulig forretningsverdi på kortest mulig tid. Scrum tillater oss å hurtig inspisere reell arbeidssoftware gjentatte ganger (annenhver uke eller månedlig). Bedriften setter prioritetene. Teamene organiserer seg selv for å avgjøre den beste metoden for å levere funksjonalitet med høyest prioritet. Annenhver uke eller månedlig kan hvem som helst se reell arbeidssoftware og avgjøre om det kan slippes til markedet som det er 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 Scrum presentert på OOPSLA 96 med Sutherland Forfatter av tre bøker om Scrum Mike Beedle Scrummø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 software Intern utvikling Kontraktsutvikling Prosjekter med avtalt pris Finansielle applikasjoner ISO 9001-sertifiserte applikasjoner Innesluttede systemer 24x7 systemer med krav til 99.999% oppetid Joint Strike Fighter Videospillutvikling FDA-godkjente, livskritiske systemer Kontrollsoftware for satellitter Websider Håndholdt software Mobiltelefoner Nettverksapplikasjoner Uavhengige softwareleverandør- applikasjoner Noen av de største applikasjonene i bruk

Egenskaper Selvorganiserte team Produktutvikling i en serie av månedlige “sprinter” Krav blir spesifisert på en liste som oppgaver som venter på å bli gjort Ingen spesifikke metoder blir beskrevet Bruker regler som fremkaller et smidig miljø for å levere prosjekter Én av flere ”smidige prosesser”

Det Smidige Manifestet – en forklaring av verdier Prosesser og verktøy Personer og interaksjon over Omfattende dokumentasjon Fungerende software over Kontraktsforhandling Kundesamarbeid over Følge en plan Reagere på endring over Kilde: www.agilemanifesto.org

Projekt 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

Potensielt utsendbart Scrum 24 timer Sprint 2-4 uker Return Sprint mål Potensielt utsendbart produkttillegg Sprint backlog Return Cancel Gift wrap Coupons Cancel Gift wrap Coupons Produkt backlog

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

Sprintene Scrumprosjekter gjør fremskritt i en serie av sprinter Tilsvarende iterasjoner i Extreme Programming Typisk varighet er 2-4 uker eller maks én kalendermåned En konstant varighet fører til bedre rytme Produktet er designet, kodet og testet i løpet av sprinten

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

Ingen forandringer i løpet av en sprint Planlegg varigheten på en sprint i forhold til hvor lenge du kan binde deg til å holde forandringer ute av en sprint

Scrum rammeverket Roller Seremonier Produkt Produkteier Scrummaster Teamet Roller Sprint planlegging Sprint gjennomgang Sprint retrospekt Daglige scrummøter Seremonier Produkt backlog Sprint backlog Progresjonsdiagram Produkt

Scrum rammeverket Roller Seremonier Produkt Produkteier Scrummaster Teamet Roller Sprint planlegging Sprint gjennomgang Sprint retrospekt Daglige scrummøter Seremonier Produkt Produkt backlog Sprint backlog Progresjonsdiagram

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

Scrummaster Representerer ledelsen ovenfor prosjektet Ansvarlig for å vedta Scrum verdier og metoder Fjerner hindringer Forsikrer at teamet er funksjonelt og produktivt Muliggjør tett samarbeid mellom rollene og funksjonene Skjermer teamet fra eksterne inngrep

Teamet Typisk 5-9 folk Kryssfunksjonelt: Teamene er selvorganiserende Utviklere, testere, UI designere osv. Medlemmene bør være fulltidsansatte Kan være unntak (f.eks. databaseadministrator) Teamene er selvorganiserende Ingen titler ideelt sett, men sjelden en mulighet Medlemskap burde kun skiftes mellom sprinter

Scrum rammeverket Roller Seremonier Produkt Produkteier Scrummaster Teamet Roller Sprint planlegging Sprint gjennomgang Sprint retrospekt Daglige scrummøter Seremonier Produkt backlog Sprint backlog Progresjonsdiagram Produkt

Sprint mål Sprint backlog Sprint planleggingsmøte Sprint prioritering Teamets kapasitet Sprint prioritering Analysere og evaluere produkt backlog Velge mål for sprinten Sprint mål Produkt backlog Forretnings- betingelser Sprint planlegging Bestem hvordan man kan nå målet i sprinten (design) Lag sprint backlog (gjøremål) ut i fra produkt backlog oppgaver (brukerundersøkelse / funksjonalitet) Estimere sprint backlog i timer Gjeldendeprodukt Sprint backlog Teknologi

Sprint planlegging Teamet velger elementer de kan binde seg til å fullføre fra produkt backlog En sprint backlog blir opprettet Oppgavene blir identifisert og hver av dem blir estimert (1-16 timer) Gjøres sammen, ikke av scrummaster alene Design på et høyt plan blir vurdert Som en ferieplanlegger vil jeg se bilder av hotellet. Kode midtre laget (8 timer) Kode brukergrensesnittet (4) Skriv testplaner (4) Kode foo klassen (6) Oppdatere performance-tester (4)

Daglig scrum Parametre Ikke til problemløsing 15 minutter Standup Ikke til problemløsing Hele verden er invitert Bare teammedlemmer, scrummaster og produkteier kan prate Hjelper til unngå 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 Dette er ikke status for Scrummasteren Det er forpliktelser ovenfor kollegaer

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

Sprint retrospekt Ta en titt på hva som fungerer og hva som ikke fungerer fra tid til annen Typisk 15–30 minutter Gjøres etter hver sprint Hele teamet deltar Scrummaster Produkteier Teamet Muligens kunder og andre

Start / Stopp / Fortsett Hele teamet møtes og diskuterer hva de vil gjøre: Start handling Stopp handling Dette er kun én av mange måter man kan drive sprint retrospekt. Fortsett handling

Scrum rammeverket Roller Seremonier Produkt Produkteier Scrummaster Teamet Roller Sprint planlegging Sprint gjennomgang Sprint retrospekt Daglige scrummøter Seremonier Produkt backlog Sprint backlog Progresjonsdiagram Produkt

Dette er produkt backloggen Kravene En liste over alt arbeid for prosjektet Beskrevet slik at hvert element har verdi for brukerne eller kundene av produktet Prioritert av produkteier Reprioritert før hver sprint Dette er produkt backloggen

Produkt backlog eksempel Backlog element Estimering Tillat en bruker å lage en reservasjon 3 Som en bruker vil jeg kansellere en reservasjon 5 Som en bruker 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

Målet for sprinten En kort beskrivelse over hvilke elementer som har fokus i denne sprinten Biovitenskap Supportere nødvendig funksjonalitet for genetiske studier. Databaseapplikasjonen Applikasjonen skal kjøre på SQL Server i tillegg til Oracle. Finansielle tjenester Supportere flere tekniske indikatorer enn firma XYZ med sanntidsdata.

Håndtere sprint backloggen Personer tar på seg arbeid etter eget ønske Arbeid er aldri avtalt/utpekt Gjenstående arbeid er oppdatert daglig Ethvert teammedlem kan legge til, fjerne eller forandre sprint backloggen Arbeid for sprinten vil oppstå Hvis arbeidet er uklart kan man definere et sprint backlog element med et høyere estimat og dele det opp senere Oppdater gjenstående arbeid etterhvert som man vet mer

En sprint backlog Elementer 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 midtre lag Teste midtre laget Skriv online hjelp Skriv foo klassen

Et sprint progresjonsdiagram Timer

Elementer 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 midtre lag 16 Teste midtre laget 8 Skriv online hjelp 12 50 40 30 Timer 20 10 Man Tirs Ons Tors Fre

Skalerbarhet Et typisk individuelt team består av 7 ± 2 personer Skalerbarhet kommer i form av team av team Faktorer i skalering Applikasjonstype Teamets størrelse Teamets spredning Prosjektets varighet Scrum har blitt brukt på flere prosjekter bestående av 500+ personer

Skalering gjennom Scrum av scrums

Scrum av scrums av scrums

Hvordan gå videre www.mountaingoatsoftware.com/scrum www.scrumalliance.org www.controlchaos.com scrumdevelopment@yahoogroups.com

Scrum leseliste 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

Copyrighterklæring You are free: Under the following conditions to Share―to copy, distribute and transmit the work to Remix―to adapt the work Under the following conditions Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Nothing in this license impairs or restricts the author’s moral rights. 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.