Krav & dokumentation, del 2 2017-03-28 Robert Åhlén Krav & dokumentation, del 2 Krav som user stories

User stories & acceptanskriterier Snabbkurs i agil kravhantering

Agil kravhantering i praktiken Detaljera ”just in time” – lösningen måste inte vara färdigtänkt när kravet skrivs Kundkontakt (=användarkontakt), välkomna sena ändringar, det är viktigare med rätt innehåll än rätt process => Framgång mäts i en fungerande produkt Användningsfallen är inte beställningen till utvecklingen; beställningen görs i form av ärenden/stories

User story – vad är det ens? Metod för att tvinga fram kommunikation Genom att endast beskriva det allra mest fundamentala måste en diskussion hållas mellan kravskrivare och utvecklare Ju mer som är detaljerat vid första anblick, desto sämre är det (illusion av ”genomtänkthet”/”oändringsbarhet”) Storyn kallas ibland för ”ett löfte om ett samtal” Får utvecklas och förändras under sprinten – är inte låst som en beställning, utan vi välkomnar förändring!

User story – mallen Som en <roll> Vill jag <kunna/vilja/se/få XYZ> För att <motiv> Som en ny användare Vill jag skapa ett konto För att kunna köpa en bok Som säljansvarig Vill jag att bokköpare ska skapa användarkonton För att kunna skicka riktad reklam till dem och sälja mer

User story – beståndsdelar Tanken är att rollerna ska vara hyfsat fasta och att motiven ska vara kända Jämför med en effektkarta där man börjar med att ta fram målgrupper/användare och deras behov – då är halva storyn gjord! Rollen ska fylla i det som inte sägs – handläggare har andra behov än sökande, handläggar-personan ”Edit” har andra behov än personan ”Björn” Kan precisera en roll med ett ”när” Som handläggare när jag försöker byta telefonnummer vill jag… Som någon som vill byta telefonnummer vill jag… Motivet! Varför är det här intressant? Vilken är verksamhetsnyttan? Vem underlättar vi för och varför? I företag: Hur tjänar vi pengar? Hos oss: Hur sparar vi pengar?

User story – någon slags process När storyn skrivs Tillåts vara oklar, breda roller, brett varför, kanske saknar beståndsdelar Står knappt på egna ben Efter första diskussion krav <-> team Roller blir klarare, varför framstår, vad som behövs börjar skönjas, lösningar skissas Börjar klara sig själv Utredning/analys Förtydligas: Vilka roller definierar vi in och bort? Vilka lösningar är värda att gå vidare med?

User story – någon slags process Inför sprint Alla är överens om vad som ingår Under sprint Ingen överens (), ändra/backa/justera Efter sprint Kasta bort! Dokumentation löses lämpligast på annat sätt Olika processer tillåts Allt måste inte vara klart inför sprinten Kan låta föregående slide ingå i sprintprocessen Primära objektet som drivs genom sprinten Kan ibland vara detsamma som ett sprintmål Är en utgångspunkt, ej nödvändigtvis slutresultatet En story kan bli 15 ärenden i 7 sprintar…

User story – krav på kraven INVEST: Independent (står på egna ben – är inte endast en del) Negotiable (tillåta diskussion) Valuable (tillföra värde, värdet ska helst inte komma från annan story) Estimable (säga något om scope – vad innehåller det, vad innehåller det inte?) Small (se ovan, inte för stort scope!) Testable (självständigt och värdefullt kan testas) Stories som inte uppfyller INVEST kan behöva delas eller slås ihop eller splittras på annat sätt När vill man att storyn ska uppfylla INVEST? Före sprint, under sprint? Stories som levereras ska ge nytta I SIG

User story – tips & trix Otroligt lätt att de här bara görs för sakens skull Individuals and interactions over processes and tools Att utföra meningslöst arbete är just meningslöst: waste i lean Se till att de blir meningsfulla och fyller sitt syfte Ska underlätta, inte ersätta, kommunikation Tips för att det inte ska bli en tom rutin!

User story – tips & trix Vänd på mallen! Halvera mallen! För att <motiv> För att inte riskera felaktiga telefonnummer Vill jag, som en <roll> Vill jag som sökande som bytt telefonnummer <Kunna/vilja/se/få XYZ> Få ett bekräftelse-SMS skickat till mig Detta lyfter fram motivet på ett oväntat tydligt sätt – vad är det ens för problem vi försöker lösa? Halvera mallen! När jag <situation> När telefonnummer byts Utelämna roll och ”vill” – fokusera på problemet och situationen och låt lösningen arbetas fram Använd storyn som diskussionsunderlag med teamet Fyll i roller och behov allt eftersom

Acceptanskriterier Beskriv i förväg hur det ser ut/fungerar när storyn är färdig, klar och accepterad Lite mer fri form än storyn i sig själv: ”Det ska gå att göra X” Kan vara i form av ”lokalt användningsfall”: Användare gör X Systemet gör Z Osv Punktlistor är finfint Ska fortfarande vara fokus på användaren och nyttan – inte på systemet och lösningen Kan ersättas av testfallsbeskrivning / demoplan: ”Storyn demas genom A, B, C, sedan X, Y…” Funkar det, funkar storyn Fungerande mjukvara är främsta framgångskriteriet

Återigen: agila principer Stories och acceptanskriterier ska inte ses som slutgiltiga förrän koden är pushad och ärendet avslutat Formuleringar görs i samarbete mellan krav och utveckling Formuleringar, inriktningar, lösningar ändras beroende på användares reaktioner Inget är egentligen färdigt förrän det är klart, produktionssatt och använt Fokusera på användarnyttan – eller egentligen verksamhetsnyttan Användaren kanske vill ha något som egentligen verksamheten i stort inte är hjälpt av Vilket är det överordnade målet egentligen? Men allt passar inte som user story!

Nyttopyramid – ”big picture quality pyramid” SUCCESSFUL? USEFUL? USABLE? WORK WELL? DOES IT WORK? Adzic, Evans & Roden (2015:10-11)

Nyttopyramid – enkla definitioner SUCCESSFUL? USEFUL? USABLE? WORK WELL? DOES IT WORK? Uppfyller affärsbehov Används i produktion Går att använda Fungerar utan uppenbara fel Fungerar enligt specifikation

Nyttopyramid – kvalitetsaktiviteter SUCCESSFUL? USEFUL? USABLE? WORK WELL? DOES IT WORK? Uppfyller affärsbehov Används i produktion Går att använda Fungerar utan uppenbara fel Fungerar enligt specifikation Kontrollera... ...produktionsdata! Acceptanstest Funktionell test Enhetstest

Varför gör vi något alls? Vilken förmåga möjliggör vi för verksamheten? Vad kan de göra nu som de inte kunde göra nyss? Testa detta överordnade!

Exempel VAD När går det? När går det bra? När kan det användas? När används det? När är det en succé?   Det finns anledning att fundera kring dessa frågor när vi startar upp ärenden. Inte bara ”acceptanskriterier” utan ”succékriterier”! ”Inga felrapporter” på det vi skickar ut är ett självklart mål, men det ambitiösa målet är ”inga supportärenden” – användarna förstår vad som ska göras utan att behöva kontakta supporten! (Det finns också en tredje nivå – inga ärenden till produktionssupporten, något att fundera på!)

Tack! Frågor?