Användningsfall 2.0
I en tid då användningsfall för många ses som en förlegad omodern specifikationsteknik kontrar dess upphovsperson Ivar Jacobson med en uppdaterad variant: Användningsfall 2.0 – lättviktiga, skalbara, mångsidiga och lättanvända! Låter inte det agilt, så säg?
Användningsfall 1.0
Användningsfall har sina rötter i 60-talet men beskrevs officiellt först 1987. Sedan dess har metoden förfinats och förtydligats. Främst är det Kurt Bittner och Ian Spence som bidragit till att skapa förståelse för modellen men Alistair Cockburn har också bidragit till olika sätt att skriva användningsfallsspecifikationer.
Under alla dessa år har grundtankarna och principerna i användningsfall bestått (och i allra högsta grad även missuppfattats). Med Användningsfall 2.0 införlivas erfarenheter och intryck från agil utvecklingsmetodik. Det handlar inte om några grundläggande förändringar i modellen utan om en ”relansering” av metodiken med några nya begrepp som beskriver hur användningsfallsmetodiken appliceras i utvecklingsprocessen.
Scenario är historia
När jag introducerar användningsfall som kravmetodik i agila utvecklingsprocesser så brukar jag föreslå att varje scenario, som är en möjlig instans av ett användningsfall, utgör en uppgift i uppgiftslistan (”backlog”). Det har fungerat bra med några modifikationer (återkommer till det). Nu ersätts scenarierna av det mer agilklingande användarhistorier (”user story”).
Konceptuellt sett är det ingen större skillnad: scenarier är och har alltid varit små användarhistorier. I praktiken blir det mer tydligt och uppenbart hur användningsfall direkt kan användas i Scrum och Kanban. Användarhistorierna används alltså som uppgifter i uppgiftslistan men det är inte hela sanningen.
Skiva osten!
En utmaning med att använda historier som uppgifter i uppgiftslistan är att de kan resultera i rätt omfattande utvecklingsarbete. Det kan bli mycket design, mycket kod och mängder av testfall och det får inte alltid plats i ett inkrement (”vi hinner inte bli färdiga med ett helt scenario!”).
Det är dock inte så väldigt intressant att kapa upp en fin historia i delar – då hänger den ju inte ihop längre. Istället skivas hela utvecklingsarbetet på andra ledden: genom design, kod, testfall och testscript. För de som snappade upp ”användningsfallsmoduler” från 2003 så ersätts de nu av skivor.
Vägledande för denna klyvning är testfallen. För varje historia finns det naturligt flera testfall med olika testdata. En skiva definieras av sin historia plus det eller de testfall som levandegör den specifika historien.
Varje historia utgörs alltså av en eller flera skivor. För planeringsändamål utgör skivorna de uppgifter som ingår i ett inkrement. Det går utmärkt att välja ut flera små skivor från samma historia om det passar ändamålen.
Själv tycker jag att klyvningen kan ske även enligt andra lämpliga mönster. Så har jag också applicerat det när jag utgått ifrån scenarier.
Värdet
För oss som är väl bekanta med användningsfall är skillnaden inte så enorm. Själv har jag redan praktiserat dessa principer och det är inget konstigt med det. Användningsfall 2.0 bygger på samlade erfarenheter från de senaste 20 åren.
När det gäller användningsfallens plats hos företag som utvecklar agilt så tycker jag att de generellt sett bidrar med bland annat följande värden:
- Samlar ihop ett antal lösa, relaterade användarhistorier till en sammanhängande värdebringande enhet.
- Möjliggör en bättre övergripande förståelse för ett vad ett system gör och hur det, ur ett användarperspektiv, är strukturerat.
- Utgör ett utmärkt planeringsunderlag för releaser, sprintar, testning, etc.
Som alltid så blir det inga krav i uppgiftslistan utan en duktig produktägare som arbetar med den inledande kravställningen!
Mer att läsa: Presentation
Jag tycker att det i många fall är lite oklart vilken abstraktionsnivå historier resp användningsfall ”ligger bäst på”. Jag har sett exempel där historier griper över ett större flöde som sedan bryts ner i användingsfall, men jag har även sett det omvända där användningsfallet beskriver en stor funktion eller ett funktionsstöd som sedan bryts ner i olika historier kring hur man använder den.
Oavsett vilket så landar man ofta i ett nedbrytningsproblem när man ska planera sina tillräckligt korta iterationer samtidigt som man känner att det finns ett värde i varje iteration. Här tycker jag att nedbrytning i testfall ofta fungerar bra. Ett problem som jag har stött på i den situationen är att man missar att ta fram testfall för delar av funktionaliteten därför att man, i agil anda, inte vill ta fram alla testfall för en historia/användningsfall om inte alla ryms inom nästa iteration.
Intressant! Tack för kommentaren.
Det är inte rättvist av mig att uttala mig utan att ha sett några exempel men ”historier som griper över ett större flöde” låter mer som övergripande förmåga (feature), episk historia (epic) eller ett tema (theme) som ”ska” brytas ner i ett antal historier eller användningsfall. Med andra ord så är abstraktionsnivån för användarhistorien ”för hög” i det fallet. Kan det vara så?
”Nedbrytningen i testfall” och ”ta fram” – det får du gärna utveckla. Märkte att jag fick en rad frågor (identifierar eller skriver? bryter ner hur? bryter ner hur mycket och när?). Med skivorna nöjer man sig med att identifiera alla testfall och sedan peka ut de som ingår i skivan men skriva dem först i inkrementet de ingår.
Du har helt rätt i att det säkert handlar om ”epic stories” eller liknande när historierna är högst upp i abstraktionsnivåerna. Jag ville mest belysa att olika organisationer jobbar med historier och användningsfall i olika ”abstraktionsordning”.
När det gäller testfallen tror jag att vi menar samma sak. Jag menar att den sista nivån i nedbrytningen av en historia med fördel ur vissa aspekter kan göras till testfall så att man kan använda dem när man kör TDD i resp iteration. Jag ser dock en risk att man då missar aspekten att man i varje inkrement vill leverera värde till kunden genom att man sprider ut testfallen över flera inkrement och att varje testfall knappast är utformat för att säkerställa kundvärde.
Att inkrementplanera efter skivorna löser ju detta på ett tydligt sätt. Förutsättningen är givetvis att man har brutit ner sina historier till en storlek som är hanterbar inom ett inkrement.
[…] boken ”Writing effective use cases”. Och tidigare har jag skrivit om Ivar Jacobssons Användningsfall 2.0. Till och med Dean Leffingwell tar i sin bok ”Agile software requirements” upp […]