En introduksjon til Scrum

Mountain Goat Software, LLC

En introduksjontil Scrum

<ditt navn><dato>


<deg><dato>

Presentert av

En introduksjon til Scrum


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.”


•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.

Scrum på 100 ord


Scrums opprinnelse• Jeff Sutherland• Innledende scrum på Easel Corp i

1993

• IDX og 500+ folk bruker Scrum

• Ken Schwaber• ADM

• Presenterte Scrum på OOPSLA 95 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

Prosesser og verktøy

Personer og samspill

Personer og samspill

fremfor

Å følge en planÅ følge en planÅ reagere på endringer

Å reagere på endringer

fremfor

Kilde: www.agilemanifesto.org

Omfattende dokumentasjonOmfattende

dokumentasjonProgramvare som

virkerProgramvare som

virkerfremfor

Kontraktsforhandlinger

Kontraktsforhandlinger

Samarbeid med kunden

Samarbeid med kunden

fremfor


Et prosjekts støynivå

Enkelt

KompleksAnarki

Vanskelig

Teknologi

Krav

Langt unna avtale

Nær avtale

Nær

sikker

Langt unna

sikker

Kilde: Strategic Management and Organizational Dynamics av Ralph Stacey i Agile Software Development with Scrum av Ken Schwaber og Mike Beedle.


Scrum

Cancel

Gift wrap

Return

Sprint2-4 uker

Return

Sprint-mål

Sprint backlog

Potensielt leverbartproduktinkrement

Productbacklog

CouponsGift wrap

Coupons

Cancel

24 timer


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

Kilde: “The New New Product Development Game” av Takeuchi og Nonaka. Harvard Business Review, januar 1986.

I stedet for å gjøre en ting om gangen... ...gjør Scrum-team

litt av alt hele tiden

Krav Design Kode Test


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

Endringer


Scrum-rammeverket•Produkteier•ScrumMaster•Teamet

Roller

•Sprint-planlegging•Sprint-gjennomgang•Sprint-retrospekt•Daglige scrum-møter

Seremonier

•Product backlog•Sprint backlog•Burndown-diagram

Artefakter


Scrum-rammeverket

•Sprint-planlegging•Sprint-gjennomgang•Sprint-retrospekt•Daglige scrum-møter

Seremonier


Artefakter

•Produkteier•ScrumMaster•Teamet

Roller


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



RollerScrum-rammeverket


Artefakter

•Sprint-planlegging•Sprint-gjennomgang•Sprint-retrospekt•Daglige scrummøter

Seremonier


Sprint-planleggingsmøte

Sprint-prioritering• Analysere og evaluere produkt backlog

• Velge sprint-mål

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

Sprint-mål

Sprint-mål

Sprintbacklo

g

Sprintbacklo

g

Forretnings-

betingelser

Forretnings-

betingelser

Teamets kapasite

t

Teamets kapasite

t

Produkt backlogProdukt backlog

Teknologi

Teknologi

Gjeldende

produkt

Gjeldende

produkt


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.

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• Daglig

• 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

•Det er ikke statusrapportering til ScrumMaster• Det er forpliktelser ovenfor kolleger

Hva gjorde du i går? Hva gjorde du i går?11

Hva skal du gjøre i dag? Hva skal du gjøre i dag?22

Hindrer noe deg i arbeidet? Hindrer noe deg i arbeidet?33


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

Begynne å gjøre

Slutte å gjøre

Slutte å gjøre

Fortsette å gjøre

Fortsette å gjøre

Dette er kun én av mange

måter å gjøre

sprint-retrospekt

på.



RollerScrum-rammeverket

•Sprint-planlegging•Sprint-gjennomgang•Sprint-retrospekt•Daglige scrummøter

Seremonier


Artefakter


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

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

3

Som en hotellansatt vil jeg kjøre en omsetningsrapprt (inntekt-per-tilgjengelig-rom)

8

Forbedre feilhåndtering 8

... 30

... 50


Sprint-målet•En kort beskrivelse over hva som har fokus i denne sprinten

Databaseapplikasjonen

Finansielle tjenester

Biovitenskap

Støtte nødvendig funksjonalitet for genetiske studier.

Støtte flere tekniske indikatorer enn ABC med sanntidsdata.

Applikasjonen skal kjøre på SQL Server i tillegg til Oracle.


• 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

Håndtere sprint backlog


En sprint backlog

OppgaverOppgaverKode brukergrensesnittKode mellomlaget

Teste mellomlagetSkriv online-hjelpSkriv foo-klassen

ManMan8

16

8

12

8

TirsTirs4

12

16

8

OnsOns TorsTors

4

11

8

4

FreFre

8

8Legg til feilregistrering

8

10

16

8

8


Et sprint burndown-diagram

Timer


Timer

40

30

20

10

0Man

Tirs

OnsTors

Fre

OppgaverOppgaverKode brukergrensesnittKode mellomlaget

Teste mellomlaget

Skriv online-hjelp

ManMan8

16

8

12

TirsTirs OnsOns TorsTors FreFre4

12

16

7

11

8

10

16 8

50


Skalerbarhet• Normalt 7 ± 2 personer per team

• 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

•[email protected]


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:• å 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/


KontaktinformasjonPresentation by: Mike Cohnmike@mountaingoatsoftware.

comwww.mountaingoatsoftware.c

om(720) 890-6110

Presentation by: Mike Cohnmike@mountaingoatsoftware.

comwww.mountaingoatsoftware.c

om(720) 890-6110You 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.

Documents

En introduksjon til Scrum