En projektledningsmodell för användarcentrerad utveckling i agila projekt med outsourcad utveckling LEONARD SAERS

Transkript

1 En projektledningsmodell för användarcentrerad utveckling i agila projekt med outsourcad utveckling LEONARD SAERS Examensarbete Stockholm, Sverige 2011

2 En projektledningsmodell för användarcentrerad utveckling i agila projekt med outsourcad utveckling LEONARD SAERS Examensarbete i människa-datorinteraktion om 30 högskolepoäng vid Programmet för datateknik Kungliga Tekniska Högskolan år 2011 Handledare på CSC var Åke Walldius Examinator var Ann Lantz TRITA-CSC-E 2011:059 ISRN-KTH/CSC/E--11/059--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 En projektledningsmodell för användarcentrerad utveckling i agila projekt med outsourcad utveckling Sammanfattning Rapporten undersöker hur ett agilt inspirerat och användarcentrerat tillvägagångssätt kan implementeras på en existerande projektledningsmodell för outsourcing. Både användbarhet enligt ISO och användarcentrerad design enligt ISO studerades. Genom att föra samman tankar från Toyotas produktionssystem, lean software development och scrum sätts en passande projektledningsmodell ihop. Modellen utvärderas sedan på ett mindre programvaruprojekt. Rapporten visar att ett agilt tillvägagångssätt var fördelaktigt för outsourcing. Det kunde också konstateras att den sammansatta modellen inte följde användarcentrering enligt ISO Det antyder att modellen kan omformas för att öka användbarheten i de program som utvecklas med den framtagna modellen. Vidare framkom en del frågor: Är det möjligt att öka användarinvolvering för utlokaliserade utvecklare? Kan grafiska designmönster användas för att öka likheten i den konceptuella modellen mellan projektets deltagare? Kan grafiska designmönster användas som ett autonomeringsverktyg för att öka mängden funktionalitet som utvecklas rätt från början? A user centered model for project management in agile projects with outsourcing Abstract This report investigates how an agile inspired and user centered approach could be implemented on an existing model for managing of outsourced projects. Both usability according to ISO and user centered design according to ISO are studied. By combining thoughts from the Toyota production system, lean software development and scrum, a suitable model for project management is compiled and evaluated in a small software development project. The report concludes that an agile approach was beneficial for outsourcing. It is also concluded that the compiled project management model did not follow the user centered design according to ISO It suggests that the compiled model could be changed in order to increase usability in software developed. Furthermore a few questions were raised: Is it possible to increases user involvement for outsourced developers? Could graphical design patterns be used to increase similarities in conceptual model among the different partners of a project? Could graphical design patterns be used as an autonomation tool in order to increase the amount of graphical designs which do not need to be redesigned after they have been delivered?

4 Förord Examensarbetet är gjort vid CSC, KTH för företaget Dream Builders. Jag vill här passa på att tacka min handledare Dr. Åke Walldius för det stöd och de råd som jag fått under examensarbetet. Jag vill även tacka Jakob Naredi och Andreas Bard vid Dream Builders för deras stöd och för att de låtit mig arbeta med användarcentrering inom outsourcing. Vidare vill jag tacka Mikael Rapp som tagit sig tid att agera bollplank under examensarbetets gång. Jag vill även tacka Ingrid och Jari Alander som båda tagit sig tid att läsa igenom och kommentera denna rapport samt Elizabeth Saers Bigün och Tony Saers som tillsammans inspirerat mig att studera vidare och utnyttja de möjligheter för att studera utomlands som finns på KTH.

5 Innehållsförteckning 1 Inledning Problem och syfte Forskningsfråga Begränsningar Bakgrund Summering av examensarbetets genomförande Teori och metod Att involvera användare Användarcentrerad design ISO Human centered design process for interactive systems Definitioner av användbarhet ISO Användbarhetsmål och användarerfarenhetsmål Användarcentrerade utvecklingsmetoder...7 Konceptuell modell...7 Prototyper Användarcentrerad utformning och utvärderingsmetoder Agila projektmodeller Manifest för Agil systemutveckling Toyotas produktionssystem Lean programvarukonstruktion...15 Lean programvarukonstruktion och ISO Scrum...19 Scrum och ISO Grafiska designmönster Genomförande och undersökning Ursprunglig projektledningsmodell...25 Den ursprungliga modellen och ISO Den nya projektledningsmodellen...28 Teoritillämpning vid utformning av ny projektledningsmodell De fyra rollerna Kommunikationsmedel Arbetsflödet Projektstart Arbetet under en iteration Användarcentrering enligt ISO Genomförande av programvaruprojekt Utvärdering av den framtagna projektledningsmodellen Genomförande och metod för utvärderingen Sammanställning av utvärderingen Uppföljning Diskussion Slutsatser Rekommendationer...49 Bilaga 1: Ett exempel på grafiskt designmönster som används av Dream Builders...51 Bilaga 2: Ett exempel på grafiskt designmönster som används av Dream Builders...52

6

7 1 Inledning 1.1 Problem och syfte Examensarbetet syftar till att förbättra den tidigare projektledningsmodell som används av uppdragsgivaren Dream Builders. Mer specifikt syftar arbetet till att införa en agil inspirerad och användarcentrerad projektledningsmodell med en tyngdpunkt på att tillfredsställa både uppdragsgivare och slutanvändare. Under examensarbetet ska ett ramverk tas fram med riktlinjer för hur projektledningsarbetet ska bedrivas. Vidare ska även rekommendationer till passande metoder för användarcentrerad utvärdering och utformning av programvara beskrivas. 1.2 Forskningsfråga Kan man sätta upp och utvärdera riktlinjer till en användarcentrerad projektledningsmodell för outsourcing, med stöd av principer för användbarhet och metodik för programvarukonstruktion? 1.3 Begränsningar Traditionella linjära arbetsprocesser kommer inte att undersökas. I stället ska ett fåtal utvalda modeller och ramverk som kan kopplas till agil utveckling behandlas. Vidare kommer inte mer specifika aspekter inom projektledning att undersökas, till exempel hur projektets medlemmar motiveras för att göra ett bra arbete. 1.4 Bakgrund Företaget Dream Builders har under flera år arbetat med internetrelaterade applikationer. De har tagit fram och formgivit internetapplikationer både för det egna företaget men också för utomstående kunder. För att klara arbetet med små resurser har de tillämpat outsourcing vid produktionen av internetapplikationer. I dagsläget samarbetar Dream Builders med ett indiskt företag som tillhandahåller utvecklare med kompetens inom webbutveckling. Dream Builders har själva framgångsrikt tagit fram rutiner för hur projektledningen ska gå till vid outsourcing och under åren genomfört ett flertal projekt där utvecklingsarbetet av källkoden varit outsourcad. Examensarbetet gjordes i samarbete med företaget för att undersöka deras projektledningsmodell samt implementera ett användarcentrerad och agilt tänk i projektledningsmodellen. Beslutet att inför en agil metod grundades på min dåvarande uppfattning om att agila metoder är bättre än linjära metoder såvida inte hela organisationen är extremt strukturerad och i förväg vet allt som ska uträttas i ett projekt. 1.5 Summering av examensarbetets genomförande Examensarbetet började med en litteraturstudie och en analys av den projektledningsmodell som Dream Builders använde. Litteraturstudien lade sedan 1

8 grunden till den nya projektledningsmodell som utformades. En serie intervjuer genomfördes varav två djupare intervjuer med syfte att hitta svagheter och styrkor i Dream Builders ursprungliga projektledningsmodell. Efter det genomfördes ett mindre programvaruprojekt där den nya projektledningsmodellen tillämpades. Programvaruprojektet involverade även en av de indiska utvecklarna som Dream Builders sedan tidigare haft kontakt med. Därefter hölls ytterligare en djupare intervju vilken syftade till att sätta den nya projektledningsmodellen i relation till den ursprungliga. Slutligen studerades ISO noggrannare och en sista intervju genomfördes i syfte att följa upp hur Dream Builders tillämpar den framtagna projektledningsmodellen. 2

9 2 Teori och metod Följande avsnitt presenterar den teori och de metoder som examensarbetet tillämpar. Avsnittet börjar med att diskutera användbarhet och användarcentrering. Därefter presenteras olika tankar och metoder som kan knytas till den agila projektmetodiken. Slutligen ges en beskrivning av grafiska designmönster. 2.1 Att involvera användare Människan har en enastående förmåga att anpassa sig till olika situationer. Denna förmåga nämns av Rubin (1994, p.7) som en av flera orsaker till att datorprogram blir svåranvända. I stället för att anpassa programmet efter användaren tvingas användaren att anpassa sig efter programmet. Användarcentrerad design syftar till att forma programvara efter användaren och inte tvärtom. Följande kapitel kommer att beskriva det användarcentrerade tillvägagångssättet, användbarhet och dess principer samt ett urval av relevanta metoder för att ta fram samt utvärdera användbarhet i programvara Användarcentrerad design Användarcentrerad design handlar om att centrera designprocessen kring användaren. I praktiken betyder det att användaren ska involveras i samtliga steg som tillämpas i designprocessen. Det innebär att användaren ska studeras och hennes behov och önskemål ska där igenom lockas fram. Vidare ska användarens idéer och önskemål beaktas. Användarcentrerad design betyder däremot inte att användaren direkt formger en produkt eller har kontroll över designprocessen (Wicken et al., 2004, p.35). För att skapa en god användarcentrerad design nämns ofta Goul och Lewis (1985) tre principer för utveckling. Tidig fokus på användare och uppgifter: Först förstå vilka användarna är och sedan involvera dem i utvecklingen. Empiriska observationer: Låt användare tidigt läsa manualer samt interagera med simulationer och prototyper. Spela in, observera och analysera användarnas interaktion. Iterativ design: När ett problem upptäcks ska det rättas till samt ska tester skapas som kontrollerar om problemet finns kvar efter det att programmet korrigerats. Detta kräver en iterativ cykel som innehåller: utformning, test, mätning samt omarbetning av utformning. 3

10 Gulliksen och Göransson (2002, p ) understryker följande i sin syn på användarcentrerad design: Med användare menas riktiga användare som kommer interagera med systemet för att genomföra uppgifter i arbetet eller andra sammanhang. Att användaren aktivt involveras under hela processen och att användaren aktivt deltar i framtagandet av lösningar. Användarcentrerad design genomsyrar hela systemets livscykel. De nyss nämnda punkterna ligger till grund för hur användarcentrering i rapporten ska tolkas ISO Human centered design process for interactive systems ISO är ett koncept för användarcentrerad systemutveckling. Standarden grundas på fyra principer (Gulliksen och Göransson, 2002, p.105) (Sharp et.al, 2007, p.462): Aktiv involvering av användare och en tydlig förståelse av användarens och uppgiftens krav: Standarden understryker att involvering av användare är en värdefull källa till information och att effekten ökar med graden av involvering mellan utvecklare och användare. En lämplig fördelning av funktion mellan användare och teknik: Ett överdrivet fokus på användarinvolvering som leder till bristande resurser för den tekniska utvecklingen är inte önskvärt. Likaså ska inte fokus på teknikutveckling få ta överhand från användarinvolveringen. Iterering av designlösningar. Tvärdisciplinär design: Olika kompetenser från olika områden bör finnas med i utvecklingslaget. Vidare definierar ISO en vägledande modell för hur det användarcentrerade arbetet ska bedrivas. Processen visas i Illustration 1. Innan en process startar ska (a) behovet för användarcentrerad design analyseras. Väljer man sedan att gå vidare med ett användarcentrerat tillvägagångssätt ska följande fyra designaktiviteter i tur och ordning genomföras iterativt. Först ska (b) användarsammanhanget analyseras. Det ska klargöras vilka användargrupper som finns, vilka mål dessa olika grupper har samt vilken miljö användarna kommer att arbeta i. Sedan ska (c) kraven sättas samman. Kraven ska bestå av både funktionella krav och användbarhetskrav. Användbarhetskraven ska i så stor utsträckning som möjligt vara mätbara. Nästkommande steg (d) blir att utveckla det som specificerats. Under detta steg ska de 4

11 framtagna lösningarna även provas på användare i så realistisk miljö som möjligt. Slutligen ska (e) en mer formell utvärdering av de användbarhetsmål vilka tidigare satts upp genomföras. Resultatet av utvärderingen ger viktigt information inför nästkommande iteration, i det fall då man fortsätter med ytterligare en iteration. Beskrivning av figurerna (a) Identifiera behovet av användarcentrerad design (b) Förstå och specificera användningssammanhanget (e) Utvärderar designen gentemot kraven Systemet uppfyller specificerade användarkrav och organisationskrav (c) Specificera användarkrav och organisatoriska krav (d) Producera designlösningar Illustration 1: Arbetsflödet enligt ISO Text tagen från Gulliksen och Göransson (2002, p. 105) Definitioner av användbarhet Användbarhet beskrivs på följande sätt av Rubin och Chisnell (2008, p.4): Användaren kan göra vad han eller hon vill göra på det sättet han eller hon förväntar sig att det ska utföras, utan hinder, tvekan eller frågor. Vad som är användbart är svårt att definiera, det finns sällan ett enda entydigt svar. Ett program kan exempelvis vara lätt att lära för den ovane men svårt att använda för den erfarne ifall programmet exempelvis saknar snabbkommandon för smidig navigering. Den erfarne har förmodligen högre krav på smidig navigering än vad den ovane har och således kan den erfarne uppleva programmets användbarhet som lägre än vad den ovane upplever. Vidare är inte enkelhet och smidighet i ett program alltid något som ökar användbarheten. I ett datorspel kan användbarhetsvärdet anses högre om spelets 5

12 uppgifter är utformade för att vara svårlösta. Det omvända gäller för ett ordbehandlingsprogram. Användbarhet beror därför bland annat på vilka som använder programmet samt vilket mål användaren har med programmet ISO ISO ger följande definition av användbarhet (Gulliksen och Göransson, 2002, p.62): den utsträckning till vilken en specificerad användare kan använda en produkt för att uppnå specifika mål, med ändamålsenlighet, effektivitet och tillfredsställelse i ett givet användningssammanhang. Vidare nämner ISO specifikt följande fyra dimensioner (Gulliksen och Göransson, 2002, p.62): Ändamålsenlighet: Noggrannhet och fullständighet med vilken användarna uppnår givna mål. Effektivitet: Resursåtgång i förhållande till den noggrannhet och fullständighet med vilken användarna uppnår givna mål. Tillfredsställelse: Frånvaro av obehag samt positiva attityder vid användningen av en produkt. Användningssammanhang: Användare, utrustning (maskinvara, programvara och annan materiel) samt fysisk och social omgivning i vilken produkten används. För att förtydliga det hela beror användbarhet på (a) vem som använder programmet och hur denne användare uppnår specifika mål med (b) ändamålsenlighet, (c) effektivitet, (d) tillfredsställelse och (e) i ett givet användningssammanhang. Vidare ser ISO användbarhet som en mätbar enhet (Gulliksen och Göransson, 2002, p.64). Det är exempelvis möjligt att med specifikationen påstå att en given utformning i ett givet användningssammanhang är 30% mer effektiv och 10% mer ändamålsenlig än en annan utformning. Detta är bra egenskaper när man ska specificera mätbara användbarhetskrav för ett program Användbarhetsmål och användarerfarenhetsmål En annan vanlig definition över hur användbarhet ska mätas eller bedömas är genom användbarhetsmål (på engelska usability goals ) och användarerfarenhetsmål (på engelska user experience goals ). Användbarhetsmålen består av 6 punkter som kompletteras av en växande mängd användarerfarenhetsmål (Sharp et.al, 2007, p20-28). Jag upplever att denna specifikation är svårare att greppa och att ISO i sig är heltäckande. Därför är det ISO som menas i denna uppsats när begreppet användbarhet används. 6

13 2.1.6 Användarcentrerade utvecklingsmetoder För att skapa användbar programvara finns ett antal användarcentrerade metoder. Några av dessa metoder kommer att presenteras nedan. Begreppet konceptuell modell kommer initialt att förklaras i syfte att ge en förståelse för vikten av användbarhet. Därefter förklaras vad som menas med begreppet prototyp. Avsnittet går sedan vidare med att ge en bild av olika användarcentrerade utvärderings och utformningsmetoder. Konceptuell modell En konceptuell modell kan ses som en övergripande beskrivning av hur ett system är organiserat samt hur det fungerar (Sharp et.al, 2007, p51-53). Varje användare av ett system har en egen konceptuell modell över systemet. Norman (1988, p ) tillämpade den konceptuella modellen och satte upp ett ramverk som belyser relationen mellan dels designerns konceptuella modell, systemets utformning och användarens förståelse för systemet, se Illustration 2. Modellen lyfter på ett tydligt sätt fram en av anledningarna till varför det är svårt att utforma programvara som upplevs som användbar av användare. Dels visar modellen (1) hur designern tänkt sig att systemet ska fungera, (2) hur systemet fungerar och (3) hur användaren uppfattar att systemet fungerar. I idealfallet har användaren och designern samma konceptuella modell av systemet, men så är sällan fallet. Det är däremot designerns kanske viktigaste uppgift att i så stor grad som möjligt föra samman användarnas olika konceptuella modeller med sin egen. För att åstadkomma detta utgör de användarcentrerade utvecklingsmetoderna kraftfulla verktyg. Designerns modell Designer Användarens modell Systembild Användare Illustration 2: Normans ramverk för relationen mellan designerns konceptuella modell och användarens förståelse av systemet. 7

14 Prototyper Det är vanligt att användarcentrerade utformnings och utvärderingsmetoder använder sig av prototyper. Prototyper är utmärkta för att ta fram nya idéer men även för att kommunicera och förklara de idéer som tas fram (Löwgren och Stolterman, 2004, p.38 39). På så sätt kan en prototyp ses som ett kommunikationsverktyg. En prototyp är en mer eller mindre utvecklad produkt som syftar till att visa hur en senare färdig produkt ska se ut och fungera. Prototypen behöver inte vara speciellt lik den slutgiltiga produkten. Det är vanligt att dela in en prototyp i en av de två grupperna: Low-fidelity (lo-fi) och High-fidelity (hi-fi), där lo-fi prototyper är av intresse för den här rapporten. Lo-fi prototypen är enkel att tillverka och enkel att modifiera. Ofta består den av pappersskisser eller något annat material som är enkelt och okomplicerat att arbeta med. Lo-fi prototyper är i sig både flexibla och billiga att ta fram. Det medför att lo-fi prototyper i än högre grad uppmuntrar till ändringar i utformning av programvara (Sharp et.al, 2007, p ). Prototyper innehåller alltid kompromisser gentemot den slutliga produkten. Tanken är att framställa något snabbt som sedan ska testa eller visa en eller flera aspekter av produkten. Två vanliga kompromisser som ofta direkt påverkar varandra är förhållandet mellan bredd och djup i prototypen. En djup prototyp, även kallad vertikal prototyp fångar upp detaljer i produkten och en bred prototyp, även kallad horisontell prototyp fångar upp helheten i produkten (Sharp et.al, 2007, p ) Användarcentrerad utformning och utvärderingsmetoder För att ta fram användbar programvara är det nödvändigt att känna till metoder för hur programvara utformas och sedan utvärderas. Utformnings och utvärderingsmetoder kan delas upp på många sätt. Löwgren och Stolterman (2004, p.85) har delat in dem i fem grupper: Undersökning Utforskning Komposition Värdering Koordinering Undersökningsmetoder syftar till att förstå den nuvarande situationen och dess förändringsmöjligheter. Till utforskningsmetoder hör de metoder som studerar vad som är möjligt att genomföra (Löwgren och Stolterman, 2004, p.90). Kompositionsmetoder används för att skapa en helhet och sätta ihop flera delar av ett system (Löwgren och Stolterman, 2004, p.102) värderingsmetoder utförs vanligtvis via användbarhetstestning där produktens lämplighet kan värderas i olika användningssammanhang (Löwgren och 8

15 Stolterman, 2004, p.116). Koordineringsmetoder syftar till att koordinera alla de metoder som används i processen för att ge ett så givande resultat som möjligt (Löwgren och Stolterman, 2004, p.124). Alla metoder involverar inte användare, då det inte alltid är praktiskt eller genomförbart, men ej användarcentrerade metoder kan tappa sitt syfte om de inte kombineras med användarcentrerade metoder. Syftet med en användarcentrerad metod är att undersöka interaktionen i en produkt där användaren sätts i fokus. Användarcentrerade metoder kan i sig delas in i intervjuer, frågeformulär och observationer (Sharp et.al, 2007, p ). Ofta är direkta observationer av användare att föredra. Innan en utformnings eller utvärderingsmetod genomförs måste mål med metoden samt etiska riktlinjer fastslås. Datainsamlandet bör också trianguleras för att öka både tillförlitligheten och giltigheten. Resultatet som framkommer från olika utvärderingar kan delas upp i kvantitativa samt kvalitativa data. Kvantitativa data mäts med siffror och kvalitativa data är subjektiva utsagor. Ofta resulterar en utvärderingsmetod i både kvantitativa och kvalitativa data (Sharp et.al, 2007, p ). Kontextuellt utforskande (Löwgren och Stolterman, 2004, p.87-88) är ett exempel på en användarcentrerad undersökningsmetod där man tillämpar intervjuer och observationer i syfte att förstå arbetssituationen. Intervjuerna kan med fördel genomförs så att användaren intervjuas samtidigt som användaren utför sina dagliga uppgifter. Både de svar som användaren ger under intervjun och det användaren gör blir till indata i metoden. Dessa utvärderingar görs ofta under en så kallad fältstudie där användaren observeras i den miljö där det är tänkt att produkten ska användas (Gulliksen och Göransson, 2002, p ). Metoden kontextuellt utforskande tenderar att ge stora mängder kvalitativa data. Användarcentrerade undersökningsmetoder kan även genomföras under kontrollerade former i ett användbarhetslaboratorium (Gulliksen och Göransson, 2002, p ). Laboratorieutvärderingar kräver mycket arbete, men de kan öka mängden kvalitativa data. Framtidsverkstad är ett utforskningsmetod som nämns av Löwgren och Stolterman (2004, p.92). Metoden syftar till att blivande användare och intressenter (1) själva är med och definiera problemen i sin nuvarande situation, (2) formar visioner om framtiden och (3) diskuterar hur visionerna kan förverkligas. Vid genomförande av det programvaruprojekt som utfördes under examensarbetet tillämpas en enklare variant av framtidsverkstad. Denna variant kommer senare i rapporten att nämnas som verkstad. Fokusgrupp är ett exempel på en användarcentrerad metod som ofta är undersökande. Under genomförandet av fokusgruppen hålls ofta en öppen intervju där ett tvärsnitt av tänkbara användare med olika bakgrund intervjuas tillsammans (Sharp et.al, 2007, p ). Metoden kan också ge vägledning till hur en produkt ska utformas och 9

16 därmed blir metoden också utforskande. Ett exempel på undersökande metod är tänka högt metoden. En användare får en eller flera uppgifter att lösa och till sin hjälp det gränssnitt som ska utvärderas. Samtidigt som användaren försöker lösa uppgifterna berättar användaren hur hon eller han tänker och resonerar. Metoden syftar till att ta reda på vilka inre tankeprocesser som pågår hos användaren (Sharp et.al, 2007, p ). Storyboard (Löwgren och Stolterman, 2004, p ) är ett exempel på en kompositionsmetod där flera bilder av gränssnittet tillsammans med ett antal texter löpande förklarar ett scenario. Metoden kan ses knyta ihop interaktionen mellan olika delar i systemet och därmed bli ett verktyg som bidrar till att synliggöra helheten. Varför-varför-varför är en annan undersökningsmetod (Löwgren och Stolterman, 2004, p ). Efter att ett problem har identifierats i den nuvarande situationen ställs ett antal på varandra följande varför frågor för att på så sätt bygga upp en kedja av samband. För ett e-handelssystem skulle man kunna fråga sig varför en given kund valde att lämna webbutiken. Det finns givetvis många svar på frågan, men ett svar kan vara att kunden inte kunde hitta den eftersökta varan. Nästa fråga blir då varför kunde inte kunden hitta den eftersökta varan. Varförmetoden ska inte underskattas, Taiichi Ohno (1988, p 17-18, p. 123) använde bland annat metoden flitigt för att bygga upp Toyotas produktionssystem. En icke användarcentrerad utvärderingsmetod är heuristisk utvärdering. Genom att följa ett uppsatt scenario för interaktion med ett gränssnitt kan en expert utvärdera användbarheten genom att beakta ett antal principer för hur användbar interaktion utformas. Heuristisk utvärdering är värd att känna till trots att den ej är användarcentrerad då den är enkel att genomföra samtidigt som metoden kan belysa uppenbara brister i en utformning (Sharp et.al, 2007, p ). För att beskriva interaktionen är det vanligt att användarfall tillämpas. Användarfall beskrivs med hjälp av aktörer som interagerar med olika system. Aktören kan vara riktiga användare eller system som interagerar med andra system (Sharp et.al, 2007, p.510). Det är viktigt att komma ihåg att syftet med de nämnda metoderna är att öka användbarheten i programvaran. Det gäller att kompetens inom människa datorinteraktion finns inom organisationen som tar fram programvara och att metoderna skräddarsys efter de mål som sätts upp för undersökningarna. Det är därför viktigt att bemästra en mängd utvärderings och utformningsmetoder. De ovan nämnda metoderna är ett litet urval av tillvägagångssätt för framtagning och utvärdering av användbar programvara och har endast presenterats kortfattat. 10

17 2.2 Agila projektmodeller Det här kapitlet börjar med en kort introduktion till agil systemutveckling. För att bättre förstå det agila arbetssättet beskrivs sedan det produktionssystem för bilar som Taiichi Ohno skapade för Toyota. Många av de agila metoder som finns i dagsläget är inspirerade av Ohnos idéer. Vidare undersöks Lean programvaruproduktion samt scrum. Modellerna och ramverken sätts i relation till ISO Manifest för Agil systemutveckling Agile manifesto sammanfattar agil systemutveckling med följande text (Agil manifesto, 2001): Vi finner bättre sätt att utveckla programvara genom att utveckla själva och hjälpa andra att utveckla. Genom detta arbete har vi kommit att värdesätta: Individer och interaktioner framför processer och verktyg Fungerande programvara framför omfattande dokumentation Kundsamarbete framför kontraktsförhandling Anpassning till förändring framför att följa en plan Det vill säga, medan det finns värde i punkterna till höger, värdesätter vi punkterna till vänster mer. Traditionella linjära projektledningsprocesser kan tyckas värdesätta det motsatta. Till exempel att följa en plan i stället för att anpassa sig till förändringar. Den ena värderingen behöver inte nödvändigtvis vara mer framgångsrik än den andra. Exempelvis kan det tänkas att det är enklare att erbjuda en beställare ett fast pris om man följer en plan framför att anpassa till förändring. Att anpassa till förändring framför att följa en plan kan i stället tillåta att den programvara som ska tas fram under utvecklingens gång i en högre grad anpassas efter användarna. Det här examensarbetet följer de agila värderingarna som nämns i Agile manifesto Toyotas produktionssystem Toyotas produktionssystem utvecklades från behovet av att kunna producera små kvantiteter av många olika modeller. Produktionssystemet utvecklades under en tid då massproduktion av ett fåtal produkter sågs som nyckeln till att sänka produktionskostnaden (Ohno, 1988, p.xiii, p.1). Ohno lyckades genom att ifrågasätta inarbetade metoder för fordonstillverkning och testa nya tillvägagångssätt implementera ett nytt produktionssystem som inte är beroende av massproduktion för att sänka kostnaderna. Det hann gå nästan 20 år från det att Ohno började arbeta med det nya produktionssystemet innan Toyota år 1963 kunde tillämpa produktionssystemet i samtliga av företagets fordonsfabriker (Ohno, 1988, p.31). 11

18 Toyotas produktionssystem är uppbyggd på två fundamentala processer (Ohno, 1988, p.4): Just-in-time (JIT). Autonomation med en mänsklig inverkan. JIT betyder att produkter ska levereras precis då produkten efterfrågas och i precis rätt mängd (Ohno, 1988, p.123). Autonomation har två likartade betydelser i Toyotas produktionssystem. För det första syftar autonomation på att överföra mänsklig intelligens till maskiner. På så sätt kan maskinen själv avgöra om de produkter den tillverkar är defektfria. Syftet är att maskinen ska kunna ta autonoma beslut. För det andra ska vanliga arbetare som bygger bilar ges möjligheten till autonoma beslut. Det huvudsakliga syftet är att både maskiner och arbetare självständigt ska kunna stoppa produktionen ifall någon brist i processen gör att defekta produkter produceras. Arbetarna ska sedan själva ha befogenhet att ändra processen på ett sådant sätt att bristen i systemet för alltid försvinner. Autonomation syftar också till att ge arbetarna befogenhet över andra beslut som exempelvis om övertid kommer att krävas (Ohno, 1988, p.45, p.113, p ). Ett genomgående tanke i Toyotas produktionssystem är att eliminera slöseri. År 1937 när Ohno arbetade på Toyotas väveri fick han berättat för sig att en amerikansk arbetare kan producera nästan 10 gånger så mycket som en japansk arbetare. Ohno drog slutsatsen att japaner slösar på arbetsresurser och att det var möjligt att öka produktionen med en faktor tio enbart genom att identifiera och eliminera slöseriet. Att eliminera slöseri är själva grunden till Toyotas produktionssystem. JIT och Autonomation är enbart verktyg för att kunna nå målet till absolut eliminering av allt slöseri (Ohno, 1988, p.3 4). Illustration 3 understryker syftet med Toyotas produktionssystem samt de två pelarna som modellen vilar på. Illustration 3: Toyotas produktionssystem utvecklades med syfte att eliminera allt slöseri (onödigt arbete). De främsta verktygen för att eliminera slöseriet är JIT och Autonomation. 12

19 Med slöseri menar Ohno allt arbete som inte behövs i processen (1988, p.57 58). Vid biltillverkning skulle slöseri exempelvis kunna vara arbetet med att packa upp levererade varor som ska monteras. I många fall skulle varorna kunna levereras färdiguppackade. Värst av allt slöseri var behovet att lagra varor på lager för framtida användning (Ohno, 1988, p.54-60). JIT blev ett av de viktigaste verktygen för att skapa ett produktionssystem med ett minimalistiskt lager. Genom att tänka sig processen baklänges lyckades Ohno få senare delar av processen att gå till tidigare delar och beställa vad de behövde (Ohno, 1988, p.25 27). Ohno såg också till att enkla beställningskort användes. Dessa kort kallas för kanban och med dem kunde senare delar i processen specificera till tidigare delar i processen den nödvändiga beställningsinformationen som behövdes (Ohno, 1988, p.27 32). Exempel på information som finns på korten är: Vilken vara som behövs. När varan behövs. Hur många varor som behövs. Vilken lastkaj som ska användas vid leveransen. Det omvända flödet och kanbankorten var båda viktiga komponenter till att varje steg i processen kunde få de delar de behövde precis då delarna behövdes. Det ska understrykas att kanban blev ett viktigt kommunikationsverktyg mellan de olika delarna i processen (Ohno, 1988, p.42). För att JIT skulle fungera blev det förbjudet att leverera defekta komponenter. Vidare gällde det att i förväg veta hur lång tid det skulle ta att tillverka varje enskild detalj (Ohno, 1988, p.99). Inget i processen fick heller gå sönder så att varorna inte kunde levereras i tid (Ohno, 1988, p.6 7). Detta löstes till stor del med autonomation. Ohno (1988, p.101) understryker vikten av att förebygga oväntade produktionsstopp i stället för att ha ett lager som tillåter att produktionen oväntat stannar. Ytterligare en viktig del i processen är balansering (på engelska leveling ). Processen måste designas för att klara av svängningar i efterfrågan. Det är exempelvis viktigt att snabbt kunna ställa om till hög eller låg produktion av en eller flera bilmodeller. Detta är ett svårt arbete men en viktig del är att varje steg i processen snabbt kan ställas om från produktion av en modell till en annan (Ohno, 1988, p ). Givetvis finns det mer att hämta från Toyotas produktionssystem. Ovanstående text nämner grundbultarna i hur en process som tidigare var beroende av massproduktion kunde omvandlas till en process som klarar av att leverera många modeller i små kvantiteter. Bilden nedan presenterar de viktigaste termerna i produktionssystemet samt hur de hör ihop. 13

20 Illustration 4: Toyotas produktionssystem. Egen tolkning av hur begrepp i modellen relaterar till varandra baserad på Tachii Ohnos bok. 14

21 2.2.3 Lean programvarukonstruktion 1990 publicerades boken The Machine That Changed the World (Womack, et al.) och begreppet lean production föddes. Lean production bygger till stor del på Toyota's produktionssystem. Mary och Tom Poppendieck (2006) ger sin syn på hur begreppet lean production kan appliceras på programvarukonstruktion genom att presentera sju principer som alla bygger på lean och Toyotas produktionsmodell. Poppendieck börjar med att understryka att en princip är en underliggande sanning som inte förändras över tiden. Tillämpningar bygger på principer men kan i sig ändras mycket under tidens gång (2006, p.19). Lean programvarukonstruktion baseras på följande sju principer. 1. Eliminera slöseri. 2. Bygg in kvalité. 3. Skapa kunskap. 4. Skjut upp åtaganden. 5. Leverera snabbt. 6. Respektera människor. 7. Optimera helheten. Eliminera slöseri följer Ohnos tankar. Poppendieck jämför halvfärdig kod med det slöseri som uppstår av att ha ett lager. Slöseriet som enligt Ohno uppstår vid överproduktion jämförs med slöseriet att lägga in extra funktionalitet som inte är nödvändig i programvaran (Poppendieck, 2006, p.23-25). Vidare nämner Poppendieck en mer specifik lista av slöseri inom programvarukonstruktion. Som exempel ges viktiga beslut som inte är dokumenterade och kod som saknar automatiska inbyggda tester eller som saknar dokumentation (Poppendieck, 2006, p.73-82). Bygga in kvalité handlar om att göra rätt från början. När en defekt identifieras stoppas utvecklingen tills defekten är åtgärdad. Automatiska tester byggs in i koden i syfte att förebygga fel innan de uppkommer. Testning är med det synsättet inte till för att hitta defekter utan ska användas för att undvika att defekter uppkommer från första början. Detta kan direkt jämföras med Ohnos tankar om autonomation. Att bygga in kvalité betyder också att enbart färdig kod får levereras (Poppendieck, 2006, p.25-29). Skapa kunskap understryker att programvarukonstruktion är en kunskapsskapande process och att det är omöjligt att i förväg veta exakt hur den slutliga applikationen ska utformas. Utvecklarna måste systematiskt få tillfälle att lära sig dels hur produkten ska utformas samt den teknik som är nödvändig för utformningen. Det är även viktigt att sätta av tid för förbättringar av processen. Precis som med balanseringen i Toyotas produktionssystem gäller det att skapa ett system som snabbt kan anpassa sig till nya 15

22 händelser (Poppendieck, 2006, p.29-32). Skjuta upp åtaganden handlar egentligen bara om att skjuta upp oåterkalleliga beslut till sista stund. Det viktig är att ha så mycket kunskap som möjligt innan kritiska beslut fattas (Poppendieck, 2006, p.32 33). Principen skulle kunna jämföras med JIT där precis rätt mängd kunskap skapats för att fatta rätt beslut. Om man väntar ytterligare med att fatta beslutet skulle senare beslut i processen försenas. Skulle man där emot fatta beslutet tidigare än nödvändigt så finns inte all den information som annars skulle ha funnits. Att leverera snabbt kräver en organisation där slöseriet är eliminerat och där kvalité byggs in från start. Byggs inte kvalité in från början kommer de första leveranserna möjligtvis att levereras snabbt, men allt eftersom projektet växer kommer leveranstiden att öka. Snabb leverans ger även tid till att skapa kunskap. Vidare nämner Poppendieck att det är bra att leverera så pass snabbt att kunden inte hinner ändra sig (Poppendieck 2006, p.34-35). Hastighet är avsaknad av slöseri (Poppendieck 2006, p.95) Respektera människor är den viktigaste av det sju principerna. Det gäller att människorna som är involverade är engagerade och tänkande. Respekteras människorna i projektet fullt ut kommer de övriga sex principerna också falla på plats (Poppendieck 2006, p.117). Poppendieck (2006, ) understryker både vikten av lagarbete, tilltro till andras kompetens samt vikten av att ge lagarbetarna möjlighet att i tid klara av de uppgifter de tar på sig. Vidare nämns vikten av ledarskap, varje lag måste ha en ledare som även är ansvarig för arbetet. Ledaren ska ha extra hög kompetens för att kunna ta de kritiska designbesluten som finns i programvarukonstruktion. Bilden nedan sammanfattar de sju principerna. Illustration 5: De sju principerna för Lean, egen tolkning av hur principerna förhåller sig till varandra. Utöver de sju principerna nämner Poppendieck ett antal tillvägagångssätt som, om de tillämpas på rätt sätt, bidrar till att principerna efterlevs. 16

23 Arbetet ska löpa i cykler. En cykel eller iteration ska ha en på förhand bestämd tidslängd. Utvecklingsarbetet ska delas upp i korta cykler där varje kommande cykel planeras noggrant och varje genomförd cykel utvärderas. Efter varje cykel är ytterligare en del av applikationen som utvecklas färdig. Varje cykel är som ett hjärtslag som pumpar ut nya färdiga delar till applikationen. Både beställare och utvecklare kan se hur applikationen utvecklas hjärtslag för hjärtslag (Poppendieck 2006, p.109). Det är även viktigt att arbeta med en kortsiktig planering eftersom förutsägelser om framtiden alltid är felaktiga ifall de är (1) komplexa (2) detaljerade (3) om en avlägsen framtid (4) om en osäker miljö. Det gäller därför att minska svarstiden för att snabbt kunna anpassa situationen (Poppendieck 2006, p.31-32). Genom att hålla cyklerna korta ökar sannolikheten till att planeringen för cykeln håller. För att framgångsrikt planera kortsiktigt ska kön av pågående arbetsuppgifter hållas så kort som möjligt och byggas på allt eftersom projektet fortskrider (Poppendieck 2006, p ). Större arbetsuppgifter måste delas in i mindre aktiviteter (Poppendieck 2006, p.107). På så sätt förenklas den kortsiktiga planeringen. Arbetet ska begränsas till den tillgängliga kapaciteten. Utvecklarna får inte arbeta övertid. Vidare rekommenderas tillämpning av dragschema (på engelska pull scheduling ) (Poppendieck 2006, p ). Det gäller därför att bryta ner arbetsuppgifter till kanban som beskriver vad som ska implementeras. Utvecklarna kan sedan välja vilka kanbans som ska utvecklas under en iteration. Rutiner för att identifiera defekter genast rätta till dem måste även implementeras i processen (Poppendieck 2006, p ). Vidare nämns vikten av ett starkt och tydligt ledarskap i utvecklingsgruppen. Organisationen ska vara platt och lagmedlemmarna ska till stor del styra sitt eget arbete. Det är också viktigt att ansvarsfördelningen är tydligt uppfördelad inom gruppen (Poppendieck 2006, p.56 57, p ,). Lean programvarukonstruktion och ISO Poppendieck understryker behovet av användarinvolvering, framförallt när det gäller att skapa kunskap kring programvaran som ska utvecklas. De understryker också behovet av att tjäna pengar på det som utvecklas. Användarinvolvering kan bland annat bidra till att uppdragsgivaren tjänar mer pengar på programvaran. Enligt Poppendieck (2006, p. 153, p ) tycks det vara viktigt att skapa smidig programvara som går lätt att omforma och att sedan ge användarna tillgång till en minimalistisk mängd funktionalitet så fort som möjligt. På så sätt kan programvaran tidigt både börja tjäna pengar åt uppdragsgivaren och användarnas interaktion med programmet kan analyseras. Vid behov kan programmet sedan omformas. Detta liknar Ohnos idé om balansering och att snabbt gå från en produktion till en annan. Men det motsäger tankarna om autonomation där felen från första början ska undvikas. Poppendieck 17

24 nämner enhetstester som ett verktyg för att kod ska bli rätt skapad från första början. Det är däremot oklart hur interaktionen ska skapas för att även den från första början ska bli rätt utformad. Man kan anta att det här finns en balansgång mellan kostnad och förtjänst för användarcentrering. Beskrivning av figurerna (a) Identifiera behovet av projektets genomförande (b) Bestäm vilka kanbans som ska utvecklas under kommande iteration. (e) Utvärderar det arbete som implementerats under iterationen Systemets värdeökning är mindre än kostnaden för ytterligare en iteration (c) Under hela processen ska nya behovsprövade arbetsuppgifter läggas in i den kortsiktiga planeringen. (d) Utveckla de uppgifter som nämns på kanbankorten Illustration 6: Ett exempel på hur en användarcentrerad process som följer lean programvarukonstruktion kan se ut. Punkt (c) och (d) skulle med fördel kunna genomföras parallellt. Därför är det ingen pil mellan dessa punkter. Illustration 6 visar ett exempel på hur lean programvarukonstruktion skulle kunna tillämpas. Att involvera användare i samtliga steg går väl ihop med principen att skapa kunskap under arbetets gång. Processen är iterativ och kan snabbt anpassas till nya förutsättningar. Det är här inga problem att anpassa arbetet efter användarens behov. Användarcentrering kan även ses som ett verktyg som bidrar till att interaktionen i programvaran utformas rätt från första början. På så sätt kan användarcentrering jämställas med enhetstester som i sig ser till att kod produceras utan buggar. Det finns inte heller några hinder för att i början av en iteration analysera användarsammanhanget 18

25 och sätta upp mätbara användarkrav. I slutänden handlar lean om att fasa ut allt onödigt arbete ur processen så att enbart värdeskapande kod produceras. Om implementeringen av ISO i processen kan bidra till det målet, är det även önskvärt att standarden implementeras Scrum Scrum är i sig ingen process eller teknik för att bygga produkter. I stället ska scrum ses som ett ramverk där olika processer och tekniker kan implementeras för att bistå en produktutveckling där avancerade produkter skapas. Scrum som ramverk är inkrementell, arbetet fortskrider således i cykliska iterationer. Scrum syftar till att optimera förutsägbarhet och kontrollera risker (Schwaber och Sutherland, 2010). Scrum vilar på följande tre pelare (Schwaber och Sutherland, 2010): Genomskinlighet: de aspekter som påverkar resultatet ska vara synliga för de personer som senare ska ta hand om resultatet. Inspektion: Olika delar i processen måste inspekteras tillräckligt ofta för att upptäcka oväntade variationer i processen. Anpassningsbarhet: Om ej acceptabla variationer detekteras vid inspektionen måste processen eller materialet som blir processat rättas till så snabbt som möjligt. Inom scrums ramverk finns följande tre roller som tydlig sätter upp en ansvarsfördelning. Scrum master (Scrummästare): Ska försäkra att processen är förstådd och att arbetet går smidigt. Uppstår situationer som hindrar vidare utveckling av någon del i processen ligger det i scrummästarens ansvar att lösa problemen. Scrummästaren får aldrig vara produktägare (Schwaber och Beedle, 2002, p ). Till rollen hör även ansvaret av att fatta samt ansvara för kritiska designbeslut (Schwaber och Beedle, 2002, p. 45). Produktägare: Maximerar arbetet som ett scrumlag genomför. Produktägaren är en person som har stor kännedom om den produkt som ska utvecklas. Produktägaren får hjälp och stöd av scrummästaren för att förstå hur hon eller han ska arbeta. Produktägaren bestämmer vilka uppgifter som är viktigast att arbeta med samt uppskattar den tid det tar att genomföra de uppgifter som ej är genomförda (Schwaber och Beedle, 2002, p ). Scrumlag: De utvecklare som driver den faktiska utvecklingen i projektet. Varje iteration kallas för sprint och är normalt 30 dagar lång. Under varje iteration finns ett antal olika mötesformer samt verktyg för koordinering av projektet. Varje sprint startar med ett planeringsmöte där beställare, användare, ledning och produktägare möts. Scrumlaget och scrummästaren möts och formar nästa sprint. Mer 19

26 specifikt sätts mål för kommande sprint samt bestäms vad som ska utvecklas. Efter mötet genomförs ett internt möte för att inom scrumlaget planera den kommande sprinten (Schwaber och Beedle, 2002, p. 47). När sprinten sedan startar får inga utomstående personer påverka sprintens mål eller något annat som bestämts under sprintens planeringsmöte. Ingen utomstående får säga till scrumlaget hur de ska arbeta för att klara av det uppsatta sprintmålet (Schwaber och Beedle, 2002, p. 51). Varje arbetsdag under en sprint börjar med det dagliga scrummötet. Mötet är endast 15 minuter långt och deltagarna i scrumlaget förklarar (1) vad de gjort sedan det senaste dagliga scrummötet, (2) vad de tänkt uträtta till nästa dagliga scrummöte samt (3) vad som hindrar dem från att uträtta arbete (Schwaber och Beedle, 2002, p. 40). Det är således ett utmärkt tillfälle för scrumlagets medlemmar att belysa problem. I slutet av varje sprint har scrumlaget ett utvärderingsmöte för sig själva samt ett redovisningsmöte med beställare, användare, ledning och produktägare. Under mötet presenteras det arbete som genomförts under den avslutade sprinten (Schwaber och Beedle, 2002, p.54-56). Illustration 7 visar en förenklad bild av arbetsflödet. 20

27 Beskrivning av figurerna (a) Identifiera behovet av projektets genomförande... (b) Planeringsmöte Produktägaren anser att projektet är klart. (d) Utvärderingsmöte Projektets resurser tar slut. (c) Iterationen pågår och i sig delas den upp i mindre iterationer. Varje morgon hålls det dagliga scrummötet osv. Det är upp till scrumlaget att tillämpa de metoder som leder till att de klarar av de uppgifter som laget åtagit sig Illustration 7: Ett exempel på arbetsflöde i ett scrumprojekt. I exemplet inkluderas användare i scrumlaget. Detta är möjligt, men förmodligen väldigt ovanligt. Till ramverket scrum tillkommer även flera verktyg där tre av de vanligaste verktygen presenteras nedan: Product Backlog: En lista som innehåller information om vad som är kvar att utveckla. Listan är prioriterad och det syns tydligt vilka delar som är viktigast att utveckla. Listan byggs på allteftersom arbetet fortskrider. På så sätt omvandlas listan ständigt för att ge den bästa bilden av vad som ska utvecklas härnäst (Schwaber och Beedle, 2002, p.32-35). Sprint backlog: En lista över de uppgifter som ska utvecklas under pågående sprint. Varje uppgiftsbeskrivning är tillräckligt detaljerad för att med god säkerhet ta mellan 4 till 16 timmar av scrumlagets tid för att genomföra (Schwaber och Beedle, 2002, p.49-50). Burn down chart: Ett tvådimensionellt diagram som över tid både tydliggör 21

28 hur stor andel av den tilltänkta funktionaliteten för projektet som är implementerad samt hur stor andel som återstår att implementera. Ofta finns det både en release burn down chart som visar statusen för nästkommande utgivning samt en sprint burn down chart som visar statusen för pågående sprint. Det krävs en hel del kunnande om scrum för att implementera burn down charts på ett givande sätt. Därför är det vanligt att scrum till en början tillämpas utan detta verktyg (Schwaber och Sutherland, 2010). Scrum innehåller en hel del andra metoder och verktyg som i sig skulle kunna vara givande för en användarcentrerad projektledningsmodell för outsourcing. Det här kapitlet nämner de viktigaste delarna av scrum samt de delar som jag upplevt kunna ha större betydelse för Dream Builders nya projektledningsmodell. Scrum kan ses ta hänsyn till de sju principerna beskrivna av Poppendieck även om scrum som ramverk inte direkt utgår från dessa principer. Framförallt ger scrum som projektmodell respekt till de personer som arbetar i projektet. De fasta 30 dagars iterationerna ger kontinuerlig snabb leverans. Produktägarens roll underlättar urvalet av funktionalitet vilket medför ett fokus på att först utveckla de mer värdefulla delarna i projektet. Processen är kunskapsskapande där lagmedlemmarna tillsammans med scrummästaren löser problem allteftersom problemen identifieras. Dessutom tas designbeslut enbart för den kommande iterationen vilket möjliggör att kritiska beslut på ett sunt sätt kan skjutas på framtiden. I scrum har även scrummästaren ansvar att hela tiden försöka optimera helheten. Scrum och ISO ISO kan implementeras i scrum utan att bryta mot ramverket. Det är i scrum upp till scrumlaget att avgöra graden av användarcentrering. Det gäller också att produktägaren är införstådd i vad användarcentrering är, eftersom det åligger produktägaren att prioritera arbetsuppgifterna. Precis som för lean är det en fördel att scrum är en iterativ process vilket bidrar till kunskapsskapandet under arbetets gång. 22

29 2.3 Grafiska designmönster Från ovanstående nämnda modeller samt ramverk gäller det bland annat att skapa en smidig process som snabbt går att anpassa efter nya förutsättningar. Att processen är kunskapsskapande är en betydande insikt och att användarcentrering är en betydande komponent för kunskapsskapandet. Det gäller också att skapa rätt från början i så stor utsträckning som möjligt. På samma sätt som autonomationen hindrar trasiga delar från att levereras, måste det finnas liknande skyddsnät inom programvarukonstruktion som bidrar till att programvaran inte är defekt vid leverans. Ett verktyg som bidrar till att forma interaktionen rätt från början är grafiska designmönster. Konceptet med designmönster föddes på 70- talet när Alexander et al. (1977) presenterade 253 designmönster inom byggnadsarkitektur där varje mönster beskriver först ett återkommande problem och sedan den så kallade kärnan till lösningen (Alexander et al., 1977, p.x). Konceptet togs sedan in i programmeringsvärlden när Gamman et al. (1995) presenterade designmönster för objektorienterad programmering. I dagsläget finns det även gott om designmönster inom grafisk och interaktiv utformning av programvara. Ett exempel är Yahoo som bland annat har en samling med i dagsläget 59 mönster som de menar är best practices. Varje mönster innehåller: titel, problem, kontext samt lösning. Vidare presenteras hur mönstret förhåller sig till andra mönster (Yahoo! Design Pattern Library, webbsida). Genom att förhålla sig till noggrant framtagna designmönster bör sannolikheten öka för att användaren både ska förstå och känna sig hemma vid interaktion med ett gränssnitt redan från första början. Som en negativ effekt av grafiska designmönster kan det tänkas att designlösningarna blir mer konvergerade från start och att nytänkande förhindras. 23

30 3 Genomförande och undersökning I början av examensarbetet genomfördes en serie intervjuer med Dream Builders i syfte att analysera den ursprungliga projektledningsmodellen. För att få en djupare förståelse av den ursprungliga projektledningsmodellen tog jag över projektledarrollen i ett av Dream Builders projekt. Under tiden formades den nya projektledningsmodellen. Ingen från Dream Builders var med i diskussionen om hur den nya modellen skulle formas då deras uppfattning av den ursprungliga modellen inte skulle påverkas. I stället diskuterade jag olika utformningar med bekanta och fick på så sätt återkoppling till minna idéer. När den nya projektledningsmodellen var framtagen genomfördes ett programvaruprojekt där en webbaserad generator för packlistor utvecklades. Strax innan programvaruprojektets genomförande hölls två djupare intervjuer med två personer från Dream Builders. De två djupintervjuerna skulle sedan jämföras med de djupintervjuer som hölls efter genomförandet av programvaruprojekt och med syfte att jämföra den nya projektledningsmodellen med den ursprungliga. Syftet var att synliggöra vilka delar av den nya projektledningsmodellen som fungerade bättre respektive sämre jämfört med den ursprungliga modellen. Programvaruprojektet genomfördes och de föreskrivna metoderna i den nya projektledningsmodellen tillämpades i så stor utsträckning som möjligt. När programvaruprojektet pågått i fyra veckor hölls ytterligare en djupintervju med den personen på Dream Builders som djupare satt sig in i den nya projektledningsmodellen. De tre genomförda djupintervjuerna användes sedan för att dra slutsatser om vilka styrkor och svagheter som den nya projektledningsmodellen har jämför med den ursprungliga. Efter sammanställningen av intervjuerna gjordes ytterligare en studie där de undersökta agila metoderna, den ursprungliga och framtagna projektledningsmodellen sattes i relation till ISO Syftet var att vidare undersöka i vilken grad användarcentrering har tillämpats. Slutligen genomfördes ett uppföljningsmöte där jag diskuterade tillsammans med Dream Builders hur de valt att tillämpa projektledningsmodellen och vad som hänt med det programvaruprojekt som startades under examensarbetet. Bilden nedan visar det nyss nämnda arbetsflödet. 24

31 Illustration 8: Övergripande arbetsflöde för examensarbetet. 3.1 Ursprunglig projektledningsmodell Dream Builders ursprungliga projektledningsmodell analyserades under en serie möten i början av examensarbetet. Samtidigt hjälpe jag till som konsult att lägga ut arbete åt utvecklarna med hjälp av de metoder och rutiner som då fanns hos Dream Builders. Nedan presenteras en generell beskrivning av arbetsflödet i den ursprungliga projektledningsmodellen. Modellen ska ses som en sammanfattning av hur arbetsflödet hos Dream Builders kan uppfattas. Denna generella modell sätts även i relation till ISO

32 Beskrivning av figurerna (a) Beställaren förklarar sina behov och en kravspecifikation tas fram. (b) Kravspecifikationen översätts så att utvecklarna förstår vad som ska göras. Programvaran uppfyller det som projektledning och beställare kommit överens om (d) Efterhand när olika bitar i systemet blir klara presenteras de för projektledningen. Här får även beställaren ibland reflektera över resultatet. Funktionalitet som måste förbättras specificeras igen. (c) Utvecklarna börjar arbeta på att omvandla specifikationen till ett program. Samtidigt tidsuppskattar det den totala tid som projektet ska ta att genomföra. Illustration 9: Generell beskrivning av Dream Builders ursprungliga projektledningsmodell (a) Ett projekt startar med att beställaren förklarar sina önskemål för projektledningen. Vid det första mötet mellan beställare och projektledning kommer programmets funktionalitet mer eller mindre att låsas. Dream Builders bidrar här med sin kunskap och kommer med förslag över hur programvaran ska utformas. (b) Därefter skrivs funktionaliteten om så att utvecklarna förstår vad som ska göras. (c) Utvecklarna tidsuppskattar projektet. Tidsuppskattningen ligger sedan till grund för det pris som Dream Builders tar av beställaren. När kunden godkänner offerten börjar utvecklarna sedan bygga den specificerade programvaran. (d) Allt eftersom bitar av programvaran blir färdiga presenteras den för projektledningen. Projektledningen granskar programvaran och vid behov kontrollerar med beställaren att utformningen är korrekt. Om utformningen inte är korrekt ändras specifikationen i det fall beställaren missat att inkludera någon funktion eller då missförstånd uppstått mellan beställare och projektledning. Nya uppgifter skapas sedan som skickas till utvecklarna. Vid de fall där utvecklarna missförstått instruktionen skickas en förtydligad instruktion tillbaka till utvecklarna. 26

33 Arbetsflödet fortsätter tills både beställare och projektledning är nöjda. Viktigt att notera är att längden på en cykel kan variera mellan några timmar till två eller tre veckor. Den ursprungliga modellen och ISO Vanliga användare involveras inte rutinmässigt i processen. Därför kan den inte ses som användarcentrerad och följer därmed inte ISO Däremot tillåter processen ändringar i offerten under arbetets gång då arbetet bedrivs i cykler utan fast längd. På så sätt finns en viss anpassningsbarhet i modellen. 27

34 3.2 Den nya projektledningsmodellen Den nya modellen formades framförallt med inspiration från de agila metoder och ramverk som studerats samt teori kring användarcentrering. Lärdomar från den tidigare kontakt som jag haft med utvecklarna spelar också roll i utvärderingen. Nedan presenteras den modell som tillämpades på det mindre projekt som genomfördes under examensarbetet. Även denna modell sätts i relation till ISO Den nya projektledningsmodellen kommer att beskrivas utifrån följande fyra punkter: Den teori som speciellt beaktats vid framtagandet av modellen. De fyra rollerna som definierar ansvarsfördelningen i modellen. Kommunikationsmedel som kan användas i modellen. Modellens iterativa arbetsflöde. Teoritillämpning vid utformning av ny projektledningsmodell Användare ska involveras i så hög grad som möjligt i de arbetsuppgifter som projektledningen genomför under projektets gång. Modellen ska bygga på JIT. En kortsiktig och tydlig planering ska användas. Kunskapen om vad som ska göras skapas under projektets gång. Uppgifterna ska definieras på kanbankort och läggas i en backlog. Detta är tänkt att följa principerna om att skjuta upp åtaganden. Från Poppendiecks rekommendation att inte planera för långt in i framtiden beslutades att arbetet ska bedrivas i korta cykler där varje cykel planeras i detalj och där varje iteration producerar ny färdig funktionalitet. En lo-fi prototyp tillsammans med ett antal kanbankort beskriver det arbete som ska genomföras under en cykel. Detta kan liknas vid det omvända flödet som tillämpas i Toyotas produktionsmodell, där programmets interaktiva utformning först formas och sedan fungerar som beställningsinformation till utvecklarna. I varje cykel involveras riktiga användare vilket bidrar med värdefull information till nästkommande iteration. Tanken är här att följa principerna om att leverera snabbt samt skapa kunskap. Att hålla cyklerna samt den detaljerade planeringen kort ökar även anpassningsbarheten vilket kan liknas med Ohnos tankar om balansering. Vidare ska varje iteration innehålla en reflektion över hur arbetet bedrivits för att på så sätt följa principen om att optimera helheten. Grafiska designmönster ska tillämpas i syfte att undvika upprepning av bristfällig grafisk utformning. Detta kan liknas vid de verktyg som tillämpas vid Toyotas fabriker för att få autonomationen att fungera. När ett systematiskt grafiskt fel upptäcks ska processen stanna och ett mönster ska skrivas för att undvika att felet uppkommer igen. Inbyggda automatiska tester i källkoden är ett annat vanligt verktyg som hör till autonomationen. Dessa tester kommer inte att tillämpas då utvecklarna saknar den 28

35 kompetens som behövs för att på ett givande sätt skriva testkod De fyra rollerna Från den tidigare projektledningsmodellen behålls de tre rollerna: Utvecklare, Beställare och Projektledning. Till det läggs rollen Användare. Följande fyra roller definierades i projektledningsmodellen: Beställaren är den eller de personer som beställt projektet. Beställaren har i sig inget direkt ansvar för utvecklingsarbetet i projektet men det är i beställarens intresse att projektet utförs på ett effektivt sätt. Därför har beställaren ett eget intresse att bistå projektledningen med egna åsikter samt resurser som för beställaren är enkla att tillhandahålla. Exempel på resurser som beställaren kan bistå med är att ge tillgång till riktiga användare. Projektledningen består av de personer som sköter kontakten mellan beställare och utvecklare. Projektledningen har det övergripande ansvaret för projektet och därav ansvaret för att maximera det positiva utfall som ett genomfört projekt ska föra med sig. Det medför att projektledningen ansvarar för att kvalitetssäkra allt som produceras i projektet vilket inkluderar både källkod och interaktiv utformning. Projektledningen ansvarar även för att lägga ut behovsprövade kanbankort på backlogen samt uppdatera de prototyper som presenteras för utvecklarna. Det medför att projektledningen måste vara insatt i användarcentrerade utvärderingsmetoder. Utvecklare ansvarar för att utveckla en fungerande kod i den mening att koden är fri från säkerhetshål samt utför den överenskomna funktionaliteten. Koden ska även vara lätt underhållen och därför väl strukturerad och med lagom mängd dokumentation. Utvecklarna ansvarar även för att välja i vilken ordning funktioner implementeras, men önskemål från projektledning ska vägleda de val av funktionalitet som ska utvecklas under kommande iteration. Användare är alla som på något sätt kan tänkas interagera med den aktuella programvaran. I vissa fall är det klart vem eller vilka som är användare, men rollen kan även vara otydlig och med fördel delas in i flera underroller. Exempelvis vid utveckling av ett webbhandelssystem skulle en första uppdelning kunna vara: administratör, affärsägare, samt kund till affären Kommunikationsmedel För att projektledningen ska klara av kommunikationen inom projektet används ett antal metoder och verktyg. Kommunikationen är inte på något sätt kristalliserad för projektledningsmodellen men för att ge tydligare riktlinjer finns ändå värde i att presentera de metoder som var tänkta att tillämpas på det projekt som skulle utvärderas. Mellan beställare och projektledning används vanliga möten samt mejl och telefonsamtal. Här är det viktigt att modellen anpassar sig efter beställarens situation. 29

36 Det är att föredra att beställare och projektledning har daglig kontakt, men då beställaren kan ha andra åtaganden blir det kanske bara ett möte i veckan. Vidare ska prototypning tillämpas för att öka den gemensamma förståelsen av vad som ska utvecklas. Beställaren har även tillgång till den senaste versionen av den programvaran som ska utvecklas. På så sätt kan beställaren se vad som planeras att göra och vad som är genomfört. Projektledningens kontakt med användare måste också vara flexibel. Här går det inte att utesluta någon typ av kommunikation då det beror på vilka metoder projektledningen använder för att involvera användare. Det kommer däremot i de flesta fall att vara möten där projektledningen träffar användare för observationsutvärderingar. För kommunikation mellan projektledning och utvecklare används mejl och skype för vanlig kommunikation samt tillämpning av kanban, lo-fi prototyper och grafiska designmönster. Varje kanban innehåller en uppgift som ska genomföras. Uppgiften i sig är inte större än att det ska ta maximalt 16 timmar för en utvecklare att genomföra uppgiften. Prototypen förmedlar en bild av hur systemet bör se ut och de grafiska designmönstren syftar främst till att undvika upprepning av felaktig utformning av programvaran. Illustration 10 visar relationerna mellan roll och kommunikationsmedel. Illustration 10: Bild av projektledningsmodellens kommunikationsmedel och dess relation till de olika rollerna. 30

37 3.2.3 Arbetsflödet En iterativ process med iterationstid på en vecka tillämpas. Bilden nedan visar arbetsflödet i den föreslagna projektledningsmodellen. Beskrivning av figurerna (a) Skapar en första prototyp samt skapar kanbans motsvarande en iterations arbete (b) Utvecklarna väljer de uppgifter som de tror sig klara av att skapa under den kommande iterationen (c) Specifiserar uppgifter som ska utvecklas innom en snar framtid (c) Hjälper till att prioritera vad som är viktigt att utveckla Systemet uppfyller beställarens önskemål (c) Utvecklarna arbetar med sinna uppgifter (c) Projektledningne utvärderar med hjälp av användarambasadörer det som redan utvecklats samt utökar de prototyper som beskriver programvaran Illustration 11: Arbetsflöde i den nya projektledningsmodellen. De aktiviteter som är markerade med (c) ska genomföras parallell under en iteration Projektstart Innan ett projekt börjar har projektledning och beställare ett eller flera möten för att övergripande utreda vad som ska utvecklas och vilka målgrupper programvaran riktar sig till. En målgruppsanalys ska göras och användare ska sedan medverka för att utvärdera och behovspröva beställarens visioner samt testa den första prototypen av programvaran som tas fram. Tillsammans med prototypen produceras tillräckligt många kanbans för att utvecklarna ska kunna planera hela den första iterationen. En tydlig skillnad mot scrum är att utvecklarna både tidsuppskattar och ansvarar för att välja de uppgifter som de tar på sig. Detta blir möjligt då listan av vad som ska utvecklas hålls kort. På så sätt kan projektledningen också ha kontroll över vad som ska utvecklas samtidigt som utvecklarna respekteras i högre grad. 31

38 3.2.5 Arbetet under en iteration Varje roll i projektledningsmodellen har sina egna ansvarsområden och därmed egna arbetsuppgifter. Varje iteration kan därför ses bestå av följande tre parallella iterationer: (1) utvecklarnas iteration, (2) projektledning och användarnas iteration samt (3) beställarens iteration. Projektledningens främsta uppgift är givetvis att styra projektet så att utfallet blir så gynnsamt som möjligt. Under varje iteration ska projektledningen utvärdera det som gjorts samt utforma det som ska göras härnäst. Därutöver är det viktigt att projektledningen har en nära kontakt med både beställare och utvecklare. Utvärderingen av det som gjorts och utformningen av det som ska göra är de mest tidskrävande uppgifterna. Det är här som kunskaper inom människa- datorinteraktion är av högt värde och det är givetvis även viktigt att användarna är med i utvärderings och utformningsprocessen. Tanken är att processen är kunskapsskapande och användarinvolveringen blir här de viktigaste verktyget för att skapa kunskap om hur programvaran slutligen ska utformas. Det är upp till projektledningen att tillämpa lämpliga användarcentrerade utvärderingsmetoder för att tillgodose sig med rätt mängd kunskap för att utforma användbar programvara. Utformningsarbetet som görs tillsammans med användarna ligger sedan till grund för de prototyper och kanban som ska presenteras för utvecklarna. Bara de mest nödvändiga funktionerna definieras på kanbankorten. Samtliga kanbankort som är producerade bör tillsammans inte ta mer än två till tre veckor att omvandla till färdig programvara. Det ska tydligt framgå vilka kanbankort som inte är utvecklade, vilka kanbankort som är planerade att bli klara under pågående iteration och vilka kanbankort som är färdigutvecklade. När utvärderingen av det som har gjorts visar på att någon del i programvaran måste formas om flyttar projektledningen det tillhörande kanbankortet från listan av färdigutvecklade kanbankort till listan för ej utvecklade kanbankort. På kanbankortet förklaras vad som var felaktigt utformat. I de fall upprepade felaktiga utformningar identifieras ska ett designmönster skrivas som beskriver problemet och kärnan till lösningen. Dessa designmönster ligger sedan till grund för framtida utformning som görs av projektledning eller utvecklare. Slutligen ska projektledningen minst en gång i veckan reflektera över vad som går att ändra i processen för att göra den bättre. Denna reflektion kan exempelvis rutinmässigt göras samtidigt som projektledningen inspekterar vilka arbetsuppgifter utvecklarna tagit på sig för den kommande iterationen. 32

39 Utvecklarna avslutar sin iteration med att själva välja de kanbankort som de tror är möjliga att utveckla under kommande iteration. När uppgifterna är valda påbörjas den nya iterationen och utvecklarna omvandlar kanbankorten till programvara. Till sin hjälp har programmerarna de prototyper som presenterats för dem samt listan med grafiska designmönster. Utvecklarna kan också direkt kontakta projektledningen vid frågor. Beställaren granskar vad som utvecklas och kommer löpande med synpunkter. Utöver detta kan beställaren även hjälpa till med att få tag i användare Användarcentrering enligt ISO Den nya projektmodellen inspirerades till större del av Toyotas produktionssystem, lean programvarukonstruktion och scrum än av ISO 13407, även om den senare också studerades innan den nya projektledningsmodellen sattes ihop. Det kan konstateras att den nya modellen inte fullt ut följer ISO Det är framförallt när det gäller att definiera mätbara användarkrav samt organisationskrav som modellen bryter mot ISO Som modellen formades involverades användare vid både utvärdering samt utformning av programvara. Däremot finns inga rutiner för att sätta upp mätbara användbarhets och organisationskrav. Det finns inget som hindrar att man sätter ihop tvärdisciplinära lag. Projektledningen kan sättas samman av flera personer med olika kunnande. Samtidigt bidrar användarna med kunnande från olika områden. Det är däremot mycket svårare att få in tvärdisciplinär kompetens bland utvecklarna. Graden av användarcentrering kan diskuteras då utvecklarna inte över huvud taget har någon direkt kontakt med användarna. Det är här samtidigt svårt att ge utvecklarna denna kontakt på ett värdefullt sätt då de ofta befinner sig på en annan del av jordklotet. Detta är ett område som tål att experimenteras för att i framtiden öka graden av användarinvolvering bland utvecklarna på ett meningsfullt sätt. Tekniken finns till viss del redan i form av exempelvis videosamtal, men hur det ska tillämpas är inte utrett i denna rapport. Vidare finns det andra problem som måste beaktas, exempelvis kulturella skillnader mellan utvecklare, projektledning och användare. 33

40 3.3 Genomförande av programvaruprojekt För att kunna utvärdera den framtagna projektledningsmodellen genomfördes ett programvaruprojekt där projektledningsmodellen kunde implementeras. Följande avsnitt beskriver det programvaruprojekt som genomfördes under examensarbetet. Under litteraturstudien och framtagande av den nya projektledningsmodellen pågick ett arbete med att hitta en kund som var villig att starta ett mindre projekt där den nya modellen kunde tillämpas. Tyvärr hittades ingen utomstående kund och projektledningsmodellen kunde således inte testas fullt ut. I stället tillämpades projektledningsmodellen på ett internt projekt hos Dream Builders. Under fyra veckors tid utvecklades en applikation för att generera packlistor till resenärer. Applikationen skulle hjälpa folk som ska ut och resa med att ta fram en lista med saker att packa ner i resväskan. Projektets resurser var små och endast en av de indiska utvecklarna tillsattes. Resurskrävande utvärderingar så som fokusgrupp genomfördes inte. Två verkstäder och en serie tänka högt utvärderingar genomfördes. Under de fyra iterationerna togs en minimalistisk version av applikationen fram. Några dagar innan utvecklaren skulle välja den kommande iterationens arbetsuppgifter hölls en verkstad där det diskuterades vad applikationen skulle göra, samt vilka målgrupper som applikationen riktar sig till. En enkel skiss ritades upp på en whiteboard, se Illustration

41 Illustration 12: Den första skissen av hur gränssnittet för den nya programvaran skulle se ut. Verkstaden bestod av tre personer från Dream Builders kontor varav en kvinna och två män. Uppgiften gick ut på att ta reda på hur målgruppen ska delas in. Det framkom under mötet att de olika målgrupperna kan klassificeras som: turist, backpacker, affärsresenär och familj. Vidare ska man kunna generera listan utifrån om man är man eller kvinna, resans längd, vad man vill göra på resan, årstid, samt vilket land som man ska resa till. Efter den första verkstaden förbereddes ytterligare en verkstad där de olika delar som framkommit under arbetet ritades ut. Prototypen skrevs ut och klipptes isär så att applikationens olika delar separerades. Utifrån applikationens olika delar diskuterades vilka delar som var viktigast att ta fram samt var på sidan som de olika delarna bör placeras. Nedanstående bild är från den genomförda verkstaden. 35

42 Illustration 13: Den andra verkstaden. Verkstaden ledde fram till en prioritering av utvecklarens arbete. Dessutom ändrades utformningen av prototypen. I stället för att välja om packlistan ska genereras för en man eller en kvinna väljer man istället mellan kategorierna: man, kvinna, barn eller bebis. Det skulle då även gå att välja fler än ett alternativ. Vidare togs familj bort som alternativ och ersattes av alternativet annat. Resultatet syns i Illustration 14. Målgruppsanalysen blev mer specificerad där familj inkluderades i val av kön. Samtidigt utökades målgruppen med att även kunna inkludera de som varken känner sig som turister, backpackers eller affärsresenärer. 36

43 Illustration 14: Den första prototypen som presenterades för utvecklarna. Den uppdaterade prototypen utvärderades även med en heuristisk utvärdering. En WordPress blogg användes som projektstyrningsverktyg. WordPress är en av de största plattformarna på internet för att bygga bloggar. Ett antal mindre uppgifter i form av kanbankort lades ut på bloggen som bloggposter. Samtliga uppgift var kategoriserad som backlog. Några av uppgifterna var dessutom kategoriserade som prioriterade. Prototypen laddades upp som en egen sida på bloggen. Illustration 15 visar en skärmdump från den WordPress blogg som användes vid projektet. Vidare var en del av kanbankorten beskrivna som användarfall, andra kanbankort hade en mer teknisk beskrivning som exempelvis direkt relaterade till databastabeller. Kanbankortet som syns i Illustration 15 får ses som en blandning av användarfall och teknisk beskrivning. I de flesta fall innehöll inte kanbankortet någon bild. I stället hänvisade kortet till den prototyp som var upplagd på WordPress bloggen. 37

44 Illustration 15: Skärmdump från den WordPress blogg som användes som projektstyrningsverktyg. Bilden visar en av alla de kanbankort som skapades. Fredagen efter det att de första uppgifterna lagts ut valde utvecklaren vilka uppgifter som planerades att göra under den kommande iterationen. De valda uppgifterna kategoriserades också som pågående iteration. Under den kommande iterationen utvärderades prototypen två gånger med tänka högt metoden. Utvärderingen genomfördes på två relativt datorovana personer som ej är delaktiga i Dream Builders. Inga direkta brister upptäcktes, därmed beslutades att inga hjälptexter behövs för sidan tills vidare. I slutet av första iterationen hade utvecklaren hunnit med allt som denne tagit på sig med undantag för en uppgift. Programvarans utseende efter en iteration visas i Illustration

45 Illustration 16: Synligt resultat efter en veckas utveckling Under de kommande två iterationerna gick utvecklingen sakta framåt. Nedanstående prototyp togs under två steg fram och utvärderades även den med tänka högt metoden. Inga nya brister framkom. Utvecklaren tog även på sig uppgiften att parallellt programmera administrationsgränssnittet till packlistan. Illustration 17: Uppdaterad prototyp 39

46 Innan den sista iterationen hade utvecklaren implementerat funktionalitet för att lägga till föremål och göra föremålen sökbara beroende på vart man ska åka samt om föremålet hörde till kvinna, man, barn eller bebis. Bilden nedan presenterar programvarans utseende efter den tredje iterationen. Illustration 18: Synligt resultat efter tre iterationer. Fram tills den tredje iterationen hade utvecklaren till största del fokuserat på funktionalitet och inte på utseende. Mycket av den data som presenterades i gränssnittet efter den tredje iterationen är ren text utan funktion. Utseendet var inte i närheten av prototypens utseende. I den kommande iterationen prioriterades implementationen av det utseende som prototypen hade. Nedanstående bild visar resultatet efter den fjärde och sista iterationen. Illustration 19: Synligt resultat efter den fjärde iterationen. 40