En introduksjon til Scrum

Presentasjon om: "En introduksjon til Scrum"— Utskrift av presentasjonen:

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

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

3 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

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

5 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

6 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

7 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 % 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

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

9 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:

10 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

11 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

12 Alt sett i sammenheng Bilde tilgjengelig på

13 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

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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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)

24 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

25 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

26 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

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

28 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

29 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

30 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

31 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

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

33 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

34 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

35 Et sprint burndown-diagram
Timer

36 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

37 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 deltakere

38 Skalering gjennom Scrum of scrums

39 Scrum of scrums of scrums

40 Hvor kan man finne ut mer

41 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å

42 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

43 Presentation by: Mike Cohn
Kontaktinformasjon Presentation by: Mike Cohn (720) 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.