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

4 reaktioner på ”En oväntad upptäckt”

  1. En utmaning i kravarbetet är att få kraven att hänga ihop och få till en helhetsbild, vilket säkert också gör det svårt för en testare att strukturera testerna.

    Det låter som det var strukturen och att få till helheten som du lyckades med här genom att redan använda de befintliga kraven men att koppla dom till en user storie. Bra!

  2. Intressant! Så trevligt att du delar med dig av praktiska situationer!

    Olika kravstilar på olika nivåer och från olika perspektiv kan verkligen göra kraven mer levande! Att endast kommunicera genom dokumentation är en mycket dålig idé men att kommunicera genom dokumentation är absolut inte för den sakens skull värdelöst.

    Ditt inlägg triggar en del frågor, så klart. 🙂

    Jag blir lite nyfiken på testarnas argument. Ingen skugga på någon, här kommer endast vilda spekulationer. Kunde de inte ta till sig kravspecen? Förstod de inte det som stod i den? Kunde de inte arbeta utifrån den? Hade det att göra med den teststrategi man ville använda?

    Du skriver ju trots allt att kravspecen var välskriven. Undrar därför vad det egentligen innebär? Jag fick känslan att kravspecen saknade något innan du tillförde US?

    Och till sist en metodikundran eftersom du skriver att du använder stilen utan att använda hela metodiken/modellen som det var tänkt från början (vilket absolut kan vara helt ok!). Om testarna efterfrågar user stories, efterfrågar de då implicit ett sådant angreppssätt i utveckling och planering av denna? Jag tänker att det kanske finns många fler user stories än de som du identifierade och om man förväntar sig ”arbete utifrån en komplett uppsättning user stories” (även om US får tillkomma efterhand) så finns det ett hål att fylla?

  3. Problemet med att ha en specifikation utan det du kallar för US är att man saknar länken till huvudintressenterna. De flesta moderna standarder och metoder har tydliga krav på att denna länken skall finnas. Att testansvariga ber om detta är inte förvånande. Det förvånande i din beskrivning är att krav författarna tyckt sig klara sig utan den information som testarna inte kan vara utan. Har man genomfört krav verifiering? På vilket underlag? med vilka roller? Rent spontant är slutsatsen att man varken gör rätt saker, eller saker rätt. Att göra saker rätt kräver den metodik du säger att ni inte följer och att göra rätt saker kräver riktiga krav och det har ni inte för ni saknar de scenarion och uppdragsbeskrivningar som skall innehålla det som motsvarar det ni kallar för US som ni skulle haft om ni hade gjort saker rätt, dvs följt metoden. Din första känsla att det är ”onödigt” och ”meningslöst” är rätt. Om kunder ber om sådant är det inte bra.

  4. Tack för alla engagerade kommentarer! Det är roligt att kunna diskutera sådana här saker med er andra. Det utvecklar oss alla.

    Som ni säkert förstår kan jag ju tyvärr inte skriva så mycket detaljer om vad det egentligen gäller eftersom det gäller en kunds arbete så därför är det lite svårt att svara på era frågor men jag ska göra ett försök att förtydliga.

    Kravspcen är framtagen i nära samarbete med huvudintressenterna. De har både varit med i workshops och granskningar och har haft mycket stort inflytande på utformningen av kraven och kravspecen. Vilka intressenterna är och vad syftet med utvecklingen av systemet är, är väl känt och dokumenterat. Utmaningen har snarare varit att testarna och utvecklarna inte har getts tillfälle att vara med under kravarbetet och dessutom fanns ett behov av att speca ”hela” systemtet innan man började utveckla. Detta av administrativa skäl som jag tyvärr inte kan gå in på. I det läget var inte US ett optimalt sätt att jobba eftersom de, iallafall i mitt tycke, kräver delaktighet och kommunikation av alla. Tyvärr var inte det tekniskt möjligt utan man var tvungen att jobba enligt den gamla vattenfallsmetoden.

    All information (intressenter, scope, mm) fanns i kravspecen och jag kan inte gå in på något resonemang om varför man gjorde som man gjorde. En gissning ska jag dock våga mig på och det är att jag tror att vissa personer i kedjan var vana att jobba i en annan typ av kravställnings- och utvecklingsmiljö än man var tvingad till just här och dessutom hade alldeles för lite tid att lägga på just detta projekt. Jag har själv gjort många bra lärdomar av detta och det var ena av dem jag villa dela med mig av.

    I den bästa av världar skulle man givetvis vilja jobba annorlunda men poängen var att det blev bra till slut och att det faktiskt inte var bortkastad tid att göra på det här sättet. Ibland kommer man ju in sent i projekt som inte gått så bra och då kanske man kan använda detta för att ”rädda” en situation.

    Dela gärna med er av era egna erfarenheter! Tillsamman blir vi smartare. 😉

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *