Jobbar med Scrum

Användarberättelse

Användarberättelser är ett effektivt sätt att ange krav på mjukvara under utveckling. Sådana berättelser innehåller korta råd på uppdrag av användaren av programvaran.

Eftersom i Scrum-metoden är att sätta mål vanligtvis är kundens eller mjukvaruägarens privilegium, anses de vara det främsta sättet att påverka utvecklingsprocessen. Varje User Story har en begränsning i mängden text och komplexiteten i presentationen. Historia skrivs oftast på ett litet blad, vilket i sig begränsar volymen.

Tack vare användarberättelser kan du dokumentera kundens önskemål och snabbt svara på marknadens krav.

Användarberättelsen bör betraktas som ett förenklat mått på krav eftersom den inte inkluderar en acceptanstestning. Sammanställningen av användarberättelsen måste följa antagningsförfarandet. Detta kommer att säkerställa att User Story når sitt mål.

Berättelsestrukturen ser ut så här: "Som användare <användartyp> vill jag utföra <åtgärd> för att få <resultat>" (Som produktägare vill jag ...). En sådan struktur är inte bara enkel, utan också förståelig för alla.

Fördelar med att använda User Stories:

• Berättelser är små och lätta att skapa.
• Hjälp alla intressenter att diskutera arbetet med projektet och dess stöd.
• Behöver inte konstant underhåll.
• Endast relevant vid användning.
• Förbättra interaktionen med kunden.
• Tack vare dem kan du dela upp projektet i små etapper.
• Underlätta arbetet med projekt med dåligt förstådda krav.
• Förenkla uppgiftsutvärdering.

Nackdelar med User Stories:

• Utan föregående överenskommelse kan rutiner göra det svårt att lägga till grund för ett avtal.
• Deras användning kräver nära kontakt med beställaren genom hela projektet, vilket ibland försvårar arbetsflödet.
• De har nackdelar när man skalar på stora projekt.
• Direkt relaterad till utvecklarnas professionella nivå.
• Används för att starta en diskussion, men kanske inte avslutar en diskussion, och används inte för systemdokumentation.

Orderstock

Produktbackloggen är de aktuella uppgifterna i form av en lista, sammanställd i prioritetsordning. Listan bildas på grundval av projektets färdplan (roadmap) och de punkter som anges i den. De viktigaste uppgifterna står oftast högst upp på listan. Detta är nödvändigt för att förstå vilket arbete som bör utföras först.

Utvecklingsteamet väljer hastigheten för att slutföra eftersläpningsuppgifter oavsett kundens önskemål, men baserat på deras kvalifikationer och erfarenheter från tidigare spurter. Det är extremt oönskat att "justera" programmerare. Teamet väljer själva uppgifter ur eftersläpningen efter sina egna överväganden och förmågor. Utförande sker utan avbrott (Kanban) eller flera iterationer (Scrum).

Två viktiga eftersläpningsvillkor

Kärnan i en produktbacklog består av en färdplan, förslag och utförandevillkor. Epos innehåller villkor och User Story. Låt oss ta en närmare titt på ett typiskt färdplansexempel.

Skapandet av webbplatsen "Teams in Space" är det första förslaget från färdplanen. Det måste delas in i epos (i figuren visas de i gröna, blå och turkosa färger) och en User Story för varje epos.

Programvarukunden bildar en lista från flera User Stories. Om det behövs kan han ändra ordningen som berättelserna körs i, så att utvecklarna först tar itu med ett av de viktigaste eposerna (till vänster) eller kollar hur rabatterad biljettbokning fungerar. För att göra detta måste du implementera berättelser från epos (höger). Båda alternativen kan ses nedan.

Utifrån vilka faktorer ska kunden prioritera?

• Relevans för användare.
• Närvaron av feedback.
• Utvecklingens komplexitet.
• Förhållandet mellan uppgifter (för att slutföra "B", måste du först göra "A").

Prioriteringar i arbetet bestäms av kunden, men andra parter kan yttra sig om detta. Eftersläpningens framgång beror bland annat på åsikter från kunder och programmerare. Tillsammans kan de uppnå bättre resultat och säkerställa snabb leverans av den färdiga produkten.

Hur man håller en eftersläpning

Om eftersläpningen redan har skapats måste du efter det regelbundet ändra den under det fortsatta arbetet. Programvarukunden bör se till att eftersläpningen är korrekt sammanställd före varje ny iterationsplanering. Detta kommer att hjälpa till att klargöra prioriteringar eller ändra något efter analysen av den senaste iterationen. Att justera eftersläpningen i Agile kallas ibland "grooming" eller "refinement" eller "backlog maintenance".

Om eftersläpningen redan är relativt stor behöver kunden gruppera uppgifter efter kortsiktigt och långsiktigt utförande. Kortsiktiga uppdrag bör granskas innan de ges denna status. Du måste komponera en User Story, ta reda på alla nyanser inom teamet.

När det gäller långsiktiga uppgifter är det mycket önskvärt att utvecklarna ger dem sin bedömning. Det gör det lättare att prioritera. Kanske kommer något att förändras, men teamet kommer att förbättra sin förståelse för uppgifterna och få jobbet gjort snabbare.

Eftersläpningen är en viktig komponent mellan kunden och programmeringsteamet. Kunden kan alltid ändra prioriteringar baserat på kundfeedback, prognoser eller nya krav.

Det rekommenderas att undvika att göra ändringar direkt under drift. Detta har en dålig effekt på arbetsflödet och det känslomässiga tillståndet hos programmerare.

Sprinta

En sprint är en kort period under vilken en tidigare överenskommen arbetsmängd ska genomföras. Sprints är baserade på Scrum och Agile metoder. Att välja rätt sprints hjälper ett agilt team att utveckla kvalitetsmjukvara.

”Med Scrum kan du utveckla en produkt i flera iterationer med en tydlig varaktighet - sprints. Det hjälper till att bryta ner stora projekt i mindre uppgifter”, säger Megan Cook, Jira Lead på Atlassian.

Hur planerar och genomför Scrum sprints?

Enligt författarna till Scrum-metoden behöver alla träffas på ett separat möte för att kunna planera framtidens sprint. Vid detta evenemang måste lagmedlemmarna hitta svar på två huvudfrågor: vad behöver göras i denna sprint och hur gör man det bäst?

Programvarukunden, Scrum master och programmerare är med och bestämmer listan över arbetsuppgifter. Kunden förklarar målet med sprinten och uppgifter från eftersläpningen.

Sedan tar teamet fram en plan enligt vilken uppgifterna i sprinten ska slutföras. Denna plan, tillsammans med de valda arbetspunkterna, kallas sprintbacklog. Efter planeringsmötet sätter teamet igång. Utvecklare väljer uppgifter från eftersläpningen, när arbetet är klart ändras statusen för varje uppgift från "Pågår" till "Klar".

Under sprinten håller teamet dagliga Scrum-möten (stand-ups) för att diskutera aktuella frågor och framsteg. Sådana möten behövs för att identifiera svårigheter som kan påverka genomförandet av sprinten.

Om spurten är klar visar teamet resultatet av sitt arbete med granskning av resultaten (demo). Varje deltagare i projektet kan bekanta sig med resultaten. Bekantskap bör göras innan den färdiga koden slås samman i produktionsmiljön.

Retrospektivet avslutar sprintcykeln. På den identifierar teamet områden som behöver förbättras i en framtida sprint.

Vad ska man vara uppmärksam på och vad man inte ska göra

De flesta unga lag har svårt att introducera sprints i sitt arbetsflöde för första gången. För att undvika problem rekommenderar vi att du granskar listan över åtgärder som behöver prioriteras.

Vad behöver vi göra:

• Kontrollera att laget förstår syftet med sprinten och hur det kommer att lyckas. Detta är nödvändigt för att alla tillsammans ska gå mot ett framgångsrikt resultat.
• Du bör ha en tydlig och begriplig eftersläpning. Om eftersläpningen inte sköttes korrekt kan detta bli ett problem som kan skada arbetsflödet.
• Se till att din uppskattning av arbetstakten är korrekt, med hänsyn till sommarlov och andra faktorer.
• Delta aktivt i sprintplaneringen. Uppmuntra teammedlemmar att utöka planen för berättelser, buggar och uppdrag.
• Avvisa uppgifter under vilka utvecklare inte kommer att kunna lösa beroendeproblem.
• Efter att planen har godkänts utser du en anställd som ska ansvara för att mata in data i projektledningsprogrammet (Jira-kort etc.).

Vad du bör undvika:

• Överanvänd inte ett stort antal berättelser, bedöm nyktert arbetstakten och tilldela inte uppgifter som kommer att vara svåra att slutföra i en sprint.
• Var uppmärksam på kvaliteten på ditt arbete. Kontrollera om du har tillräckligt med tid för kvalitetskontroll och fixa buggar i koden.
• Se till att alla lagmedlemmar tydligt förstår innehållet i sprinten. Jaga inte fart. Hela laget måste röra sig tillsammans.
• Överbelasta inte utvecklare med extra arbete. Snart kommer ytterligare en sprint.
• Om teamet uttrycker oro över arbetsbelastningen eller deadline bör du ta hänsyn till deras åsikt. Ta itu med problem och åtgärda dem vid behov.

scrumbräda

Scrum Board är ett verktyg som visar hur arbetet i Scrum Teamet går till. Du kan visa information på en sådan tavla på papper, på väggen eller i elektronisk form (JIRA, Trello).

En Scrum-bräda har minst tre kolumner: Att göra, Pågår och Klart. Här är ett exempel på tavlan:

Scrum-tavlan innehåller all information från backloggen, som tidigare godkänts för planering. Som regel fästs visitkort på tavlan med prioritet uppifrån och ned. Du kan dela in dem i specifika typer av arbete (arbete med kod, design och annat).

När en del av arbetet är slutfört flyttas kortet över spelplanen till nästa kolumn. För att visa synligheten av framstegen i teamets arbete, hjälper det "återstående arbetet" per dag på Burndown Chart.

Du kan också använda en blädderblockstavla. På den är verkens namn skrivna på pappersklistermärken och fästa på tavlan. Så snart arbetet är klart flyttas klistermärkena till en annan kolumn.

nedbränningsdiagram

Nedbrytningsdiagrammet visar hur mycket arbete som gjorts och hur mycket arbete som återstår. Den uppdateras varje dag och är tillgänglig för alla intresserade. Grafen behövs för att visa framstegen i arbetet med sprinten.

Det finns två typer av diagram:

• Burndown-diagram som visar arbetets framsteg i en sprint.
• Burndown-diagram som visar arbetets framsteg fram till lanseringen av produkten (data sammanfattas från flera sprints).

Diagramexempel:

Det här exemplet använder psykologi: diagrammet visar inte antalet slutförda uppgifter, utan antalet återstående (ej utförda).

Det vill säga, om teamet har gjort 90 uppgifter av 100, så kan det finnas en falsk känsla av att allt är klart. När allt kommer omkring, framsteg från 90 till 100 uppgifter förändrar egentligen ingenting.

Om du visar antalet återstående uppgifter kan du inte låta bli att märka hur de blir färre och färre för varje gång. Detta sporrar undermedvetet projektdeltagarna att nå målet snabbare – det ska inte finnas oavslutade uppgifter i styrelsen.