Prosesser i Scrum

Sprintplanlegging

Sprintplanlegging er den innledende fasen i Scrum-sprinten. Det bestemmer omfanget og måtene å utføre arbeid på under sprinten. Hele Scrum-teamet er involvert i planleggingen.

En sprint er en klart definert tidsperiode der et spesifisert stykke arbeid må fullføres. En sprint trenger planlegging før den starter. Først av alt må du bestemme varigheten og målet for sprinten.

På planverkstedet avtales oppgavelisten og målet for sprinten. Det er viktig å lade teamet med riktig motivasjon til å jobbe, slik at hvert medlem er fokusert på suksess.

Hvis spurten er dårlig planlagt, kan dette føre til at laget mislykkes. Utviklere vil ikke være i stand til å takle forventningene som er stilt til dem, fordi oppgavene viste seg å være urealistiske.

Spørsmål å vurdere når du planlegger en sprint:

• Kunden eller programvareeieren kunngjør målet med sprinten, underveis og forklarer hvordan man oppnår det. Scrum-teamet finner ut hvilke oppgaver som kan fullføres i en fremtidig sprint for å nå dette målet.
• Utviklere distribuerer en arbeidsplan seg imellom, som avtales med programvarekunden.
• Kunden (eieren) av produktet er alltid med på å lage sprintplanen. Han setter seg et mål, og programmeringsteamet må finne ut om det kan oppnås i en sprint.
• Planen bør bruke en produktbacklog, informasjon som kan legges til planen.
• Teammedlemmer bør avslutte planleggingsmøtet med en klar forståelse av hva de trenger for å oppnå resultatet. Du kan vise rekkefølgen på fremtidige handlinger i sprintbacklog.

Planlegging bør ikke overstige to timer per uke. Scrum Master må forklare alle at det er tidsbegrensninger. Hvis alle arbeidsproblemer løses raskt, kan møtet avsluttes tidligere enn vanlig. Det er ingen minimumsvarighet for et slikt møte.

Oppgavevurdering

Å vurdere kompleksiteten til arbeidet trenger ikke å overdrive det. Planprosessen trenger ikke en eksakt, men i det minste en omtrentlig vurdering av kompleksiteten i utbyggingen. Laget må ikke bare forstå målet med sprinten, men også sammenligne målet med lagets evner.

For å vurdere kompleksiteten kan du bruke de vanlige klesstørrelsene for alle (L, XL, XXL). Dette gir selvsagt ingen garanti for nøyaktighet, men likevel.

For at vurderingen av kompleksitet skal bli mer nøyaktig, er det nødvendig med gjensidig forståelse. Teammedlemmer bør åpent dele sine meninger og ikke være redde for å stille spørsmål til produktets eier.

Kritikk mot laget etter at arbeidet er avsluttet kan føre til at ved planlegging av neste sprint vil prognosene være mindre optimistiske. Dette vil hjelpe teamet til å unngå å gjenta feilen og beskytte det mot å bli negativt vurdert i fremtiden.

Evaluering av vanskelighetsgrad i poeng, poeng og timer

Vanligvis estimerer utviklingsteam kompleksiteten til arbeidet deres over tid. Men noen smidige lag velger å rangere vanskelighetsgrad i poeng eller poeng. Dette er en bedre indikasjon på den totale kostnaden som kreves for å implementere en ordrepost eller annen tildelt oppgave.

Poeng tildeles basert på kompleksiteten og volumet av arbeidet. I tillegg tas mulig risiko i betraktning. Scoring ved hjelp av denne metoden bidrar til å effektivt bryte ned arbeidet i små trinn.

Ved jevnlig å bruke skåringsmetoden (poeng) når de planlegger, har teamene en bedre og mer nøyaktig forståelse av hvor mye tid de vil trenge for å fullføre arbeidet. I tillegg er det andre fordeler også.

• Tidsestimatet tar ikke hensyn til arbeid som ikke er direkte relatert til prosjektet, selv om det sikkert vil dukke opp. Å diskutere arbeidsspørsmål gjennom en messenger, holde møter – alt dette tar også tid for teammedlemmene.
• Følelser kan påvirke valg av datoer. Scoring ved evaluering av arbeid eliminerer denne faktoren.
• Vurderingen av kompleksiteten til arbeidet og følgelig hastigheten på å fullføre oppgaver kan være forskjellig for hvert av lagene. Arbeid med poeng kan ikke betraktes som noen indikator på hastighet. Det vil si at det ikke er noe psykisk press på laget.
• Ved riktig fordeling av arbeidskostnader og kompleksitet kan du raskt og uten konflikt dele punkter for utført arbeid mellom deltakerne.
• Antall poeng for å fullføre en oppgave avhenger av dens kompleksitet, og ikke av tidsbruken. Derfor vil programmerere tenke på å forbedre effektiviteten, og ikke på hvor lang tid det vil ta.

Ulempen med kompleksitetsestimering er at den ofte misbrukes. Denne metoden kan for eksempel ikke brukes til å evaluere ansatte.

Lag bør bruke et poengsystem for å bedre forstå mengden arbeid som er tildelt dem og prioritere riktig.

Daglig Scrum-møte

Workshops er viktige: på dem deler teammedlemmene sine meninger, kommuniserer og blir enige om videre handlinger. Daglige scrum-møter er også nødvendig for å heve lagånden og kunngjøre aktuelle nyheter.

Stand-up er et kort møte med nøkkelprosjektdeltakerne: programvareeieren, programmerere og scrum master. Strukturen til stand-upen består av tre spørsmål.

• Hva klarte vi i går?
• Hva jobber vi med i dag?
• Hva hindrer oss i å oppnå resultater?

Å stille disse spørsmålene stimulerer utvikling og hjelper til med å identifisere problemer i teamet. Når hver deltaker kommuniserer hvordan han/hun bidrar til å nå et felles mål, forbedrer dette den gjensidige forståelsen i teamet.

Det er viktig å huske at det ikke finnes en enkelt mal for hvordan man skal gjennomføre stand-ups. Hvert team holder møter etter sin egen modell, basert på egenskapene til teamet.

Og la oss nå diskutere hva som skal til for den perfekte stand-up og bli kjent med eksempler på effektive stand-ups.

Først må du velge et tidspunkt som passer alle. Vanligvis holdes stand-ups for team fra samme kontor i begynnelsen av arbeidsdagen – mellom 9 og 10 om morgenen. Dette gir deg tid til bedre å planlegge timeplanen for dagen. Hvis teammedlemmer jobber i ulike regioner, velges en tid som passer alle. For eksempel, hvis noen teammedlemmer bor i California og Sydney, starter stand-up klokken 15:30 California-tid. Stand-up etter middag er selvsagt ikke praktisk for alle, men det gjør det mulig å holde kontakten med kolleger på den andre siden av havet.

Hold oversikt over stående produktivitet. Ikke hold møtet for lenge - konsentrasjonen av oppmerksomhet skal forbli på sitt beste. Hvis mulig, hold stand-ups ikke lenger enn 15 minutter.

Bruk ballen. Det kan kastes til hverandre etter tur. Så alle vil være med i diskusjonen. Dette spillet er med på å holde oppmerksomheten i gruppen. Bruk team retrospektivt. Stand-ups brukes i mange Agile-metodikker, dette hindrer oss ikke i å diskutere effektiviteten til stand-ups ved retrospektiver. Noen møtes hver dag, andre lag – et par ganger i uken. Hvis det er vanskelig for laget å dra nytte av stand-up, finn årsakene til dette og endre noe.

Sprint anmeldelse

Vårgjennomgang gjennomføres i sluttfasen av sprinten. Det er nødvendig å sjekke produkttilveksten og skreddersy etterslepet. Hele scrum-teamet og alle interessenter deltar i gjennomgangen av sprintresultatene. Møtet holdes i et avslappet format for å forbedre samhandlingen mellom prosjektdeltakerne.

Sprintresultatgjennomgangen inkluderer følgende elementer:

• Programvareeieren viser hva fra etterslepet som er fullført og hva som ikke er det.
• Programmererne diskuterer hva som gikk bra, hvor vanskelighetene dukket opp og hvordan de ble eliminert.
• Utviklingsteamet viser resultatene av arbeidet deres under sprinten, og hvilken produkttilvekst de mottok.
• Produkteieren deler sine tanker om den nåværende etterslepet. Den gir også en prognose for neste mål og fristen for implementeringen.
• Alle diskuterer hva som er best å gjøre videre basert på markedsvurdering og brukerinteresser.
• Det er en utveksling av synspunkter om tidspunkt, budsjett og utsikter for å øke etterslepet.

Resultatet er en oppdatert etterslep med nye mål for påfølgende spurter. Etterslepet kan endres dersom situasjonen tilsier det.

Sprint retrospektiv

Sprint Retrospective er en workshop som diskuterer hvordan du kan forbedre arbeidsflyten din. Det lager også en forbedringsplan for neste sprint. Møtet finner vanligvis sted etter sprintgjennomgangen og tar ikke mer enn tre timer. Leder for møtet er Scrum Master.

Hovedmålene for Sprint Retrospective inkluderer:

• Sprintanalyse (arbeid av deltakere, resultater og problemer).
• Diskuter mulige løsninger for å forbedre arbeidsflyten i påfølgende spurter.
• Oppretting av en plan for implementering av forbedringer av teammedlemmer under gjennomføringen av prosjektet.

Scrum Master inviterer teammedlemmer til å komme med forslag til hvordan man kan forbedre utviklingseffektiviteten. Teamet diskuterer forslagene og foreslår visse måter og teknikker for implementering av dem.

På slutten av Sprint Retrospective bør teamet fremheve noen forbedringsforslag som skal implementeres i neste sprint. Forslag kan implementeres når som helst, men Sprint Retrospective gir en mulighet til å se dypere på deres mulige tilpasning fra teamets synspunkt.

Det er her vi avslutter vår diskusjon om Scrum-metodikken. Du kan lære mer om det i temadokumentasjonen eller på din første arbeidsplass.