Integrera UCD i Scrum

För att förstå tydligt vad problematiken ligger i när man skall integrera UCD i Scrum är det viktigt att inse dessa olika processers bakgrund. Scrum har sitt ursprung i ett datavetenskapligt tänkande om hur man effektivt skall göra en produkt som rent funktionellt är stabil och utan buggar. Det primära målet kan anses vara att skapa mjukvara med hög funktioanalitet i en dynamisk miljö [1] UCD har ett annat fokus som Macinley et al. formulerar på följande vis:

Användarcentrerad design är en process med fokus på använd-barhet genom hela utvecklingsprocessen och vidare genom hela sy-stemets livscykel [15].

Följaktligen har de olika processerna olika fokus under utvecklingen, att skapa en bra och stabil produkt i en dynamisk miljö eller i UCDs fall ha ett fokus på användbarhet genom hela utvecklingen. Dessa olika fokus är i sig inte

motstridiga i någon mening men om man tittar djupare på hur man skall arbeta med de olika processerna ser man en stor skillnad.

Scrum förespråkar att varje iteration “sprint“ skall producera fungerande kod som är en del av slutprojektet. Om man är osäker på hur hela produkten skall se ut börjar man med de delar som man är säker på och iterera fram resul-tatet. Detta står delvis i konflikt med hur UCD sätt att arbeta. Enligt UCD är det viktigt att man förstår helheten innan implementationen av slutprodukten startar. Detta innebär att implementation av den faktiska produkten ej startar i den första iterationen. Från början är det analys av användaren sen fortsätter processen enligt figur 3.7. Implementationen av produkten skall alltså göras först när man förstått helheten. Detta för att det är mycket mindre kostsamt att ändra en skiss än att programmera om ett helt system.

För att kunna lösa dessa problem kan man tänka sig att en gedigen analys av målgruppen görs från början innan imlementationen tar vid. Efter det får man fokusera på att ta fram koncept tills man slagit fast hur produkten skall fungera och vad denna skall innehålla i grova drag. När man gjort detta kan man med fördel börja implementera de delar som är klara i väntan på att resten av designen skall bli fördig.

Under projektet med ICA har vi erfarit att det är mycket viktigt att arbeta mot korta mål och deadline. Under vissa skeden har det varit tendenser åt att man gör om designen och koncept många gånger utan att ta sig framåt i projektet, det har då varit till stor hjälp att ha tydliga mål och deadlines. Om man inte har dessa deadlines är risken stor att man inte når önskat resultat och slutprodukten blir försenad. Det är därför viktig att sätta upp några tydliga och mätbara mål innan projektstart som man kan förhålla sig till när man är mitt uppe i arbetet. Risken med att utveckla del för del och inte se hur lång tid hela projektet kommer att ta är att man underskattar andra delar och jobbar hårt med problemen som finns för dagen.

För att komma åt problemet med att integrera en fungerade designprocess i Scrum är det viktigt att noga överväga designanalysen av alla prototyper i Scrum, om dessa påverkar den implementation som pågår och hur man skall förhålla sig till detta.

I Scrum ligger tonvikten på att producera mjukvara som är stabil, och sam-tidigt kunna ta in nya önskemål från beställare under implementationsfasen. När man säger att scrum är anpassat för att utveckla stabil mjukvara i en dy-namisk miljö tänker man främst på funktionalitet. När beställarens önskemål analyseras är det stor fokusering på huruvida dessa önskemål är tekniskt ge-nomförbara eller inte. Det som ofta åsidosätts är hur detta önskemål påverkar helheten av produkten. Risken med en sådan utveckling är att helhetsintrycket av applikationen inte blir det man eftersträvar.

Detta stöttes på under projektet med ICA under flertalet gånger. Vad som är viktigt när man stöter på dessa problem var att inte säga “ja“ till ändringar i funktionen bara med argumentet att rent tekniskt skulle detta vara möjligt. På ett designplan måste man även väga in helheten och ställa sig frågan, om detta implementeras hur påverkar det resten av applikationen?

En annan intressant aspekt av vad som skulle kunna göras redan på ett designstadie i processen är att designa applikationen på ett skalbart sätt. Med detta menas att man kan gör en typ av design som tillåter ett växande inom vis-sa ramar. Mer konkret kan detta fungera genom att tidigt designa grundelement som genomsyrar hela applikationen, ett exempel på detta är receptkategorier-na i receptdelen av applikationen “En Riktig Jul“. Sättet som valdes var att använda en typ av grid med bilder med förklarade text under bilden, se figur 6.3. När denna design fastslogs bestämdes även att alla delar i applikationen med liknade val skulle se ut på liknade sätt. Detta kan man se bland annat i sökfunktionen, filmdelen och julkorten. Detta gjordes för att användaren enkelt skulle känna igen interaktionen och för att skapa en bra helhet.

Att ständigt ha en nära kontakt med användare är centralt i både UCD och Scrum för att säkra en bra kvalité på produkten. Alla projekt är unika och det kan vara olämpligt att slaviskt följa en process som är fördefinierad. Det viktiga med ett visst projekt är att man skapar en bra produkt, inte att följa en process. Därför skall dessa processer och en integration mellan dem närmast ses som riktlinjer för vad man ska tänka på när man utvecklar mjukvara.

Metodbeskrivning

För att uppnå ett bra resultat och en bra arbetsmiljö är det viktigt att ha ett tätt samarbete med alla inblandade, detta för att gemensamt komma överens inom vilka ramar arbetet ska utföras.

Ett delsyfte med projektet har varit att undersöka vilka metoder/arbetssätt som är lämpliga när man utvecklar produkter för mobilaenheter. Denna inrikt-ning togs för att underlätta och bättre förstå liknade projekt i framtiden.

Arbetet med att plocka fram och utvärdera olika koncept har hela tiden varit en stor del av arbetet, detta för att undvika extraarbete och säkerställa en hög kvalité på produkten. Till en början var dessa koncept vitt skilda åt men allt eftersom utvecklades koncepten tills en färdig prototyp uppkom.

Detta kapitel behandlar vilken utvecklingsprocess som använts under pro-jektet, vilka förberedelser som gjorts samt vilka verktyg som användes under projektet.

4.1 Utvecklingsprocessen

Under projektet används ett iterativt arbetssätt (se figur 4.1), mer specifikt User Centered Design (UCD) integrerat i ett Agile-liknade arbetssätt. Detta gjordes för att minska riskerna att beställarens krav och mål inte skulle upp-fyllas (se sektion 3.2).

I processen lades även ett tydligt fokus på användartester i syfte att sä-kerställa en hög kvalitet med ett tydligt fokus på användbarhet. Lämpliga an-vändartester kommer även att utredas närmare i sektion 3.1.

Figur 4.1: Bilden illustrerar en itterativ utvecklingsprocess, just denna bild är inspirerad av en sprint som används i Scrum, läs närmare i sektion 3.2.

Arbetet genomfördes på ett sprint-liknande sätt som figur 4.1 illustrerar. Varje sprint inleddes med en analys av uppgiften genom fakta och observationer av användare. Utifrån denna kunskap inleddes designfasen i vilken koncept förslag togs fram och utvärderades. De bästa koncepten togs sedan vidare till implementationfasen där implementation kunde vara allt från digitalisering av skisser till fungerande program. Dessa implementationer testades på användare på olika sätt, som behandlas i sektion 3.1.