Kan du berätta vem du är och var du arbetar med?
Ja, [namn] heter jag, jag jobbar som utvecklingschef på [verksamhet]. Eh, så jag är chef för en avdelning med 30 personer ungefär som sysslar med mjukvaruutveckling för allmänna nyttigheter så vi har […] system för elhandel, fjärrvärme, vatten, avlopp, bredband, renhållning… den typen av tjänster.
Hur många år har du arbetat inom detta?
På det här jobbet så har jag varit i ett år, innan dess så var jag agil coach och scrum master och jobbade bara med det i tre år ungefär. Och innan dess så har jag jobbat som utvecklare, eh och lite scrum master vid sidan av i ah 15 år kanske. Nåt sånt.
Vilka slags agila metoder har du använt dig av ute i arbetet?
Eh ja, vad har jag jobbat med? Totalt sett under karriären eh, extreme programming har jag jobbat med, scrum har jag jobbat med, eh, scrumban, kanban, lean, ah det är väl i huvudsak det. Är det mest Extreme Programming eller är det Scrum? Det kanske är svårt att säga?
Jag skulle säga att det är mest Scrum.
Vilka praktiker inom Extreme Programming har du arbetat med?
Ja, jag får väl säga typ alla. Nä, men om man går igenom dem så kollektivt kan man väl skapa sig en grund, det har man på alla ställen nu för tiden. Eh, kodstandarder är samma sak där, det är också någonting som man jobbar med. De senaste fem åren skulle jag väl säga att det smalnat av ganska mycket. Nu är det ju ganska mycket clean code som gäller, sånt som kodstandard. [..] continues delivery, ja, det har också kommit ganska mycket, ganska vanligt skulle jag säga. På många ställen. På senare år. Där jag jobbar nu så jobbar vi ju mot det. Just nu har vi gått från… när jag började på [verksamhet] så hade de release var fjärde månad […], så nu är vi nere på en release varje sprint, vi har tre veckors sprintar och sen under 2019 så kommer vi växla över till en veckas sprintar och sen kommer vi gå till continues delivery kanske hösten 2019. Yes, ha mer testdriven utveckling, ja, det är mindre självklart än vad man skulle kunna tro faktiskt. När jag har jobbat med utvecklare har jag jobbat mest testdrivet, men många gör det inte. Det tycker jag är lite synd. Små releaser får man ju automatiskt när man har continues delivery. Enkel design, samma sak där. Jobbar man testdrivet så får man enkel design på köpet. Sen har jag jobbat i vissa organisationer som utvecklar där man haft med arkitektdesigner som har gjort design också. Skulle säga att det funkar nästan aldrig. Så dom stora projekten, riktigt stora projekten som har kört på det viset, så har man kört på ett tag, några år kanske och sen har man liksom börjat närmat sig release och deadline, och så säger man nej, nu får utvecklarna göra som dem vill. Nu måste vi leverera något liksom. Sustainable pace är väl också något som man försöker jobba med, långt ifrån alla som gör det, jag tycker att det är viktigt, att man som chef, scrum master och agil coach att man jobbar med att folk inte liksom jobbar för mycket, att de inte stressar för mycket, att man liksom ska trivas. Man ska ha kul på jobbet och man ska ha ett liv utanför jobbet också. Det ska inte bara vara liksom sitta och knacka kod hela dagarna. Sen är det väl, jag har jobbat mest i dem branscherna med utveckling som kanske upplevs som
32 lite tråkigare på något sätt. Alltså jobbat med administrativa system och jobbat för myndigheter och storföretag och sådär. Jag har ändå en uppfattning att det är mindre sustainable på liksom mer hippa bolag om man säger så. Alltså dem som gör spel och appar och sånt. Då tänker man att folk kan komma ut och jobba för skitpengar och jobba 60 timmar i veckan liksom, för det är så många som vill ha dem här jobben. Men folk tenderar att bränna ut sig på det.
Du pratade lite om att ni programmerade offshore, hur programmerar ni offshore? Är det parprogrammering?
Ja.
Hur kommer det sig att ni gör det?
När jag började så hade man egentligen team som var offshore och team som var onshore. Så, uppdelat. Sen ändrade vi på det så att nu har vi halva teamen är onshore och halva teamen är offshore i varje team så att säga. Så vi har fyra indier och tre svenskar i varje team. För att kunskapssprida och för att få ah men mer flyt och bättre förståelse i utvecklingen. Våra svenska utvecklare har inte jobbat så mycket med den nya versionen av systemet utan det var mest indierna som hade byggt, så de kunde inte det. Samtidigt så märker vi när vi har indier inne att liksom när vi skriver en behovsbild så hade de ofta liksom svårt att förstå den. För saker som vi tar, ser som ganska självklart, ah men det ska jag betala med Swish liksom, alla vet ju vad Swish är så det behöver man ju inte beskriva, men en indier har ju ingen aning om Swish. Så googlar dom, så får dom en spec på svenska liksom och ah, haha… Så därför har vi slagit ihop teamen så att de jobbar ihop så att säga.
Så det är för bättre förståelse och mer flyt i utvecklingen och…?
Bättre kunskapsspridning. Både om liksom behoven och om koden.
Vad har ni använt er av när ni har parprogrammerat mellan Sverige och Indien?
Skype. Det är det?
Mm.
Har man skärmdelat då eller?
Ah.
Så då är det ju en person åt gången bara som kan koda. Så då byter man inte, eller byter man liksom förare?
Ah det kan man göra. Man kan ju ge kontroll i Skype till den andra. Så den kan köra remote. Agilt
Varför tycker du att det är viktigt att arbeta agilt?
Ja. För att få något gjort.
33 Ja, det tenderar att inte bli så mycket gjort. Man lägger väldigt mycket tid på att liksom, man börjar i början på sitt projekt, det är väl egentligen samma sak om man jobbar med RUP, man skriver ner alla sina krav och så lägger man ganska mycket tid på att skriva krav och så ska dem bli fina och bra liksom. Och så drar den fasen ut lite på tiden. Lite mer. Och sen så ska man göra en arkitektur och då lägger man massa tid på arkitektur, så börjar man få mindre och mindre tid fram till deadline. Så när man kommer fram till designen, men då gör man bara design på 80% av arkitekturen för resten har redan […] för att man ska hinna med. Så när man kommer ut till slutändan av produkten så kanske man bara har med 30% av scopet, men man har ändå lagt jättemycket tid i början på att skriva krav på 100% av scopet och slängt 70% av det. Och när man väl har levererat det till slut, då har det gått tre år, då har marknaden förändrat sig, det man har byggt är irrelevant, man kanske […] men det är inte speciellt användbart. Så det är snabba cykler för att skapa värde fort, kunna realisera sitt värde fort. Alltså bygger man en liten produkt och börjar sätta den i hemmakunderna, då kan man också börja dra in pengar liksom efter kanske inte en sprint, men efter två månader så kan man bara tjäna pengar på sin produkt. Istället för att vänta tre år innan man får in några pengar. Då har man, då kan man investera dem pengarna igen så att säga. Men också som sagt för att personalen ska må bra. Det är roligare att jobba när man ser resultat, man får feedback, man kan ha […] på arbetet osv. På vilket sätt är de agila värderingarna (ur det agila manifestet) viktiga enligt dig? Spelar det fortfarande roll exakt vad det står där?
Ja det tycker jag att det gör. Skulle säga att det stora misstaget som många gör, där det inte funkar med Scrum, oftast är det Scrum, man kan inte så mycket så ska man jobba agilt, så plockar man upp Scrum för det är vad alla andra gör och där finns en enkel manual liksom. Och så gör man bara precis dom sakerna som står i Scrumguiden, men man får inte ut något av det om man inte vet varför man gör det. Man kan inte tolka och anpassa om man inte förstår bakgrunden. Så jag tycker att värderingarna är grundläggande, man behöver nästan ha dem först innan man har metod.
Om man ska jobba agilt ute i arbetsmiljö, vet alla då som är inblandade vad det agila manifestet är?
Nej.
Man blir tillsagd av chefer och så vad man ska göra och hur man ska arbeta?
Ja, ganska mycket så är det så.
Så man behöver inte vara påläst om detta innan man ska jobba liksom?
Nej det måste man väl inte, men det hjälper.
På vilket sätt är de agila utvecklingsteknikerna viktiga enligt dig? Du skulle kunna ta några exempel på tekniker som är viktiga just för dig.
Jag skulle säga att testdriven utveckling kanske är den allra viktigaste metoden för utvecklare att behärska. Och det är viktigt för att få kvalitet i det arbetet man gör. Det är ganska lätt på ett sätt att skriva kod så länge man sitter själv i liten grupp med 3-4 stycken, så skriver man någonting i några veckor eller några månader. Men när man hamnar i projekt med hundra
34 programmerare som sitter i fem år och bygger någonting, då är det så mycket kod, så mycket grejer man inte känner till, så mycket komplexitet i systemet så det måste finnas kvalitet genom hela vägen så att säga. Och då ser man att man måste ha tydlig kod, man måste ha kod som har bra täckning med enhetstester så att man kan, så att man inte är rädd att ändra i koden. När man har sett det och börjar backa tillbaks i mindre och mindre system så ser man att det finns en fördel i att jobba på det här sättet, även om man bara gör någonting som är pyttelitet. Det blir rätt och det blir hög kvalitet på den. Så det skulle jag säga är den allra viktigaste delen av den tekniska, praktiska delen av det agila.
Är det de agila värderingarna eller de agila teknikerna som är viktigast inom agil arbetsmetodik enligt dig?
Nej, man kan inte ha den ena utan den andra. De hör ihop liksom.
Men om man inte är så påläst, vilken är den viktigaste delen att försöka förstå?
Nej man måste göra båda delarna parallellt. Man får dela sin uppmärksamhet. Lite av varje. Vad skulle du säga krävs för att man ska kalla sig agil i sitt arbete?
Jag skulle säga, har man läst och förstått och håller med liksom om det agila manifestet, då tycker jag att man kan kalla sig agil.
Parprogrammering
På vilket sätt bidrar parprogrammering till ett agilt arbetssätt?
Alltså det bidrar ju till att man jobbar som ett team, viktigt. Man kan inte vara team utan att man jobbar tillsammans för att lösa en uppgift och då måste man parprogrammera. Och då ser man också man får feedback av andra, man producerar högre kvalitet för att man får ett par ögon till på koden. Man får bättre framfart, man fastnar inte så mycket i sina problem där man sitter utan man kan bolla lite, få ut någonting av någon annan, man sprider kunskap inom teamet. Jag skulle säga att man bidrar till att kunna leverera, fokusera på att lösa en uppgift, leverera den och sen ta sig nästa.
Hur mycket parprogrammering har du arbetat med?
Det har varit lite olika. Av och till ganska mycket. Skulle säga att man parprogrammerar inte 100% av tiden oftast, men någonstans mellan 30 och 50% av tiden skulle jag säga är det optimala. Det beror lite på vad man jobbar med. Har man mycket förvaltning och man sitter liksom, nu har vi hundra småbuggar som vi ska fixa den här sprinten, då kanske man inte behöver parprogrammera, det är ganska enkla saker, det blir mest att man ska leta i koden och hitta vad man ska ändra på. Så då kanske det inte är så effektivt. Eller man sitter och gör någonting som är repetitivt men ganska enkelt liksom, medan man, när man jobbar på nya områden, man behöver tänka till lite, man behöver ta in någon ny i teamet och lära dom hur det ser ut osv. då är det mycket bättre att fokusera på parprogrammering.
35 Ja, inte bara problemlösning. Men problemlösning eller där man behöver sprida kunskap i teamet.
Vad är din uppfattning om parprogrammering på distans?
Det funkar ju inte lika bra som att sitta i samma rum, så är det ju. Det är ju mycket lättare, man har ju en annan kommunikation med människor man sitter i samma rum med, så är det ju. Speciellt när man har ett, parprogrammerar med en människa som pratar ett annat språk, och så har man en kultur och sitta i ett annat land och så nu har vi indier, och vi kan bara parprogrammera fyra timmar om dagen för att sen går dem vid lunch hem. Då är klockan sex och dem slutar jobba. Och det är alltid det, tekniken strular, det är raspiga telefonlinjer, folk sitter i kontorslandskap och det skramlar och det är folk som pratar bredvid och liksom det ja. Det funkar, men det funkar inte lika bra som att sitta i samma rum.
Är det mest tekniken då eller är det att man inte har den fysiska face-to-face, sitta och peka på skärmen…?
Både och skulle jag säga. Tekniken går ju att lösa, sen det här att man inte sitter i samma rum, det är svårare att fixa.
Finns det några ställen där det funkar enklare och bättre att parprogrammera på distans?
Inte som jag har upplevt. Sen som sagt, det skulle för min del vara enklare om man satt i samma tidszon t.ex.
Så om man sitter i Stockholm och Malmö så skulle det vara enklare?
Ja. Om vi håller oss till Sverige så har ju de flesta kontoren liksom en bra stabil internetförbindelse. Då blir det inte ett problem. Det finns grundläggande förutsättningar som rent tekniskt ska få det att funka.
Vilka säkerhetsrisker ser du i att parprogrammera över internet?
Nej, det kan jag inte säga att jag tycker.
Vi tänkte lite på det, kanske om kod skulle läcka…?
Nej. Risken att någon skulle avlyssna sessionen är ju försvinnande liten. Lyckas de så förtjänar de att få koden.
Enligt din uppfattning, till hur stor utsträckning skulle du säga att parprogrammering idag används som ett verktyg för att utveckla mjukvara?
Min uppfattning är för lite skulle jag säga. Man bör jobba med det, som sagt kanske inte 100%, men någonstans mellan 30 och 50% kanske. Och sen växla liksom att har man, att man har parprogrammerat kod, då behöver man inte kodgranska samma kod, men har man inte parprogrammerat, då kanske man skickar iväg på kodgranskning istället. Man har ju olika mekanismer för att se till att det är flera personer som granskar koden innan den checkas in och används liksom.
36 På vilket sätt tror du projektets storlek påverkar nyttan av molnbaserad virtuell parprogrammering?
Det vet jag inte. Nej jag tror inte att det spelar någon större roll, därför att man parprogrammerar ju nästan alltid med någon i samma team som en själv ändå.
Vi kanske tänkte lite att om koden blir lite sämre om man sitter på distans och kodar. Om många team gör det, då kanske helheten blir lite sämre. Att det i längden kanske inte blir lika bra resultat om det är liiite sämre att parprogrammera på distans.
Ja, det blir bättre resultat än om man sitter var och för sig.
Ja, jo. Men du tror inte att det har någon signifikant skillnad?
Nej, det tror jag inte.
Vilka potentiella problem/risker finns med molnbaserad virtuell parprogrammering?
Nej, egentligen inte. Det är klart, rent tekniskt så kan ju saker alltid sluta att funka. Det är samma sak där, det är lättare att sitta vid samma dator och jobba tillsammans för att, ens egen lokala maskin upphör oftast inte att fungera. Men har man en maskin i molnet så ska man ha två internetförbindelser och det är mycket som kan strula på vägen. Det kan bli mer störningar, som är frustrerande på det sättet om det inte funkar som det ska.
Ser du någon anledning till att man skulle vilja använda sig av molnbaserad virtuell parprogrammering?
Alltså, jag vet egentligen inte varför man skulle vilja ha maskin i molnet och programmera på. Som sagt när vi kör på distans, då har vi ju en skärmdelning istället. Så man delar ju på samma dator, eller släpper in den andra på sin egen lokala maskin. Jag vet inte vad fördelen skulle vara att ha en maskin i molnet.
Vi tänkte delvis, man kan parprogrammera från vilken plats som helst, och du behöver aldrig ha någon kod på din egen dator. Ett företag kanske inte behöver köpa in dyra datorer? Ekonomiska aspekter, man blir extra tillgänglig osv.
Ja, samtidigt som sagt så har man ju den risken att man inte har någon dator alls. Alltså man har inte tillgång till sin kod överhuvudtaget. Har man en lokal dator där man har laddat hem koden då kan man jobba, man kanske inte kan checka in det, man kanske inte kan se andras förändringar i koden men man kan fortsätta jobba några timmar utan att man har en internetförbindelse. Jag tycker att det är en intressant diskussion att man ska köpa en billig dator till sina anställda. Ni ska jobba som programmerare?
Ja.
Tycker ni att det är kul med datorer? Ja.
Så om ni fick komma till ett företag, du får välja vilken dator du vill. Bara take it, det får kosta precis vad det vill upp till kanske 40 000, eh så får du en ny dator vartannat, var tredje år. Och
37 så får du 500 kronor mindre i lön på det stället. Jämfört med ett annat ställe, där du får, ah men du får bara en tråkig IBM ThinkPad liksom. Skulle du tycka att det var värt 500 spänn i månaden att få vilken dator du då vill?
Ja. Utan tvekan.
Så om man tänker den där datorn för 40 000, den kostar ju bara företaget 30 000 eller sådär när man tagit bort moms, för det behöver man inte betala för, så har man lite mängdrabatt, så kanske 25 000 betalar företaget för den där. Och den där ThinkPaden är ju inte gratis heller, så de kanske betalar 15 000 extra över en treårsperiod. Det är 350-400 kronor i månaden. De går redan plus på den där femhundringen. Men dom där 40 000 ska du betala skatt på om du skulle köpa samma dator, då är du uppe i en lön på kanske 100 000, 80-100 000. Så ska de lägga arbetsgivaravgifter på det, och då är man uppe i 120 000 kanske. Så att du skulle köpa den skulle kosta mig som arbetsgivare 3 000 kronor i månaden, men jag kan ge dig 500 spänn mindre i lön och köpa samma maskin för dom pengarna. Så varför skulle man vilja billiga skitdatorer och ge till sina anställda när man är i en bransch där folk vill ha roliga leksaker? Mm, det är ett bra argument. Vi tänkte mycket på detta och en tanke som kom upp var om man t.ex. ska lära studenter så kan det vara bra om man bara kan logga in på ett program på datorn och koda därifrån tillsammans.
Jag har svårt att se nyttan med det och en molnmaskin kostar ofta ganska mycket pengar. Man kan stänga av den när man inte använder den naturligtvis men det kostar förvånansvärt mycket att ha en maskin snurrandes i Azure eller ABS eller vad det nu är. Men det är inte en dålig idé om man ska ha det tillfälligt och om man ska samla utvecklingsmiljö som är ihopsatt och så ska det komma in ah men en massa studenter kanske, olika människor som ska jobba i samma kod. Då kan det mycket väl vara en bra idé.
Varför tror du att molnbaserad virtuell parprogrammering inte är en välanvänd arbetsteknik inom agil arbetsmetodik idag?
Ser inte nyttan med det. Och jag skulle tro att de allra flesta sitter ändå i samma lokal. Det är mycket enklare att bara dela datorn. Man behöver inga tekniska hjälpmedel. Man bara tar