Så här arbetar vi agilt

ReQtest bytte från vattenfallsmodellen till att arbeta agilt med Scrum. Resultatet blev bättre krav, bättre tester, högre kvalitet och ännu bättre användbarhet. Många agila tekniker går att tillämpa i traditionella projekt, så även om du inte arbetar med Scrum eller någon annan agil metod i dag, kommer du kunna dra nytta av många av koncepten.

Bakgrund – detta är ReQtest

ReQtest är ett webbaserat test- och felrapporteringsverktyg på svenska med fokus på rätt funktioner och god användbarhet. ReQtest levereras som en SaaS-tjänst (Software as a Service) vilket innebär att kunden hyr ReQtest och betalar en månadsavgift som inkluderar support och fria uppgraderingar. Ta gärna en titt på www.reqtest.se om du vill se exempel på kunder. Teamet som utvecklar ReQtest består av 6 personer inklusive utvecklare, Scrum master, produktägare och produktutvecklare.

Från sekventiell utveckling till agil utveckling med Scrum

Vi började utveckla ReQtest 2001 och fram tills för ett par år sedan hade vi en traditionell vattenfallsmodell med kravhantering, design, implementering och test. Vi driftsatte systemet fyra gånger per år och upplevde alla de sedvanliga nackdelarna med detta arbetssätt:

• Felen upptäcktes för sent. Testerna gjordes i slutet och om kritiska fel hittades flyttades leveransdatumet eller kravet ändrades. Om det var möjligt att ändra kravet blev det dyrt och på bekostnad av annan funktionalitet.
• Brister i användbarhet, t ex på grund av att bristfälliga krav feltolkades av utvecklarna och därmed implementerades utan att användbarhetstestas.
• Leveranser skedde för sällan. Vi ville öka leveranstakten så att kunderna ser att det händer något hela tiden.
• För lite testning. Testningen skedde manuellt och utan att någon kände tillräckligt mycket ansvar för aktiviteten.

Scrum som vi tillämpar det i ReQtest

Vår product backlog innehåller cirka 300 krav. Detta är önskemål från kunder, nya idéer etc som inte är planerade för en specifik sprint. Vi använder kravhanteringsmodulen i ReQtest för att hålla koll på dessa krav och listan är grovt prioriterad.

Inför varje sprint väljer produktägaren ut ett antal krav från product backlog. I vår verksamhet kan det innebära att vi väljer ett antal krav som gäller testgenomförande eller rapportfunktionerna i ReQtest. Utvecklingsteamet gör en tidsestimering av aktiviteterna. Om det är nödvändigt detaljeras kraven ett steg till för att kunna göra korrekta tidsuppskattningar. En sådan detaljering kan exempelvis göras i form av en prototyp. Vi använder workshops för att fånga och strukturera krav, både internt och tillsammans med kunder. När tidsuppskattningen är klar och vi slutligt väljer vad som ska ingå i sprinten samlas de utvalda kraven i en sprint backlog som i vårt fall är whiteboard-tavlan i utvecklingsrummet. Sprinten inleds och ett releasedatum fastställs.

Vi har valt att våra sprintar ska omfatta fyra veckor (undantagsvis kortare). När sprinten är klar driftsätter vi leveransen. Scrum säger inte att man måste driftsätta efter varje genomförd sprint, men i vårt fall när vi bygger en webbaserad programvara utan kopplingar till andra system är det en stor fördel för alla att driftsätta regelbundet. Våra kunder ser hela tiden att det tillkommer ny funktionalitet och vi kan hela tiden utveckla och testa en lagom stor mängd funktionalitet.

Under sprintens gång sker utveckling och de flesta testerna. Vi har inga dedikerade testare utan det är utvecklarna som utför de flesta testrelaterade uppgifterna. Testerna utförs nästan uteslutande automatiskt, både i samband med nattliga byggen och när utvecklarna checkar in kod. Det gör att utvecklarna blir mer självsäkra eftersom de snabbt ser om en ändring leder till problem någon annanstans i systemet. Varje vecka håller utvecklarna en demo för produktägaren för att visa veckans framsteg.

När sprinten är slutförd uppdaterar vi vår back log i ReQtest för att ha hålla koll på vad som är gjort. Om man jämför med traditionell testning kan man säga att det som utvecklarna gör motsvarar komponent-, integrations- och systemtest och produktägaren utför acceptanstesterna. Utvecklarnas tester är automatiserade med hjälp av open source-verktyg som Nunit och Selenium. Acceptanstesterna utförs som en demonstration där utvecklarna visar de kravställda funktionerna för produktledningen. Vid behov kompletterar vi med manuella tester. Eftersom systemet efter detta är vältestat och diskussioner har förts löpande under utvecklingsarbetet hittas vanligen endast få fel inför produktionssättningen. Om fel hittas vid produktionssättning analyserar utvecklarna orsaken och ger förbättringsförslag. Kontinuerlig förbättring är därmed inbyggd i arbetssättet.

Några av våra framgångsfaktorer

Att vi inte har några renodlade testare innebär att alla i teamet får bredare kompetens än vanligt. Förutom att skriva kod deltar utvecklarna även i kravarbetet genom att göra prototyper och genomföra användbarhetstester. Produktägaren skriver kraven och är också med och testar. Det är utvecklarna som hanterar support eftersom det är extremt viktigt att utvecklarna förstår kundernas problem. Min uppfattning är att arbetet blir roligare när man får ta ett större ansvar för en längre kedja av aktiviteter på det här sättet.

ReQtest skickar automatiskt mail till vår support när det inträffar fel i produktionsmiljön. Det hjälper oss att reagera snabbt utan risk att missa fel.

Vi mäter kodtäckning i realtid. Det gör det lätt att bedöma om vi har tillräckligt omfattande automatiserade testfall.

Parprogrammering används regelbundet. Det leder till bättre kodkvalitet, minskar behovet av tidsödande kodgranskning och ger mindre personberoende. Givetvis har vi utvecklare som är specialiserade på olika saker såsom avancerad databasutveckling eller gränssnittsprogrammering, men alla kan tillräckligt mycket om alla delar i ReQtest.

Vi användbarhetstestar all ny funktionalitet på potentiella användare med så kallade tänka högt-tester. Föst dokumenterar vi uppgifter som ska utföras, sedan låter vi en användare utföra uppgifterna och berätta högt om sådant som känns bra, krångligt eller kan missförstås. Vanligen har vi två observatörer, exempelvis produktägaren och en utvecklare. Ett användbarhetstest går snabbt att planera och utföra och ger oerhört mycket värdefull information.

Kommunikation i vårt Scrum-projekt

Vi har planerat kontorsmiljön för att stimulera kommunikation och visualisering. Skrivborden är placerade så att vi har nära till varandra, både sinsemellan utvecklarna och mellan utvecklare/produktledning. På väggarna finns det rejält tilltagna ytor för att visualisera trender och tydliggöra förloppet med hjälp av notislappar.

Bilden visar hur väggen i utvecklingsrummet kan se ut. Den övre halvan visar vilka aktiviteter som ska utföra i sprinten och varje rad motsvarar ett krav. Varje lapp är en aktivitet för att lösa ett krav. Lapparna är placerade i olika kolumner som visar aktivitetens status. Exempel på status är ”åtagen”, ”under arbete”, ”i test” och ”klar”. Lapparna ges olika färg beroende på aktivitetens art. Det är vanligt att ha olika färger för utveckling, test och dokumentation. Diagrammet längst ner är vår burn down-chart som visar om vi ligger i fas med den planerade tiden eller om det finns risk för förseningar.

Informationen på väggen uppdateras dagligen av utvecklarna i samband med morgonmötet (kallat daily Scrum) där utvecklarna står upp vid väggen. Våra ståmöten tar max 15 minuter och var och en berättar vad som gjordes i går, vad som ska göras i dag och om det finns några problem eller hinder.

Tips!

Ha korta möten frekvent i stället för långa möten sällan. En tumregel är att 90 % av mötena ska vara korta och 10 % längre. Exempel på möten som behöver längre tid är sprintplanering och veckodemo.

Nästa steg

Alla kan inte göra allt men alla kan göra något. De flesta av aktiviteterna som jag har beskrivit ställer inte krav på att man arbetar enligt Scrum. Om du vill veta mer om hur man skriver användarberättelser, utför användningstester eller gör en burn down-chart rekommenderar jag ett besök i Faktabanken på www.konsultbolag1.se, där kan du läsa artiklar på detta tema.