Direkt till innehållet

Utvecklingssprint

Utvecklingssprint

I Region Halland har vi valt ett agilt arbetssätt och metodiken Scum för att uppnå det. En av de viktigaste delarna i Scrum är sprinten. Vi har bestämt oss för att likställa en kalendermånad med en sprint. Undantaget är juli/augusti som vi kör som en sprint. Vi benämner sprintarna som 2020.10 eller 2021.07-08 för att indikera år och kalendermånad.

Sprinten innehåller ett antal aktiviteter, vilka finns i menyn till vänster på denna sida. Aktiviteterna är ofta kopplade till ett specifikt datum i sprinten. Det är viktigt att aktiviteterna slutförs vid dessa tidpunkter eftersom sprinten ofta är sekventiell, vilket innebär att om en aktivitet förskjuts så kan det påverka efterföljande aktiviteter.

Vi har valt Azure DevOps som IT-stöd i Scrum-processen. En central del i Azure DevOps är User Story, ofta förkortat US.

Under utvecklingssprinten

Under sprinten pågår en mängd löpande aktiviteter, som mer är kopplade till att utföra det överenskomna arbetet.  Kring detta arbete förs det en "dialog" i Azure DevOps. Så fort något ändras i exempelvis en User Story så får beställaren information om det via en notifiering i ett mejl.

Utvecklaren betar av US i prioriteringsordning från första till sista. När första Tasken på en User Story startas sätter utvecklaren om statusen från New till Active. Tasken sätts också från New till Active.

När arbetsdagen är slut så uppdaterar utvecklaren Remaining Work på alla Aktiva Tasks så att de ungefär återspeglar hur lång tid det återstår av uppgiften. Det kan tillkomma fler Tasks under sprinten, tidsuppskattning ska sättas på dessa också. Det kan även vara så att tidsuppskattningarna växer, det kan framkomma information som gör att Remaining time ökar.

När en Task är klar sätter utvecklaren om statusen på Tasken till Resolved. När en Task flyttas till Resolved så justeras inte tiden för Remaining eller Completed per automatik, utan detta får göras manuellt. Antingen görs detta genom att öppna aktuell Task och skriva in tiden. Alternativt, så sätter man först status Closed på Tasken för att låta DevOps sätta tiderna, för att sedan sätta tillbaka status till Resolved.

När en Task sedan lyfts över till testmiljön, så ska dess status sättas till Closed.

När en User Story har lyfts till testmiljön och är klar för att testas, sätter utvecklaren om statusen till Resolved. När en User Story är satt till Resolved signalerar det till kravställaren att det finns ny funktionalitet att testa. Utvecklaren meddelar beställaren och lägger till en kommentar i US att det finns funktionalitet i testmiljön att testa samt att beställaren återkopplar när testandet är klart. Det är viktigt med kommentaren för spårbarhet.

Om kravställaren godkänner leveransen av storyn meddelar denne det till utvecklaren, plus en kommentar om att US är redo att produktionssättas. Utvecklaren produktionssätter och ändrar själv status till Closed på US.

Om det uppstår frågor används Diskussions-funktionen på User Storyn.

Buggar

Hittas buggar ska de registreras i DevOps genom att på User Storyn lägga till en bugg. Beskrivningen av buggen ska innehålla tillräcklig information för att utvecklaren ska kunna återskapa samma fel. Skärmdump på eventuellt felmeddelande och vid webblösningar får gärna urlen till den felande sidan synas tydligt i skärmdumpen. Tilldela sedan buggen till den utvecklare som jobbat med User Storyn.

När utvecklaren påbörjar felsökningen av Buggen sätter hen om den till Active. Eventuella kompletteringar och frågor hanteras genom Diskussionsfunktionen på ärendet i DevOps. Om utvecklaren inte kan felsöka för att det inte finns tillräckligt med information sätts Buggen tillbaka till den som rapporterade den.

Utvecklaren får förstås också registrera buggar som hen hittar.

När utvecklaren rättat buggen och lagt upp den i testmiljön sätter hen om den till Resolved. DevOps kommer då automatiskt att tilldela tillbaka den till den person som rapporterade buggen.

Kravställaren testar att buggen verkligen är rättad och efter verfiering sätter om buggen till Closed.

Avstämning

Det är viktigt att kravställare och utvecklare stämmer av under sprinten så att det inte uppstår komplikationer som kan riskera att försvåra eller fördröja arbetet.

Senast ändrad: