Teknik och samhälle
Datavetenskap
Examensarbete
15 högskolepoäng, grundnivå
Samspelet mellan projektledare och utvecklingsmetod –
En litteraturstudie inom området mjukvaruutveckling
Interaction between project manager and development method -
A literature review in the area of software development
Författare: My Binh Vuong
Examen: Kandidatexamen 180 hp Handledare: Kristina Allder
Huvudämne: Datavetenskap Examinator: Mia Persson
Program: Data och telekom
Sammanfattning
En stor del av mjukvaruutveckling sker idag i projektform och projektledaren spelar en viktig roll i ett projekt. Projektledaren har det största ansvaret för projektet och leder sitt utvecklingsteam mot målet för projektet. Inom området för mjukvaruutveckling har olika utvecklingsmetoder skapats för att hantera projekt och projektledning. Inom området skiljer man generellt mellan traditionella och agila utvecklingsmetoder. De agila utvecklingsmetoderna introducerades för att eliminera brister hos de traditionella utvecklingsmetoderna. I de traditionella utvecklingsmetoderna är det nödvändigt att vara medveten om samtliga krav inom projektet från början medan de agila metoderna är mer flexibla i förhållande till kravinsamling.
Ämnesområdena projektledning och utvecklingsmetoder inom projektarbete diskuteras vanligen var för sig i skilda kontexter och betraktas därför ofta som oberoende av varandra. Forskning påvisar att många mjukvaruprojekt misslyckas på grund av bristande projektledning. Därför är det nödvändigt att projektledaren besitter ett antal egenskaper som identifierats som avgörande för att leda framgångsrika projekt. Genom den litteraturstudie som gjorts har fyra kritiska egenskaper hos projektledaren identifierats: relationsförmåga, personlighet, kompetenser och kommunikationsförmåga. Även om projektledaren besitter dessa beskaffenheter betyder det inte att projektet i sig lyckas. Utvecklingsmetoden för projektet är också en avgörande faktor för att skapa framgångsrika projekt. Val av utvecklingsmetod i samband med projektledarens egenskaper skapar således olika förutsättningar för projektets framgång. Resultatet som framkommit av denna studie påvisar att dessa två ämnen i hög grad är beroende av varandra. Studien visar också att projektledarens beskaffenheter många gånger är helt avgörande vid tillämpning av traditionella utvecklingsmetoder. Projektledarens egenskaper är också aktuella vid arbete med agila utvecklingsmetoder men inte i samma utsträckning som för traditionella utvecklingsmetoder.
Nyckelord: Projektledare, projektledning, utvecklingsmetoder, mjukvaruutveckling,
mjukvaruutvecklingsprojekt, utvecklingsteam.
Abstract
A large part of software development today is conducted in the form of projects and the project manager plays an important role in a project. The project manager has the largest responsibil-ity and leads the development team towards the goal of the project. In the area of software development different development methodologies have been created for project management. One generally distinguishes between traditional and agile development methodologies. The agile development methods were originally introduced to eliminate the shortcomings of the traditional development methods. With traditional methods it is necessary to be aware of all the requirements for the project from the start while the agile methods are more flexible with regard to requirements elicitation.
Disciplines of project management and development methodologies in a project are usually discussed separately in different contexts, and are therefore often regarded as independent of each other. Research shows that many software projects fail due to deficiencies in the project management. It is consequently necessary that the manager possesses a number of properties that have been identified as critical for managing successful projects. This study identified four key characteristics of the project manager: relationship ability, personality, competence and communication skills. Even if the project manager possesses these traits or capacities it does not mean the project itself is or will be successful. The development methodology for the project is also a crucial factor in the process of creating successful projects. The choice of de-velopment method in conjunction with the project manager’s characteristics creates different conditions for success of the project. The results that emerged from this study demonstrates that these two subjects are highly interdependent. The study also demonstrates that the pro-ject manager's characteristics are often crucial in the application of traditional development methods. The project manager's characteristics are also relevant when working with agile de-velopment but not to the same extent as for traditional methods.
Keywords:
Project manager, project management, development methods, software
development, software development project, development team.
Innehållsförteckning
1. Inledning ... 1
1.1. Bakgrund ... 1
1.2. Problemdiskussion ... 2
1.3. Syfte och identifierade frågeställningar ... 3
1.4. Avgränsning ... 3
2. Metod... 4
2.1. Hermeneutik ... 4
2.2. Forskningsstrategi och datainsamlingsmetod ... 4
2.2.1. Litteraturstudie till frågeställning 1... 4
2.2.2. Litteraturstudie till frågeställning 2... 7
2.3. Källkritik ... 8
2.4. Metoddiskussion ... 8
3. Teoretisk referensram ... 10
3.1. Projekt ... 10
3.2. Introduktion till traditionella och agila utvecklingsmetoder ... 11
3.3 Vattenfallsmodellen ... 11
3.3. Rational Unified Process ... 13
3.4. Spiralmodell ... 15
3.5. Scrum ... 16
3.6. Extreme Programming ... 18
3.7. Dynamic Systems Development Method ... 19
4. Resultat ... 22
4.1. Relationsförmåga ... 22
4.2. Personlighet ... 23
4.3. Kompetens ... 24
4.4. Kommunikationsförmåga... 25
4.5. Diskussion av resultatet ... 26
5. Analys ... 28
5.1. Vattenfallsmodellen ... 28
5.1.1. Relationsförmåga ... 28
5.1.2. Personlighet ... 28
5.1.3. Kompetens ... 28
5.1.4. Kommunikationsförmåga... 29
5.2. RUP ... 29
5.2.1. Relationsförmåga ... 29
5.2.2. Personlighet ... 29
5.2.3. Kompetens ... 29
5.2.4. Kommunikationsförmåga... 30
5.3. Spiralmodellen ... 30
5.3.1. Relationsförmåga ... 30
5.3.2. Personlighet ... 30
5.3.3. Kompetens ... 30
5.3.4. Kommunikationsförmåga... 31
5.4. Scrum ... 31
5.4.1. Relationsförmåga ... 31
5.4.2. Personlighet ... 31
5.4.3. Kompetens ... 31
5.4.4. Kommunikationsförmåga... 32
5.5. XP... 32
5.5.1. Relationsförmåga ... 32
5.5.2. Personlighet ... 32
5.5.3. Kompetens ... 32
5.5.4. Kommunikationsförmåga... 33
5.6. DSDM ... 33
5.6.1. Relationsförmåga ... 33
5.6.2. Personlighet ... 33
5.6.3. Kompetens ... 33
5.6.4. Kommunikationsförmåga... 33
6. Slutsats ... 35
7. Vidare forskning ... 37
Källförteckning... 38
Figurförteckning
Figur 1: Projektmodell som visar projektets livscykel ... 11
Figur 2: Illustration på Vattenfallsmodellen faser ... 13
Figur 3: RUPs olika faser och discipliner ... 15
Figur 4: Spiralmodellens olika varv och faser ... 16
Figur 5: Scrum processen ... 17
Figur 6: XPs tolv tillämpningar ... 19
Figur 7: DSDM processen... 21
Tabellförteckning
Tabell 1: Sammanfattning av sökresultat och filtrering ACM ... 5
Tabell 2: Sammanfattning av sökresultat och filtrering IEEE ... 6
Tabell 3: Sammanfattning av sökresultat och filtrering ACM ... 7
Tabell 4: Sammanfattning av sökresultat och filtrering IEEE ... 7
Tabell 5: Visar om det är stor eller liten påverkan som framgångsrika projektledares egenskaper har
på de olika utvecklingsmetoderna ... 35
1
1. Inledning
I detta inledande kapitel beskrivs bakgrunden till projektledning samt ett urval av traditionella och agila utvecklingsmetoder. Därefter följer en problemdiskussion som mynnar ut i två frågeställningar. Även syftet med uppsatsen och avgränsningen för denna presenteras.
1.1. Bakgrund
Projektledning är idag ett högaktuellt område som är under intensiv utveckling och som ofta berör hela organisationen (Tonnquist 2007). I de flesta organisationer, oavsett bransch, finns det någon form av projektledning. En allmänt vedertagen definition av begreppet projektledning är:
”Tillämpningen av kunskaper, färdigheter, verktyg och metoder på projektaktiviteter i syfte att motsvara projektkraven” (LTH, u.å, s 6).
Ett välbekant och aktuellt begrepp inom projektledning är den så kallade projektledarrollen. Bakka, Fivelsdal & Lindkvist (2006) menar att projektledare ofta är en person som styr och vägleder ett projektarbete. Enligt Hughes & Cotterell (2009) är projektledarskap inom mjukvaruutveckling annorlunda än projektledarskap för andra projekt. Planering, övervakning och kontroll är tre nyckelord för en projektledare inom mjukvaruprojekt. Ett mjukvaruprojekt måste tillfredsställa riktiga behov och det är projektledares ansvar att identifiera projektets intressenter och mål. En framgångsrik projektledare har ett autentiskt intresse för människor och vet hur man får medarbetare att vilja komma till jobbet varje dag. Detta innebär även att en projektledare behöver agera och fungera som en coach för utvecklingsteamet och se varje individs styrkor och svagheter. Projektledaren tillsammans med beställaren är de viktigaste rollerna i ett projekt, tillsammans utgör de projektets kärna. Tonnquist (2007) menar att en projektledares huvuduppgift är att leda utvecklingsteamet som ska leverera ett resultat till beställaren. Därför bör en projektledare känna till sina arbetsuppgifter för att kunna effektivisera projektarbetet.
Genomförandet av ett mjukvaruprojekt tillämpar vanligtvis någon välkänd utvecklingsmetod. Det finns huvudsakligen två grupper av utvecklingsmetoder som används inom mjukvaruutveckling, de traditionella och de agila utvecklingsmetoderna (Rehman et al. 2010). Traditionella utvecklingsmetoder och arbetsätt som används idag kommer från det kalla krigets dagar. Syftet med metoderna var att nå försvarsprojekt innan motståndaren. De verktyg som togs fram användes för att koordinera och minska ledtiden av ett projekt. Ledtid är den tid det tar från att påbörja ett projekt till att avsluta det. Att administrera och kordinera så många aktiviteter som möjligt var syftet. Ju fler aktiviter som kunde hanteras desto kortare kunde ledtiden bli för projektet. Traditionella utvecklingsmetoder är ofta ”dokumenttunga”, d.v.s. att projektet noga ska dokumenteras under projektets ledtid (Gustavsson 2013).
Agile är det engelska ordet för smidig eller rörlig. Översättning av ordet agile till svenska har blivit ”lättrörlig” (Gustavsson 2013). Mjukvaruutvecklingsarbete beskrivs ofta som ett komplext arbetsområde, framförallt inom IT-projekt. Grundtankarna bakom agil utveckling finns i det så kallade agil manifestot:
Individer och interaktion framför processer och verktyg. Fungerande programvara framför omfattade dokumentation. Kundsamarbete framför kontraktsförhandling.
2
Arbetet bedrivs inkrementellt och iterativt vilket innebär att regelbundna små leveranser sker löpande till kunden. Ändringar kan snabbt ske för att möta nya krav och önskemål (Gustavsson 2013). När man arbetar med agila metoder eftersträvar man att arbeta på ett smidigt, flexibelt och lättrörligt sätt (Schwaber 2004). Gustavsson (2013) menar att det finns tre argument för att arbeta agilt:
Nytta per krona - det viktigaste görs först. Att arbeta med det som ger störst nytta för kunden ger också mest värde per krona. Leverans sker löpande så att kunden kan få möjlighet att ändra och påverka sina krav.
Flexibilitet - förändringar är välkomna. Efter varje iteration får kunden resultatet presenterat med möjlighet att ge återkoppling och möjlighet att ändra projektets planering inom givna ramar.
Tydlighet - transparens finns genom hela projektet. Projektet följs upp dagligen vilket gör att det kan följas och spåras på ett enkelt sätt. Detta skapar trygghet och motivation för såväl kunden som projektledaren och utvecklingsteamet.1.2. Problemdiskussion
Taylor & Woelfer (2009) menar att många företag investerar i utvecklingen av sina projektledare med förväntan att projekt ska bli lyckade. I en rapport från Sveriges kommuner och Landsting från 2008 är det färre än 10 % av alla mjukvaruutvecklingsprojekt som har karakteriserats som lyckade (Kontract, 2013). En rapport från Standish Group som undersöker trender i mjukvaruprojekt rapporterar upprepande oroande statistik för branschen. Rapporten från 2011 visar att 37% av alla mjukvaruprojekt lyckades att leverera i tid, inom budget och med alla nödvändliga funktioner. 42% av projekten levererades sent, gick över budget och/eller levererades med mindre än begärda egenskaper och funktioner. Resterande 21% ansågs vara fullständigt misslyckade på grund av annullering före leverans eller att mjukvaran aldrig användes efter färdigställande (Quotient, 2012).
Sommerville (2010) menar att ett gott projektledarskap inom mjukvaruutveckling är särskilt utmanade på grund av följande faktorer:
Produkter är immateriella. Produkter är inte synliga, det kan varken röras eller ses.
Projektledare kan inte se framsteg genom att bara titta på den artefakt som är under utveckling.
Lärdomar från tidigare projekt kan inte överföras till nya projekt eftersom alla projekt är olika.
På grund av dessa faktorer är det inte överraskande att mjukvaruprojekt inte möter deadlines och överstiger budget. Orsaken till misslyckade projekt är ofta dålig projektledning enligt Hughes & Cotterell (2009). Hantering av utvecklingsteam inom mjukvaruutveckling är en komplicerad uppgift för en projektledare. Komplexit uppstår på grund av att projekt ofta har begränsade resurser. Det förekommer även distribuerade grupper som kräver lämpliga, vilket ytterligare komplicerar uppgiften (Bohner, McCrickard & Smith 2005).
Det globala datorföretaget IBM undersökte orsakerna till varför IT-projekt misslyckas och identifierade fem nyckelområden som påverkar huruvida projekt kan anses vara lyckade eller misslyckande. De fem nyckelområdena är:
Projektledning (54%) Affärer (21%)3
Människor (14%)
Metod (8%) Teknisk (3%)Första punkten ovan, projektledning (54%), visar att mer än hälften av projekten i studien misslyckas på grund av bristande projektledning. Undersökningen visar att projektledning har stort inflytande på om ett projekt lyckas eller misslyckas (Quotient, 2012).
I början av 1960-talet fanns det ett antal modeller som idag betraktas som de traditionella utvecklingsmetoderna t.ex. Vattenfallsmodellen, Spiralmodellen och olika inkrementella modeller. Dessa modeller uppvisar både starka och svaga sidor och utgår från att man har fullkomlig förståelse av kraven i det första stadiet av utvecklingsprocessen. Detta innebär svårigheter eftersom de flesta kunder inte vet vad de vill ha från början (Bandinelli et al. 1995). Därför introducerades en ny grupp av metoder under 1980-talet, som betraktas som agila metoder, för att eliminera bristerna i de traditionella metoderna. Rehman et al. (2010) menar att agila metoder inte är tillräckligt för att eliminera de brister som finns hos de traditionella metoderna. Det menar även att projektledning är ett av de viktigaste områdena inom mjukvaruutveckling och att projektledning har en mycket viktig roll i såväl traditionella och agila sammanhang. Utan rätt projektledning är det omöjligt att leverera ett bra resultat, oavsett om det är traditionella eller agila metoder som används under utvecklingen (Rehman et al. 2010).
1.3. Syfte och identifierade frågeställningar
Syftet med denna uppsats är att undersöka hur tillämpningen av de olika utvecklingsmetoderna inom mjukvaruutveckling samspelar med de egenskaper som kännetecknar en framgångsrik projektledare och således hur det kommer att påverka projektets resultat. För att kunna uppnå det ovannämnda syftet med uppsatsen behöver följande två frågeställningar besvaras:
Frågeställning 1: Vilka egenskaper kännetecknar en framgångsrik projektledare? Frågeställning 2:Hur samspelar egenskaperna identifierade i frågeställning 1 med utvecklingsmetoder för mjukvaruutveckling?
Med definitionen av ordet samspel i detta sammanhang avses hur de egenskaper som kännetecknar en framgångsrik projektledare påverkar de olika utvecklingsmetoderna.
1.4. Avgränsning
Projektledning är ett stort område som finns i de flesta branscher. Därför har uppsatsen avgränsats till att endast undersöka projektledarskap inom mjukvaruutveckling. Inom de agila utvecklingsmetoder kommer Scrum, Extreme Programming och Dynamic Systems Development Method att undersökas. Inom de traditionella utvecklingsmetoderna kommer Vattenfallsmodellen, Rational Unified Process och Spiralmodellen att undersökas. Urvalet motiveras i teoretisk referensramavsnittet.
4
2. Metod
Detta metodavsnitt presenterar tillvägagångssättet for uppsatsen. Vilket synsätt som har legat till grund för arbetet, vilken forskningsstrategi som har använts samt hur datainsamlingen har skett. Kapitlet avslutas med en källkritik och en metoddiskussion där författaren diskuterar varför den valda metoden har använts och vilka fördelar och nackdelar det finns med metodvalet.
2.1. Hermeneutik
Denna uppsats utgår från en hermeneutisk forskningsmetod i form av insamling av material. Hermeneutik betyder ungefär tolkningslära och är en vetenskaplig inriktning där man studerar, tolkar och försöker förstå grundbetingelserna för det insamlade materialet (Patel & Davidson 2011). Enligt Bryman (2011) är syftet med en hermeneutisk metod att genom analys av det insamlade materialet försöka få fram textens mening utifrån upphovsmannens perspektiv. Detta har även varit grundvalet av synsätt för denna uppsats. Det är nödvändigt att förstå helheten och sträva efter att förstå textens objektivitet för att kunna dra slutsatser utan att generalisera.
2.2. Forskningsstrategi och datainsamlingsmetod
Kvantitativ och kvalitativ metod är två undersökningsmetoder som brukar användas inom forskning. Kvantitativ data är mätbar och kan uttryckas i siffror och tal eller andra mängdtermer menar Halvorsen (1992). Kvantitativ forskning kan betraktas som en forskningsstrategi som betonar kvantifiering när det gäller insamling och analys av data medan kvalitativ forskning vanligtvis lägger vikt vid ord under insamlingen och analysen av data. Eliasson (2013) menar att kvantitativa metoder passar bra för att göra generaliseringar medan kvalitativa metoder däremot passar bra för att tränga in på djupet i en frågeställning. I denna studie tillämpas den kvalitativa metod som Marshall & Rossman (2010) betecknar som Analys av dokument och material. En kvalitativ metod är mest lämpad för denna uppsats då syftet med uppsatsen är att få en djupare förståelse för ämnet.
Primärdata och sekundärdata är de två typer av data som man bruka skilja mellan. Primärdata är ny data som forskaren själv samlar in genom att använda sig av en eller flera datasamlingsmetoder (Halvorsen 1992). Primära källor kan ofta innehålla nytt tänkande, nya upptäckter eller ny information. Sekundärdata är data som redan existerar och som någon annan samlat in. Bryman (2013) menar att en sekundäranalys har ofta flera fördelar för en student som ska göra ett större eller mindre projekt. Det kan vara ett bra metodiskt val eftersom man på så sätt får mer tid till analys och tolkningen av informationen. Datainsamling i denna uppsats är från sekundärdata och har skett genom en litteraturstudie.
2.2.1. Litteraturstudie till frågeställning 1
För att kunna besvara frågeställning 1 har ACMs och IEEEs databaser använts eftersom dessa två databaser är inriktad mot teknik och datavetenskap. De huvudsakliga söktermer som använts för att kunna besvara vad som kännetecknar en framgångsrik projektledare är:
Software project management Project leadership
5
Successful project management Project management failure Good project management Good project leadership Bad project management Bad project leadership Management skills
Dessa söktermer har kombinerats för att hitta relevanta källor. Nedan följer en tabell av hur artiklarna har sållats för att se vilka artiklar som bidrar till att besvara frågeställning 1. Samtliga söktermer har används i samtliga två databaser för att kunna värdera om de olika databaserna ger samma sökresultat. Söktermer som har använts är:
S1: Software project management OR software project leadership AND managing people. S2: Successful project management software OR Successful project leadership AND people. S3: Project management failure OR project leadership failure AND people.
S4: Good project management OR good project leadership AND software. S5: Bad project management OR Bad project leadership AND software S6: Project management skills OR project leadership skills AND people.
Tabell 1: Sammanfattning av sökresultat och filtrering ACM.
ACM Efter titel Efter abstrakt Efter artikeln
S1 99 26 12 2 S2 89 22 10 0 S3 2 1 1 1 S4 218 36 14 0 S5 63 21 6 2 S6 201 32 16 5 Relevant: 10
Nedan följer en lista på de relevanta artiklarna:
Raccoon, L.B.S. 2006. A Leadership Primer for Software Engineers.
Keretho, S., Lent, B & Pinkowska, M. 2011. Process Based Identification of Software Project Manager Soft Skills
Chen, P., Chen, C & Chern, C. 2012. Software project team characteristics and team performance: Team motivation as a moderator.
Gao, J & Ma, H. 2009. A Research On the Construction of Team Leadership Effectiveness and its relationship with Big-five Personality. Li, F & Wang, Y. 2009. How does project managers´personality matter?: building the linkage between project managers´ personality and the success of software
development projects.
Howard, A. 2001. Software Engineering Project Management.
Jalil, Zunera & Shahid, A. 2008. Is Non Technical Person A Better Software Project Manager.6
Creighton, W. J. 1990. Managing Technical Staff. Judge, T & Bono, J. 2000. Five-factor model of personality and transformational leadership.
Eisenberg, H. & Graziano, W. 1997. Agreeableness: A dimension of personality.
Tabell 2: Sammanfattning av sökresultat och filtrering IEEE.
IEEE Efter titel Efter abstrakt Efter artikeln
S1 84 31 11 2 S2 66 22 9 2 S3 53 19 6 1 S4 258 58 19 4 S5 57 26 8 0 S6 179 45 18 8 Relevant: 17
Nedan följer en lista på de relevanta artiklarna:
Durham, R. & Durham, M. 2007. What to do when things go wrong an ethical solution. Komchaliaw, S & Wongthongtham, P. 2010. A state of the art review on softwareproject performance management
Khan, R & Spang, K. 2011. Critical Success Factors for International Projects.
Jeng, D. 2011. Structural analysis on Team Iternal Soft Factors to Project Success. Barrick, M & Mount, M. 1991. The Big Five Personality Dimensions and JobPerformance: A Meta-Analysis.
Furnham, A & Hough, L. 2002. Importance and use of personality variables in work settings.
Thite, M. 1999. Leadership: a critical success factor in IT project management
Gemuenden, H & Hoegl, M. 2001. Teamwork quality and the Success of Innovative Projects: A theoretical concept and empirical evidence.
Costa, P & McCrae, R. 1991. Facet scales for agreeableness and conscientiousness: A revision of the NEO personality inventory.
Dvir, D., Sadeh, A & Malach-Pines, A. 2006. Projects and project managers: the relationship between project managers’ personality, project types, and project success.
Hassan, M., Rezaei, M & Shahhosseini, V. 2012. Competency Based Optimized Assignment of Project Managers to Projects.
Merrill, D & Collofello, J.S. 1997. Improving software project management skills using a software project simulator.
Carbone, T & Sampson, G. 2004. Project Manager Skill Development: A Survey of Programs and Practitioners. .
El-Sabaa, S. 2001. The skills and career path of an effective project manager.
Tarim, T. 2013. Managing Technical Professionals: When to Know to Transition From Technology Manager to Individual Contributor
Brewer, J. L. 2005. Project Managers, Can We Make Them or Just Make Them Better?7
2.2.2. Litteraturstudie till frågeställning 2
Även ACMs och IEEEs databaser har använts för att besvara på frågeställning 2. Sökningen utfördes på samma sätt som för frågeställning 1. Söktermer som har används är:
T1: Project management and interaction development methods
T2: Software project management and interaction development methods T3: Management and interaction traditional development methods T4: Management and interaction agile development methods
T5: Software project management and interaction traditional development process T6: Software project management and interaction agile development process
Tabell 3: Sammanfattning av sökresultat och filtrering ACM.
ACM Efter titel Efter abstrakt Efter artikeln
T1 56 3 0 0 T2 11 1 0 0 T3 8 0 0 0 T4 3 0 0 0 T5 5 0 0 0 T6 0 0 0 0 Relevant: 0
Tabell 4: Sammanfattning av sökresultat och filtrering IEEE.
IEEE Efter titel Efter abstrakt Efter artikeln
T1 26 2 0 0 T2 15 0 0 0 T3 12 1 0 0 T4 4 0 0 0 T5 5 0 0 0 T6 3 0 0 0 Relevant: 0
Från denna litteraturstudie erhålls 0 relevanta artiklar. Resultatet kan bero på att det inte finns så mycket forskning kring områdena projektledning och utvecklingsmetoder tillsammans. Det finns mycket forskning om dessa två områden som enskilda ämnen.
8
2.3. Källkritik
Det gäller att vara källkritiskt till all typ av informationsinhämtning. Källor bör i samtliga fall sättas i relation till det sammanhang som man avser använda dem, vilket leder till en kritisk reflektion i form av en prövning eller värdering i urvalet av källor. För att bedöma informationsinsamlingen föreslår Rienecker & Jørgensen (2008) att aspekter så som författarens auktoritet, analysens konsistens, källans ämnesmässiga status, källans objektivitet och ett antal andra aspekter bör beaktas ur ett källkritiskt perspektiv. Enligt (Thurén 2013) är källkritik en samling metodregler för att ta reda på vad som är sant, eller åtminstone vad som är sannolikt. För att kunna bedöma trovärdigheten för de källor som används ska dessa granskas kritiskt. Thurén (2013) beskriver källkritiska principer utifrån fyra kriterier som ska finnas i åtanke vid granskning av källans trovärdighet:
Äkthet - källan ska vara det den utger sig för att vara.
Tidssamband - ju längre tid som har gått mellan händelse och källans berättelse, desto större skäl finns det att tvivla på källan.
Oberoende - källan ska inte vara en avskrift eller ett referat av en annan källa. Tradering är en form av beroende som betyder att informationen förts vidare i många led. För att informationen ska vara tillförlitlig krävs att minst två källor som är oberoende av varandra påstår samma sak.
Tendensfrihet - misstanke kan finnas om den källa som används ger en falsk bild av verkligheten. Det finns intressen som förvränger verklighetsbilden av personliga, ekonomiska, politiska eller andra intressen.
Källor som har använts har framförallt bestått av vetenskapliga artiklar från ACMs och IEEEs databaser. De vetenskapliga artiklar som har använts har alla blivit kritiskt granskade av uppsatsens författare utifrån Thuréns (2013) kriterier. Artiklarna har bedömts som trovärdiga källor då samtliga författare har refererat och citerat till andra källor. Vilket i sin tur underlättar avgörandet huruvida källan är lämplig och vilka källor man kan sätta störst tilltro till. Även läroböcker som använts har betraktas som trovärdiga då författarna som har skrivit läroböckerna har lång erfarenhet inom forskningsområdet. Böckerna är tryckta av välkända bokförlag och har därmed granskats noga före publicering.
Elektroniska källor från diverse webbsidor som har använts håller dock inte lika stor trovärdighet som de övriga källorna ur en källkritisk synpunkt utifrån Thuréns (2013) kriterier. Eftersom avsikten med webbsidor ofta inte är helt tydlig och även i vilket syfte texten har skrivits kan vara otydligt, är det som undersökare väsentligt att noga granska källan utifrån Thuréns (2013) kriterier. På grund av att digitala källor kan förändras väldigt snabbt är det avgörande att ha detta i åtanke då man som författare använder sig av en elektronisk källa.
2.4. Metoddiskussion
Metoden som använts i denna uppsats har en kvalitativ utgångspunkt i form av en hermeneutisks grund. Det är väsentligt att ställa sig kritisk till de valda metoderna och angreppssätten då olika former av metoder kan innehålla varierande osäkerhetsmått. På grundval av de frågeställningar som utformats bedöms den valda metoden trots detta som lämplig eftersom det finns hänvisningar till andra undersökningar där samma metod föreskriver framgång. De frågeställningar som uppsatsen utgår ifrån kräver en mer omfattande undersökning. Således är en hermeneutisk utgångspunkt lämplig då det handlar om tolkningslära. En kvalitativ metod med djupintervjuer med ett antal projektledare samt utvecklare hade kunnat ge ett annorlunda resultat. På grund av tidsbrist samt kontaktbrist
9
har denna metod uteslutits. Det resultat som utmynnar från denna uppsats bedöms påverkas av det faktum att andra eller kompletterande metodval inte använts, men inte i den grad att resultatet är osannolikt.
10
3. Teoretisk referensram
Detta avsnitt presenterar sex olika utvecklingsmetoder inom mjukvaruutveckling för att skapa förståelse för hur metoderna verkar. Ramverket som presenteras här är projekt, Vattenfallsmodellen, Rational Unified Process, Spiralmodellen, Scrum, Extreme Programming och Dynamic Systems Development Method.
3.1. Projekt
Mjukvaruutveckling sker normalt i projektform. Projekt kan definieras som:
”Ett projekt är målorienterat, det vill säga har ett specifikt slutresultat, och består av ett antal aktiviteter som skall genomföras under en avgränsad tid med begränsade resurser och budget” (Wohlin 2005, s 45).
Målorienterat - Wohlin (2005) menar att ett projekt bör formuleras kring ett tydligt mål. Med tydligt mål i detta sammanhang menas att målet bör vara unikt för varje projekt.
Slutresultat - ett projekt bör resultera i något konkret och är nära relaterat till målet (Wohlin 2005).
Aktiviteter - ett projekt innehåller normalt ett antal aktiviteter som ska genomföras och som tillsammans leder projektet fram till målet. Projektledarens uppgift är att planera aktiviteterna så att de kan genomföras på bästa möjliga sätt (Wohlin 2005). Avgränsad tid - ett projekt har oftast en startpunkt och slutpunkt och karakteriseras
av att det är begränsad med tid (Wohlin 2005).
Begränsade resurser och budget - att ett projekt har tillgång till ett visst antal personer, viss utrustning och vissa lokaler är en begränsning i resurser. Ett projekt förväntas att genomföras inom vissa givna kostnader, så kallade begränsning i budget (Wohlin 2005).
Projektledaren är den som har det övergripande ansvaret för projektet. Tonnquist (2007) beskriver att ett projekt består av fyra faser:
Förstudie - där förutsättningar analyseras samt att projektuppdraget specificeras. Planering - handlar om att planera hur genomförandet av projektet ska se ut.
Genomförande - efter planeringen ska genomförande ske genom att utvecklingsteamet arbetar för att uppnå ett resultat.
Avslut - när resultatet är levererat sker ett avslut där projektet utvärderas och slutligen avvecklas projektet.11
Figur 1: Projektmodell som visar projektets livscykel.3.2. Introduktion till traditionella och agila utvecklingsmetoder
Vattenfallsmodellen, Rational Unified Process och Spiralmodellen tillhör de traditionella
metoderna. Scrum, Extreme Programming och Dynamic Systems Development Method tillhör de
agila metoderna.
Anledningen till valet av just dessa är för att de är vanligt förekommande metoder inom litteratur för mjukvaruutveckling. Metoderna nedan presenteras endast översiktligt och beaktas endast den nödvändiga information som behövs för att kunna förstår uppsatsen.3.3 Vattenfallsmodellen
Vattenfallmodellen är uppdelad i olika faser och varje fas ska vara avklarad innan nästa påbörjas. Uppstår det ett fel försöker man lösa felet innan man går vidare till nästa fas, eftersom metoden inte förespråker att gå tillbaka till föregående fas. Faserna exekveras systematiskt i en sekventiell ordning. Vattenfallsmodellen har tydliga mål för varje fas. Dokumentation produceras i varje fas i Vattenfallsmodellen. Detta gör det synligt för projektledare som kan övervaka framstegen mot utvecklingsplanen (Sommerville 2010). Den första formella beskrivningen av Vattenfallsmodellen anses vara från 1970 i en artikel skrivit av Winston W. Royce. Men ordet ”Vattenfallsmodellen” användes inte, istället presenterade Royce modellen som en bristfällig modell (Royce 1970). Royce (1970) menade faktiskt att man behöver gå tillbaka till vissa steg under utvecklingen men detta ignorerades senare. I originalartikeln beskriver Royce (1970) följande steg i modellen, som består av:
Systemkrav Programvarukrav Analys Design Kodning Testning Underhåll
De olika faserna i Vattenfallsmodellen kan se olika ut beroende på projektet, men de huvudsakliga målen med modellen är desamma, att varje fas ska avslutas innan nästa påbörjas. Nedan beskrivs de olika faserna enligt Sommerville (2010).
Krav definition - analys och definition av krav är det första steget i utvecklingsprocessen. Funktionella- och icke funktionella krav bryts ner för att ge en tydlig ram för utvecklingsprocessen.
12
System- och mjukvarudesign - systemdesign är processen för att definiera arkitektur, komponenter, moduler, gränssnitt och data för att uppfylla specificerade krav. Mjukvarudesign är den process som skapar en specifikation av en programvaruartefakt, avsedd att uppnå målen med hjälp av en uppsättning av primitiva komponenter.
Genomförande och enhetstestning - enhetstestning innebär att kontroller görs för att säkerställa att varje enhet uppfyller specifikationen. Målet med enhetstestning är att isolera varje del av systemet och visa att de enskilda delarna är korrekta.
Integration och systemtestning - målet med systemtestning är att säkerställa att det integrerade systemet som helhet är funktionellt komplett och uppfyller både de funktionella och icke funktionella krav. Efter testning levereras systemet till kunden.
Drift och underhåll - underhåll innebär korrigering av fel som inte upptäcktes i tidigare faser, förbättra genomförandet av systemenheter och förbättra systemets tjänster så som nya krav som upptäckts.Fördelar:
Utvecklingsteamet sparar tid genom att modellen är relativt överskådlig och lätt att förstå.
Vem som helst ska kunna implementera systemet om kravspecifikationen och designen är tillräckligt bra.
Dokumentation finns som ska hjälpa till och se var man avslutade arbetet och vad som ska göras om ett projekt ska återupptas i framtiden.
Nackdelar:
Man måste ha 100% överblick från start till slut.
Förändringar och tillägg blir mycket komplicerade och resurskrävande eftersom det inte är möjligt att gå tillbaka till föregående fas.
13
Figur 2: Illustration på Vattenfallsmodellens olika faser. Egen bild
Källa: Sommerville (2010)
3.3. Rational Unified Process
Rational Unified Process kommer i fortsättningen att skrivas som RUP. RUP är en iterativ utvecklingsprocess och tanken är att RUP ska skräddarsys så att det passar den enskilda organisationen och projektet. Utvecklingsmodellen ägs numera av IBM och utvecklas av IBM Rational Software (IBM, 2014). RUP projekt delas in i fyra faser som ett projekt går igenom. Varje fas avslutas med en definierad milstolpe där specifika delmål måste uppfyllas. Varje fas består av en eller flera iterationer beroende på projektet. Under varje iteration utförs aktiviteter med syfte att skapa en eller flera artefakter. De fyra faserna är:
Förberedelse - systemkrav samlas in för att fastställa den grundläggande idén för systemet. Totala kostnader och risker för utvecklingen av systemet identifieras och beslut om vidare utveckling ska göras fortlöpande (Sommerville 2010).
Etablering - hela systemet måste vara förstått för att kunna fatta beslut angående systemets arkitektur (Sommerville 2010).
Konstruktion - denna fas innebär systemdesign, programmering och testning (Sommerville 2010). Överlämning - överlämningsfasen innebär att leverera systemet till slutanvändarna och få det att fungera i en verklig miljö (Sommerville 2010).
Inom varje iteration kategoriseras uppgifterna i nio discipliner, sex tekniska och tre stödjande discipliner. De sex tekniska är:
14
Krav Analys och design Implementering Test och distribution De tre stödjande disciplinerna är:
Konfiguration och förändringsledarskap Projektledning
MiljöArbetsflödet för projektledning inom RUP är ett ramverk för hantering av projekt och risker. Det innehåller även praktiska riktlinjer för planering, bemanning, genomförande och övervakning av mjukvaruprojekt (IBM, 2014). RUP är uppbyggd av olika element som beskriver vad som ska produceras, visar de nödvändiga kunskaper som krävs och beskrivningar av hur specifika utvecklingsmål ska nås. De olika elementen är följande:
Roller (vem) som definierar en uppsättning av vad relaterat till kompetens, färdigheter och ansvar. Inom RUP-processen är det rollerna som definierar hur individerna ska utföra arbetet.
Aktiviteter (hur) beskriver en enhet av arbete som en individ i en roll kan bli ombedd att utföra och som ger ett meningsfullt resultat. Exempel på aktivitet kan vara att projektledaren planerar en iteration för utvecklingsteamet.
Artefakt (vad) är den påtagliga produkten för projektet. Artefakter används som underlag av utvecklingsteamet för att utföra en aktivitet (IBM, 2014).RUP baseras även på sex stycken tillämpningar och användning av dessa minskar risker i mjukvaruprojekt. Dessa sex tillämpningar är:
Utveckla iterativt - planera systemet inkrementellt baserat på kundens prioriteringar. I en iterativ utvecklingsmodell är det möjligt att gå tillbaka och t.ex. ändra på systemkrav och planera om följande iterationer (Sommerville 2010). Hantera systemkrav - funktionella och icke-funktionella krav bör dokumenteras för att lätt kunna hantera förändringar (Sommerville 2010).
Använd komponentbaserad arkitektur - komponenter är delsystem som uppfyller en specifik funktionalitet av hela systemet. Komponentbaserad arkitektur ger flexibilitet och effektivare programåtervinning (Sommerville 2010).
Modellera visuellt - visuella modeller fångar upp arkitekturens och dess komponenters struktur och beteende, samt hjälper till att kommunicera olika aspekter av mjukvaran (Sommerville 2010).
Kontinuerlig kvalitetskontroll - se till att mjukvaran uppfyller de organisatoriska kvalitetsstandarderna. Systemkvalitet definieras genom att värdera systemets tillförlitlighet, funktionalitet och prestanda (Sommerville 2010).
Kontrollera förändring- förändringar är ofrånkomliga i mjukvaruutveckling. RUP hjälper till att kontrollera, följa upp och dokumentera förändringar (Sommerville 2010).15
Figur 3: RUPs olika faser och discipliner. Egen bild
Källa: http://theexplorationofmyworlds.wordpress.com/2012/07/02/rup-rational-unified-process/
3.4. Spiralmodell
Modellen som presenteras nedan är en blandning av både Boehms (1986) och Wohlins (2005) Spiralmodell. Spiralmodellen är en variant av iterativ utveckling som ämnar kombinera riskhantering med iterativ utveckling och den är även influerad av Vattenfallsmodellen och bygger enligt Wohlin (2005) på följande nyckelord:
Budget Bestäm mål Alternativ Begränsningar Riskanalys Prototyp
Utveckla och testa
Modellen är byggd kring en spiral och varje varv i spiralen består av fyra faser. De två första faserna är likadana för samtliga varv i Spiralmodellen.
Varv 1 - budget för projektet bestäms i den första fasen i det innersta varvet, målet sätts beroende på budgeten. Alternativa lösningar identifieras utifrån målet, sedan identifieras begränsningar. En riskanalys genomförs i den andra fasen genom prototyputveckling som betyder att information tas fram för att kunna göra en utvärdering. En övergripande modell tas fram som beskriver hur systemet ska fungera i den tredje fasen på första varvet. En livscykelplan för produkten skrivs och krav på produkten tas fram i den sista fasen på första varvet (Boehm 1986).
Varv 2 - produktkraven bryts ned till krav på programvaran i den tredje fasen, även avstämning av kraven gentemot kund och marknad sker. Utvecklingsplan görs i den sista fasen (Wohlin 2005). Varv 3 - design genomförs i den tredje fasen och integrationstest planeras i den fjärde fasen (Boehm 1986).
16
Varv 4 - detaljerad design, kodning och test genomförs i den tredje fasen och upprepas i ett antal iterationer och leverans sker slutligen i den sista fasen (Wohlin 2005).Figur 4: Spiralmodellens olika varv och faser. Egen bild
Källa: http://www.torefriskopp.se/annat/minska-risken-med-iterativ-utvecklingsmodell
3.5. Scrum
Syftet med Scrum är att effektivisera arbetet och arbetsfördelningen genom att införa olika typer av roller. De olika rollerna består av Product Owner, Scrum Master och Scrum Team. Product Owner, som också kallas för produktägaren, är den som ansvarar och företräder alla som jobbar med projektet. Product Owner är även den som tar emot, hanterar och prioriterar önskemål och ändringar för en produkt. En Scrum Master som fungerar som en coach för Scrum Teamet och ser till att regler skapas och följs. Scrum Master är även den som hanterar eventuella konfliker i teamet. Att säkerställa överlevnad av processen är Scrum Masterns uppgift. Scrum Mastern har en coachande och rådgivande roll men skiljer sig från en projektledare då en Scrum Masters roll saknar ledningsansvar. Det finns ingen definierad projektledarroll i Scrum. Den sista rollen är Scrum Team som är gruppen som gör det praktiska arbetet. Scrum Teamet ingår individer med olika färdigheter och gruppen arbetar under självorganiserande förhållanden (Schwaber 2004).
Olika komponenter inom Scrum:
Product backlog – en lista med krav på systemet som ska utvecklas. Produktägaren ansvarar för och prioriterar backlogen (Schwaber 2004).17
Sprint backlog - den del av produktbacklogen som Scrum Teamet åtar sig att implementera under en sprint. Definierar arbetet eller arbetsuppgifter (Schwaber 2004).
Inkrement - det som skapas i varje sprint, d.v.s. tillskott av nya egenskaper eller funktioner. Inkrementet måste vara användbart ifall produktägaren genast väljer att implementera funktionen (Schwaber 2004).
Sprint - i Scrum delas arbetet in i sprintar och längden är normalt 2-4 veckor (Sommerville 2010). Sprinten inleds med en Sprint planning och avslutas med en Sprint review. Under sprinten sker dagligen Daily Scrums (Schwaber 2004).
Daily Scrum - dagliga planeringsmöten för Scrum Teamet som maximalt får ta 15 minuter. Scrum Teamet inspekterar sin progress så här långt i sprinten och var och en i teamet svarar på följande tre frågor: Vad har du gjort sedan igår? Vad har du planerat att göra nu intill nästa Daily Scrum? Vad hindrar dig? (Schwaber 2004).
Sprint review - som kan översättas som sprintgranskning, görs i sluten av sprinten. Sprintgranskning är ett fyra timmars möte, där status för projektet presenteras inför produktägaren och andra intressenter. Syftet är att presentera hur långt Scrum teamet kommit, vad som är klart och vad som ska göras härnäst (Schwaber 2004).
Spring retrospective – med detta menas återblick. Scrum Teamet tillsammans med Scrum Mastern och produktägaren går igenom erfarenheter från sprinten och identifierar möjliga förbättringar till nästa sprint (Schwaber 2004).
Sprint planning - produktägaren, Scrum Mastern och Scrum Teamet går igenom de önskemål som finns. Genom att jämföra de tidsuppskattade och prioriterade önskemålen med tillgänglig tid tas en sprint backlog fram av produktägaren som Scrum teamet åtar sig att genomföra.
Figur 5: Scrum processen. Egen bild
18
3.6. Extreme Programming
Extreme Programming kommer vidare i uppsatsen att förkortas som XP. XP utvecklades på grund av att många mjukvaruprojekt avbröts eller att projektplanen inte kunde hållas. Det är vanligen en projektledare som hjälper utvecklingsteamet på rätt spår samt underlättar processen. Projektledaren är även den som hanterar resurser och den externa kommunikationen (Xprogramming, 2014).XP bygger på fyra värderingar och dessa består av:
Kommunikation och återkoppling - den optimala kommunikationsmetoden kan sägas vara ”face to face”-kommunikation. Kunden är på plats, vilket innebär att kontinuerlig kommunikation blir möjligt mellan utvecklarna och kunden. Kunden har möjlighet att ändra systemkraven så att de viktigaste kraven hanteras först. Kommunikation är viktig för återkoppling (Hughes & Cotterell 2009).
Enkelhet - enklast möjliga design ska användas för att implementera användarens krav (Hughes & Cotterell 2009). Ansvar - utvecklare är ansvariga för systemets kvalitet (Hughes & Cotterell 2009). Mod - alla utvecklarna ska vara ärliga med vad de kan göra och inte kan göra (Hughes
& Cotterell 2009).
Förutom de fyra värderingarna inom XP finns det också tolv tillämpningar som stöttar de fyra värderingana:
Planeringspelet - den process där funktionerna i nästa leverans bestäms och var och en av dessa funktioner dokumenteras i en kort textbeskrivning (Xprogramming, 2014).
Små leveranser - tiden mellan leveranserna av funktionerna bör vara så kort som möjligt (Xprogramming, 2014). Metafor - enkel beskrivning av hur systemet ska fungera (Xprogramming, 2014).
Enkel design - all kod ska hållas enkel genom en enkel design. Upptäcks det onödigt komplexitet i koden tas denna bort (Xprogramming, 2014).
Testning - utförs samtidigt som kodning och är till för att kontrollera att funktionen är korrekt och hjälper till att klargöra kraven. Det krävs två tester, enhetstestning som fokuserar på koden som utvecklare har skrivit och funktionstestning som är användorienterad och kontrollerar korrekthet av en viss funktion (Xprogramming, 2014). Omstrukturering av kod - genom att kontinuerligt ta bort identisk och onödigt komplex kod (Xprogramming, 2014).
Parprogrammering - där all kodning utförs av två utvecklare, en som skriver koden och den andra som observerar genom att diskutera, kommentera och ge förslag. Partnerutbyte sker konstant. Därför är det viktigt att man har kännedom om de funktioner som är under utveckling (Xprogramming, 2014).
Gemensamt ägarskap - även om det parprogrammeras så äger alla utvecklarna koden gemensamt. Alla har rätt att ändra i all kod, oavsett om den är skriven av dem själva eller någon annan (Xprogramming, 2014).19
Kontinuerlig integration - eftersom ändringar görs och för att säkerställa att alla komponenter fungerar tillsammans (Xprogramming, 2014).
40-timmars arbetsvecka - programmerare tänker och arbetar bättre utvilade. Därför har XP en tillämpning som heter 40-timmars arbetsvecka, vilket innebär att utvecklarna inte bör arbeta mer än 40 timmar i veckan. I extrema fall kan övertid behövas men övertidsarbete är inte tillåtet i mer än två veckor i rad (Xprogramming, 2014). Kunden på plats - för en effektivare kommunikation med utvecklarna, och för att kunna besvara frågor, definiera systemet samt utföra tester, finns kunden på plats på heltid (Xprogramming, 2014).
Kodningsstandard - då koden ägs av alla finns det en konsekvent kodningsstandard som följs av alla utvecklarna (Xprogramming, 2014).
Figur 6: XPs tolv tillämpningar.
Egen bild
Källa: http://xprogramming.com/what-is-extreme-programming/
3.7. Dynamic Systems Development Method
Dynamic Systems Development Method kommer i fortsättningen att skrivas som DSDM. DSDM är en iterativ och inkrementell utvecklingsmetod som omfattar principerna för agil utveckling. DSDM Atern lanserades 2007 och är en metod för projektledning och lösningsleverans som menar att fler mjukvaruprojekt misslyckas på grund av mänskliga problem än tekniska problem. DSDM Atern fokuserar på att hjälpa utvecklingsteamet att arbeta effektivt för att tillsammans uppnå projektmålet. Metoden fokuserar på tidiga leveranser av verklig nytta för ett företag, användare eller kund. DSDM Atern består av åtta principer. Dessa principer leder utvecklingsteamet i den attityd de måste ha och de tankesätt som ska vidtas för att leverara konsekvent. Metoden fokuserar även på ett projekts livscykel
20
med en flexibelt definierad uppsättning principer, samt tydliga roller och ansvarsområden för att möjliggöra en leverans (Dsdm, 2014). De åtta principerna består av:
Fokus på affärsbehov - systemet som levereras ska tillfredsställa det nuvarande affärsbehovet. Leverera i tid - deadlines ska alltid följas.
Samarbeta - för att ett beslut ska kunna fattas effektivare och snabbare krävs det att både utvecklare och användare integreras tillsammans i projektet.
Aldrig kompromissa kvalitet - realistiska projektmål sätts upp tidigt i projektet. Tidig och kontinuerlig testning av funktionerna sker löpande. Utveckla iterativt - fokus på täta och många små leveranser.
Bygga stegvis från företagsets grunder - för bättre affärsnytta eftersträvas leveranser så tidigt som möjligt.
Kommunicera kontinuerligt - för projektets effektivitet krävs det kommunikation och samarbete mellan projektets intressenter. Demonstrera kontroll - planer och framsteg görs synliga för alla. Framsteg mäts genom fokus på leverans snarare än på genomförda aktiviteter.
DSDM Atern hjälper ett mjukvaruprojekt att genomgå en kontrollerad start fram till en punkt där förståelsen för projektet är tillräckligt bra för att börja bygga lösningen iterativt och inkrementellt. Processen har fem faser som består av:
Genomförande
Grunder
Utforskning
Teknik
DistributionDessa föregås av en förprojektering som följs av en efterprojektfas. Förprojektfasen säkerställer att det är rätt mjukvaruprojekt som startas. Målet med detta är att bekräfta att projektet ligger i linje med affärsstrategin, samt att planera resurshantering i genomförandefasen. Förprojektfasen bör vara kort och koncis. Projektet bör utvärderas kontinuerligt under hela projektets gång för att se att slutprodukten ger fördelar vid användning och överväga kostnaderna för projektet. Under genomförandefasen avgörs det om projektet är lönsamt både ur ett affärsperspektiv och ett teknisk perspektiv (Hughes & Cotterell 2009).
21
Figur 7: DSDM processen.Egen bild
22
4. Resultat
Detta avsnitt beskriver de resultat som framkommit ur litteraturstudiens genomförande för att besvara frågeställning 1, ”Vilka egenskaper kännetecknar en framgångsrik projektledare?”. De resultat som framkommit är indelade i relationsförmåga, personlighet, kompetens och kommunikationsförmåga.
4.1. Relationsförmåga
Raccoon (2006) menar att projektledaren måste engagera sitt utvecklingsteam genom ett socialt kontrakt. Genom det sociala kontraktet påverkar projektledaren och utvecklingsteamet omgivningen. En projektledare ska kunna använda sitt inflytande för att främja utvecklingsteamet, intressenter och ändamål för att uppnå projektmålet. Det är sannolikt att utvecklingsteamet känner tillit för projektledaren om projektledaren inte missbrukar sin auktoritet. Komchaliaw & Wongthongtham (2010) menar att förtroende har en positiv effekt på samarbete och prestation. Ökat förtroende har en direkt positiv inverkan på utvecklingsteamets attityd. Keretho, Lent & Pinkowska (2011) anser att effektivitet bestäms av ömsesidigt förtroende, som bygger på personlig kännedom om varandra. Därför är det viktigt att relationen mellan projektledare och utvecklingsteamet är god. Utvecklingsteamet blir engagerade med hjälp av projektledarens färdigheter och ett effektivt sätt att leda utvecklingsteamet är att utveckla ett mentorskap. Alla projektledare behöver sina utvecklare oavsett hur effektiva de är. Projektledare arbetar för att uppnå ett projektmål och utvecklingsteamet är kärnan i utvecklingsprocessen.
Projektledaren är den som främst ska få arbetsprocessen att fungera genom att samarbeta och samordna med sitt utvecklingsteam. Han/hon är även den som påverkar sitt utvecklingsteam direkt genom tal, skrift och sin närvaro (Raccoon 2006).Varje person påverkas medvetet eller omedvetet av människor som man integrerar med. Projektledare påverkar sitt utvecklingsteam medvetet genom att använda sitt inflytande för att ta fram de bästa i sitt utvecklingsteam och tillsammans föra mjukvaruprojektet mot målet. Chen, Chen & Chern (2012) menar att projektledaren bör fokusera mer på utvecklingsteamets motivation för att kunna uppnå ett lyckat resultat. Keretho, Lent & Pinkowska (2011) menar att motivation av utvecklingsteamet är en viktig aktivitet för en projektledare och motivationen skapas genom uppbyggnad av en god relation. Utvecklingsteamets motivation ökar engagemanget för projektet och således effektiviteten och framgången menar Khan & Spang (2011).
Projektledarskap handlar om att projektledaren har personliga och vardagliga interaktioner med sitt utvecklingsteam. Projektledaren kan både vara en ”yttre ledare” som ställer uppenbara mål men även en ”inre ledare” som främjar personliga relationer. Projektledaren och utvecklingsteamet förväntar sig mycket av varandra. Projektledaren förväntar sig att utvecklingsteamet samarbetar med varandra och genom det levererar ett gott resultat. Utvecklingsteamet förväntar att projektledaren har förtroende för dem. Det är viktigt för utvecklingsteamet, men även för mjukvaruprojektet, att projektledaren i ett tidigt skede tydligt uttrycker målet för projektet så alla i utvecklingsteamet kan sträva efter detta. Närvaron i projektet är viktigt för en projektledare. Det är genom projektledarens närvaro som engagemang skapas hos utvecklingsteamet. En projektledare måste ha beslutsamhet, förtroende och den uthållighet som krävs för att få saker gjorda. Att vara optimistisk är en egenskap som en projektledare bör ha. Om projektledaren inte tror att utvecklingsprojektet kommer att lyckas så kommer förmodligen inte heller utvecklingsteamet att tro på det. Och då kommer projektet med största sannolikhet att misslyckas (Raccoon 2006).
23
Oftast är det inte projektledaren som väljer utvecklingsteam för att utveckla mjukvaran. Utvecklingsteamet som skapats är det man leder, även om det inte är just de människorna man vill ha i utvecklingsteamet eller vill arbeta med vid ett senare tillfälle. Men effektiva projektledare uppmärksammar sina projektmedlemmar och frammanar kompetens från var och en av dem. Projektledaren tar också hänsyn till vem de är och vad de är kunniga till att utföra (Raccoon 2006). Projektresultatet beror enligt Jeng (2011) på hur väl ett utvecklingsteam fungerar ihop. En viktig faktor som påverkar projektet är alltså relationen mellan utvecklingsteamet och projektledaren.
4.2. Personlighet
Projektledaren spelar en viktig roll i de flesta projekt inom mjukvaruutveckling. Projektledarens ledarskapsnivå är avgörande för ett projekts framgång eller misslyckande. Gao & Ma (2009) menar att projektledarens personlighet har en stor påverkan på utvecklingsteamets effektivitet. Ledarskapsbeteende är en viktig dimension av mänsklig beteende och är starkt präglat av individens personlighet. Människors attityder och beteende bestäms till stor del av deras personlighet. Människors personlighet återspeglas i deras tankar, beteende och livsstil. Därför är det rimligt att projektledarens personlighet spelar en stor roll i mjukvaruutvecklingsprocessen (Li & Wang 2009).
Barrick & Mounts (1991) Five Factor model beskriver personlighetsdrag med fem faktorer. Li & Wang (2009) betraktar dessa fem faktorer som indikatorer för utvecklingsprojektets framgång men också av hur projektledarens personlighet påverkar utvecklingsteamet genom förmedling av ledarskapskonstruktioner. De fem faktorerna för personlighetsdragen är:
Öppenhet - avser en generell uppskattning för känslor, äventyr, ovanliga idéer, fantasi, nyfikenhet och olika erfarenheter. De projektledare som ofta är villiga att pröva nya saker är människor med hög öppenhet medan låg öppenhet i denna dimension är människor som ofta föredrar stabilitet (Li & Wang 2009). Öppenhet är viktigt för förändring. Mjukvaruutveckling verkar i en bransch som påverkas av många oförutsägbara faktorer som kan påverka ett projekt negativt (Furnhamn & Hough 2002). En låg öppenhet hos projektledaren kan leda till misslyckande med att hantera tekniska förändringar. Och är därmed ett hot mot det tekniska ledarskapet eftersom teknik och metoder inom mjukvaruutveckling ständigt förändras (Thite 1999). Judge & Bono (2000) menar att öppenhet är viktigt för en projektledare då denna verkar som samordnare mellan individer i gruppen. Öppenhet gynnar utvecklingsteamets arbete och därmed dess prestationsförmåga.
Neuroticism - som ibland kallas för emotionell instabilitet, är tendensen att uppleva negativa känslor såsom ilska, ångest och depression. Projektledare med hög neuroticism är känsliga för stress och är mer benägna att tolka vanliga situationer som hotfulla. De är ofta på dåligt humör eftersom deras negativa emotionella rektioner tenderar att kvarstå under lång tid. Dessa problem kan minska förmågan att tänka klart, fatta beslut och hantera stress på ett effektivt sätt. Individer med hög neuroticism tenderar att misslyckas med att leverara ett positivt ledarskap, då de har lätt att bilda negativa frågeställningar. De med låg neuroticism ofta välanpassade i en dynamisk miljö. En projektledare med låg neuroticism kan bättre hantera de frågor som uppkommer under utvecklingsprocessen och leverera ett ledarskap på hög nivå (Li & Wang 2009).
Vänlighet - en snäll, omtänkssam, hjälpsam och samarbetsvillig personlighet i detta sammanhang (Eisenberg & Graziano 1997). I mjukvaruutvecklingsprojekt där mänskliga interaktioner och samarbeten är viktiga, är det uppenbart att vänlighet24
kommer att underlätta aktiviteter som innebär samarbete och samverkan mellan olika individer. Samarbete och effektiv kommunikation är en av de viktigaste faktorerna för att ett projekt ska lyckas. Projektledare med hög vänlighet är mer benägna att ge stöd och vägledning i utvecklingsteamet (Gemuenden & Hoegl 2001).
Samvetsgrannhet - är tendensen på att visa självdisciplin och sträva efter prestation. En samvetsgrann person är någon som planerar snarare än att agera spontant. Personer som har hög samvetsgrannhet är ofta drivna och genom hårt arbete villiga att uppnå hög standard på sin arbetsprestation (Costa & McCrae 1991). De är angelägna att göra sitt bästa för att förbättra sitt ledarskap. Det blir möjligt för projektledaren att ses som en förebild för sina underordnade och stimulera utvecklingsteamet att prestera bättre och uppnå målet (Li & Wang 2009).
Extraversion – används för att beskriva människor som är fulla av energi. Dessa individer är sociala, aktiva, självsäkra, positiva, utåtriktade och har en tendens att söka stimulans och andras sällskap (Dvir, Sadeh & Malach-Pines 2006). Projektledare inom mjukvaruutveckling behöver hantera många interna som externa frågor, samt bygga relationer med kunder för att uppnå framgång i projektet. En högt extravert personlighet passar i socialt relaterat arbete så som mjukvaruutveckling. Hög extraversion påverkar inte bara internt ledarskap, det är även positivt förknippat med framgång för mjukvaruutvecklingsprojekt (Li & Wang 2009).4.3. Kompetens
Hassan, Rezaei & Shahhosseini (2010) menar att projektledarens kompetenser har en direkt inverkan på utvecklingsteamets prestation. Eftersom utvecklingsprojekt plågas av kostnader som är större än budget, schema som går över tiden och kvalitetsproblem finns det ett tydligt behov av effektivitet som projektledningskompetens. Många projekt hade kunnat lyckas bättre om vissa gemensamma projektledningsfallgropar hade undvikits. Merrill & Collofello (1997) menar att dålig projektledning kan öka utvecklingskostnaderna snabbare och mer än någon annan faktor. Planering, uppföljning och styrning är projektledarens största uppgifter inom mjukvaruutveckling. För att kunna hantera dessa krävs det kompetens. En viktig kompetens är att känna till de vanliga projektledningssvårigheterna och att ha färdigheter att kunna erkänna dessa svårigheter och anpassa sig efter nya omständigheter (Merrill & Collofello 1997). Enligt Merrill & Collofello (1997) är projektledarens uppgift väldigt komplex. Mjukvaruprojekt måste följas upp kontinuerligt, övervakning måste ske konstant och problem som inträffar ska reageras på snabbt och smidigt. Därför behövs praktisk och aktiv erfarenhet för att effektivisera projektledningen. Det finns tre typer av ledarkompetenser, dessa är mänskliga, organisatoriska och tekniska.
Eftersom det är människor som är ansvariga för leverans av projektet menar Durham & Durham (2007) att mänskliga färdigheter ofta är den viktigaste utav de tre ledarkompetenserna för en projektledare. Khan & Spang (2011) menar att projektledarens kunskaper, färdigheter och förmågor är avgörande för projektet. För att en projektledare ska kunna leda gruppen mot det planerade målet krävs det förståelse för projektmiljön, kunskap och social kompetens. Carbone & Sampson (2004) menar att få organisationer genomför internutbildning för sina projektledare inom projektledningsområdet. Istället förlitar de sig på att arbetslivserfarenhet utvecklar projektledare och att de tekniska färdigheterna främjar projektledarens förmåga. Istället menar El-Sabaa (2001) att det är viktigare för en projektledare, oavsett bransch, att ha mänsklig kompetens än teknisk kompetens. Keretho, Lent & Pinkowska (2011) menar att en projektledare som har förmåga att hantera de mänskliga faktorerna bidrar till högre effektivitet. Därför är projektledarens kompetens
