Distribuerad systemutveckling

Distribuerad systemutveckling är ett begrepp som numer går hand i hand med IT-projekt. Att ett IT-projekt är distribuerat innebär att projektets medlemmar inte befinner sig på samma plats, utan att de arbetar från olika platser (Lings, et al., 2006). Lings et al. (2006) menar att dessa olika platser inte behöver innebära enorma distanser såsom mellan länder eller

kontinenter, utan det kan även inkludera olika kontor i samma stad (ibid.). Man kan också tala om tidsmässigt distribuerade projekt vilket exempelvis kan innebära att projektmedlemmar inte har möjlighet att arbeta på samma tider eller att projektet kan vara så pass geografiskt distribuerat att det befinner sig i flertalet tidszoner (ibid.).

En anledning till att organisationer väljer att arbeta distribuerat presenteras av Jiménez et al. (2009) som tillgänglighet av resurser, ofta till ett billigare pris (Jiménez, et al., 2009). Dessa fördelar kommer dock inte utan nackdelar, en distribuerad organisation uppstår unika situationer som måste hanteras. Jiménez et al. (2009) sammanfattar dessa i tio

problemområden; kommunikationsproblem, gruppmedvetenhet, hantering av

mjukvarukonfiguration, kunskapshantering, koordination, kollaboration, projekt- och processhantering, processtöd, kvalitetsuppföljning samt riskhantering (ibid.). Koordination påverkas enligt Jiménez et al. negativt i den mening att det är svårare att uttrycka exakt vad som ska göras (ibid.). Detta grundas i problem med kommunikation, gruppmedvetenhet och en komplex organisation (ibid.). Liknande problem tas upp av Elizabeth Woodward, Steffan Surdek och Matthew Ganis i boken A practical guide to distributed Scrum (2010) – en publikation från IBM12. Man påpekar där att Scrum som modell inte hjälper till att lösa dessa problem men att det med agil utveckling kan vara lättare att finna problem snabbt och åtgärda dem (Woodward, et al., 2010).

En studie av distribuerade IT-projekt har också genomförts av Audris Herbsleb och James Mockus (2003) där en av frågeställningarna var om distribuerat arbete tar längre tid att

genomföra än arbete inom samma kontor. Deras resultat visade på att det inte var någon större skillnad när det kom till antal hinder, dvs. när anställda behövde uppsöka ytterligare

information från en kollega eller behövde att en kollega skulle ta ett beslut, mellan det egna kontoret och det geografiskt skilda kontoret (Herbsleb & Mockus, 2003). Däremot visade det sig att den tid det tog att avlösa dessa hinder, för att kunna fortskrida i arbetet, var bet ydligt större när det involverade distribuerat arbete och resurser (ibid.). De två organisationer som de undersökte visade att det kunde ta mer än dubbelt så lång tid jämfört med att enbart jobba lokalt (ibid.). De genomförde även en enkätundersökning som visade på samma resultat, att distribuerat arbete medför mer förseningar rent tidsmässigt gentemot lokalt arbete (ibid.). Lings et al. (2006) har, utifrån tidigare litteratur, sammanställt framgångsfaktorer som är viktiga att se till när det kommer till distribuerade projekt. Dessa presenteras nedan och baseras helt på (Lings, et al., 2006).

Clarify all understandings är en viktig aktivitet i ett distribuerat projekt. Då utveckling kommer ske på olika platser måste alla involverade förstå målet med projektet och vad som ska skapas. Detta kan lösas genom att klargöra vad som ska göras på varje plats, samt att man tillsammans kommer överens om vilka processer och liknande man ska följa. (Ibid.)

Use cultural mediation påtalar att kulturella problem kan uppstå, och att det är effektivt att ha en slags mellanhand mellan olika kulturer. Detta innebär att man kan ta en person från det ena kontoret och placera denna person på det andra kontoret. Denna person kan då agera

mellanhand mellan de två kontoren, och är menad att reducera kulturella skillnader. (Ibid.) Have a clear distribution rationale betonar att det bör finnas en baktanke med att arbeta distribuerat. Man bör bara jobba distribuerat i projekt som är strukturerade, lätta att definiera samt möjligheter till att bryta ner projektet i mindre uppgifter. En viktig del, för att jobba distribuerat, är att det finns ett gemensamt språk mellan de distribuerade projektgrupperna. Likaså måste delar av arbetstiden överlappa mellan de olika arbetsplatserna, om inte bör man undvika att jobba distribuerat. (Ibid.)

Facilitate human communication behandlar den kommunikation som kommer ske inom projektet. Man kan öka kommunikationsverktygs påverkan genom, t.ex. i en telekonferens, använda sig av en person som försöker få alla att jobba mot samma mål, genom att minska missförstånd och att lösa konflikter. Även språkkurser kan ge positiv effekt, och genom att öka informell kommunikation mellan deltagare så kan formell kommunikation, t.ex. möten, öka kvalitetsmässigt. (Ibid.)

Manage processes belyser att det bör finnas någon som är huvudansvarig för projektet, men även detta kompletteras med lokala projekt- och gruppledare. Man bör även planera möten då arbetstiden överlappar på de involverade arbetsplatserna. Även inkrementell utveckling och korta iterationer är att föredra. (Ibid.)

Develop a sense of teamness vill belysa att man måste skapa en samhörighet inom

projektgruppen. Bland annat nämns att man bör skapa en projektportal, där man ska kunna finna information om projektmedlemmar, viktiga händelser i projektet, projektets status samt planeringsinformation. Man bör även där kunna finna de beslut som tagits i projektet, något som bör vara lättillgängligt. (Ibid.)

Encourage temporary collocation är ett sätt att reducera framtida problem och bör inkludera alla i projektgruppen. Det innebär att man placerar projektmedlemmarna, som annars jobbar distribuerat, tillsammans under en begränsad tid på en och samma plats. Det effektivaste sättet anses vara att genomföra detta i början av ett projekt, även om det också går att genomföra regelbundet under projektets gång. (Ibid.)

Develop an effective tool base behandlar koordination, och att det bör finnas enhetliga verktyg för att kommunicera mellan arbetsplatserna. Viktigt är att man väljer verktyg som löser de potentiella problem som upplevs. (Ibid.)

Schwaber (2004) delger sina erfarenheter av att arbeta distribuerat i med Scrum och påpekar då att man främst bör tänka till kring om man verkligen behöver vara distribuerade

(Schwaber, 2004). Till största möjliga mån bör distribution minskas (ibid.). Något han också lägger vikt på är att implementera en infrastruktur som låter de distribuerade