Kvalitetssystem av olika slag bygger på att det man har producerat har tagits fram på ett välbeskrivet sätt, så att om något fel uppdagas så ska man snabbt kunna ta reda på exakt vad i processen som orsakade det felet, och felsäkra just den delen.
För mjukvara handlar det om att du ska veta exakt vilken version som är i drift, och kunna visa på precis vilka krav som du menar uppfylls av mjukvaran, och exakt vilka mått och steg du vidtagit för att garantera detta. Scrum i sig självt garanterar ingenting, men man kan med ganska små medel få till det. Det handlar bara om att tillämpa vissa saker ur agil kravhantering, och att inte slarva med vissa saker i ramverket.
Versionshanterad "Definition of done". En "Definition of done" (ett "klarkriterium") är en beskrivning av de villkor som måste vara uppfyllda för att en leverabel ska anses vara klart, till exempel: "För varje kodförändring är koden granskad av en kollega, refaktorerad, och dokumentationen samt enhetstesterna är uppdaterade." Klarkriteriet är en överenskommelse mellan utvecklare och omvärld (i Scrum representerad av produktägaren), och den överenskommelsen är under ständig förbättring. För att få spårbarhet måste kriteriet därför vara versionshanterat så att du vet vilket kriterium som gällde den sprint då en viss del av mjukvaran skapades.
Funktionskrav med tydliga acceptanskriterier. Till exempel kan man välja att beskriva varje funktion som en "CCC"-komplett användarberättelse. Användarberättelsen behöver vara tillräckligt versionshanterad så att man vet exakt vilken version av användarberättelsen som den släppta versionen av mjukvaran menar sig implementera.
Du måste dessutom kunna visa att acceptanskriterierna är uppfyllda. Typiskt låter man sitt klarkriterium för funktioner innehålla villkoret att varje användarberättelse är testad i enlighet med acceptanskriterierna. För att få spårbarhet i det behöver det för varje funktion finnas ett eller flera testfall beskrivna som antas pröva om funktionen uppfyller kriterierna. Testfallen måste vara versionerade, precis som användarberättelsen, så att det går att i efterhand pröva om testet verkligen säkerställde att kriteriet var uppfyllt.
På samma sätt behöver beskrivningen av paketet, den släppbara grupp av funktioner som tillsammans genererar ett nytt slags värde i mjukvaran innehålla ytterligare begränsande (ickefunktionella) krav (versionshanterade) och den matris som spårar kraven mot testfallen för ickefunktionella krav (ett krav kan kräva flera testfall och ett testfall kan testa av flera krav). Även dessa testfall ska vara versionshanterade.
I Scrum finns det en överlämningspunkt när utvecklarna berättar om vad de gjort för produktägaren: sprintgranskningen (Sprint Review). För att inte allt omak med versionshanterade krav, processelement och testfall ska vara förgäves behövs det att alla inblandade är på det klara med vad som är gjort och inte gjort. Antingen är ärendena, funktionerna och de implementerade paketen klara i enlighet med klarkriterierna (vilket betyder att tester är avklarade och så vidare), eller så har finns det avvikelser och då ska dessa rapporteras till produktägaren. Kvalitetssystem brukar kräva att det formella godkännandet av leveransen är bokfört, och det sker enklast om gruppen tillsammans har en beslutslogg: en enkel kalkylarksfil där varje beslut noteras löpande och av vem.
Det är alltså inte så mycket man behöver tillföra utöver Scrum och vanlig agil kravhantering med användarberättelser. Det enda som krävs är att allt är versionshanterat och loggat så att ni vet precis vilka test som var utförda för precis den version av mjukvaran som visade sig fungera dåligt i hjärtstartaren...
Inga kommentarer:
Skicka en kommentar