Processer i Scrum

Sprint planlægning

Sprintplanlægning er den indledende fase i Scrum-sprintet. Det bestemmer omfanget og måderne at udføre arbejdet på under spurten. Hele Scrum-teamet er involveret i planlægningen.

En sprint er en klart defineret periode, hvor et bestemt stykke arbejde skal afsluttes. En sprint skal planlægges, før den starter. Først og fremmest skal du bestemme varigheden og målet for spurten.

På planlægningsværkstedet aftales opgavelisten og målet med sprinten. Det er vigtigt at oplade teamet med den rette motivation til at arbejde, så hvert medlem er fokuseret på succes.

Hvis spurten er dårligt planlagt, så kan dette føre til, at holdet fejler. Udviklere vil ikke være i stand til at klare de forventninger, der stilles til dem, fordi opgaverne viste sig at være urealistiske.

Spørgsmål at overveje, når du planlægger en sprint:

• Kunden eller softwareejeren annoncerer målet for spurten undervejs og forklarer, hvordan man opnår det. Scrum-teamet finder ud af, hvilke opgaver der kan løses i en fremtidig sprint for at nå dette mål.
• Udviklere distribuerer en arbejdsplan imellem sig, som aftales med softwarekunden.
• Kunden (ejeren) af produktet er altid med til at udarbejde sprintplanen. Han sætter sig et mål, og programmeringsholdet skal finde ud af, om det kan nås i en spurt.
• Planen skal bruge en produktbacklog, hvorfra information kan tilføjes til planen.
• Teammedlemmer bør afslutte planlægningsmødet med en klar forståelse af, hvad de skal bruge for at opnå resultatet. Du kan vise rækkefølgen af ​​fremtidige handlinger i sprintbacklog.

Planlægning bør ikke overstige to timer om ugen. Scrum Masteren skal forklare alle, at der er tidsbegrænsninger. Hvis alle arbejdsproblemer løses hurtigt, kan mødet slutte tidligere end normalt. Der er ingen minimumsvarighed for et sådant møde.

Opgaveevaluering

At vurdere kompleksiteten af ​​arbejdet behøver ikke at overdrive det. Planlægningsprocessen behøver ikke en nøjagtig, men i det mindste en omtrentlig vurdering af kompleksiteten af ​​udviklingen. Holdet skal ikke kun forstå målet med spurten, men også sammenligne målet med deres holds evner.

For at vurdere kompleksiteten kan du bruge de sædvanlige tøjstørrelser til alle (L, XL, XXL). Dette giver selvfølgelig ikke en garanti for nøjagtighed, men alligevel.

For at vurderingen af ​​kompleksitet skal være mere præcis, er der behov for gensidig forståelse. Teammedlemmer bør åbent dele deres meninger og ikke være bange for at stille spørgsmål til produktets ejer.

Kritik over for holdet efter arbejdet er afsluttet kan føre til, at når man planlægger næste sprint, vil prognoserne være mindre optimistiske. Dette vil hjælpe teamet med at undgå at gentage fejlen og beskytte det mod at blive negativt vurderet i fremtiden.

Evaluering af sværhedsgrad i point, point og timer

Typisk vurderer udviklingsteam kompleksiteten af ​​deres arbejde over tid. Men nogle Agile-hold vælger at bedømme sværhedsgraden i point eller point. Dette er en bedre indikation af de samlede omkostninger, der kræves for at implementere en efterslæb eller en anden tildelt opgave.

Point tildeles baseret på kompleksiteten og omfanget af arbejdet. Derudover tages der højde for mulige risici. At score ved hjælp af denne metode hjælper til effektivt at nedbryde arbejdet i små trin.

Ved regelmæssigt at bruge scoringsmetoden (point), når de planlægger, har teams en bedre og mere præcis forståelse af, hvor meget tid de skal bruge til at fuldføre arbejdet. Derudover er der også andre fordele.

• Tidsestimatet tager ikke højde for arbejde, der ikke er direkte relateret til projektet, selvom det med sikkerhed vil dukke op. At diskutere arbejdsspørgsmål gennem en messenger, holde møder – alt dette tager også tid for teammedlemmer.
• Følelser kan påvirke valget af datoer. Scoring ved evaluering af arbejde eliminerer denne faktor.
• Vurderingen af ​​arbejdets kompleksitet og følgelig hastigheden af ​​udførelsen af ​​opgaver kan være forskellig for hvert af teamene. Arbejde med point kan ikke betragtes som nogen indikator for hastighed. Det vil sige, at der ikke er noget psykisk pres på holdet.
• Ved korrekt fordeling af lønomkostninger og kompleksitet kan du hurtigt og uden konflikter fordele punkter for det udførte arbejde mellem deltagerne.
• Antallet af point, der modtages for at udføre en opgave, afhænger af dens kompleksitet og ikke af den brugte tid. Derfor vil programmører tænke på at forbedre deres effektivitet, og ikke på hvor lang tid det vil tage.

Ulempen ved kompleksitetsvurdering er, at den ofte misbruges. For eksempel kan denne metode ikke bruges til at evaluere medarbejdere.

Hold bør bruge et pointsystem for bedre at forstå mængden af ​​arbejde, der er tildelt dem, og prioritere korrekt.

Dagligt Scrum møde

Workshops er vigtige: På dem deler teammedlemmer deres meninger, kommunikerer og bliver enige om yderligere handlinger. Daglige scrum-møder er også nødvendige for at højne holdånden og annoncere aktuelle nyheder.

Stand-up er et kort møde mellem de vigtigste projektdeltagere: softwareejeren, programmører og scrum master. Opbygningen af ​​stand-up'et består af tre spørgsmål.

• Hvad kunne vi i går?
• Hvad arbejder vi med i dag?
• Hvad forhindrer os i at opnå resultater?

At stille disse spørgsmål stimulerer udvikling og hjælper med at identificere problemer i teamet. Når hver deltager kommunikerer, hvordan han/hun hjælper med at nå et fælles mål, forbedrer dette den gensidige forståelse i teamet.

Det er vigtigt at huske, at der ikke er en enkelt skabelon for, hvordan man udfører stand-ups. Hvert team afholder møder efter sin egen model, baseret på teamets karakteristika.

Og lad os nu diskutere, hvad der skal til for den perfekte stand-up og stifte bekendtskab med eksempler på effektive stand-ups.

Først skal du vælge et tidspunkt, der passer alle. Normalt afholdes stand-ups for hold fra samme kontor i starten af ​​arbejdsdagen – mellem 9 og 10 om morgenen. Dette giver dig tid til bedre at planlægge din tidsplan for dagen. Hvis teammedlemmer arbejder i forskellige regioner, så vælges et tidspunkt, der passer alle. For eksempel, hvis nogle teammedlemmer bor i Californien og Sydney, starter stand-up kl. 15:30 Californisk tid. Stand-up efter middagen er selvfølgelig ikke praktisk for alle, men det gør det muligt at holde kontakten med kollegerne på den anden side af havet.

Hold styr på stand-up produktivitet. Hold ikke mødet for længe - koncentrationen af ​​opmærksomhed skal forblive i top. Hvis det er muligt, hold stand-ups ikke længere end 15 minutter.

Brug bolden. Det kan smides til hinanden på skift. Så alle vil være med i diskussionen. Dette spil er med til at holde opmærksomheden i gruppen. Brug team retrospektivt. Stand-ups bruges i mange agile metoder, dette forhindrer os ikke i at diskutere effektiviteten af ​​stand-ups ved retrospektiver. Nogen mødes hver dag, andre hold - et par gange om ugen. Hvis det er svært for holdet at drage fordel af stand-up, så find årsagerne til dette og skift noget.

Sprint anmeldelse

Forårsgennemgang udføres på sprintens sidste fase. Det er nødvendigt at kontrollere produkttilvæksten og skræddersy efterslæbet. Hele scrum-teamet og alle interessenter deltager i gennemgangen af ​​sprintresultaterne. Mødet afholdes i et afslappet format for at forbedre samspillet mellem projektdeltagere.

Sprintresultatgennemgangen omfatter følgende elementer:

• Softwareejeren viser, hvad der er gennemført fra efterslæbet, og hvad der ikke er.
• Programmørerne diskuterer, hvad der gik godt, hvor vanskelighederne dukkede op, og hvordan de blev elimineret.
• Udviklingsteamet viser resultaterne af deres arbejde under spurten, og hvilket produkttilvækst de har modtaget.
• Produktejeren deler sine tanker om det nuværende efterslæb. Det giver også en prognose for det næste mål og deadline for dets implementering.
• Alle diskuterer, hvad der er bedst at gøre næste gang baseret på markedsvurdering og brugerinteresser.
• Der er en udveksling af synspunkter om timing, budget og udsigter til at øge efterslæbet.

Resultatet er et opdateret efterslæb med nye mål for de efterfølgende spurter. Efterslæbet kan ændres, hvis situationen kræver det.

Sprint retrospektiv

Sprint Retrospective er en workshop, der diskuterer, hvordan du kan forbedre din arbejdsgang. Det skaber også en forbedringsplan for næste sprint. Mødet finder normalt sted efter sprintgennemgangen og tager ikke mere end tre timer. Leder af mødet er Scrum Master.

Hovedmålene for Sprint Retrospective inkluderer:

• Sprintanalyse (deltagernes arbejde, resultater og problemer).
• Diskuter mulige løsninger til at forbedre arbejdsgangen i efterfølgende sprints.
• Udarbejdelse af en plan for implementering af forbedringer af teammedlemmer under gennemførelsen af ​​projektet.

Scrum Master inviterer teammedlemmer til at komme med forslag til, hvordan man kan forbedre udviklingseffektiviteten. Holdet diskuterer forslagene og foreslår bestemte måder og teknikker til deres implementering.

I slutningen af ​​Sprint Retrospective bør teamet fremhæve et par forbedringsforslag, der skal implementeres i næste sprint. Forslag kan implementeres til enhver tid, men Sprint Retrospective giver mulighed for at se dybere på deres mulige tilpasning fra teamets synspunkt.

Det er her, vi slutter vores diskussion af Scrum-metoden. Du kan lære mere om det i temadokumentationen eller på din første arbejdsplads.