Arbejder med Scrum

Brugerhistorie

Brugerhistorier er en effektiv måde at angive krav til software under udvikling. Sådanne historier indeholder korte råd på vegne af brugeren af ​​softwaren.

Da det i Scrum-metoden normalt er kundens eller softwareejerens privilegium at sætte mål, anses de for at være den vigtigste måde at påvirke udviklingsprocessen på. Hver User Story har en begrænsning i mængden af ​​tekst og kompleksiteten af ​​præsentationen. Historie skrives oftest på et lille ark, hvilket i sig selv begrænser volumen.

Takket være brugerhistorier kan du dokumentere kundens ønsker og hurtigt reagere på markedets krav.

Brugerhistorien bør betragtes som et forenklet mål for krav, fordi den ikke inkluderer en accepttestprocedure. Sammenstillingen af ​​brugerhistorien skal følge optagelsesproceduren. Dette vil sikre, at User Story når sit mål.

Historiestrukturen ser sådan ud: "Som bruger <brugertype> vil jeg udføre <handling> for at få <resultat>" (Som produktejer vil jeg have ...). En sådan struktur er ikke kun enkel, men også forståelig for alle.

Fordele ved at bruge User Stories:

• Historier er små og nemme at skabe.
• Hjælp alle interessenter med at diskutere arbejdet med projektet og dets støtte.
• Kræver ikke konstant vedligeholdelse.
• Kun relevant ved brug.
• Forbedre interaktionen med klienten.
• Takket være dem kan du opdele projektet i små faser.
• Facilitere arbejdet med projekter med dårligt forståede krav.
• Forenkle opgaveevaluering.

Ulemper ved User Stories:

• Uden forudgående aftale kan procedurer gøre det vanskeligt at bruge som grundlag for en aftale.
• Brugen af ​​dem kræver tæt kontakt med kunden gennem hele projektet, hvilket nogle gange gør arbejdsgangen vanskelig.
• De har ulemper ved skalering på store projekter.
• Direkte relateret til det professionelle niveau af udviklere.
• Bruges til at starte en diskussion, men afslutter muligvis ikke en diskussion og bruges ikke til systemdokumentation.

Efterslæb

Produktbacklog er de aktuelle opgaver i form af en liste, opstillet i prioriteret rækkefølge. Listen er dannet på baggrund af projektets køreplan (køreplan) og de punkter, der er opstillet heri. De vigtigste opgaver er normalt øverst på listen. Dette er nødvendigt for at forstå, hvilket arbejde der skal udføres først.

Udviklingsteamet vælger hastigheden af ​​udførelsen af ​​backlog-opgaver uanset kundens ønsker, men ud fra deres kvalifikationer og erfaring fra tidligere spurter. Det er ekstremt uønsket at "justere" programmører. Teamet vælger selv opgaver fra efterslæbet efter egne overvejelser og evner. Udførelse foregår uden afbrydelse (Kanban) eller flere iterationer (Scrum).

To vigtige efterslæb

Kernen i et produktbacklog består af en køreplan, forslag og udførelsesbetingelser. Epos indeholder betingelser og brugerhistorie. Lad os se nærmere på et typisk køreplanseksempel.

Oprettelse af hjemmesiden "Teams in Space" er det første forslag fra køreplanen. Det skal opdeles i epos (i figuren er de vist i grønne, blå og turkise farver) og en User Story for hvert epos.

Softwarekunden danner én liste fra flere User Stories. Hvis det er nødvendigt, kan han ændre rækkefølgen, som historierne udføres i, så udviklerne først vil beskæftige sig med et af de vigtigste epos (til venstre) eller tjekke, hvordan rabatbooking af billetter fungerer. For at gøre dette skal du implementere historier fra epos (til højre). Begge muligheder kan ses nedenfor.

Ud fra hvilke faktorer skal kunden prioritere?

• Relevans for brugerne.
• Tilstedeværelsen af ​​feedback.
• Udviklingens kompleksitet.
• Forholdet mellem opgaver (for at fuldføre "B", skal du først gøre "A").

Prioriteringer i arbejdet fastlægges af kunden, men andre kan give deres mening til kende herom. Efterslæbets succes afhænger blandt andet af kundernes og programmørernes meninger. Sammen kan de opnå bedre resultater og sikre rettidig levering af det færdige produkt.

Sådan holder du et efterslæb

Hvis efterslæbet allerede er oprettet, skal du derefter periodisk ændre det i løbet af det videre arbejde. Softwarekunden bør sikre sig, at efterslæbet er korrekt kompileret før hver ny iterationsplanlægning. Dette vil hjælpe med at afklare prioriteter eller ændre noget efter analysen af ​​den sidste iteration. Justering af efterslæbet i Agile kaldes nogle gange "grooming" eller "forfining" eller "backlog vedligeholdelse".

Hvis efterslæbet allerede er relativt stort, så skal kunden gruppere opgaver efter kortsigtet og langsigtet udførelse. Kortvarige opgaver bør granskes, før de får denne status. Du bliver nødt til at komponere en User Story, finde ud af alle nuancerne i teamet.

Hvad angår langsigtede opgaver, er det meget ønskeligt, at udviklerne giver dem deres vurdering. Det vil gøre det nemmere at prioritere. Måske vil noget ændre sig, men teamet vil forbedre deres forståelse af opgaverne og få arbejdet gjort hurtigere.

Efterslæbet er en vigtig komponent mellem kunden og programmeringsteamet. Kunden kan altid ændre prioriteter baseret på kundefeedback, prognoser eller nye krav.

Det anbefales at undgå at foretage ændringer direkte under drift. Dette har en dårlig effekt på programmørernes arbejdsgang og følelsesmæssige tilstand.

Sprint

En sprint er en kort periode, hvor en på forhånd aftalt mængde arbejde skal udføres. Sprints er baseret på Scrum og Agile metoder. At vælge de rigtige sprints hjælper et agilt team med at udvikle kvalitetssoftware.

”Med Scrum kan man udvikle et produkt i flere iterationer med en klar varighed – sprints. Det hjælper med at dele store projekter ned i mindre opgaver,” siger Megan Cook, Jira Lead hos Atlassian.

Hvordan planlægger og udfører Scrum sprints?

Ifølge forfatterne af Scrum-metoden skal alle mødes til et separat møde for at kunne planlægge den fremtidige sprint. Ved dette arrangement skal teammedlemmer finde svar på to hovedspørgsmål: hvad skal der gøres i denne sprint, og hvordan gør man det bedst?

Softwarekunden, Scrum master og programmører er med til at fastlægge listen over arbejdsopgaver. Kunden forklarer målet med spurten og opgaver fra efterslæbet.

Derefter udarbejder holdet en plan, hvorefter opgaverne i spurten skal løses. Denne plan kaldes sammen med de udvalgte arbejdspunkter for sprintefterslæbet. Efter planlægningsmødet går teamet i gang. Udviklere vælger opgaver fra efterslæbet, efterhånden som arbejdet er afsluttet, skifter status for hver opgave fra "I gang" til "Udført".

I løbet af spurten afholder teamet daglige Scrum-møder (stand-ups) for at diskutere aktuelle problemstillinger og fremskridt. Sådanne møder er nødvendige for at identificere vanskeligheder, der kan påvirke gennemførelsen af ​​spurten.

Hvis spurten er gennemført, så viser holdet resultaterne af deres arbejde med gennemgangen af ​​resultaterne (demo). Hver deltager i projektet kan stifte bekendtskab med resultaterne. Inden den færdige kode flettes ind i produktionsmiljøet.

Retrospektivet fuldender sprintcyklussen. På den identificerer holdet områder, der skal forbedres i en fremtidig sprint.

Hvad skal man være opmærksom på, og hvad man ikke skal gøre

De fleste unge hold har svært ved at indføre sprints i deres arbejdsgang for første gang. For at undgå problemer anbefaler vi, at du gennemgår listen over handlinger, der kræver prioriteret opmærksomhed.

Hvad skal vi gøre:

• Tjek, at holdet forstår formålet med spurten, og hvordan det vil lykkes. Dette er nødvendigt for at alle sammen kan bevæge sig hen imod et vellykket resultat.
• Du skal have et klart og forståeligt efterslæb. Hvis efterslæbet ikke blev vedligeholdt korrekt, kan dette blive et problem, der kan skade arbejdsgangen.
• Sørg for, at dit skøn over arbejdstempoet er korrekt under hensyntagen til sommerferier og andre faktorer.
• Deltag aktivt i sprintplanlægningen. Tilskynd teammedlemmer til at udvide planen for historier, fejl og opgaver.
• Afvis opgaver, hvor udviklere ikke vil være i stand til at løse afhængighedsproblemer.
• Efter at planen er godkendt, skal du udpege en medarbejder, som skal være ansvarlig for at indtaste data i projektledelsesprogrammet (Jira-kort osv.).

Hvad skal man undgå:

• Overbrug ikke et stort antal historier, vurder nøgternt arbejdstempoet og tildel ikke opgaver, der vil være svære at gennemføre i en spurt.
• Vær opmærksom på kvaliteten af ​​dit arbejde. Tjek, om du har tid nok til kvalitetskontrol og rettelse af fejl i koden.
• Sørg for, at alle teammedlemmer klart forstår indholdet af spurten. Lad være med at jage fart. Hele holdet skal bevæge sig sammen.
• Overbelast ikke udviklere med ekstra arbejde. Endnu en sprint kommer snart.
• Hvis teamet udtrykker bekymring over arbejdsbyrden eller deadline, bør du tage hensyn til deres mening. Håndter problemer og ret dem om nødvendigt.

scrum board

Scrum Board er et værktøj, der viser, hvordan arbejdet i Scrum Teamet udføres. Du kan vise information på en sådan tavle på papir, på væggen eller i elektronisk form (JIRA, Trello).

Et Scrum-bræt har mindst tre kolonner: To Do, In Progress og Done. Her er et eksempel på en tavle:

Scrum-tavlen indeholder al information fra backlog, som tidligere er godkendt til planlægning. Som regel fastgøres visitkort til tavlen efter prioritet fra top til bund. Du kan opdele dem i specifikke typer arbejde (arbejde med kode, design og andet).

Når en del af arbejdet er afsluttet, flyttes kortet over brættet til næste kolonne. For at vise synligheden af ​​fremskridtene i teamets arbejde hjælper det "resterende arbejde" om dagen på Burndown Chart.

Du kan også bruge en flipovertavle. På den er værkernes navne skrevet på papirklistermærker og fastgjort til tavlen. Så snart arbejdet er afsluttet, flyttes klistermærkerne til en anden kolonne.

nedbrændingsdiagram

Nedbrændingsdiagrammet viser mængden af ​​udført arbejde og mængden af ​​tilbageværende arbejde. Den opdateres hver dag og er tilgængelig for alle interesserede. Grafen er nødvendig for at vise fremskridtene i arbejdet på spurten.

Der er to typer diagrammer:

• Nedbrændingsdiagram, der viser arbejdets fremskridt i en sprint.
• Nedbrændingsdiagram, der viser arbejdets fremskridt indtil frigivelsen af ​​produktet (data er opsummeret fra flere sprints).

Eksempel på diagram:

Dette eksempel bruger psykologi: diagrammet viser ikke antallet af afsluttede opgaver, men antallet af resterende (ikke udført).

Det vil sige, at hvis teamet har udført 90 opgaver ud af 100, så kan der være en falsk følelse af, at alt er klar. Når alt kommer til alt, ændrer fremskridt fra 90 til 100 opgaver ikke rigtig noget.

Hvis du viser antallet af resterende opgaver, så kan du ikke undgå at bemærke, hvordan de bliver færre og færre for hver gang. Dette ansporer ubevidst projektdeltagerne til hurtigere at nå målet – der skal ikke være uafsluttede opgaver på tavlen.