På fallföretaget sker mjukvaruutvecklingen internt på företaget. De mjukvaruutvecklare som utvecklar inbyggda system sitter med i tre olika utvecklingsprojekt som i denna rapport kommer att kallas för projekt A, B och C.
Ambitionen med att arbeta med återanvändbara komponenter togs av projektledaren vid uppstarten av projekt A. Detta beslut togs på grund av att produktägarna såg ett behov av att minska utvecklingstiden för utvecklingsprojekt. Därav uppkom initiativet av att införa en komponentbaserad utveckling i projektet.
Urvalet av mjukvaruutvecklare som ingår i respektive projektteam har en kunskap inom ett visst produktområde. Det vill säga mjukvaruutvecklare inom Projekt A som utvecklar en fordonsapplikation är utvalda på grund av deras kompetens, erfarenheter och domänkunskaper inom fordonsapplikationer. På samma sätt ser bemanningen och organisationen ut även i Projekt B som utvecklar infanteriapplikationer, samt Projekt C som tar fram antitankapplikationer.
Projekt A och projekt B startades ungefär samtidigt och projekt C har nyligen startat. De tre projekten arbetar med tre olika produkter som skiljer sig i hårdvara och mjukvara. Alla projekten fick som direktiv att utveckla och sen dela med sig mjukvarukomponenter mellan sig. Det var ett nytt arbetssätt som skulle skapa olika fördelar för företaget, bland annat att spara kostnader, implementera ett långsiktigt tänk, effektivisering, minskad utvecklingstid och framtagning av enhetliga produkter. Alla nämnda fördelarna gynnar kunden i slutändan, eftersom de får produkten fortare och mjukvaran i produkterna är enhetlig och fungerar på liknande sätt.
I nuläget finns det ett fåtal komponenter som ses som återanvändbara komponenter och delas mellan projekten. Dessa komponenter är:
• Operativsystem • Drivrutiner
• Filhanteringssystem
På fallföretaget har det historiskt sätt funnits olika produktlag med mindre team som har löst projekt efter projekt. Teammedlemmarna bestod av en mjukvaruutvecklare, en elektronikingenjör och en applikationsingenjör. Här har mjukvaruutvecklarna utgått från personliga mjukvarukomponenter, som har lett till ett tankesätt där det krävs mer återanvändbara komponenter. Ytterligare en faktor för att påbörja en utveckling av återanvändbara komponenter har varit när det kommit in ny personal eller inhyrda konsulter, då anställda på fallföretaget upplevt en svårighet i att förklara hur systemet är uppbyggt. Därför bestämdes det att projekten skulle inleda ett arbete med att använda återanvändbara komponenter.
4.2 Empiri
I nedföljande avsnitt presenteras den insamlade empiriska materialet utifrån intervjuer med mjukvaruutvecklarna i de berörda projekten. Det kommer att behandla arbetssätt, samarbete, ägarskap, befogenhet och beslutstagande med fokus på återanvändbara komponenter.
4.2.1 Aktuella arbetssättet för framtagning av återanvändbara komponenter/
Samarbete och Kommunikation mellan projekten
I nuläget finns det utmaningar med det gemensamma tänket kring komponenter enligt mjukvaruutvecklarna. Det saknas kunskap kring de andra projektens mjukvara, arbetssätt och progression i projekten. Det finns oftast ingen kommunikation mellan utvecklare när och om återanvändbara komponenter skall tas fram. I nuläget saknas det strategier för hur återanvändbara komponenter ska sättas upp och göra dem generella. Flera av de intervjuade nämnde att det saknas en standard kring hur komponenter ska sättas upp.
De komponenter som togs fram styrdes till stor del av projekt A, på grund av att det är en naturlig lösning för deras produkt att utveckla en komponent.
För att kunna utnyttja återanvändbara komponenter finns idag ett versionshanteringssystem, kallat Git. Git tillåter utvecklarna i projekten att skapa Git-repositories. Ett repository innehåller multipla källkodsfiler som tillsammans utgör ett program. Utvecklarna i de olika projekten kan referera till varandras Git-repositories och därmed hämta in källkodsfiler. Funktionen Git erbjuder är ifall en utvecklare hittar en bugg och gör en uppdatering eller förändring av den källkodsfilen, där alla som har refererat källkodsfilen till sitt Git-repository se förändringen samt även se hur lösningen är implementerad. Projekten kan även bestämma ifall de är intresserad av att ta del av uppdateringen eller inte. I ett av projekten skapades ett Git-repository av en komponent som fanns tillgänglig för andra projekt att referera till. Utvecklare i projektet upptäckte senare att ett annat projekt hade kopierat koden och gjort en egen version av komponenten som ändrats och förbättrats. Komponenten var tänkt som en gemensam komponent och skulle förbättras i
versionshanteringssystemet. På grund av bristande kommunikation mellan projekten skapades två egna versioner av komponenten istället för att ta fram en gemensam komponent.
En mjukvaruutvecklare säger:
“Då försvinner idén med gemensamma komponenter. Man vill slippa ha 40 filer som gör samma sak och istället ha en fil som alla kan använda och förbättra hela tiden.”
En viktig del av framtagning av komponenter är samarbetet mellan projektteamen. Det finns indikationer som pekar åt att samarbetet fungerar väl och mindre väl.
Det uttrycks en olik syn på hur samarbetet fungerar men att det inte beror på konflikter emellan projektgrupperna utan snarare att man inte kommunicerar eftersom det inte finns ett uttalat krav att göra det.
En framgångsfaktor för ökad kommunikation är informationsförsörjning. Det är det oftast svårt att få den nödvändiga informationen om vad de andra projekten arbetar med eftersom insynen och kunskapen ibland saknas. Då uttrycks att det inte finns någon anledning att gå över och prata med de andra projekten.En mjukvaruutvecklare uttrycker:
“Att just kommunicera med varandra är ju inga problem, det är ju bara det att det inte händer.”
En annan mjukvaruutvecklare uttrycker:
“Jag springer inte till mina kollegor på andra sidan bron och frågar, vad gör du? Det finns ingen anledning.”
Det uttrycks att det finns kommunikationsbrist från båda sidorna när komponenterna ska tas fram som leder till att den nödvändiga informationen inte nås fram.
Mjukvaruavdelningen har varje vecka ett avdelningsmöte, där ungefär ett 30-tal personer delar med sig av vad som händer i sitt projekt. Det uttrycks från majoriteten av mjukvaruutvecklarna som intervjuats att avdelningsmötet inte är ett lämpligt forum för att kunna skapa diskussioner kring återanvändbara komponenter, på grund av tidsbrist. Det saknas även kunskap kring hur komponenter ska fungera, vilken in- och utdata de har. I idealfallet ska mjukvaruutvecklarna endast kunna ta in komponenterna och ändra i en konfigurationsfil. Dock fungerar det inte så i nuläget utan de får oftast gå in i huvudfilerna och göra ändringar. Den saknade kunskapen kring funktionerna och att komponenten inte har testats på den specifika plattformen påverkar tilliten mjukvaruutvecklarna har för återanvändbara komponenter.
Nyligen bestämdes det, att en ny kodstandard som fastställdes ska följas. Projekt C som startades nyligen har börjat följa kodstandarden. Däremot har både projekt A och B inte gjort det för att de projekten startades för två år sen. Projekt C har tagit ansvar och uppdaterat komponenten till den nya kodstandarden och även tagit fram en översättningsfil så att de andra projekten fortfarande kan ta del av komponenten. Det skapar svårigheter för
delningen av komponenter eftersom att A och B inte kan använda komponenten utan en översättningsfil.
4.2.2 Befogenhet
Ambitionen att arbeta med återanvändbara komponenter har sitt ursprung från uppstart av
projekt A men även inom mjukvaruavdelningens ledning. Mjukvaruutvecklarna upplever
att det inte följs i organisationen, då de inte har bestämt strukturer eller hur arbetet skall genomföras. Det råder en diskrepans bland mjukvaruutvecklarna över vem som har befogenhet till att bestämma om huruvida återanvändbara komponenter ska utvecklas eller inte. Det finns åsikter som pekar på att ansvaret ligger hos projektledaren, som har beslutsmandat för vad som skall utvecklas i projektet. En annan mjukvaruutvecklare uttrycker att det övergripande ansvaret ska ligga på mjukvaruavdelningen, där mjukvaruarkitekten och linjechefen ingår för att bestämma vilka återanvändbara komponenter som ska tas fram.
Ett problem som uttrycks av flera mjukvaruutvecklare att det inte finns uttalat vad som ska utvecklas som återanvändbara komponenter, det saknas även information kring vilka komponenter som finns i nuläget. Det blir tydligt att mjukvaruutvecklarna själva anser att arbetet för att utföra kodning och designspecifikationer ligger på dem men inte beslutet om det ska göras.
En annan utmaning som finns för utvecklingen av återanvändbara komponenter är resursfördelningen. När det inte finns uttalat vad som ska utvecklas gemensamt, fokuserar mjukvaruutvecklaren sig endast på sitt eget projekt och har inte alltid andra projekt i åtanke, på grund av att deras eget projekt måste komma vidare. Även förvaltning och ägarskap av en återanvändbar komponent tar tid och resurser från det aktuella utvecklingsprojektet som skapar en konflikt mellan mjukvaruutvecklaren och mjukvaruavdelningen till på vad utvecklarna ska fördela sin tid på.
En mjukvaruutvecklare uttrycker:
“Men jag tror att det här är en management fråga, det kan inte bara vara […] på oss programmerare. […] Det måste fastslås att det ska vara gemensam”
Mjukvaruutvecklarna har inga resurser till att göra återanvändbara komponenter. Det finns dessutom åsikter att det slutgiltiga ansvaret borde ligga på mjukvaruarkitekten eftersom hen har en helhetssyn över den arkitektur som råder mellan projekten. Hen skulle bestämma om vilka komponenter som ska utvecklas gemensamt för att hen inte sitter med i något projekt och arbetar på en mer strategisk nivå.
De olika synvinklarna gör det tydligt att det inte finns en gemensam bild av vem som har beslutsmandat. Det råder en koncensus bland mjukvaruutvecklarna att det borde finns ett uttryckt direktiv för vem som har beslutsmandat och koordinerar de återanvändbara komponenterna.
Dock är det en majoritet av mjukvaruutvecklarna som ser att ansvaret för arkitekturen ligger hos mjukvaruavdelningens mjukvaruarkitekt. Hen har dock inget ansvar att utveckla och underhålla komponenterna utan endast det strukturella ansvaret. Det innebär att ha ansvar över hur komponenten ska vara uppbyggd, vad den ska uppfylla för krav, hur den ska testas och hur dokumentationen ska vara utformad. Dessutom ligger mycket koordinationsarbete och standardiseringsarbete på mjukvaruarkitekten. Idag är mjukvaruarkitekten satt som projektledare för Libbet vilket gör att hens tid blir fördelat på det projektet istället för att ansvara för den övergripande arkitekturen för de återanvändbara komponenterna.
En mjukvaruutvecklare uttrycker:
“Hen är ju den som egentligen har det övergripande ansvaret för arkitekturen hos oss. Men hen har blivit satt som projektledare för ett projekt också. Vilket jag också tycker kan vara väldigt konstigt. Det är bättre att hen bara hålls ansvarig för själva arkitekturen då“
4.2.3 Koordinationsmöten & standard
Det som saknas är en övergripande koordination, där det måste bestämmas vilka komponenter som ska vara återanvändbara och koordinera informationen hur långt mjukvaruutvecklarna har kommit i utvecklingen. Det finns även ett önskemål att sätta upp ett standardiserat sätt över hur de återanvändbara komponenterna ska sättas upp och dokumenteras. Komponenterna borde definieras och visualiseras på ett sätt som talar om hur de ska användas, se ut, vad de ska göra och vilka beroenden som finns mellan dem. På så sätt kan utvecklare från olika projekt förstå och sätta sig in i komponentens funktionalitet. Detta är något som borde ha bestämts och dokumenterats innan projektets uppstart, vilket skulle ha skapat en bättre överblick över komponenterna. Därmed skulle de olika projekten senare se vilka komponenter som man kan ta in som återanvändbara.
En mjukvaruutvecklare uttrycker följande:
“Vi hamnar ofta i det här att “nu ska vi börja koda”, från dag ett när vi börjar i projektet ska vi börja skriva kod (...) Det är ingen som har tänkt innan hur det ska vara. Varför gör vi en komponent, utan den bara blir.”
Mjukvaruutvecklarna ser ett behov av en utsedd grupp bestående av en mjukvaruarkitekt och mjukvaruutvecklare från respektive projekt. Denna grupp bestämmer hur ett format ska se ut, i form av hur dokumentationen ska vara utformad, som beskriver återanvändbara komponenters in- och utdata. Den här avstämningen ska ske veckovis. Mjukvaruutvecklarna är med för att kunna dela sin tekniska kunskap inom sitt projekt men kan också fungera som budbärare av kunskap till sina projektmedlemmar. Mjukvaruarkitekten är med för att bidra med arkitekt perspektivet.
4.2.4 Ägarskap
Ägarskapet uttrycks som nånting som krävs för att lyckas med återanvändbara komponenter. I nuläget finns det vissa återanvändbara komponenter som har en
kontaktperson, på grund av att det inte finns nödvändiga resurser till officiellt ägarskap. Det är exempelvis operativsystemet och filsystemet som har en uttalad kontaktperson. Fördelen med ägarskapet är att information kan distribueras av ägaren och denna bidrar med den djupa tekniska kunskapen. Finns det ingen uttalad kontaktperson blir den personen som har utvecklat koden en inofficiell kontaktperson som mjukvaruutvecklarna vänder sig till när de har frågor kring komponenten.
Med en utpekad ägare tillåts inte utvecklare ändra i andras arbete, därför rapportera man buggar till ägaren som är ansvarig för kodgranskning när ny kod skapas av andra.
Mjukvaruutvecklarna har en skild syn på ägarskapet. En majoritet anser att ägarskap är viktigt för att få arbetssättet kring återanvändbara komponenter att fungera och att ägarskapet borde uttalas från början. Andra anser att ägarskapet inte kommer vara till fördel för att komponenter ska vara ägd av alla. Dessutom diskuteras det även kring resurser i form av tid som måste sättas av i separata projekt tillägnat för underhåll av en gemensam komponent, för att kunna utföra ägarskapsuppgiften. Det krävs extra resurser för att möjliggöra ägarskapet.
4.3 Analys
För att analysera empirin kommer de två valda teorierna användas: Boundary Object theory och Affordance theory. För att tydliggöra olika teman i analysen har avsnittet följande underrubriker: Återanvändbara komponenter som gränsobjekt; Specialisering inom projektteam; Motivation för samarbete; Uppfinna hjulet om och om igen; Knowledge broker. Affordance perspektivet belyser de olika handlingserbjudanden som återanvändbara komponenter möjliggör. Analysen avslutas med en kombination av båda modellerna för att förklara problemsituationen.
4.3.1 Gränsobjekt
Gränsobjekt kan användas för att beskriva olika sociala verkligheter (Star & Griesemer, 1989). I fallstudien kan komponenter identifieras som gränsobjekt mellan de olika projektteamen: projekt A, B och C. Komponenterna i Git-repositories finns lagrade i komponentbibliotek som de olika utvecklarna har tillgång till. Git skulle kunna ses som ett gränsobjekt, men används i nuläget inte på det sätt som skulle kunna leda till att gränser mellan projektteam bryts ner.
Det finns dessutom olika dokument och system som stödjer arbetet kring återanvändbara komponenter. Git, System och dokument agerar i det här fallet inte som gränsobjekt utan enbart som stödjande roll till komponenterna, eftersom utvecklarna kommunicerar med varandra när de för diskussioner kring återanvändbara komponenter. De dokument som stödjer arbetet skall även agera som ett stöd för de diskussionerna.
Återanvändbara komponenter som gränsobjekt
Återanvändbara komponenter har identifierats som gränsobjekt inom verksamheten. Dock är de enbart de existerande komponenter som i nuläget uppfyller funktionen som gränsobjekt. Även kommande komponenter skulle kunna agera som gränsobjekt. För att ta fram återanvändbara komponenter krävs olika typer av kunskap: krav, funktioner, in- och utdata, samt nödvändig dokumentation. Den kunskapen, det vill säga det abstrakta, icke-existerande komponenter kan också agera som gränsobjekt mellan olika projektteam. Dock räcker det inte för att skapa kunskapsöverföring i nuläget för att de finns pragmatiska gränser mellan projektteamen (Carlilie, 2004). Detta beror på att en rad okända faktorer och inte tydligt beskrivna arbetsprocesser vilket leder till att egenskaper som gränsobjekt inte kan inträdas. Okända faktorer kan exempelvis vara projektspecifika krav på hård -och mjukvara. För att kunskapsöverföring ska ske måste domänkunskap förändras och överföras, så att andra projektteam kan applicera den i sin praktik.
Specialisering inom projektteam
Hos respektive projektteam finns en expertis inom ett av de olika produktområdena som tar fram applikationer inom; Fordon, Infanteri och Antitank. Mjukvaruutvecklarna som arbetat inom ett visst produktområde med utveckling av applikationer har över tid samlat på sig erfarenheter inom produktområdet som blivit till kunskap och därmed byggt upp en expertis och domänkunskap som har lett till specialisering. Den specialiserade kunskapen är nödvändig för att skapa en effektiv utveckling av produkten.
Varje projektteam har sina deadlines och krav att tillfredsställa, vilket gör att specialisering av kunskap bland mjukvaruutvecklarna ökar inom projekten.
Motivation för samarbete
De tvärfunktionella gränserna som existerar mellan de olika projektteamen kan delas in i tre olika typer av gränser: syntaktiska, semantiska och pragmatiska gränser. Även om utvecklarna uttrycker att det inte finns någon konflikt mellan projektteamen, finns det ingen anledning för utvecklarna att gå över och kommunicera med de andra projekten. Pragmatiska gränser uppstår utifrån en rad okända faktorer och olika intressen som aktörerna fullföljer (Carlile, 2004). Dessa består av att möta milstolpar och projektdeadlines i deras egna projekt. Det är därför gränserna mellan utvecklarna kan identifieras som pragmatiska gränser.
Enligt utvecklarna har de försökt att ta fram återanvändbara komponenter, dock har man även efter möten inte lyckats att skapa ett kontinuerligt samarbete. Det visar på att gränsen inte kan vara av semantisk karaktär utan att det saknas grundläggande kunskap kring de andra projektens uppgifter som gör att gränsen är pragmatisk.
Uppfinna hjulet om och om igen
Projektteamen plockar in kod ifrån varandra och gör lokala kopior som blir till en egen version av en komponent där projektteamet internt ändradrar och förbättrar den. Denna metod är en typ av kunskap som är investerad för att utföra arbetet och har använts över tid och därmed blivit en inbäddad kunskap. När inbäddad kunskap i form av arbetssätt eller metoder fungerar är individer mer benägna att lösa sina framtida problem på liknande sätt.
Genom återupprepning av detta arbetssätt skapas därav inga nya återanvändbara komponenter och anledningarna till att kommunicera med varandra över projektgränser minskar. De arbetssättet är en metod som fungerar enligt utvecklarna för att utveckla kod inom deras projekt. Metoden har dock lett till ett minskat samarbete för att skapa återanvändbara komponenter. Det uttrycks även av utvecklarna måste frångå det arbetssättet för att inte skapa lokala kopior. Diskussionen för att hitta gemensamma lösningar över projektgränser minskar, ifall ett projektteam stött på patrull med en komponent. Det skapas en distans mellan de olika projektteamen, som inte går att överkomma med det aktuella arbetssättet.
En barriär för att förändra detta mönster och bryta ner den pragmatiska gränsen kan bero på att mjukvaruutvecklarna anser att det är ett fungerande arbetssätt, som även tar mindre tid. Teamen hittar en egen lösning snarare än en generell lösning på grund av att de är stressade i sina projekt. Att förändra denna inbäddade kunskap skulle innebära att projektteamen behöver möta kostnaden för att förändra vad de gör för att utveckla nya sätt att hantera problem som de möter.
Det finns olika försök att förändra arbetssättet som exempelvis att utveckla en kodstandard som gäller för alla utvecklingsprojekt. Att ha en gemensam kodstandard löser problematiken på en syntaktisk nivå, för att det enbart handlar om att ha ett enhetligt sätt att skriva kod på. Det som måste förändras är arbetssätt kring samarbete och tydlig informations- och kunskapsspridning för att minska de okända faktorerna.
Knowledge broker
Utvecklarna uttrycker att mjukvaruarkitekten har det övergripande ansvaret, som tar beslut om vilka komponenter som skall återanvändas. Till denne person kan även utvecklare vända sig till vid frågor om arkitektur. Denna person har en överblick över hela processen och kan identifiera när olika personer kommer till hen med liknande problem och kan därmed agera som en knowlege broker. Brokern kan ha en stödjande roll för att bryta ner de pragmatiska gränserna och hjälpa till att organisera aktiviteter som ska leda till att bryta ner gränserna. Alla utvecklare identifiera hen i den rollen. Det finns alltså en acceptans bland mjukvaruutvecklarna för information och beslut som fördelas utifrån mjukvaruarkitekten. Dessutom kan mjukvaruarkitekten stödja ägarna för de olika komponenterna och fördela