TDDD26 Individuell projektrapport

Transkript

1 TDDD26 Individuell projektrapport Kort beskrivning av projektet Vi hade som projekt att utveckla en digital media servicer som skulle hjälpa filmentusiasten att organisera sitt filmbibliotek. Programmet söker igenom datorn efter filmer, laddar ner information om dem och låter användaren kategorisera och spela upp filmer från sitt egna lokala filmbibliotek. Vår projektgrupp bestod av sju medlemmar och vi delade ut roller till alla så som det var tänkt. Fördelningen inom teamet blev fem utvecklare och tre interaktionsdesigners. Vi bestämde dock från början att alla skulle delta i programmerandet i på någon nivå. Jag hade rollen interaktionsdesigner för vårt projekt samt användare åt en annan grupp. Därför tänkte jag i den här rapporten mest fokusera på min roll som interaktionsdesigner. Vad jag har bidragit med Jag valde rollen som interaktionsdesigner/användbarhetsexpert för att kunna tillämpa några av de kunskaper som jag tagit med mig från andra kurser. TDDD36* TDDD13* TDDD22* TDDD35* Projekttermin: Säkra Mobila System Interaktionsprogrammering Interaktionsdesign Användbara system Erfarenheter av agil utveckling Under projektterminen lärde vi oss vad scrum innebar och jobbade en hel termin utifrån det. Terminen började med de tvådagars scrum master certifieringskurs där vi lärde oss väldigt mycket om vad agil utveckling och scrum betydde. Jag gick den utbildningen med Fredrik i projektgruppen vilket innebar att vi hade två personer i vårt team med scrumutbildning i bagaget. Jag tror att vi tillsammans bidrog väldigt mycket till att gruppen åtminstone följde principerna för agil utveckling. Jag tror att det var ett stort stöd för gruppen att några av oss redan hade använt scrumaktiviteter förut som till exempel: burndown charts, product backlogs, planning poker. Detta gjorde att många aktiviteter flöt på väldigt bra och vi behövde inte oroa oss för huruvida vi följde processen rätt. Erfarenheter av interaktionsdesign När det var dags att ta fram en design för produkten för första gången kunde jag använda det jag hade lärt mig från kursen i interaktionsdesign. Mitt bidrag var här att försöka utvidga designrymden och komma med många olika parallella lösningar på designproblem (divergera) för att sedan konvergera till en bra design. Jag märkte att de andra interaktionsdesigners gärna kom med ett förslag var och sedan skulle vi rösta på vilket som var det bästa. Man ska vara villig att kasta bort en design som inte funkar och inte vara för fäst vid sina egna idéer (Armitage, 2004). Idéerna ska vara många och disponibla, ok att kasta bort. Jag tror att jag hjälpte till bra på båda fronterna: bidrog med många alternativa idéer och hade lätt att diskutera idéer fram och tillbaka oavsett om det var min eller Antal ord:

2 någon annans idé. Jag har också bidragit med att lyssna på utvecklare om en designidé inte visade sig var bra i praktiken. Som designer var jag ofta kundkontakten och ledde designworkshops, användartester, mm. Detta var en bra roll för mig eftersom jag inte var kund åt andra samtidigt. Erfarenheter av användbarhetstester Jag använde min erfarenhet från kursen i användbara system för att bygga prototypen. Jag var den som hade med mig allt material och organiserade så att vi hade en pappersprototyp så fort som möjligt efter varje designförslag. Jag tillsammans med de andra som var designers gjorde totalt tre ordentligt utföra användbarhetstest. Kunskaper om UI-design Jag kunde även bidra med en hel del konkreta designförslag på UI-komponenter och deras användbarhet. Många av dessa idéer hade jag fått från kursen i interaktionsprogrammering. Till exempel innehöll vår första prototyp en startskärm med knappar till varje del inom programmet. Jag argumenterade för att skrota den och istället bygga in navigationen i själva programmet. En sådan startskärm skulle i stället vara bättre lämpad för ett program med många förstagångsanvändare, som använder systemet sällan (Tidwell 2006, s21). Vad jag har lärt mig Kundkontakten Inom agila utvecklingsmetoder är det av största vikt att kunden visar ett stort engagemang och intresse. Vi skulle under projektet haft mycket bättre kundkontakt annars kan missförstånd lätt uppstå, och det är inte så konstigt eftersom man har olika mål. Vi stötte på lite av en intressekonflikt med kunden eftersom vi som programmerade gärna tog den lätta vägen ut medan kunderna ville ha den häftigaste funktionaliteten. Detta ledde till några missförstånd mellan oss och kunderna och vi hade delvis olika synsätt på produkten. Detta visade sig när vi skulle göra det första acceptanstestet efter iteration 1. Vi ansåg oss ha klarat alla user stories medan kundens tolkning var att vi bara hade uppfyllt en femtedel av förväntningarna. Detta berodde till stor del på att vi inte hade skrivit acceptanstesten tillsammans. Kunden hade skrivit dem själv och tagit med sig dem till testmötet. Innan hade vi sagt att alla user stories var så självklara och entydiga att inga test behövde skrivas. Det visade sig vara raka motsatsen då vi och kunden hade olika åsikter på i stort sätt alla acceptanstest. Detta hade vi undvikit om vi hade skrivit acceptanstest i samband med att stories skrevs, direkt på kortets baksida. Detta var exakt vad vi gjorde under sprint 2 och det fungerade utmärkt då både vi och kunden var nöjda med hundra procent av alla stories vi hade tagit på oss. Vi skulle även haft mycket mer kundkontakt under sprintens gång än vad vi hade. Något vi inte var så bra på var den regelbundna dagliga kontakten med kunderna som är så viktig (Wells, 2009). Vi träffades ungefär en gång under varje iteration och vid sprint start och end. Det märktes att det inte var bästa metoden. Det uppkom missförstånd och jag tror inte de kände sig så delaktiga i mjukvaran som de egentligen borde vara. Detta gjorde att kunderna inte riktigt var involverade i systemet, och Antal ord:

3 det kändes fel när det var de som skulle bestämma vilka stories som borde implementeras. Vi hamnade lite i fallgropen när vi tänkte: Kunderna vet inte riktigt vad de vill. Som Wells skriver är detta en dålig ursäkt. Man ska ha en interaktiv dialog med kunden och ställa rätt frågor tills man hittat problemet tydligt och har en bra lösnning (Wells, 2009 avs Communicate ). Lite klagomål måste vi rikta mot kunden eftersom en agil utvecklingsprocess kräver ett stort kundengagemang och produktvision vilken de inte riktigt hade, där fick vi hoppa in lite extra. Vi fick fylla i luckorna när vi inte hade någon input från kunden, och detta kom tillbaka mot oss i iterationens slut. Såsom Wells skriver måste managern/scrum master ingripa om kunden inte leder teamet med en konsistent produktvision (Wells, 2009 avs Team Empowerment ). Tyvärr hade vi inte utsätt någon ledare för teamet, jag tror att detta hade hjälp oss. Designinput från kunden Jag tror det hade varit bra om vi hade utsett en kund med designansvar, så som Rittenbruch kallar design customer (Rittenbruch, M. et al., 2002). Detta hade inneburit att det skrivs user stories med designmål som sedan läggs ihop med de andra. För det blev så att vi hade tre designers som mest gjorde designjobb och inte lika mycket programmering. Då hade det varit bra med lite mer kund input om designen av systemet istället för att bara fokusera på funktionalitet. Som det var nu träffade vi aldrig kunden angående design förutom på första designmötet men vi bjöd aldrig in kunden till att ta designbeslut överhuvudtaget. Det var skönt för oss att få jobba ifred och baserad oss på användbarhetstester för att ta olika beslut, men det skulle vara bättre för kundens nöjdhet att de är insatta i designen också. Integrera design med agila processer Något vi lärde oss allteftersom projektet fortskred var att de agila principerna passade bra in på designen på många sätt. Vi lärde oss vara mindre försvarande och territoriala kring designen och designförslagen. Precis som med collective code ownership för programmeringen ska man inte vara rädd för att ens design blir till något annat eller tas bort helt (Armitage, 2004). Man ska inte se det som att man själv är sin idé eller äger den. Man ska se det som framgång för teamet och projektet som helhet. Vi kunde börja med en enkel design, och med hjälp av feedback under sprinten samt mer kunskap om tekniska detaljer och kundens åsikter utveckla designen till att bli mer komplex och bättre anpassad. Jag tror vi gjorde misstaget att försöka planera designen för långt in i framtiden. Till exempel innehöll interfacet först en profil skärm som var helt inkonsistent med resten av programmet eftersom konceptet med användarprofil aldrig blev en story som implementerades. Vissa saker designades efter features som vi trodde skulle komma men aldrig gjorde det. Därför borde vi ha tänkt mer på att begränsa designen och hålla den enkel (Armitage, 2004). Vi var även lite rädda för att göra för stora ändringar efter en iteration när det kom nya krav. Fjärde XP grundregeln courage hade hjälp oss här genom att lita på processen och inte oroa sig för nya krav (Rittenbruch, 2002). Det blev lättare att experimentera med design eftersom features växer fram lite åt gången så kunde designen också göra det. En nackdel var att man var tvungen att börja programmera innan den första GUI designen var klar. Det kan ha varit ett misstag att vi inte började med kodintegration från första Antal ord:

4 början. Vi hade inget programskal de första 4 dagarna men det uppfattades inte som något större problem. Jag håller med Armitage om att det ett bra sätt för nybörjardesigners att få den graden av feedback som man får under den agila utvecklingsmetoder. Det fungerar bra när man inte vet så mycket om varken design, kraven för projektet eller de tekniska förutsättningarna. Vi kunde utnyttja många av fördelarna av att jobba som designer åt ett agilt team men även några av nackdelarna. Vi hade dilemma efter sprint 1 om vi skulle göra en total omdesign av interfacet, eller välja att ändra designen lite utan att behöva ändra kod lika mycket. Det märktes att man hindrades från att göra en hel omdesign utan bra anledning. Här skulle vi ha kanske ha designat enklare lösningar från början som var lättare att ändra (Armitage, 2004). User stories med beroenden Jag tror att vi hade för många beroenden i våra user stories som inte kunden ska behöva sätta sig in i när de gör sina val. Ett exempel var storyn: Användaren ska kunna markera filmer som sedda och detta ska programmet komma ihåg och kunna visa i användarens profil. Denna story förutsätter att det finns någonting som heter filmprofil redan i programmet. Stories vara kompletta och estimerade som att de vore det enda man skulle bygga (Wells, D 2009). Det ska vara som en shoppinglista för människor utan teknisk bakgrund. Nu blev det så att vi lyckades hålla oss borta från tekniska detaljer i stories men vi borde ha minskat antalet beroenden något. Nu kunde kunden välja en story och sedan behövde vi argumentera för att en annan story borde göras först. Projekt heartbeat Vi hade innan andra iterationen inga standup-meetings alls. Vi tänkte inte så mycket på att det skulle behövas men när vi väl började med dem insåg vi snabbt vad vi hade missat. Det var svårt för programmerare och designers att få en klar bild av hur projektet fortskred och vilka tasks som var påbörjade. Det hade underlättat kommunikationen avsevärt om vi alltid hade suttit i samma rum när vi designade och programmerade samt hade standup meetings varje dag vi sågs. Enligt Wells ska teamet sitta tillsammans i grupp för att få en konsistent heartbeat i projektet och undvika fel i kommunikationen (Wells, 2009). Vi hade inte utsett någon scrum master eller manager till vårt projekt och så här i efterhand tror jag att vi hade tjänat på att ha någon som ägde processen och såg till att vi följde de agila metoderna som vi hade tänkt från början. Nyttan av användartester Vi gjorde vårt första användbartest ganska sent i iteration 1, och jag tycker vi borde ha gjort det testet ännu tidigare med tanke på hur mycket vi fick ut av testerna. Vårt arbete gick till så att vi gjorde pappersprototyper, utförde tester på många olika typer av användare som får testa systemet för första gången. Många resultat bekräftade våra tankar, och några nya nyttiga tips fick vi ut. Sedan kunde vi presentera för resten av utvecklarna och de fick en enhetlig design att gå efter. Jag tror vi underskattade värdet av att få någon att se på systemet med nya ögon. Lösningar som vi tyckte verkade bra visade sig snabbt inte fungera och vi fick direkt förslag från användare, till exempel var de förväntar sig att hitta ögonfilter knappen i vårt filmbibliotek. Pappersprototyperna bestod av många lösa delar som vi klippt ut och färglagd. Jag tror att de mera statiska funktionerna i prototypen som Antal ord:

5 inte var på lösa papper försvann lite ur användarens fokus, de såg inte klickbara ut. Vi kunde ha löst detta genom att till exempel färglägga klickbara knappar eller lägga alla i liknande lösa delar. Avslutning Jag tyckte att det märktes tydligt att embrace change principen från agil utveckling fungerade väldigt bra för oss. Det var eftersom vi hade ett team som fungerade bra ihop och vi kunde lägga ansvaret på alla i teamet (Wells 2009). Vi hade väldigt kul och vi byggde en bra mjukvara som vi alla var väldigt nöjda med i slutändan. Jag har sällan arbetat i ett lika bra fungerande team och mycket är nog tack vara metoderna vi lärt oss använda. Antal ord:

6 Referenser Armitage, J. (2004) Are agile methods good for design? interactions 11, 1 (Jan. 2004), Rittenbruch, M. et al. (2002) Extreme Participation - Moving Extreme Programming Towards Participatory Design. In: Proceedings of the Seventh Biennial Participatory Design Conference, June Tidwell, J. (2006) "Designing Interfaces", O'Reilly Wells, D. (2009) Extreme Programming: A gentle introduction. < Antal ord: