Scrum

2007-12-04 Artikelbanken Test Läst 8183 gånger

Agila utvecklingsprocesser, i synnerhet Scrum, har blivit riktigt heta samtalsämnen på sistone. Det snackas Scrum på kafferaster, i lunchrum och på konferenser. Men vilken påverkan har de nya metoderna på testarbetet och ställer de några särskilda krav på testaren? I denna artikel har vi utgått ifrån våra egna erfarenheter av Scrum och reflekterat över testarens förändrade roll i utvecklingsprocessen.

Kort om Scrum

Förenklat kan man beskriva Scrum som en iterativ utvecklingsmetodik med korta inkrement, så kallade sprintar, där man efter varje sprint skall ha en mer eller mindre färdig produkt att visa upp för kund eller produktägare och därigenom få snabb och kontinuerlig feedback. Arbetet i sprintarna utförs av små utvecklingsgrupper med 5-9 deltagare där deltagarna gemensamt förbinder sig att lösa en delmängd av alla krav som finns i en lista som enligt Scrum kallas backlog. De roller som finns utöver utvecklingsgruppen är Scrum master som motsvarar en ”coachande” projektledare, och produktägaren som ansvarar för backlogen och prioritering av arbetet. Något som kännetecknar Scrum är det dagliga mötet där deltagarna berättar om gårdagens och kommande dags arbete. För mer utförlig info kring Scrum, rekommenderar vi en titt på Scrum Alliance webbsida där det finns ett stort antal olika presentationer som både förklarar metodiken samt erfarenheter av olika implementeringar av denna. Se www.scrumalliance.org.

Agila manifestet:
Individer och interaktion framför processer och verktyg.
Fungerande mjukvara framför omfattande dokumentation.
Samarbete med kunden framför kontraktsförhandling.
Anpassning till förändring framför att strikt följa en plan.

Se agilemanifesto.org för mer information.

Anpassningsförmåga

Ett av de krav som ställs på testare i Scrum är förmågan att kunna anpassa sig till nya situationer och roller. Då teamet har ett gemensamt ansvar för att lösa sina åtaganden i sprinten krävs det att alla är redo att ta sig an olika roller för att teamet ska uppnå sitt mål. Om det för stunden inte finns tester att förbereda eller exekvera gäller det att försöka hitta sätt att understödja utvecklarna i teamet. I större projekt där man har parallella Scrum-team kan det vara viktigt att under en kort period vara beredd på att växla team för att understödja testresurserna i andra team.

På grund av de korta inkrementen och att backlogen ständigt kan omprioriteras inför varje sprint kan vägen från idé till färdig produkt vara kort. Då gäller det att snabbt kunna sätta sig in i idéer och krav för att genomföra testarbetet och garantera kvalitet.

Testarens oberoende

Scrum uppmuntrar till närhet mellan teammedlemmar, dels fysiskt men även samarbetsmässigt. Med en sådan närhet till utvecklare finns det en överhängande risk att det oberoende en testare bör ha gentemot utvecklare minskar. Man blir ”kompis” med sina utvecklare och är inte lika kritisk och ifrågasättande som man hade varit annars. Risken bör givetvis vägas mot de fördelar närheten till utvecklarna leder till. Vid ett tidigt skede kan testare ta del av, och möjligtvis påverka, beslut/krav som kan vara rent av felaktiga. Förekomsten av de fall där testare upptäcker designförändringar först när de får mjukvaran i handen minskas radikalt.

Vad är klart?

Traditionellt sett brukar testare ha störst belastning under slutskedet av utvecklingsarbetet på grund av beroendet av utvecklarnas leveranser. Det är ingen större skillnad i Scrum, belastningen blir som störst vid slutet av sprinten eftersom utvecklarna normalt kan leverera mjukvaran först en bit in på sprinten. Dock blir det mer påtagligt i Scrum då varje sprint ska resultera i en färdig produkt där alla tester är slutförda.

Det kan även uppstå tvetydigheter huruvida sprintprodukten är helt klar eller inte. Om utvecklarna levererat den planerade funktionaliteten och testare genomfört de planerade testerna så kan det av vissa definieras som klart ur Scrum-perspektiv; men är produkten i sådant skick att den verkligen går att släppa? Det är nog få testledare/testare som skulle känna sig bekväma med att ge tummen upp för en produkt som varken genomgått en stabilisering eller en regression. Det gäller därför att försöka bygga upp en samsyn kring definitionen av begreppet ”klart” inom teamet.

Dokumentation

Hur dokumentation används i agila metodiker varierar förstås kraftigt mellan olika projekt, men i enlighet med det agila manifestet sätts fungerande mjukvara framför dokumentation. Det dokument som inte tillför ett värde till produkten anses vara överflödig. Även detta har självklart både för- och nackdelar. Många har säkerligen jobbat i dokumenttunga projekt där minsta sak skall dokumenteras, utan att det egentligen går att se värdet av det. I dessa fall lämnas en stor del av ansvaret till dokumenten över. I Scrum lyfter man hellre huvudet från skärmen och berättar helt enkelt för teamet vad som gäller istället för att hänvisa till ett dokument.

Brist på dokumentation kan alltså vara hanterbart om teamets medlemmar är tillräckligt få för att sitta fysiskt tillsammans och ha gemensamma möten. Då behöver nödvändigtvis inte informationen dokumenteras för att det enkelt ska spridas till alla i teamet. Större team ökar problematiken med kommunikation och risken att man går mot normal inkrementell utveckling och avsaknad av dokumentation blir mer påtaglig. Fler antal team utökar problematiken med koordination mellan team och ytterligare integrationsproblem.

Förvaltning

Beroende på hur Scrum tillämpas, riskerar man att få problem när förändringar senare behöver hanteras när systemet förvaltas. Om man som i extremfallet låter programvaran vara dokumentationen så är de facto alltid alla krav uppfyllda. Det kan därmed bli svårt med stora kravförändringar under förvaltning om nyckelresurser har flyttas från projekten och dokumentationen är hållen på en minimal nivå. Som testare kan det därmed bli mycket mertid för att verifiera förändringar.

Summa summarum

De ”klassiska” problem en testare ställs inför är även närvarande i Scrum. Orsaken är ofta att testares syn på kvalitet normalt skiljer sig från övriga involverade i projektet. Dock möjliggör Scrum för testarrollen att inte bara involvera sig i större utsträckning, men även tidigare under utvecklingsarbetet. Scrum gör även en viktig distinktion att hela teamet, inte bara utvecklarna, ska bli klara för att sprinten ska anses som lyckad, en syn som inte alltid delas i traditionella projekt. På grund av nämnda argument tycker vi att testarrollen har blivit mer stimulerande genom Scrum. Dock kan vägen mot ett Scrum-projekt med en gemensam syn på balanserad dokumentation och test/kvalitet vara lång.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln