Övrigt i sprintprocessen

Incidenter

Definition

Vi är noggranna med skillnaden mellan buggar och incidenter:

• Buggar är en avvikelse som upptäcks under en pågående leverans. I huvudsak är det en avvikelse i förhållande till kravställningen. Här använder vi ärendetypen "Bug" i DevOps.
• Incidenter är en oförutsedd störning som inträffat i ett tidigare levererat system. Här använder vi ärendetypen "Task" i DevOps.

Ansvar

Varje Scrum-team har ett incidentansvar för tidigare levererade system. Varje teammedlem turas om att vara ansvarig för incidenterna. Detta incidentansvar följer ett schema som antingen är en vecka eller en sprint i taget, beroende på team.

För den incidentansvarige reserverar vi upp ett antal timmar, cirka 40-50 timmar per sprint. Mängden timmar bygger på ett historiskt underlag kring hur mycket tid incidenterna brukar ta. Eftersom en teammedlems heltid motsvarar cirka 150 timmar per sprint innebär det att den som är incidentansvarig även har utvecklingsuppdrag, parallellt.

Incidenterna är prioriterade över systemutvecklingen om det visar sig att det reserverade antalet timmar inte räcker till.

De olika teamens incidentschema finns i DevOps:

• Team Applikation och API Länk till annan webbplats.
• Team Datalager Länk till annan webbplats.
• Team Integration Länk till annan webbplats.
  

Prioritering

För alla incidenter ska vi alltid värdera allvarlighetsgraden i incidenten. Akuta incidenter ska lösas i incidenthanteringen av den som är incidentansvarig, vid behov med hjälp av kollegor, alltså experten i ämnet. Om vi har utrymme resursmässigt i incidenthanteringen kan vi förstås lösa mindre akuta incidenter också. Incidenter som kan vänta ska planeras i en kommande sprint. Om incidenten planeras in i en kommande sprint skapas en User Story som estimeras i vanlig ordning, som om det vore ett nytt utvecklingsönskemål.

Om incidenten löses akut läggs en Task upp i DevOps och den underordnas, har sin "förälder", i den User Story som finns för incidentansvaret.

Den incidentansvarige äger incidenten, sköter kommunikationen med kunden, följer upp dess status och avrapporterar dess Task. Den incidentansvarige kan ta hjälp av kollegor, i sitt eget team eller i annat team, helt eller delvis av den som är expert i ämnet. Vi försöker dock undvika att andra än den som är incidentansvarig frontar utåt, om inte experten också råkar vara incidentansvarig.

Tips och tricks

Det finns en del saker att tänka på, dessa är samlade här.

• När en User Story är påbörjad får den inte byta sprint (Iteration Path).
  
• Så länge en US inte är påbörjad kan vi flytta den framåt till kommande sprintar, men så fort den har en status annat än "New" får sprinten inte ändras. En målsättning är ju att innehållet i User Stories hanteras så att det går att slutföra inom en sprint, men det kan finnas undantag. Ett exempel på undantag är då produktionssättningen av det som utförts i US glider över ett sprintskifte. I det fallet är det endast underliggande Tasks som flyttas fram till kommande sprint. US för blir orörd i det avseendet.
• Ej påbörjad User Story som har tillhörande Tasks kan flyttas till annan sprint (Iteration). Det görs lämpligast via en board och de tre punkterna på respektive rad i boarden. Då följer tillhörande Tasks med över till den nya sprinten. Om sprintbytet görs i editeringsläget på en User Story följer inte Tasks med över automatiskt.

devTalk

En gång per sprint har respektive team en aktivitet som heter devTalk. Detta är ett längre möte där man mer ingående visar/diskuterar olika saker som berör teamet. Detta är ett tillfälle att titta detaljerat på hur olika lösningar implementerats, olika teknikval samt kunskapsspridning.

Vad som ska avhandlas avgör teamet själva och allt dokumenteras i en Planner i Teams. En lista fylls löpande på med saker att ta upp, och som ett resultat av detta kan olika åtgärder genomföras. Oavsett vilket område som tas upp på detta möte, så är den röda tråden teknik och i synnerhet teknik bakom en befintlig lösning och teknik som kan hjälpa oss framöver.

devDay

Två till fyra gånger per år samlas hela utvecklingsavdelningen för en hel-/halvdagskonferens. Detta är ett tillfälle för kunskapsspridning mellan teamen, teambuilding, omvärldsbevakning, inspiration samt framtidsspaning.

Deltagarna, både interna och externa, föreläser om ett ämne runt systemutveckling, en teknik, arkitektur eller metodik. Det kan vara om något som vi redan använder idag eller redan kan, men det kan också vara ett ämne eller teknik som vi inte använder.