Agil systemutveckling... och användbarhet?
På CHI 2008 behandlade två paneldebatter och en workshop ämnet agil systemutveckling och användbarhet/interaktionsdesign, och det märktes att ämnet engagerade - många lyssnade, och många pratade.
Erfarenheterna var tämligen likartade, oavsett land och typ av uppdrag, och kan sammanfattas med att det inte egentligen finns någon konflikt (även om det finns de som är mycket oroliga) - poängen är snarare att exempelvis Scrum är en systemutvecklingsmetod, inte en projektmetod. Det betyder att metoden ska underlätta och stödja systemutvecklingsprocessen - hur man kom fram till vad man ska utveckla, och hur det ska hänga ihop; det är en helt annan sak och får därför tas om hand på något annat sätt.
Det intressanta är dock att om man har gjort sitt förberedelsearbete på ett bra sätt så kan man sedan med framgång designa de enskilda dialogerna allt eftersom projektet fortskrider, vilket i sig möjliggör en kontinuerlig dialog mellan interaktionsdesignern och systemutvecklaren under projektets gång. Just det är något som ofta annars ställer till problem - interaktionsdesignern designar alltför ofta enbart utifrån användarens perspektiv, när utvecklingsprocessen egentligen är en samarbetsfråga där användare, nytta och den tekniska plattformen måste balanseras på ett för samtliga optimalt sätt.
Denna brist på kontinuerlig kommunikation leder ofta till att systemutvecklaren väljer att strunta i interaktionsdesignen, och det i sin tur leder till att interaktionsdesignerns arbete är bortkastat.
Och vad är då meningen med vårt arbete?
Etiketter: agil systemutveckling, användbarhet, chi2008, interaktionsdesign
7 Comments:
Intressant! Håller med om att det krävs ett ordentligt förarbete i form av att ta reda på användarnas behov, vilka mål man vill uppnå med produkten, en konceptuell design osv. Om det är gjort kan man med fördel arbeta enligt scrum för att ta fram den detaljerade interaktionsdesignen samt justera den konceptuella designen.
Jag är nyfiken på om det kom fram exempel på användbarhets-aktiviteter som passar just med scrum? Jag funderar t ex på om det finns något bra sätt att ta tillvara det faktum att det i slutet av varje scrum-sprint ska finnas färdiga tjänster/scenarios/delapplikatíoner att visa upp? Kan man på ett agilt sätt genomföra någon användbarhetsutvärdering här?
Tyvärr var det ingen som egentligen hade något att komma med på det området... Eller - i alla fall ingen av de jag lyssnade på.
Flera tänkte sig konkreta tester i slutet av varje sprint, men själv tänker jag så att ja, man kan väl testa just den dialogen eller det delflödet man gjort men man kan ju inte testa helheten förrän senare.
Min känsla är att det finns många vita luckor, och vi kan inte förvänta oss att nån annan ska fylla dem åt oss - fältet är vårt, om vi bara vill och orkar ta det...
jag håller inte alls med om att scrum skulle vara en systemutvecklignsmetod. Scrum går att använda till alla typer av projekt: allt från att bygga IT till att helgstäda hemma. det viktiga med de agila metoderna och ramverken är ju just iterativiteten och samarbetet mellan olika roller i ett projekt.
jag har arbetat i ett antal projekt där scrum varit projektmetoden och där vi med stor framgång implementerat användarcentrerade aktiviteter i projekten och där vi arbetat tillsammans, programmerare och användbarhetsfolk.
Intressant. Ingen av de interaktiosndesigners eller användbarhetskonsulter jag pratade med om detta under CHI 2008 hade några konkreta exempel på hur och när i sprintarna det passade att integrera användarorienterade aktiviteter.
Min erfarenhet är att Scrum verkligen underlättar dialog mellan kompetenserna - det är bra för oss som arbetar med användbarhet. Men ingenstans finns en beskrivning av hur man arbetar med helhetsbilden. Så när projektet leds med teknikfokus tappas helhetsperspektivet lätt bort... Och det är det som är min kritik, egentligen.
Det skulle vara intressant att höra hur du/ni har arbetat med agila metoder; få lite input i hur andra arbetar!
Tja, om man vill jobba med stora förstudier eller designspecar eller vad det nu kan tänkas vara är det ju bara att arbeta enligt scrum även i det arbetet, dvs i tät kontakt med produktägaren och med leveranser av fungerande "kod" (dvs personor, GUI-skisser eller avd det nu kan vara som skapar mervärde för kunden). dock bör man ju såklart försöka hålla det till ett minimum, koncept snarare än detaljer och sedan arbeta tillsammans med kodarna när det gäller den faktiska implementationen.
ett förslag kan vara att man kör "extreme programming" tillsammans med kodare när det gäller att ta fram gränssnitt. utgå från dina skisser (obs: skisser, inte färdiga specar) och bygg gränssnittet tillsammans med pogrammeraren. skippa således html-prototyperna och andra detaljerade prototyper.
testa och utveckla iterativt, använd användnignstester på samma sätt som andra tester inom sys.utveckling.
vidare kan det givetvis tänkas att man tar fram funktionalitet och krav för en målgrupp i taget, i produktägarens prioordning och att man genomför målgruppsanalys kontinuerligt i projektet för att på så sätt kunna genomföra fungerande dellevaranser allt eftersom tiden går. allt för att maximera agiliteten och ändringsbenägenheten.
de här sakerna har jag testat i olika projekt och de funkar bra.
Jag håller absolut med dig. Problemet är att många tenderar 'läsa boken', och då finns inte användarperspektivet (eller förarbete, för den delen) med. Projektägare/ledare med systemutvecklar- eller systemarkitektbakgrund eller liknande kan då lätt få för sig att metoden ger en rätt att inte bry sig om de sakerna... och så kallar man in en interaktionsdesigner som får i uppgift att designa enskilda lösryckta flöden.
Tyvärr verkar det vara vanligt förekommande, även i ett internationellt perspektiv.
Vad jag efterfrågar, och vad vi som användbarhetsmänniskor skulle kunna skapa, är en vidareutveckling av dokumentationen runt Scrum (eller agila metoder i stort) - ett forum där vi som representanter för våra roller (oberoende av bolag etc.) kunde utveckla våra mönster, våra best practices. Det skulle gynna alla inblandade!
visst är det vanligt förekommande. men det är ju inte ramverkets fel, utan snarare så att folk inte förmår att tänka själva. vill man diskutera detta kan jag för övrigt tipsa om den här:
http://tech.groups.yahoo.com/group/agile-usability/
Skicka en kommentar
<< Home