I detta avsnitt beskrivs de valda utvecklingsmetodikerna och om den data som samlats in f¨or att analysera projektet.
A.4.1
Utvecklingsmetodiker
De fyra utvecklingsmetodiker som jag valt beskrivs kortfattat med en punktlista p˚a slutet, d¨ar ben¨amner jag saker de s¨atter extra v¨arde p˚a.
A.4.1.1 Vattenfallsmodellen
Vattenfallsmodellen ¨ar en av de enklaste modellerna. Det bygger p˚a att steg f¨or steg g˚a igenom ett best¨amt antal aktiviteter(Awad, 2005). Varje steg g¨ors en g˚ang och du g˚ar som ett ’vattenfall’ ned˚at i stegen. Stegen varierar fr˚an k¨alla till k¨alla oftast kan stegen defineras som ’Vad? Hur? Implementation, testning och Leverans/dokumentation’. Figur 15 illustrerar dessa steg. Att vat- tenfallsmodellen inte till˚ater ”tillbaka vandring” g¨or det kostsamt att g˚a tillbaka i stegen. Att testningen ligger sist kan ocks˚a g¨ora att det inte ¨ar helt ovanligt att man m˚aste g˚a tillbaka i processen(Valueatwork - Vattenfallsmetodiken en kostsam myt , 2013).
V¨arde f¨or vattenfallsmodellen ¨ar • Allt g¨ors en g˚ang under projektet
• Planera hela projektet i b¨orjan av projektet • Samlar in alla krav i b¨orjan av projektet
• L¨agger mycket fokus p˚a dokumentation i b¨orjan av projektet
Figur 15 – Illustration ¨over vattenfallsmodel- lens steg.
Figur 16 – Illustration ¨over hur pri- oriteringar f¨or tid kan vara under ett UP projekt. Bilden ¨ar tagen fr˚an http://guide.agilealliance.org/guide/daily.html
A.4.1.2 Unified Process (UP)
UP ¨ar en ’iterativ and incremental’ metodik som bygger p˚a att du itererar ¨over ett antal steg varje iteration. F¨or varje iteration bygger du p˚a det du redan gjort (eller ¨andrar) f¨or att till slut g¨ora en f¨ardig produkt. Att du g¨or samma steg varje iteration betyder dock inte att iterationer- na ser likadana ut. Utan oftast l¨agger du olika mycket tid p˚a de olika stegen beroende p˚a var i projektet du ¨ar(Awad, 2005). Det ¨ar h¨ar ifr˚an de fyra faserna f¨or UP kommer ifr˚an (’Incep- tion’,’Elaboration’,’Construktion’,’Transition’). Dessa fyra faser och hur antagandet om tid ska l¨aggas kan ses i bild 16.
Att varje projektmedlem f˚ar en specifik roll som den f¨orv¨antas utf¨ora g¨or att modellen inte ¨ar s˚a flexibel och att den kr¨aver en viss kompetens(John Hunt, 2003). Att det finns ett antal steg att checka av g¨or ocks˚a att den kan bli on¨odigt komplex och l¨ampar sig d¨arefter till st¨orre, l˚angvariga projekt.
V¨arde f¨or UP ¨ar
• De fyra P:en (People, Project, Product, Process) (Slideshare - Unified Process, 2009) • Use-case f¨or funktionalitet(Best Practices of RUP , u. ˚a.)
• Verifiera testning och kvalitet • UML-visualisering
• Kontrollerade ¨andringar A.4.1.3 Scrum
Scrum ¨ar en agil, iterativ och uppbyggnadsmetodik. Scrum bygger p˚a iterationer kallade ’Sprints’ som ¨ar generellt 30 dagar. Varje sprint ska skapa eller bygga p˚a ett fungerande system, i slutet ska ett nytt fungerande system vara producerat(Awad, 2005). F¨or att h˚alla reda p˚a vad som ska g¨oras f¨or systemet finns en ’scrum-backlog’ (Scrum alliance, u. ˚a.) d¨ar alla aktiviteter som ska g¨oras ¨over projektet finns. N¨ar en aktivitet blir vald att g¨oras under en sprint flyttas den till ’sprint backlog’ d¨ar aktiviteter som ska g¨oras under sprinten finns. Varje dag har man ett ’scrum meeting’ (¨aven Daily scrum)(Agilealliance - Daily meeting, u. ˚a.) d¨ar man g˚ar igenom vad alla gjort sedan f¨orra m¨otet, vad alla planerat att g¨ora tills n¨asta uppf¨oljning och om n˚agot har f¨orhindrat planeringen.(Kim H. Pries and Jon M. Quigley, 2011).
V¨arde f¨or scrum ¨ar
• Agila manifestet (Agila manifestet , u. ˚a.)
• ¨Oppenhet - En av de viktigaste sakerna ¨ar att vara ¨oppen om projektets status.
• Fokus - Jobba bara p˚a f˚a saker ˚at g˚angen, d¨arf¨or levererars v¨ardeful funktionalitet tidigare. • ’Dagliga m¨oten’
• ’Sprint backlog’ • ’Scrum backlog’
A.4.1.4 eXtreme Programming (XP)
XP bygger p˚a att ta sina k¨arnkvaliteter till det extrema (d¨arav namnet)(Awad, 2005). XP bygger p˚a korta iterationer, oftast n˚agra veckor och som mest 5-6 veckor (Ahmed, 2012). F¨or att planera en iteration g¨ors ett s˚a kallad ’planning-game’ d¨ar en metaphor (en ¨overrenskommen metaphor mellan kund och utvecklare som beskriver en funktionalitet) oftast ¨ar i centrum f¨or funktionaliteten som ska implementeras. Test-driven programmering st˚ar i fokus n¨ar man utvecklar, och ofta skriver man testfallen innan koden. Varje iteration avslutas med att produkten visas f¨or kund. Om kunden har inv¨andningar r¨attas dessa till innan n¨asta iteration b¨orjar.
V¨arde f¨or XP ¨ar
• Daily stand-up(Agilealliance - Daily meeting, u. ˚a.) • Agila manifestet (Agila manifestet , u. ˚a.)
• Pair-programming • Collective ownership • Test-driven programmering
• Enklaste designen ¨ar den r¨atta designen • Planering med kund
A.4.2
Analys
A.4.2.1 Enk¨ater
P˚a den enk¨at som skickades till v˚ara tre kunder fick jag tv˚a svar och p˚a enk¨aten till grupp var det fyra av fem gruppmedlemmar som svarade. Svaren kommer sammanfattas under kapitel A.5.1 och kan hittas som bilaga F.1.3 och bilaga F.1.4.
A.4.2.2 Krav
Jag gick igenom kraven som finns i kravspecifikationen f¨or att se hur m˚anga och hur spridda kraven var ¨over projektet, denna data anv¨ands sen i analysen om punkterna ”krav” i fallerins listan. Diagram 17 visar resultatet ¨over hur m˚anga, och till vilken del de olika kraven tillh¨orde.
Figur 17 – Diagram ¨over kravspecifikaitonen
A.4.2.3 Kommunikation
Data p˚a de olika kommunikationsmedierna som anv¨ants under projektets g˚ang samlade jag ocks˚a in. Denna data kommer ocks˚a anv¨andas analysen. Vi har under projektets l¨optid haft fyra stycken kommunikationsmedel.
• Mail (Hela projektet l¨optid)
• SMS-grupp (20 jan 2015 - 10 maj 2015) • Skype (11 mars 2015 - 10 maj 2015)
• Facebook grupp (25 april 2015 - 10 maj 2015)
Mail har inte anv¨ands internt inom gruppen utan mest gentemot handledare och kund. D˚a jag inte har haft tillg˚ang till alla mail, har jag valt att utesluta dessa ur statistiken nedan.
All kommunikation inom mediet ¨ar registrerat ifr˚an det datum mediet b¨orjade anv¨andas inom gruppen till den 10 maj. Diagram 18 visar antalet kommunikationer i mediet, antal dagar, samt kommunikationer per dag f¨or varje medium.
Figur 18 – Till v¨anster diagram ¨over antalet kommunikationer och till h¨oger antalet dagar och kommunikation per dag.
Totalt ger detta 1738 kommunikationer mellan gruppen. R¨aknar man med fem dagars veckor perioden 2:e februari - 10:e maj blir det 70 dagar, vilket ger ca 25 kommunikationer per dag. Nedan i diagram 19 visas tv˚a diagram p˚a antalet officiella m¨otesprotokoll dokumenterade inom projektet mellan 1:a feb och 10:e maj.
Figur 19 – Diagram ¨over m¨oten och antalet m¨oten i varje m˚anad.
Det har varit ca sex stycken m¨oten per m˚anad, ut¨over detta har det ocks˚a varit inofficiella m¨oten. Dessa m¨oten ¨ar dock inte dokumenterade och d¨arf¨or inte medtagen i statistiken.
A.4.2.4 Analysens resultat
Eftersom analysen inte g˚ar att g¨ora helt objektiv har jag valt att ta upp den som en diskuterande del (avsnitt A.5.1). Resultatet blev att projektet inte uppfyllt kommunikation, kod och process punkterna.
Extreme programming visade sig enligt v¨ardematris i kapitel A.5.2 l¨amplig f¨or att uppfylla falle- ringspunkterna.