Gå till innehåll

<!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } A:link { so-language: zxx } -->Jag har tillbringat de senaste veckorna med att läsa om prototyping (Serious Play av Michael Schrage), användbarhet och interaktionsdesign. Alla som skriver är överens om problemet att få en kund/beställare att dels veta vad de vill ha, dels förmedla detta till den som ska bygga produkten. Ett sedan länge välkänt och effektivt sätt är att skapa prototyper av något slag och låta den tänkta användaren känna sig för under noggrann observation. Motiveringen är att först då man ser en sak vet man om det är det man vill ha och om det är något  som fattas. Jag kommer på mig själv att sitta och nicka hela tiden och säga för mig själv hur självklart det är att jobba på det här sättet. I mer vattenfallsliknande projekt  brukar man säga att det funkar bäst om beställaren är aktiv under hela projektet, med andra ord känner sig för och styr in utvecklingen på rätt spår - en sorts prototyping!

I agila projekt är ett av huvudmottona  "Welcome changed requirements, even late in development" . Nu har jag suttit med på ett  par testkonferenser och dessutom diskuterat livligt om fördelarna med agile och inte minst påverkan på test.  Pablo Garcia hävdar envist att metoder som SCRUM, XP etc är mest för utvecklarna så att de levererar stabila bra produkter. Test får vara med litegrann men ofta  verkar det ligga lite utanför - som vanligt. Frågan är inte om ett SCRUM-team testar eller inte - för de gör de mycket och ofta. Frågan är om alla nivåer av test kommer med tillräckligt mycket och det är en berättigad fråga.   Dessvärre har jag inga egna efarenheter - ännu - jag ser fram emot det första agila projektet jag får bita tag i. Så om ni har några på gång till hösten, hör av er!

Men åter till problemet att den som beställer inte vet vad de vill ha. Ofta är det först i  system- eller acceptanstest som en översiktlig genomgång av alla affärsprocesser i verklig användning görs. Då är det ju som alla testare vet alldeles för sent att göra några genomgripande förändringar i designen. Det jobb vi ofta gör med affärsprocesser och röda trådar genom hela systemet borde ha gjorts tidigare med tyngdpunkten i andra änden av projektet - innan kodningen börjar.

Som jag tolkar de agila principerna så är målet att leverera ofta och  alltid en körbar version.  Detta inte bara för att se att koden fungerar utan även för att kunden ska ha en chans att ge en återkoppling på funktionaliteten och lösningen i stort. På ett sätt är det motsatsen till prototyping då en viktig princip är att prototypen är "quick and dirty" och syftet är att få fram bra krav men kodningen är slarvig och prototypen bör därför kastas. Istället gör man refactoring och får på så sätt fram bra kod  - eller iallfall bättre än dålig. Läste ett stycke i Serious Play om ett experiment där Boehm hade låtit två grupper utveckla ett litet system. Den ena gruppen mer traditionellt sekventiellt med analys, design av det mesta innan kodningen började, den andra gruppen med agila metoder med täta leveranser. Det visade sig att den agila gruppens kod var sämre strukturerad och hade färre funktioner men mer nöjda användare.

Varför inte ta det bästa av alla världar och göra en bra prototyping i början för att få fram bra krav,  utveckla agilt om det nu passar utvecklarna bättre och sen göra ordentliga tester som komplement till det som göra i den agila gruppen? Fördelarna är att experter på interaktionsdesign och användbarhet  är BÄST på att skapa en användbar produkt, utvecklarna  BÄST på att lösa problemen kodmässigt och  testarna BÄST på att  testa. Samarbete är fantastiskt och ofta effektivt men hur  lätt  är det för en  interaktionsdesigner att komma med i  ett SCRUM-team eler för en testare att komma med över huvud taget?

Det borde funka  bäst att först ta fram de flesta kraven, funktionerna och gränssnittsdesignen  ot användaren. Sen får experterna på arkitektur och kodning göra sitt bästa att realisera lösningen.