Person A R:
I1: Vilken omfattning har du på organisationen?
R: Ja vi är ju IT-konsulter, jag sysslar mest med systemutveckling.
I1: Vad ingår i ditt dagliga arbete?
R: Det är mest utveckling men även förvaltningsrelaterat, kan vara register i databaser och lite blandat. Jag sysslar mest med allt från back end till front end.
Vilka risker förekommer under en sprint?
R: Inom en sprint, ja alltså åtagandet vi har är ju ganska verksamhetsorienterat, vi utgår ju från regler och sånt som
myndigheterna bestämmer angående pension då. Men jag vet inte om jag skulle kunna säga att det är en risk för sprint då men om dom ändrar någonting som vi redan har gjort så blir det ju en risk så. Hela tiden kan komma in och göra verksamhetskrav liksom vi måste anpassa oss efter och ska genomsyras i hela systemet. Men just per sprint, skulle väl vara om vi missar nånting, vi har ju krav för utvecklingen, det skulle väl vara om man missar någonting så att inte de uppfylls då.
I2: Och när du menar missa nånting, menar du missa en funktion som kommer med i stories
R: Det kan ju vara, det kan vara att jag har missuppfattat ett krav eller test. Vi har sån här överlämning från utveckling till test om man glömmer någon detalj där men då är det ju bra att man har ett stabilt krav, annars känns det som att dom delarna är svåra att missa om man gör rätt ifrån början. Det tycker jag att sprintarna bidrar med liksom såhär kort och konsist; Det här ska vi göra den här sprinten.
I1: Jag tänkte överlag om nånting skulle missas i kravspecifikationen där ni lägger ut tasks i sprinten och så är det någonting som skulle missas, kan det vara en risk att ni frångår kravspecifikationen?
R: Om möjligheten finns menar du? Ja fast ja, det är klart möjligheten finns men det känns inte som att vi har ju, vi tilldelar alla stories och
68
tasks så vi inte ska missa något. Vi vet ju redan i början av sprinten att det här ska jag göra och så kan vi ju ha en kontinuerlig dialog hela tiden. I2: Hur ofta får ni krav från kunden eller produktägaren som ändras under utvecklingen, tex någon funktion?
R: Det är svårt att säga hur ofta, generellt. I2: Men det sker?
R: Ja det sker ju att dom har tagit något beslut eftersom att det är en verksamhetsorienterad bransch då, så vi får ju anpassa oss ifrån den andra delen.
I1: Om man tänker sig inom tidsramen för en kravspec, tycker du att det är risk att man inte hinner klar, att man haft för stort åtagande i en kravspec och att tidsestimeringen är för liten?
R: Jo det är ju alltid en risk och det är ju svårt att estimera när det är så stora delar, när man ska bygga ett system så kan man ju uppskatta fel liksom. Det förekommer ju även i vårt projekt då.
I2: Vad skulle du säga är de mest förekommande riskerna som uppstår i din omfattning som systemutvecklare?
R: Det är väl när det kommer ett nytt krav eller nånting som gör att vi måste ändra något som påverkar redan befintliga grejor, kan ju vara, då är det ju en risk att se till att allting fungerar som det ska fortfarande samtidigt som den nya funktionaliteten då. Det är ju lite... Det är viktigt att man har koll på alla delar funkar fortfarande.
I2: Och de nya kraven som kommer från myndigheten gällande
regelverk och sånt där, i och med att ni är systemutvecklare så kanske man inte kan förvänta sig att ni ska kunna dom fullt ut. Får ni någon konsultering kring det liksom, att det här är det ramverket och så här ser det ut och det är så det funkar eller får ni anta det själva?
R: Vi har ju pensionsexperter här som sitter och jobbar med kundservice så att det finns alltid någon att fråga. Jag har ju inte så mycket erfarenhet av pension just innan men kan ju alltid fråga någon om det är någon regel eller nånting jag är osäker på. Sen är det ju många som har jobbat i projektet länge så det finns alltid expertis att gå på.
69
I2: Känner du att det finns några risker knytna till den
kunskapspecialiserade pension som ni systemutvecklare har? Ni har ju expertis men finns det några risker knytna till det området?`
R: Ja det gör det ju, det är typ om jag, säg att jag antar att det funkar så här men så funkar det inte så. Men jag brukar alltid eliminera den risken genom att gå till någon som vet. Även om jag känner här är nog jag väldigt säker så kan man ju fråga. Vi har ju ett öppet landskap, även om jag inte är involverad i de diskussioner de har bredvid mig så snappar man ju upp grejor liksom, man hör ju och lär sig så också. Öppen dialog är väldigt bra.
I2: Sen har vi ju ytterigare problemområden, ni har ju servrarna för självaste för kunden här på plats, visst är det så? Servrar och sånt här?
R: Ja alltså våra testmiljöer är ju här men vi har outsourcat vår produktionsmiljö till...
I2: Håller du också på med testing? R: Nej
I2: Men om vi går in på IT-säkerhetsrelaterade risker, det har ju blivit ett återkommande problem hos företagen. Vilka säkerhetsrelaterade risker gentemot det ser du?
R: Det tror jag kan vara en fördel i och med att nu har vi ju antlitat externa, så de är ju experter på det viset. De har ju serviceavtal och läser man deras policy så känns det ju som att det är ganska bra angående det. Jag tror att ska man både systemutveckla och drifta så tror jag att det kan vara större chans att man missar någonting, man kan ju inte dra på sig för mycket.
I2: Men det är också en risk att man kan ta på sig för mycket? R: Ja jag tror det.
I1: Ja det är ju också ett problem om man ska både drifta och underhålla ett system, det kräver mycket.
I2: Skulle du kunna påstå att outsourcing har både positiva och negativa aspekter? De negativa aspekterna skulle kunna vara om det finns risker med att outsourca det.
R: Ja det gör det ju också, och sen är det ju liksom att man, då kan ju inte vi kontrollera om något har gått fel hos dom, då måste vi kontakta dom
70
och det är liksom, det är ju liksom mellansteg då. Men jag tycker att fördelarna väger upp nackdelarna.
I2: Vad skulle du säga är de största anledningarna till att det sker förseningar i att man ska utveckla en viss funktion?
R: Generellt, det skulle jag nog säga att något är felestimerat gällande tid då, man får göra någon form av uppskattning och gå igenom vad som ska göras och så här lång tid tror vi att det tar. Men det är ju svårt att veta exakt när det kommer till kritan. Kanske man märker andra grejer som att det är viktigt med lagkrav också, så får man ju minimera de upptäckter man gör i efterhand.
I1: Vi har identifierat tidigare i mötet med er Scrum master att sen ni blev klar med det stora projektet så vet ni inte riktigt mot vilken mål ni jobbar med kunden, kunden vet inte riktigt vad dom vill ha för nånting, upplever du som systemutvecklare att det är ett problem, nu när du sitter och utvecklar saker, att de inte riktigt är målmedvetna om vad dom vill ha?
R: Ja alltså jag kände, när vi höll på med det här stora projektet som Scrummastern pratar om, då var det ju mer tydliga mål, då visste man alltid att det här ska jag göra, nu är det lite mer otydligt. Det är klart att det känner jag av ibland, att ibland vet jag inte riktigt vilken riktning jag ska gå när jag utvecklar men vi kravar ju så gott vi kan utifrån det vi vet. Det har varit lite nu, nya verksamhetskrav då så dom vet inte riktigt, då kan inte vi utveckla till fullo heller så att det har varit lite mycket nu så här att preppa, då det här händer då kanske det ska se ut så här.
I1: Om man tänker sig utifrån ett subjektivt perspektiv, om vad man tycker själv, och vad kunden egentligen vill ha. Man vet inte riktigt vad kunden vill ha men att man utvecklar själv för vad ni tror att kunden vill ha i ett senare skede, men sen när ni släpper systemet och kunden vill ändra på det. Har det då varit en risk att kunden inte är målmedveten, att ni får omarbeta saker och ting som kostar tid och resurser?
Jag upplever inte det, men det är också en fördel med agil utveckling, vi har ju kontinuerlig kontakt med kunden. Genom att ha en sån
71
kommer 5 månader senare och säger att vi vill ha så här. Jag känner att det är ganska bra att göra så, involvera kunden i det mesta.
I2: Kommer du på några andra generella risker förutom de du tagit upp?
R: Ja det kanske är en risk att jobba agilt att man inte har ett långsiktigt mål utan man jobbar och är så fokuserad på sprintarna för sig att man tänker att den är sprinten ska göra såhär och inte ser den röda tråden. Jag tror att vi har ju en utvecklingsboard och en förvaltningsboard, vi försöker ju hålla samman mellan dom då och jag känner ju att man får ju det ändå. Jag tror att det kan vara en risk i just agil utveckling då.
I2: I och med att ni hålle på med både systemutveckling och förvaltning, det är en komplexite i sig. Ser du det som ett riskområde i och med att man tar båda begreppen och jobbar med dom parallellt?
R: Både ja och nej, alltså förvaltning då kan vi ju upptäcka nya behov och då kan vi ju utveckla efter det då . Men samtidigt som jag sa tidigare så får man ju se till att det inte förstör något i den gamla koden. Det måste ju alltid finnas nå röd tråd i vad som ska göras och förstå liksom komplexiteten i just pension då.
I2: Självaste risker relaterat till buggar och buggar som dyker upp efter testingen, existerar dom?
R: Ja det förekommer, sen lite som jag pratade innan om att det är
komplext och att det är en bugg som inte fanns i testing kan uppstå i och med att vi lägger till en annan funktionalitet och det är därför det är viktigt att vi har bra krav, vi tänker hela vägen liksom att det här kanske påverkar det där, vi måste kontrollera att det faktiskt inte förfaller det här. Det tycker jag att man löser med en bra teknisk arkitektur och bra krav.
I2: Hur många systemutvecklare är ni här som håller på med den djupa programmeringen?
R: Ja vi har ju, det mest tunga är ju back end och beräkningar för pension och jag har suttit mest med front end men även lite med back end, jag tycker att det är bra att man får lite grepp om hela systemet. Men vi är en utvecklare som blir pappaledig nästa vecka och då
72
kommer det bli jag som jobbar fulltid. Sen har vi ju två till som jobbar, dom kan ju systemutveckling men dom jobbar med förvaltning.
I2: Tycker du att ni är för många eller för få systemutvecklare?
R: Just nu är vi lagom, jag tror att när den här killen går så kommer vi behöva en till. Vi har grejor att göra, det tror jag också är en trygghet i sig att veta att det finns saker som ska göras.
I2: Skulle du kunna påstå att det finns risker i och med att man är för många eller för få?
R: Ja det gör det utan tvekan, det är ju beroende på, från projekt till projekt, hur många det behövs. Det kan ju vara för många och det är ju inte heller bra, kanske är värre om man är för få, jag vet inte.
I2: Skickligheten av programmerare, lite bakgrund till det är att jag har snackat med några som outsourcat sina koder till indien, och de är väldigt otydliga, dom ser risker med det. Men nu är ju ni
svenskutbildade kodare, är det bättre att ha det så i och med att det blir lättare att förstå koder och så här, ser du några risker relaterat till det? R: Ja jag tror att det är bra att det är samma personer som skriver koderna hela tiden för då fårman så här överblick på ett annat sätt, tex den här modulen ska vi outsourca till indien. Då kanske dom missar att den här ska funka till det här också. Finns väl fördelar och nackdelar tror jag, men jag tror att just här är det bra att vi kör alla på samma plats liksom.
Person B
PS: Vilka risker ser du existera i en sprint? A: Under sprinten bara eller utanför också? SY: Specifikt under sprinten.
A: Att man inte får in alla kvar. Att vi saknar någonting och att det inte täcker in allt. Fel som inte upptäcks kan vara en risk. PS: Då tänker du på kravspecifikationen specifikt eller? Ni som systemutvecklare tar del av kraven att dom inte upptäcks eller att någonting missas?
73
SY: Vem är det som har brist på kunskapen som blir en risk (riskägare)? A: Det kan vara både utvecklare och dom som testar. Hela kedjan, så att säga.
PS: Vilka risker skulle du klassificera som generella risker respektive specifika risker?
SY: Du var inne lite på dom specifika riskerna. Hur ser dom generella riskerna?
A: Generellt? Att kompetens försvinner, kanske. Vi är väldigt
kompetensberoende. Bugrelaterade risker finns det också; att saker blir fel.
SY: Hur ser du på dom potentiella säkerhetsrelaterade riskerna? A: Vi har inte direkt någon direkt bevakning på det. Vi har ett internt system för det. Vi skulle behöva fokusera mer på det, känner jag. SY: Hur ställer du dig till outsourcingen av säkerhetsrelaterade
komponenter?
A: Jag tycker det är bra. Sen kan man ju tycka om dom aktörerna är bra eller dåliga. Vi slipper ju hålla på med det själva, då det kostar mer resurser, kostnader och kräver bredare kunskap. Sen har vi ju infrastrukturen för det.
PS: Ni hade nyligen ett stort omfattande projekt tidigare. Nu vet kunden inte vad dom vill ha, i slutmål och krav, systemstöden till systemet som levereras. Kunden verkar inte vara riktigt medveten om vad dom vill ha och kan inte sätta mål och krav; ni vet inte vad ni jobbar emot. Tror du att det är vilseledande nu; att ni sätter många timmar på utveckling som inte genererar något: A: Till viss del kanske.
PS: Hur påverkas du av att inte ha tydliga slutmål som systemutvecklare?
A: Då får vi bestämma själva lite hur vi ska göra och hur det sker. PS: Så ni uppskattar om hur saker skall göras och måste ändra på dom sen igen?
A: Ja, till viss del; man tar det iterativt. Kunden har ett förslag om hur det skall fungera sen sker det en lagförändring om hur det skall fungera. SY: Har du någon uppfattning om risker knutna till att kunden kommer med ett krav, ni levererar det kravet och kunden påpekar att det inte är det dom vill ha. Missuppfattning mellan kunden och
74
A: Jag upplever inte att det sker. Dock är det tredjepartsleverantörer som är inblandade och då kan det bli otydligheter. Om vi ska integrera mot en bank till exempel.
SY: Du ser det som en risk också? Om en yttre intressent – en tredje part – är delaktig också?
A: Ja, det kan bli stökigt då.
SY: Ser du någon risk knutet till komplexiteten av ditt arbete? A: Det är om någon inte förstår koden t.ex., det är en risk.
SY: Vad är utfallet av en sån risk? T.ex. om projektledaren inte förstår koden och det som sker i den.
A: Kanske att något blir felestimerat. Det blir lite långsiktiga effekter; att man behöver bygga om längre fram.
PS: Kommunikation. Om ni har kravspecifikation om att något behöver ändras i systemet. Som att en ändring påverkar en annan del i systemet. Att det slår på andra ställen?
A: Det händer absolut, det är en risk. En ändring kan slå på ett helt annat ställe.
SY: Ser du någon risk kring systemutvecklarnas konsultation av experter om specifika områden som ni behandlar inom kundens ramar? A: Jo, då är man personberoende. Och då är systemutvecklaren beroende av konsultation i vissa fall så som regelverk, matematiska formler specifikt för beräkningar och så vidare. Vi använder standardformuleringen i formler och sånt, så det går ju ta in en annan om vi tappar en expert inom det område.
PS: Om flera är inne och håller på med systemet då? Flera kockar i köket.
A: Ja, då är ju inte heller så jättebra.
PS: Hur upplever du tidsestimeringen med kravspecifikationerna? Är det ofta ni överskrider den?
A: Jag har dålig uppfattning om det. Det finns ingen riktig tidsestimering.
SY: Hur många systemutvecklare här skulle klara av göra det du gör? A: Kanske en.
SY: Hur tror du projektet skulle påverkas av att tappa en sådan nyckelperson?
A: Det skulle påverkas men inte stanna upp helt. Det skulle vara bra om det fanns fler systemutvecklare, på grund av uppsägning eller sjukdom,
75
så att projektet inte stannar upp helt eller tappar effektivitet. Jämnare kompetensspridning.
SY: Skulle projektet flyta på bättre?
A: Kanske. Det kan ju vara en utmaning om man är fler.
Person C
SY: Vilken omfattning har du på företaget?
Q1: Min roll? Jag är SCRUM master för åtagandet, jag är också ansvarig testledare för åtagandet. Jag är ansvarig för alla tester och för dom som testar, så att det görs på rätt sätt enligt våran metod. Jag testar även systemet. [<Denna del kanske skall tas bort, då den intervjuade enkelt kan identifieras?>]
SY: Vilken metod arbetsmetod är det ni tillämpar? Q1: Vi arbetar med SCRUM.
SY: Vad ingår i ditt dagliga arbete?
Q1: Som SCRUM master ingår det att hålla i dagliga möten på femton minuter, stämmer av vad man ska göra under dagen och hur det går – om det finns några hinder. Det är jag som styr mötet och ser till att det inte styr över och att gruppen inte fokuserar på för många detaljer. Sen håller jag även i andra möten, kallar till återblickar, demon av det vi har gjort under sprinten och sprintplaneringarna. Vi har även
sprintplaneringar och försprintplaneringar som jag håller i och kallar in. I själva åtagandet jobbar jag med test och planerar upp tester av
systemet och jobbar med krav om systemet och dokumenterar. [<Denna del kanske skall tas bort, då den intervjuade enkelt kan identifieras?>] SY: Vilka risker upplever du inom den generella arbetsformen av SCRUM. Det övergripande genom hela processen, så kan det uppstå diverse olika risker i relation till tiden, till exempel att man inte hinner med tiden. Hur upplever du det?
Q1: I SCRUM, då ska man under en sprint jobba i 3 veckors sprintar. Då tar man på sig att man klarar av det man tagit på sig under sprinten. Det som kan vara en risk i det är att det kan vara svårt att estimera tiden för varje story; hur lång tid den tar. Så att man kanske inte hinner med det man åtagit sig, då har man misslyckats enligt SCRUM. För oss nu, vi har inte kunden riktigt med oss – kunden har inte en riktig syn in på dessa sprintar – det är mer för teamet för att veta hur vi ska hinna med det vi åtagit oss. Men jag kan tänka mig att om man har en kund som är väldigt involverad och förväntar sig att man levererar, så kan det bli
76
problem om det är svårt att estimera hur lång tid varje del tar. Sen jobbar man nära teamet, om teamet inte kan arbeta tillsammans blir det också problem. Det spelar stor roll vilka som är i teamet.
SY: Gällande tidsestimeringen för varje story; approximerar ni tiden som kommer krävas för varje sprint eller för varje story?
Q1: Just nu gör vi inte det, eftersom allt är osäker gällande krav från kunden i och med det nya avtalet. Vi lägger inte ner någon tid på att