Brukerhistorie
Brukerhistorier er en effektiv måte å angi krav til programvare under utvikling. Slike historier inneholder korte råd på vegne av brukeren av programvaren.
Siden i Scrum-metodikken er det å sette mål vanligvis kundens eller programvareeierens privilegium, regnes de som den viktigste måten å påvirke utviklingsprosessen på. Hver User Story har en begrensning i mengden tekst og kompleksiteten i presentasjonen. Historie skrives oftest på et lite ark, noe som i seg selv begrenser volumet.
Takket være brukerhistorier kan du dokumentere kundens ønsker og raskt svare på markedets krav.
Brukerhistorien bør betraktes som et forenklet mål på krav fordi den ikke inkluderer en prosedyre for aksepttesting. Sammenstillingen av brukerhistorien må følge opptaksprosedyren. Dette vil sikre at brukerhistorien når målet sitt.
Historiestrukturen ser slik ut: "Som bruker <brukertype> vil jeg utføre <handling> for å få <resultat>" (Som produkteier vil jeg ...). En slik struktur er ikke bare enkel, men også forståelig for alle.
Fordeler med å bruke User Stories:
- Historier er små og enkle å lage.
- Hjelp alle interessenter med å diskutere arbeidet med prosjektet og dets støtte.
- Krever ikke konstant vedlikehold.
- Relevant kun ved bruk.
- Forbedre interaksjonen med klienten.
- Takket være dem kan du dele prosjektet inn i små stadier.
- Tilrettelegge for arbeid med prosjekter med dårlig forstått krav.
- Forenkle oppgaveevaluering.
Ulemper med brukerhistorier:
- Uten forhåndsavtale kan prosedyrer gjøre det vanskelig å legge til grunn for en avtale.
- Bruken av dem krever tett kontakt med oppdragsgiver gjennom hele prosjektet, noe som noen ganger gjør arbeidsflyten vanskelig.
- De har ulemper ved skalering på store prosjekter.
- Direkte relatert til det profesjonelle nivået til utviklere.
- Brukes til å starte en diskusjon, men kan ikke avslutte en diskusjon, og brukes ikke til systemdokumentasjon.
Etterslep
Produktetterslepet er de aktuelle oppgavene i form av en liste, satt sammen i prioritert rekkefølge. Listen er dannet på grunnlag av veikartet (veikartet) for prosjektet og punktene som er angitt i det. De viktigste oppgavene er vanligvis øverst på listen. Dette er nødvendig for å forstå hvilket arbeid som bør gjøres først.
Utviklingsteamet velger hastigheten på å gjennomføre backlog-oppgaver uavhengig av kundens ønsker, men basert på deres kvalifikasjoner og erfaring fra tidligere spurter. Det er ekstremt uønsket å "justere" programmerere. Teamet velger selv oppgaver fra etterslepet etter egne hensyn og evner. Utførelse skjer uten avbrudd (Kanban) eller flere iterasjoner (Scrum).
To viktige etterslepforhold
Kjernen i en produktbacklog består av et veikart, forslag og utførelsesbetingelser. Epos inneholder betingelser og brukerhistorie. La oss se nærmere på et typisk veikarteksempel.
Opprettelsen av nettstedet "Teams in Space" er det første forslaget fra veikartet. Den må deles inn i epos (i figuren er de vist i grønne, blå og turkise farger) og en brukerhistorie for hvert epos.
Programvarekunden danner én liste fra flere User Stories. Om nødvendig kan han endre rekkefølgen historiene blir utført i, slik at utviklerne først skal ta for seg et av de viktigste eposene (til venstre) eller sjekke hvordan rabattert billettbestilling fungerer. For å gjøre dette må du implementere historier fra epos (til høyre). Begge alternativene kan sees nedenfor.
Ut fra hvilke faktorer bør kunden prioritere?
- Relevans for brukere.
- Tilstedeværelsen av tilbakemelding.
- Utviklingens kompleksitet.
- Forholdet mellom oppgaver (for å fullføre "B", må du først gjøre "A").
Prioriteringer i arbeidet bestemmes av kunden, men andre kan si sin mening om dette. Suksessen til etterslepet avhenger blant annet av meningene til kunder og programmerere. Sammen kan de oppnå bedre resultater og sikre rettidig levering av det ferdige produktet.
Hvordan holde et etterslep
Hvis etterslepet allerede er opprettet, må du etter det med jevne mellomrom endre det i løpet av videre arbeid. Programvarekunden bør sørge for at etterslepet er riktig kompilert før hver ny iterasjonsplanlegging. Dette vil bidra til å avklare prioriteringer eller endre noe etter analysen av den siste iterasjonen. Å justere etterslepet i Agile kalles noen ganger "grooming" eller "refinement" eller "backlog maintenance".
Hvis etterslepet allerede er relativt stort, må kunden gruppere oppgaver etter kortsiktig og langsiktig utførelse. Korttidsoppdrag bør granskes før de gis denne statusen. Du må komponere en brukerhistorie, finne ut alle nyansene i teamet.
Når det gjelder langsiktige oppgaver, er det svært ønskelig at utbyggerne gir dem sin vurdering. Dette vil gjøre det lettere å prioritere. Kanskje vil noe endre seg, men teamet vil forbedre forståelsen av oppgavene og få jobben gjort raskere.
Etterslepet er en viktig komponent mellom kunden og programmeringsteamet. Kunden kan alltid endre prioriteringer basert på tilbakemeldinger fra kunder, prognoser eller nye krav.
Det anbefales å unngå å gjøre endringer direkte under drift. Dette har en dårlig effekt på arbeidsflyten og den følelsesmessige tilstanden til programmerere.
Sprint
En sprint er en kort periode hvor en på forhånd avtalt mengde arbeid må gjennomføres. Sprints er basert på Scrum og Agile metodikk. Å velge riktige spurter hjelper et smidig team med å utvikle kvalitetsprogramvare.
«Ved bruk av Scrum kan du utvikle et produkt i flere iterasjoner med en klar varighet - sprints. Det hjelper med å bryte store prosjekter ned i mindre oppgaver, sier Megan Cook, Jira Lead hos Atlassian.
Hvordan planlegger og gjennomfører Scrum sprints?
I følge forfatterne av Scrum-metodikken må alle møtes på et eget møte for å planlegge fremtidens sprint. På dette arrangementet må teammedlemmene finne svar på to hovedspørsmål: hva må gjøres i denne sprinten og hvordan gjøre det best?
Programvarekunden, Scrum-master og programmerere er med på å fastsette listen over arbeidsoppgaver. Kunden forklarer målet med sprinten og oppgaver fra etterslepet.
Deretter utvikler laget en plan som oppgavene i sprinten skal gjennomføres etter. Denne planen, sammen med de valgte arbeidspostene, kalles sprintbacklog. Etter planleggingsmøtet går teamet i gang. Utviklere velger oppgaver fra etterslepet, etter hvert som arbeidet er fullført, endres statusen til hver oppgave fra «Pågår» til «Ferdig».
I løpet av sprinten holder teamet daglige Scrum-møter (stand-ups) for å diskutere aktuelle saker og fremgang. Slike møter er nødvendig for å identifisere vanskeligheter som kan påvirke gjennomføringen av sprinten.
Hvis spurten er fullført, viser teamet resultatene av arbeidet med gjennomgangen av resultatene (demo). Hver deltaker i prosjektet kan gjøre seg kjent med resultatene. Familiarisering bør gjøres før den ferdige koden slås sammen i produksjonsmiljøet.
Retrospektivet fullfører syklusen av spurter. På den identifiserer teamet områder som må forbedres i en fremtidig sprint.
Hva du skal være oppmerksom på og hva du ikke skal gjøre
De fleste unge lag synes det er vanskelig å introdusere sprints i arbeidsflyten for første gang. For å unngå problemer anbefaler vi at du går gjennom listen over handlinger som trenger prioritert oppmerksomhet.
Hva må vi gjøre:
- Sjekk at laget forstår hensikten med sprinten og hvordan den vil lykkes. Dette er nødvendig for at alle sammen skal bevege seg mot et vellykket resultat.
- Du bør ha et klart og forståelig etterslep. Dersom etterslepet ikke ble vedlikeholdt på riktig måte, kan dette bli et problem som kan skade arbeidsflyten.
- Sørg for at estimatet ditt på arbeidstempoet er riktig, tatt i betraktning sommerferier og andre faktorer.
- Delta aktivt i sprintplanlegging. Oppmuntre teammedlemmer til å utvide planen for historier, feil og oppgaver.
- Avslå oppgaver der utviklere ikke vil være i stand til å løse avhengighetsproblemer.
- Etter at planen er godkjent, utnevne en ansatt som skal være ansvarlig for å legge inn data i prosjektstyringsprogrammet (Jira-kort, etc.).
Hva du bør unngå:
- Ikke overbruk et stort antall historier, vurder nøkternt arbeidstempoet og ikke tildel oppgaver som vil være vanskelige å fullføre i en sprint.
- Vær oppmerksom på kvaliteten på arbeidet ditt. Sjekk om du har nok tid til kvalitetskontroll og fikse feil i koden.
- Sørg for at alle teammedlemmer tydelig forstår innholdet i sprinten. Ikke jag etter fart. Hele laget må bevege seg sammen.
- Ikke overbelast utviklere med ekstra arbeid. Enda en sprint kommer snart.
- Hvis teamet uttrykker bekymring for arbeidsbelastningen eller fristen, bør du ta hensyn til deres mening. Håndter problemer og korriger dem om nødvendig.
scrum bord
Scrum Board er et verktøy som viser hvordan arbeidet til Scrum Teamet gjøres. Du kan vise informasjon på en slik tavle på papir, på veggen eller i elektronisk form (JIRA, Trello).
Et Scrum-brett har minst tre kolonner: Å gjøre, Pågår og Ferdig. Her er et eksempeltavle:
Scrum-styret inneholder all informasjon fra backlog, tidligere godkjent for planlegging. Som regel festes forretningsoppgavekort til brettet etter prioritet fra topp til bunn. Du kan dele dem inn i bestemte typer arbeid (arbeid med kode, design og annet).
Etter at en del av arbeidet er fullført, flyttes kortet over brettet til neste kolonne. For å vise synligheten av fremdriften til teamets arbeid, hjelper det "gjenværende arbeidet" om dagen på Burndown Chart.
Du kan også bruke en flippovertavle. På den er navnene på verkene skrevet på papirklistremerker og festet til tavlen. Så snart arbeidet er fullført, flyttes klistremerkene til en annen kolonne.
nedbrenningsdiagram
Nedbrenningsdiagrammet viser mengden arbeid som er utført og mengden arbeid som gjenstår. Den oppdateres hver dag og er tilgjengelig for alle interesserte. Grafen er nødvendig for å vise fremdriften i arbeidet med sprinten.
Det finnes to typer diagrammer:
- Nedbrenningsdiagram som viser fremdriften av arbeidet i en sprint.
- Nedbrenningsdiagram som viser fremdriften i arbeidet frem til utgivelsen av produktet (data er oppsummert fra flere spurter).
Diagrameksempel:
Dette eksemplet bruker psykologi: diagrammet viser ikke antall fullførte oppgaver, men antall gjenværende (ikke utført).
Det vil si at hvis teamet har gjort 90 oppgaver av 100, så kan det være en falsk følelse av at alt er klart. Tross alt endrer ikke fremgang fra 90 til 100 oppgaver egentlig noe.
Hvis du viser antall gjenværende oppgaver, kan du ikke unngå å legge merke til hvordan de blir færre og færre for hver gang. Dette sporer ubevisst prosjektdeltakerne til å nå målet raskere – det skal ikke være uferdige oppgaver på styret.