Prosjektledelse i SCRUM

Hvordan fungerer det?

I praksis betyr dette at hele prosessen hele tiden optimaliseres og tilpasses behovene til team og produkt gjennom hele arbeidsperioden på prosjektet. prosjekt. Ansvaret for å administrere produktutvikling er fordelt mellom produkteieren (PO) og designteamet. PO er den personen som er ansvarlig for å ta beslutninger knyttet til retningen på produktutviklingen, og som har en helhetlig "visjon" av hva produktet skal bli. Oppgavestyringen er basert på Kanban-tavlen (i forbindelse med sprint funksjonalitet kalt SCRUM-tavlen). Alle deltakerne i prosessen kan legge til oppgaver i etterslepet, men det er OP som har ansvaret for å prioritere. Prosjektteamet er ansvarlig for å "omdanne" PO-ens ideer til konkrete oppgaver og planlegge gjennomføringen av dem.

Forløpet av syklusen

Prosessen er delt inn i iterasjoner (sprinter). I løpet av en sprint, som varer i ca. 2 uker, implementerer og tester prosjektteamet den tidligere planlagte delen av funksjonaliteten.

Sprinten begynner med "planlegging", der teamet diskuterer og forbereder oppgavene som tidligere har blitt klargjort og satt opp av PO-en øverst i backloggen. Deretter estimeres vanskelighetsgraden til disse oppgavene, og de gis poeng i henhold til vanskelighetsgraden. Med relativt konstant teamsammensetning og arbeidsforhold er antallet poeng som utføres i hver sprint, repeterbart og gjør det mulig å planlegge fremtidig arbeid. På slutten av planleggingsmøtet velges de oppgavene som skal fullføres i løpet av en sprint, og en ny sprint begynner.

I midten av sprinten finner grooming sted. Dette er et møte der den operative lederen presenterer teamet for ytterligere forventninger og ideer, mens prosjektteamet analyserer dem, bryter dem ned i mindre oppgaver og presenterer mulige forslag for den operative lederen. I planleggingen av fremtidige oppgaver rådfører den operative lederen seg med analytikere, brukere, UX og grafiske designere. Ytterligere analyser (marked forskning og datavitenskap) er ofte nødvendig på dette stadiet. Først etter å ha analysert og formulert den såkalte User Story, vil PO publisere disse historiene i en backlog. Brukerhistorien bør inneholde informasjon om hva PO forventer av en gitt oppgave eller gruppe av oppgaver, og hvilke kriterier som skal brukes for å avgjøre om oppgaven er fullført.

I løpet av sprinten avholdes det såkalte "Daily standup meeting" hver dag. På disse møtene forteller hver utvikler resten av teamet hva han eller hun har gjort den siste dagen, og informerer eventuelt om eventuelle problemer eller blokkeringer som hindrer det videre arbeidet. Takket være denne utvekslingen av status er det mulig å fange opp potensielle konflikter mellom ulike oppgaver mye raskere og unngå at utvikleren blir sittende fast i et problem og ikke kan komme videre med det. Det daglige standup-møtet skal være så kort som mulig, men samtidig fylle sin rolle. Den faste formelen for møtet oppfordrer teamet til å holde det kort.

I løpet av sprinten flyttes oppgavene på SCRUM-tavlen i henhold til deres nåværende status. Valget av kolonner samsvarer vanligvis med bedriftens eller teamets arbeidssystem og er knyttet til versjonskontrollsystemet og utgivelsesfrekvensen. For oss er det som følger:

• To do - oppgaver som venter på å bli fullført
• Pågående - oppgaver som pågår
• Kode gjennomgang - oppgaver som venter på å bli sjekket av en annen utvikler
• Forberedt - oppgavene kontrolleres og godkjennes av utviklerne
• Staged - oppgaver som ligger på en staging-instans og venter på godkjenning av PO
• Akseptert - oppgaver som er akseptert av PO
• Ferdig - klare oppgaver som ligger på produksjonsinstansen

Etter sprinten gjennomføres et retrospektivt møte. Dette er et møte som er dedikert til optimalisering av arbeidet. Hele teamet diskuterer hva som har gått bra i den siste sprinten, og hva som må forbedres. Vi refererer også ofte til forrige retrospektiv og sjekker om vi har klart å implementere alle ideene for å forbedre arbeidet. Problemene som diskuteres i retrospektivet, kan være alt fra utviklingsverktøy, arbeidspress og vanskeligheter med oppgaver til kommunikasjonsproblemer (både mellom utviklere, teamet og PO).

SCRUM-masterens ansvarsområder

Den som er ansvarlig for at SCRUM-prosessen gjennomføres på riktig måte, er SCRUM-mesteren. Dette er ofte den mest uforståelige rollen i teamet. SCRUM-masteren har ingen beslutningsmyndighet. Beslutninger tas i fellesskap av teamet og PO, mens SCRUM-masterens rolle er å fjerne hindringer i riktig prosessforløp.

SCRUM-masteren har blant annet følgende oppgaver

• Gjennomføring av SCRUM-møter, inkludert planlegging, grooming, daglige standup-møter og retrospektive møter
• Sørge for at oppgavene på SCRUM-tavlen jevnlig blir vedlikeholdt av teamet og prioritert av PO
• Fungerer som et bindeledd mellom teamet og PO-en; derfor er det ofte SCRUM-masteren som har en vanskelig rolle i å oversette programmerernes språk til forretningsspråket, og omvendt. Dette skyldes at SCRUM-masteren i vårt selskap er en utvikler, og dermed en teknisk person. Det generelle rammeverket for SCRUM-masterens arbeid krever ikke dette.
• Stopper teamet fra å gå utenfor tema og overvåker agendaen på møtene
• Ta vare på stemningen i teamet - hovedsakelig på møter.
• Løse konflikter hvis de oppstår.

Les også:

• Codests gode praksis for å bygge programvare. Vår tilnærming til kundereisen
• Codests gode praksis for å bygge programvare: GitFlow
• Codests gode praksis for å bygge programvare. Hvordan gjennomfører vi kravanalysen?