i denne innledende nivå artikkelen ser vi på mekanikken I En Sprint, og på hvordan gruppemedlemmer forventes å samarbeide for å produsere en utgivelse kvalitet økning.

Den første dagen: Sprintplanlegging

hele teamet, inkludert Produkteieren, møtes På Sprintens første Dag og gjennomfører En Sprintplanleggingsøkt. Dette er det aller første som skal skje så snart Sprinten starter.

Forberedelse

Sprint Planlegging bør være forberedt på. Den viktigste forberedelsen er å sikre At Produktbackloggen har blitt raffinert til et passende detaljnivå, med estimater og akseptkriterier (dette er formålet Med Produktbacklogforbedring). Deretter Burde Produkteieren ha bestilt arbeidet med Produktbackloggen, og ha en generell ide om hvordan man forhandler et verdifullt Sprintmål med teamet. Alternativene for å forhandle Et Mål bør også ha vært vurdert under Forfining, og reflektert i ordrereserve. Teamet bør også ha en ide om deres evne til Denne Sprinten, det vil si hvor mye arbeid de tror de kan ta på seg. De kan kanskje bruke sin erfaring med tidligere Spurter for å hjelpe dem med å fastslå størrelsen på dette budsjettet.

først planlegge verdien som skal leveres

Hver Sprint skal resultere i en verdifull økning av fullført arbeid, passform og klar for umiddelbar utgivelse. Produkteieren er helt ansvarlig for hva «verdi» betyr, og burde ha bestilt Produktbackloggen på en slik måte at verdien kan maksimeres av teamet, sprint-for-sprint. Det første laget må gjøre er derfor å planlegge hvilke varer Fra Produktbackloggen som skal bearbeides i Denne Sprinten, slik at den beste verdien kan leveres innen utgangen av Den.

for å gjøre dette, jobber Teamet med Produkteieren for å velge de mest verdifulle elementene fra Produktbackloggen som passer til deres forventede kapasitet for Sprinten. Husk at hvert element på Produktkøen burde ha fått et estimat av teamet, så de vil vite omtrent hvor mye arbeid som sannsynligvis vil være involvert.

Sørg for å bli enige Om Et Sprintmål

dette utvalget av arbeid skal være sammenhengende, og Ikke bare en gruppering av ikke-relaterte og ulike elementer. Husk At En Sprint er en tidsboksen mulighet til å oppnå noe betydelig. For eksempel, ved Slutten Av Sprinten kan en sammenhengende funksjon ha blitt levert, eller en betydelig risiko vil ha blitt redusert. Sprintmålet er et enkelt uttrykk for dette formålet, av den overordnede betydningen av det valgte arbeidet, og sammenhengen bak utvalget.

et Godt Sprintmål vil tillate teamet å demonstrere fokus og engasjement, og tillate samarbeid og omplanlegging av arbeid slik at det blir oppfylt.

neste plan hvordan arbeidet skal gjøres

En Sprint Backlog er mer enn bare et utvalg av arbeid med et sluttmål i tankene. Det er også en plan for hvordan dette målet skal oppnås, og hvordan det tilhørende arbeidet skal utføres. Dette kan gjøres ved å identifisere og bestille de tekniske oppgavene som sannsynligvis vil være involvert. I praksis Sprint Backlog er en plan for å møte Sprint Mål, og en prognose av arbeidet som må gjøres.

Produkteieren trenger ikke å være til stede for Denne Delen Av Sprintplanleggingen, da det er opp til teamet å planlegge denne prognosen på et teknisk nivå. Imidlertid Bør Produkteieren være tilgjengelig, selv om det bare er eksternt, for å svare på eventuelle spørsmål teamet måtte ha, og for å gi noen avklaring som kan være nødvendig om omfanget av arbeidet. Hvis det forventes mer enn en utgivelse under Sprinten, bør dette avtales MED PO og regnskapsføres I Sprintbacklogen.

ved Slutten Av Sprintplanleggingen bør et lag være trygg på at det har gjort en god prognose for arbeidet som trengs for Å møte Sprintmålet. Det vil ha fanget den planen I Sprint Backlog som laget helt eier. Teamet skal kunne begynne å implementere den planen umiddelbart og med en klar forståelse – for Eksempel En Sprint Nedbrenning – av hvor mye arbeid som gjenstår på et gitt tidspunkt.

Hver dag, hver dag

når laget har planlagt Sin Sprint Backlog de kan starte arbeidet. Hvis de har planlagt ting som oppgaver, vil de samarbeide med hverandre, som et team, for å sikre at disse oppgavene er fullført. De vil være i stand til å spore deres fremgang ved hjelp av deres oppgavetavle og Deres Sprint Burndown av gjenstående arbeid.

hvert teammedlem vil være sikker på å holde Scrum Task Board og Sprint Burndown oppdatert, slik at informasjonen kan stole på av andre. En informasjon radiator bør alltid fortelle sannheten.

Hold En Daglig Scrum

Hver arbeidsdag, Samtidig Vil Utviklingsteamet møte og planlegge hva de skal gjøre for å bringe dem nærmere Sprintmålet. Dette møtet kalles Daily Scrum, og det bør aldri ta mer enn 15 minutter.

bare Utviklingsteammedlemmer bør delta, da arbeidsplanen helt tilhører dem. Det er en tid-boxed mulighet til å re-planlegge Sprint Backlog som følge av nye funn og erfaringer i Løpet Av Sprinten. Hele laget må delta. Hvert lagmedlem bør kunne redegjøre for:

• Hva de gjorde i går for Å hjelpe laget med Å nå Sprintmålet
• Hva de har tenkt å gjøre i dag for å hjelpe laget med Å nå Sprintmålet
• eventuelle hindringer som kommer i veien

ved slutten av Den Daglige Scrum, bør laget ha en klar plan for de neste 24 timene og en forståelse av hvordan de må samarbeide for å oppnå det. De bør også ha en liste over eventuelle hindringer som krever Scrum Master oppmerksomhet.

Avgrens Produktbacklog

I Scrum Er Produktbacklog Raffinement ikke en formell hendelse, men en pågående aktivitet-prosessen med å legge til detaljer, ordre og estimater Til Produktbacklog Elementer som Brukerhistorier. Det er Opp Til Scrum-Lagene selv å bestemme hvor ofte de skal gjøre dette, selv om det absolutt er en god ide for dem å bygge raffinement i sin daglige rutine. Forbedring bør ikke ta mer enn 10% av et lags totale tid under En Sprint. For de fleste lag kan en halv time om dagen være tilstrekkelig, selv om noen kanskje foretrekker å tilbringe en time eller to et par ganger i uken. Viktigste er å sørge For At Produktet Backlog er raffinert på en riktig måte slik At Sprint Planlegging kan skje uten hinder. Hele teamet, Inkludert Produkteieren, bør delta.

en finjusteringsøkt begynner vanligvis med At Produkteieren presenterer den gjeldende Produktkøen for teamet. Etterslepet kan holdes i en rekke former, for eksempel en elektronisk Scrum Board eller andre samarbeidsverktøy, eller det kan bare være et regneark. En projektor eller delt skjerm kan være svært nyttig.

teamet starter på Toppen Av Produktbackloggen og jobber seg nedover, og raffinerer hvert element i sin tur. De vil undersøke hver enkelt og diskutere omfanget, og akseptkriteriene som vil være nødvendige for ferdigstillelse. Hvert element vil da bli estimert ved hjelp Av en teknikk som Planlegging Poker. Et stort element kan brytes ned i mindre som fanger større detaljer. Epos kan brytes ned i brukerhistorier, for eksempel.

teamet stopper når øktens tidsboks løper ut. De vil gjenoppta der de slapp neste gang, til slutt starter på toppen igjen slik at etterslep holdes oppdatert.

samarbeid alltid

i smidig praksis jobber teammedlemmer aldri isolert – hvis de gjorde det, ville de ikke være et lag. Faktisk er teamarbeid så viktig at rollen Er Utviklingsteam i stedet For Utvikler.

dette betyr at Hvert Utviklingsteammedlem må samarbeide med sine jevnaldrende gjennom dagen, da de er felles ansvarlige for arbeidets fremgang. Eventuelle problemer eller feil eies i fellesskap av laget, så vel som deres suksesser. Samarbeid er ikke noe som er begrenset til hendelser Som Daily Scrum, men gjelder for alt laget gjør gjennom Hver Hele Sprint.

eksempler på samarbeid inkluderer:

• Hjelpe kolleger til å fullføre arbeidet som pågår før bringe i nytt arbeid fra en backlog
• Par programmering, slik som å ta det i svinger for å bruke tastaturet og hjelpe og sjekke hverandres arbeid
• Peer review
• Å Be om hjelp, og være opptatt av å gi den
• Gå til der arbeidet er og hjelpe, i stedet for å vente på at arbeidet skal overføres til dem
• Å Sørge for at alt arbeid faktisk oppfyller Definisjonen av ferdig
• kaller En Scrum for å løse problemer som trenger lagets umiddelbare oppmerksomhet
• Oppdatere En Scrum Oppgave bord og burndown diagram slik at informasjonen er up-to-date og kan stole på
• Ferdighet og kunnskapsdeling

den siste dagen: Gjennomgang og Retrospektiv

Hold En Sprint Gjennomgang

Hvis et team Har Samarbeidet Effektivt, de har jobbet sammen for å møte sprintmålet, håndtere eventuelle risikoer Og justere planene Etter Behov. De har vist kontroll gjennom Hele Sprinten gjennom en jevn nedbrenning av gjenværende arbeid, hvor hvert medlem så det som deres personlige ansvar å bidra til å fullføre arbeidet som pågår. De vil ha en verdifull økning for å demonstrere For Produkteieren og eventuelle inviterte interessenter. En Gjennomgang er noe et team bør se frem til.

det er også noe et lag må forberede seg på. Nok tid må være tillatt for en demonstrasjon av arbeidet som er utført. Oppgaver kan planlegges på En Sprint Backlog for dette formålet, for å sikre at Gjennomgangen gjør rettferdighet til arbeidet og verdien som nå er tilgjengelig. Også, hvis Produkteieren mener det ville være en god ide å invitere interessenter, bør disse invitasjonene ha blitt sendt. Gjennomgangen er en mulighet til å feire arbeidet som er gjort og å vise frem sine prestasjoner, så tillit er inspirert og en fortsatt investering i teamet kan være berettiget.

En Sprint Gjennomgang er også en inspisere-og-tilpasse mulighet. Det er en god tid For Produkteieren å forklare hvor godt produktet fungerer, for å få tilbakemelding førstehånds fra alle inviterte parter, og å trekke noen leksjoner som kan brukes til å forbedre Produktetterslepet ytterligere. Hvis noe arbeid ikke er fullført, uansett grunn, vil dette også bli vurdert og re-estimert På Produktbacklog for mulig planlegging i fremtidige sprints.

deretter gjennomføre En Sprint Retrospektiv

Sprint Gjennomgang sett På Produktet og verdien levert, på arbeidet som er gjort, og ærlig og ærlig på noe arbeid som ikke ble gjort, uansett årsak.
Den neste tingen å gjøre er å gjennomføre En Sprint Retrospektiv. En Retrospektiv vurderer prosessen som teamet følger. Jobber de så effektivt som mulig? Det er generelt best å holde Retrospektivet umiddelbart etter Gjennomgangen, fordi den tidligere kan introdusere ideer til vurdering i sistnevnte.

Hele Utviklingsteamet, Produkteieren og Scrum Master må alle delta I Retrospektivet, fordi alle er felles ansvarlige for suksessen til lagets arbeid. Det er veldig viktig å ha en fri og åpen økt som kommer til hjertet av eventuelle problemer og identifiserer handlinger som vil bidra til å løse dem. En Retrospektiv kan begynne med følgende erklæring:»Uansett hva vi oppdager, forstår vi og tror virkelig at alle gjorde den beste jobben de kunne, gitt det de visste på den tiden, deres ferdigheter og evner, ressursene som er tilgjengelige og situasjonen ved hånden.»

i En» Retro», alle har en lik stemme. En tilnærming, Som Scrum Master kan lette, er å identifisere:

• Ting som gikk bra
• Ting som ikke gikk så bra
• Ideer for forbedring
• Shout-outs for teammedlemmer som gjorde noe eksepsjonelt

Etablere en tidslinje Kan hjelpe jogge deltakernes minner om viktige hendelser under Sprinten.