Processer i Scrum

Sprintplanering

Sprintplanering är det första steget i Scrum-sprinten. Det avgör omfattningen och sätten att utföra arbetet under sprinten. Hela Scrum-teamet är med och planerar.

En sprint är en tydligt definierad tidsperiod under vilken ett specificerat arbete måste slutföras. En sprint behöver planeras innan den startar. Först och främst måste du bestämma varaktigheten och målet för sprinten.

På planeringsverkstaden avtalas uppgiftslistan och målet med sprinten. Det är viktigt att ladda teamet med rätt motivation att arbeta, så att varje medlem är fokuserad på framgång.

Om spurten är dåligt planerad kan detta leda till att laget misslyckas. Utvecklare kommer inte att kunna klara av de förväntningar som ställs på dem, eftersom uppgifterna visade sig vara orealistiska.

Frågor att tänka på när du planerar en sprint:

• Kunden eller programvaruägaren tillkännager målet med sprinten, längs vägen och förklarar hur man uppnår det. Scrum-teamet tar reda på vilka uppgifter som kan utföras i en framtida sprint för att uppnå detta mål.
• Utvecklare distribuerar en arbetsplan sinsemellan, som avtalas med mjukvarukunden.
• Kunden (ägaren) av produkten deltar alltid i upprättandet av sprintplanen. Han sätter ett mål, och programmeringsteamet måste ta reda på om det kan uppnås i en sprint.
• Planen bör använda en produktbacklog, från vilken information kan läggas till planen.
• Teammedlemmar bör avsluta planeringsmötet med en tydlig förståelse för vad de behöver för att uppnå resultatet. Du kan visa ordningen på framtida åtgärder i sprintbackloggen.

Planeringen bör inte överstiga två timmar per vecka. Scrum Mastern måste förklara för alla att det finns tidsgränser. Om alla arbetsfrågor löses snabbt kan mötet avslutas tidigare än vanligt. Det finns ingen minimilängd för ett sådant möte.

Uppgiftsutvärdering

Att bedöma komplexiteten i arbetet behöver inte överdriva det. Planeringsprocessen behöver inte en exakt, men åtminstone en ungefärlig bedömning av bebyggelsens komplexitet. Laget måste inte bara förstå målet med sprinten, utan också jämföra målet med deras lags förmåga.

För att bedöma komplexiteten kan du använda de vanliga klädstorlekarna för alla (L, XL, XXL). Detta ger naturligtvis ingen garanti för noggrannhet, men ändå.

För att bedömningen av komplexitet ska bli mer korrekt krävs ömsesidig förståelse. Teammedlemmar bör öppet dela sina åsikter och inte vara rädda för att ställa frågor till produktägaren.

Kritik mot teamet efter avslutat arbete kan leda till att vid planeringen av nästa sprint blir prognoserna mindre optimistiska. Detta kommer att hjälpa laget att undvika att upprepa misstaget och skydda det från att bli negativt bedömt i framtiden.

Utvärdering av svårighetsgrad i poäng, poäng och timmar

Vanligtvis uppskattar utvecklingsteam komplexiteten i deras arbete över tid. Men vissa agila lag väljer att betygsätta svårighetsgraden i poäng eller poäng. Detta är en bättre indikation på den totala kostnad som krävs för att implementera en eftersläpningspost eller annan tilldelad uppgift.

Poäng delas ut baserat på arbetets komplexitet och volym. Dessutom beaktas eventuella risker. Att poängsätta med denna metod hjälper till att effektivt bryta ner arbetet i små steg.

Genom att regelbundet använda poängmetoden (poäng) vid planering får teamen en bättre och mer exakt förståelse för hur mycket tid de kommer att behöva för att slutföra arbetet. Dessutom finns det andra fördelar också.

• Tidsuppskattningen tar inte hänsyn till arbete som inte är direkt relaterat till projektet, även om det säkert kommer att dyka upp. Att diskutera arbetsfrågor genom en budbärare, hålla möten – allt detta tar också tid för teammedlemmarna.
• Känslor kan påverka valet av datum. Poängsättning vid utvärdering av arbete eliminerar denna faktor.
• Bedömningen av komplexiteten i arbetet och följaktligen hastigheten för att slutföra uppgifter kan vara olika för vart och ett av teamen. Arbete med gjorda poäng kan inte betraktas som någon indikator på hastighet. Det vill säga att det inte finns någon psykologisk press på laget.
• Genom att korrekt fördela arbetskostnader och komplexitet kan du snabbt och utan konflikter fördela punkter för utfört arbete mellan deltagarna.
• Antalet poäng som erhålls för att slutföra en uppgift beror på dess komplexitet och inte på den tid som spenderas. Därför kommer programmerare att tänka på att förbättra sin effektivitet, och inte på hur lång tid det kommer att ta.

Nackdelen med komplexitetsuppskattning är att den ofta missbrukas. Den här metoden kan till exempel inte användas för att utvärdera anställda.

Lag bör använda ett poängsystem för att bättre förstå hur mycket arbete de har tilldelats och prioritera rätt.

Dagligt Scrum-möte

Workshops är viktiga: vid dem delar teammedlemmarna sina åsikter, kommunicerar och kommer överens om ytterligare åtgärder. Dagliga scrummöten behövs också för att höja lagandan och presentera aktuella nyheter.

Stand-up är ett kort möte med nyckelprojektdeltagarna: mjukvaruägaren, programmerare och scrummaster. Uppbyggnaden av standupen består av tre frågor.

• Vad kunde vi göra igår?
• Vad jobbar vi med idag?
• Vad hindrar oss från att nå resultat?

Att ställa dessa frågor stimulerar utveckling och hjälper till att identifiera problem inom teamet. När varje deltagare kommunicerar hur han/hon hjälper till att uppnå ett gemensamt mål, förbättrar detta den ömsesidiga förståelsen inom teamet.

Det är viktigt att komma ihåg att det inte finns en enda mall för hur man ska genomföra stand-ups. Varje team håller möten enligt sin egen modell, utifrån teamets egenskaper.

Och låt oss nu diskutera vad som behövs för den perfekta standupen och bekanta oss med exempel på effektiva stand-ups.

Först måste du välja en tid som passar alla. Vanligtvis hålls stand-ups för team från samma kontor i början av arbetsdagen – mellan 9 och 10 på morgonen. Detta ger dig tid att bättre planera ditt schema för dagen. Om teammedlemmar arbetar i olika regioner väljs en tid som passar alla. Till exempel, om några lagmedlemmar bor i Kalifornien och Sydney, startar stand-up klockan 15:30 Kaliforniens tid. Självklart är stand-up efter middagen inte bekvämt för alla, men det gör det möjligt att hålla kontakten med kollegor på andra sidan havet.

Håll koll på stand-up-produktiviteten. Håll inte mötet för länge - koncentrationen av uppmärksamhet ska vara som bäst. Om möjligt, håll stå-up inte längre än 15 minuter.

Använd bollen. Det kan kastas till varandra i tur och ordning. Så alla kommer att vara delaktiga i diskussionen. Detta spel hjälper till att behålla uppmärksamheten i gruppen. Använd team retrospektivt. Stand-ups används i många agila metoder, detta hindrar oss inte från att diskutera effektiviteten av stand-ups vid retrospektiv. Någon träffas varje dag, andra lag – ett par gånger i veckan. Om det är svårt för laget att dra nytta av stand-up, hitta orsakerna till detta och ändra något.

Sprintrecension

Vårgenomgång genomförs i slutskedet av sprinten. Det är nödvändigt att kontrollera produktökningen och skräddarsy eftersläpningen. Hela scrumteamet och alla intressenter deltar i granskningen av sprintresultaten. Mötet hålls i ett avslappnat format för att förbättra interaktionen mellan projektdeltagarna.

Sprintresultatgranskningen innehåller följande delar:

• Programvaruägaren visar vad från eftersläpningen som har slutförts och vad som inte har gjort det.
• Programmerarna diskuterar vad som gick bra, var svårigheterna dök upp och hur de eliminerades.
• Utvecklingsteamet visar resultatet av sitt arbete under sprinten och vilken produktökning de fått.
• Produktägaren delar med sig av sina tankar om den nuvarande eftersläpningen. Den ger också en prognos för nästa mål och deadline för dess genomförande.
• Alla diskuterar vad som är bäst att göra härnäst utifrån marknadsbedömning och användarintressen.
• Det finns ett utbyte av åsikter om tidpunkten, budgeten och utsikterna för att öka eftersläpningen.

Resultatet är en uppdaterad backlog med nya mål för efterföljande spurter. Eftersläpningen kan ändras om situationen kräver det.

Sprint retrospektiv

Sprint Retrospective är en workshop som diskuterar hur du kan förbättra ditt arbetsflöde. Det skapar också en förbättringsplan för nästa sprint. Mötet sker vanligtvis efter sprintgenomgången och tar inte mer än tre timmar. Leder mötet är Scrum Master.

Huvudmålen för Sprint Retrospective inkluderar:

• Sprintanalys (deltagares arbete, resultat och problem).
• Diskutera möjliga lösningar för att förbättra arbetsflödet i efterföljande spurter.
• Skapande av en plan för implementering av förbättringar av teammedlemmar under genomförandet av projektet.

Scrum Master uppmanar teammedlemmar att ge förslag på hur man kan förbättra utvecklingseffektiviteten. Teamet diskuterar förslagen och föreslår vissa sätt och tekniker för deras implementering.

I slutet av Sprint Retrospective bör teamet lyfta fram några förbättringsförslag att implementera i nästa sprint. Förslag kan implementeras när som helst, men Sprint Retrospective ger en möjlighet att ta en djupare titt på deras eventuella anpassning ur teamets synvinkel.

Det är här vi avslutar vår diskussion om Scrum-metoden. Du kan lära dig mer om det i den tematiska dokumentationen eller på din första arbetsplats.