Projektledelse i SCRUM

Hvordan fungerer det?

I praksis betyder det, at hele processen hele tiden optimeres og tilpasses behovene i den enkelte virksomhed. hold og den produkt gennem hele arbejdsperioden på projektet. projekt. Ansvar for at styre produktudvikling er fordelt mellem produktejeren (PO) og designteamet. PO er den person, der er ansvarlig for at træffe beslutninger om produktudviklingens retning og har en holistisk "vision" om, hvad produktet skal blive til. Opgavestyring er baseret på Kanban-tavlen (i forbindelse med sprint funktion kaldet SCRUM-tavlen). Alle deltagere i processen kan tilføje opgaver til backloggen, men det er OP'en, der er ansvarlig for at prioritere. Projektteamet er ansvarligt for at "omdanne" PO's ideer til specifikke opgaver og planlægge deres gennemførelse.

Cyklussens forløb

Processen er opdelt i iterationer (sprints). Som en del af et sprint, der varer ca. 2 uger, implementerer og tester projektteamet den tidligere planlagte del af funktionaliteten.

Sprintet begynder med "planlægning", hvor teamet diskuterer og forbereder de opgaver, der tidligere er blevet forberedt og sat op af PO'en øverst i backloggen. Derefter vurderes opgavernes sværhedsgrad, og de tildeles point i forhold til sværhedsgraden. Med en relativt konstant teamsammensætning og arbejdsforhold kan antallet af point i hvert sprint gentages, og det gør det muligt at planlægge det fremtidige arbejde. Ved afslutningen af planlægningsmødet udvælges opgaver med et samlet antal point, der skal gennemføres inden for et sprint, og et nyt sprint begynder.

Midt i sprinten finder grooming sted. Det er et møde, hvor OP'en præsenterer teamet for yderligere forventninger og ideer, mens projektteamet analyserer dem, bryder dem ned i mindre opgaver og præsenterer mulige forslag for OP'en. Når OP'en planlægger fremtidige opgaver, rådfører han sig med analytikere, brugere, UX og grafiske designere. Yderligere analyser (marked forskning og datavidenskab) er ofte nødvendige i denne fase. Først efter at have analyseret og formuleret den såkaldte User Story vil PO'en offentliggøre disse historier i en backlog. User Story skal indeholde oplysninger om, hvad PO'en forventer af en given opgave eller gruppe af opgaver, og hvilke kriterier der skal bruges til at se, om opgaven er fuldført.

I løbet af sprinten afholdes der dagligt et såkaldt "Daily standup meeting". På disse møder fortæller hver udvikler resten af teamet, hvad han har lavet den sidste dag, og informerer muligvis om eventuelle problemer eller blokeringer, der hindrer hans videre arbejde. Takket være denne udveksling af aktuel status er det muligt at fange potentielle konflikter mellem forskellige opgaver meget hurtigere og undgå den situation, hvor udvikleren sidder fast i et problem og ikke kan komme videre med det. Den daglige standup skal være så kort som muligt, men samtidig opfylde sin rolle. Mødets stående formel opfordrer teamet til at holde det kort.

I løbet af sprinten flyttes opgaverne på SCRUM-tavlen i henhold til deres aktuelle status. Valget af kolonner svarer normalt til virksomhedens eller teamets arbejdssystem og er forbundet med versionskontrolsystemet og hyppigheden af udgivelser. For os er det som følger:

• To do - opgaver, der venter på at blive afsluttet
• I gang - igangværende opgaver
• Kode review - opgaver, der venter på at blive tjekket af en anden udvikler
• Forberedt - opgaver tjekket og accepteret af udviklere
• Staged - opgaver, der ligger på en staging-instans og venter på PO-godkendelse
• Accepteret - opgaver accepteret af PO
• Færdig - færdige opgaver placeret på produktionsinstansen

Efter sprinten finder der et retrospektivt møde sted. Det er et møde, der er dedikeret til at optimere arbejdet. Hele teamet diskuterer, hvad der er gået godt i det sidste sprint, og hvad der skal forbedres. Vi henviser også ofte til det forrige retrospektiv og tjekker, om vi har været i stand til at implementere alle ideer til forbedring af arbejdet. De problemer, der diskuteres på retrospektivet, kan være alt fra udviklingsværktøjer, pres, opgavemæssige vanskeligheder til kommunikationsproblemer (både mellem udviklere og teamet og PO'en).

SCRUM-masterens ansvarsområder

Den person, der er ansvarlig for den korrekte gennemførelse af SCRUM-processen, er SCRUM-masteren. Det er ofte den mest uforståelige rolle i teamet. SCRUM-masteren har ingen beslutningskompetence. Beslutninger træffes i fællesskab af teamet og PO'en, mens SCRUM-masterens rolle er at fjerne forhindringer i processens rette forløb.

SCRUM-masterens opgaver omfatter følgende:

• Gennemførelse af SCRUM-møder, herunder planlægning, grooming, dagligt standup-møde og retrospektiv.
• Sikre, at opgaverne på SCRUM-tavlen regelmæssigt plejes af teamet og prioriteres af PO'en.
• Fungerer som bindeled mellem teamet og PO'en; derfor er det ofte SCRUM-masteren, der har en vanskelig rolle med at oversætte programmørernes sprog til forretningssproget og omvendt. Det skyldes, at SCRUM-masteren i vores virksomhed er en udvikler og dermed en teknisk person. De generelle rammer for SCRUM-masterens arbejde kræver ikke dette.
• Forhindre teamet i at gå uden for emnet og holde øje med dagsordenen på møderne
• Omsorg for stemningen i teamet - primært ved møder.
• Løsning af konflikter, hvis de opstår.

Læs også her:

• Codests gode praksis for at bygge software. Vores tilgang til kunderejsen
• Codest's gode praksis for at bygge software: GitFlow
• Codests gode praksis for at bygge software. Hvordan gennemfører vi kravanalysen?