En oväntad upptäckt
På sista tiden har det pågått lite diskussion om use cases (UC) och user stories (US). När ska man använda vad och vad är för- och nackdelarna med respektive metod. I det här inlägget kommer jag inte gå in på några djupa detaljer om detta utan jag vill dela med mig av en intressant upptäckt jag gjorde nyss.
En sak brukar de flesta vara överens om och det är att User Stories handlar om kommunikation. En US är inte bara ett annat sätt att skriva krav på utan det är mer än så. Man tvingas att tillsammans fundera på vilken den verkliga intressenten är och vad som faktiskt är dennes verkliga behov. Därför är det viktigt att arbetet med att formulera US är en gemensam aktivitet med representanter från alla delar av projektet. Tyvärr är det ju så att metoder kan missförstås (och ibland missbrukas medvetet)...
För ett tag sedan blev jag ombedd att skriva US till en kravspec som redan var väldigt detaljerad. Kravspecen som sådan var bra. Den hade ett tydligt fokus på verksamhetsnytta och innehåll inte oavsiktliga lösningar. Specen var strukturerad och heltäckande och tydlig och var framtagen för att beskriva en viss verksamhets behov av att nytt stödsystem. Som sådan var den inte framtagen med någon specifik utvecklingsmetodik i åtanke. Jag skulle vilja kalla den för en klassisk, välskriven kravspec. Det enda problemet var att den testarna inte hade varit delaktiga i framtagandet och det var representanter för dessa som nu bad mig skriva US ”istället”.
Att sitta själv på sin kammare och skriva US till en redan färdig kravspec kändes först som en onödig och meningslös uppgift men man gör som kunden vill. Eller hur…
Men det som sedan hände var faktiskt riktigt spännande.
Jag satte mig ner och tittade på avsnitt för avsnitt och försökte formulera max tre US för varje. Jag lade stort fokus på ”Som en…” och ”…för att” delarna och försökte hålla ”..vill jag..” så generellt som möjligt och sedan placerade jag mina US direkt ovanför kraven i respektive avsnitt.
När jag sedan läste igenom helheten kändes de ”klassiska” kraven annorlunda. Istället för att bara vara krav så fick de en tydlig karaktär att vara acceptanskriterier, utan att jag hade ändrat något alls. Jag kommer nu att prova att lämna detta till test och be dem planera testningen utifrån detta, alltså utan att skriva några nya acceptanskriterier. Om det håller så tycker jag att det är en spännande upptäckt som visar att det ett sätt att använda en metod eller modell inte behöver vara ”fel” bara för att man inte gör exakt som det var tänkt från början.
/Alexander von Essen, Require AB