Blev inte din nya webbplats som du tänkt dig?

Du bokar en bil för att köra till flygplatsen. Uthyraren frågar hur många personer som ska färdas i bilen och du svarar en. Bilen levereras. Ooops! Väskorna får inte plats, bilen är för liten. Att fånga samtliga krav innan produkten levereras är viktigare än många tror.

Det är inte alltid det blev som man tänkt sig när man började arbetet med att bygga en ny webbplats. Någon funktion fungerar inte som den ska. Designmässigt kanske den inte blev så bra som man hoppats på. En anledning kan givetvis vara att det gjorts fel av utvecklaren eller att designern inte gjorde ett bra arbete. Det är dock ovanligt att det faktiskt är det som felet beror på. Bilden nedan visar andelen källor till fel. Den enskilt största källan till fel beror på för dåliga krav.

  Procent-diagram över andelen källor till fel som uppstår i IT-system. 

Beställaren talar om vad man förväntar sig och vad det är man vill få ut av sin nya webbplats. Jobbar man agilt görs en backlogg där vi dokumenterar krav och gör en prioritering. Därefter börjar utveckling. Det som ofta glöms bort är att backloggen behöver gås igenom och detaljerat utreda kraven inför varje sprint. Risken finns annars att designen inte uppfyller sitt syfte, utvecklaren kodar som hen tolkar att det ska vara, testaren gör sin tolkning och därefter sker acceptanstest av beställaren som har sin tolkning. Det kan till synes se korrekt ut direkt vid testning men efter ett par månader visar sig inte alls stämma på grund av feltolkningar eller avsaknad av krav. Då behöver en rättning göras. En rättning innebär att:

  • Felet ska utredas och kravställas
  • Utvecklaren ska felsöka
  • Utvecklaren ska rätta felet
  • Utvecklare testar rättningen
  • Testare testar rättningen
  • Regressionstest, har rättningen orsakat nya fel?
  • Installationsfix
  • Ev information ska skapas och skickas ut till användarna

Och detta är bara kostnaden rent arbetsmässigt. Vad som är mycket värre är att man kan ha fått minskad trovärdighet. Det leder även till högre utvecklingskostnader, högre förvaltningskostnader, förseningar, försämrad relation mellan beställare och leverantör.

Ju tidigare vi hittar fel och brister ju billigare och bättre produkt får vi. Hittar vi fel redan i kravställningen är mycket vunnet, inget är ju byggt än. Beställaren och leverantören får även samsyn över vad som faktiskt ska byggas.

Kravhantering när man arbetar enligt Scrum

När man arbetar agilt enlig Scrum läggs kraven upp i en backlogg. Ett krav i en backlogg ska bestå av en användarberättelse. I den ingår vem, vad och varför.

Användarberättelse VVV
Som en [intressent] Vem
vill jag [mål] Vad
så att [motiv] Varför

 

Ett exempel: ”Som en förälder vill jag kunna se när skolan börjar så att jag kan planera min ledighet”. Det är viktigt att få med motivet då det annars är lätt att missa syftet med kravet och då kanske det ges fel prioritering i backloggen. I detta arbete detaljeras inga krav utan detta är så att säga rubriken på kravet, detaljeringen sker i agil anda inför varje sprint.

Backloggen prioriteras inför varje sprint, det ska vara en levande backlogg som tillåter att det kommer in nya krav och önskemål. Finns det en effektkarta är det lätt att prioritera kraven då man har den att luta sig mot. De högst prioriterade kraven detaljeras så både leverantör och beställare är införstådda med vad de innebär innan utvecklingen påbörjas. Vid denna aktivitet bör det delta olika roller eftersom man ser på kraven med olika ögon. En bra gruppsammansättning är beställare, utvecklare, testare och designer.

När detta är gjort kan teamet planera in dessa i nästkommande sprint. Krav kan dels vara utveckling av koden men det kan också vara en design som ska tas fram. Kraven bör identifieras innan designen tas fram. Ett vanligt misstag är att designen sätts först och sedan får kraven anpassa sig efter den.

I sprinten ska det nu vara arbetsro. Inga förändringar ska göras för det är då det lätt uppstår ett fel som man senare får rätta. Det är lätt att tro att ”vi arbetar agilt, vi ändrar under tiden”, men får man aldrig någon arbetsro kommer det slinka in fel som oftast beror på att man inte tänkt hela vägen. Under sprinten kan man däremot fortsätta att utreda krav för nästkommande sprint så man är redo och inte får några ställtider.

Det finns olika typer av krav och olika tekniker för att samla in de olika kraven och det kommer jag skriva om i en bloggpost längre fram.

Slutsats

Ett bra förarbete där kraven tas fram och detaljeras innan design och utveckling påbörjas bidrar till att det blir en framgångsrik webbplats som både beställare och leverantörer kan vara stolta över. Det blir en webbplats där besökare får sina behov uppfyllda och därmed blir återkommande besökare. 

Relaterade academyinlägg

Är din digitala tjänst värdeskapande eller bara komplex? De flesta organisationer är överens om vikten av att skapa värde för kunder och därmed den egna organisationen. Vår erfarenhet säger dock att samsynen på vad som skapar värde för den egna organisationen ibland kan skilja sig åt. Vad är egentligen värde? Och varför prata värde när man pratar digitala tjänster?