Är agila utvecklingsmetoder av ondo för användbarhetsperspektivet?
Alla har bråttom, och om man dessutom betalar så vill man att det ska kosta så lite pengar som möjligt. Känns det igen? Jag tror det gäller oavsett om man insett att man behöver en ny diskmaskin, ska bygga om köket, eller bestämmer sig för att bygga en ny webbplats eller applikation.
Funkar det?
Tja, det beror väl på vad man accepterar. Har diskmaskinen kraschat och det är bråttom med en ny, då får man ta vad som finns.
Ska man bygga om köket kanske man är lite mera noga, och kan tänka sig att skjuta på tidplanen lite för att få det som man vill ha det, till rätt pris.
Webbplatser och applikationer... av någon anledning tror många att de är som diskmaskinen - bara att köpa och köra - när de i själva verket är som köket; man måste fundera lite på hur man vill jobba i det, vad som är nyttan, med vilka lösningar.
För det syftet fungerar agila metoder bra. Du har en idé om vad du vill åstadkomma, men du behöver flera kompetenser än din egen för att kunna kunna hitta den rätta lösningen.
För att det ska fungera bra måste du ha en klar bild av målet, nyttan, och de praktiska förutsättningarna, men det borde vara självklart.
Ett problem här är förstås att många tror att man agil utveckling betyder att man kan börja utveckla utan att ha en aning om vart man ska, och till råga på allt tror man att det ska bli bättre än om man jobbar på något annat sätt. Ursäkta, men var tappade du hjärnan nånstans? Börjar man bygga köket genom att säga till en snickare "jag behöver ett nytt kök, sätt igång"?
Nähä. Tänkte väl inte det.
;-)
För precis som med köket måste systemen specas, åtminstone vad gäller omfattning, syfte, mål, nytta, ekonomi, och allt det andra. Sedan måste man våga låta detaljbesluten vänta till senare. Ett exempel är att i definitionen av projektet kan det vara lämpligt att ta reda exakt på vilka användarna är, mappa deras vardag och behov, liksom att noggrant dokumentera system/produktägarens mål och syften. Man behöver förstå omfattningen, och kanske testa fram ett generellt navigationsramverk. Men den praktiska gränssnittsdesignen, den tas fram iterativt, sprint för sprint, gärna med kontinuerlig feedback från användare och ägare.
Det är inte klassisk användarcentrerad design. Men det är nytto- och användarcentrerat så det skriker om det, om vi vill det, om vi finns där och ser till att det är interaktionsdesigners och inte utvecklare som gör gränssnitten.
Därför blir jag lite irriterad när jag läser Steve Batys kolumn Bite Sized UX research på UX Matters. I inledningen står det -
WTF?!?!?! Extrem tidbrist, bristande planering, bristande förståelse för vår kompetens... kan likställas med att man använder en agil utvecklingsmetod?!?!It’s not uncommon for projects to lack the time, money, or resources to conduct ideal user research activities. There are many reasons why this occurs:
- Sometimes we’re brought onto a project late.
- Perhaps we’re new to an organization that doesn’t really get UX.
- Maybe a company is rushing to bring a product to market for some reason—and there are plenty of good and bad reasons this might be so—and there simply isn’t time to “go big”.
- Perhaps your client or organization is following an Agile development methodology.
“As UX professionals, we can always add value, at any stage in a project.”At such times, it can be tempting to just throw up our hands in dismay and do nothing or lament the fact that everything isn’t perfect.
Jag kanske ska säga också att det är enda gången konceptet agila metoder överhuvudtaget nämns i hans text, så det känns som om han har slängt in det, lite slentrianmässigt.
Jag vet att han inte är ensam om att känna skepsis inför användandet av agila metoder. Men om man jämför med klassisk RUP eller 'vattenfall' så är det tveklöst så att rätt genomfört ökar chansen att den slutliga tjänsten eller applikationen tillför nytta, på ett för användarna tillräckligt bra sätt om man använder en agil metod.
Även om det innebär att vi måste förändra våra arbetssätt. Men det är ett mycket litet offer i relation till helheten... och det borde inte vara något offer alls, eftersom vad vi strävar efter är att göra lättanvända och ändamålsenliga lösningar.
Eller?
Etiketter: agil systemutveckling, användbarhet
posted by Pella Bergquist @ 14:51
5 comments
5 Comments:
"Problemet" som jag ser, vilket långt ifrån alla håller med om, är att så fort det kommer ett nytt utvecklarparadigm så anpassar vi oss, likt kameleonten. Vad innebär då användarperspektivet eller användarcentreringen? Lite raljerande blir det då som att vad som helst går att benämna användarcentrering. Inom Usability Engineering var det mätning. I Unified Process är det användningsfall. Vad är det inom Agil utveckling? Iterationer? Interaktionsdesignen? Om vi tror på "klassisk" användacentrering ska vi inte prata om användarcentrering i ex. Scrum-projekt. I dessa finns utrymme för interaktionsdesign, vilket oftast är mycket uppskattat av teamet, men knappast för så mycket mer. Däremot ges det mer och mer utrymme för användarcentrering inom affärs- och verksamhetsutvecklingen. Detta är givetvis mycket insiktsfullt och roligt för oss. Ramverk som bl.a. vi jobbar med; "Användardriven innovation" och "Medarbetarperspektiv i verksamhetsförändringen" har hämtat sin värdegrund från ”klassisk” användarcentrering och lånar tekniker och metoder därifrån.
Efter att ha arbetar som konsult inom interaktiva medier sedan 1991 kan jag lugnt säga att det inte finns någon hundraprocentig projektmetod. Däremot är jag säker på att majoriteten av de problem som uppstår i projekt beror på bristande kommunikation inom projektet och mellan projekt och uppdragsgivare, samt bristande samstämmighet mellan vad som konstrueras och den verklighet det konstruerade ska leva i.
Fördelen med exempelvis Scrum är att den möter detta behov av kommunikation på ett formaliserat sätt.
Jag håller med om att mycket av det arbete som handlar om att definiera användarna och deras verklighet/er har infogats i det arbete som verksamhetsutvecklarna bedriver. Ett problem i sammanhanget är dock att verksamhetsutvecklare ofta nog saknar förståelse för de konkreta användningssituationerna samt för de begränsningar och möjligheter som beror på val av teknisk plattform.
Med en 'sprint zero' (egentligen - klassisk förstudie) kan man jämka ihop alla dessa insikter, kunskaper och kompetenser på ett sådant sätt att man ger bästa möjliga förutsättningar för projektgenomförandet. Inte alla som arbetar enligt Scrum genomför en sprint zero, och det är den enskilt största risken med att använda en agil utvecklingsmetod - att man tror att kollektivt ansvar och kommunikation ska ersätta specar och systemavgränsning, övergripande systemdesign, etcetera.
Visst, det finns ingen perfekt projekt-/utvecklingsmetod, det tror jag att de flesta är överens om. Det beror alltid på... Vad gäller "Sprint Zero" så har jag uppfattat det som att det är något som högst sträcker sig över en vecka, vilket ger väldigt lite tid för förberedande arbete. Jag tror snarare att man ska ha ett "förprojekt" som inte är direkt kopplat till Scrum-projektet. Detta projekt definierar det som sedan skall byggas, exempelvis enligt Scrum.
Vem har sagt att sprint noll måstev ara en vecka, eller att det bara finns en sprint noll? om det mot all förmodan skulel behövar mer bakgrundskunskper, så är det upp till produktägaren att kräva mer interjuver, observationsstudier etc från teamet. Scrum är en projektstyrningsmetod, itne en programmeringsmetod, varför scrum går att använda även i rena förstudieprojekt. hela grejen är ju iterativiteten, timeboxingen och kommunikationen , inte vad som är leverabeln. därför är jag mer och mer tveksam till att vi ska kalla det för sprint noll. det implicerar att det inte är en del av projektet. sprint ett är den sprint då förstudien och de konceptuella skisserna tas fram, inte sprint noll. Leveransen är ju då inte "working code", utan kanske personor och interaktionsdesignskisser.
Det är ju bra att det går att använda Scrum till vad som helst. Men, det blir ju en liten knepig diskussion då "anything goes"... Knappast lönt att ha en sådan dialog tycker jag. Om Scrum är iterativitet, time-boxing och kommunikation så låter det ju som bra "best pratcices". Finns i DSDM såväl som i olika versioner av UP.
Skicka en kommentar
<< Home