Scrum Och Kvalitet

Bakgrund

I samband med att jag pluggade till Istqb Foundation Certified Agile Tester (tentan gick för övrigt bra) grubblade jag otroligt mycket på Scrum Och Kvalitet. Jag får känslan att man inte riktigt bryr sig om traditionell kvalitet utan man förlitar sig lite på att Scrum automatiskt ger kvalitet. Så är så klart inte fallet - ingen utvecklingsmetod ger per automatik kvalitet. Tror jag. Mjukvarukvalitet Programvarukvalitet Eller Software Quality är ett svårt ämne, och jag tycker inte det blir lätt bara av att man väljer en viss utvecklingsmodell.

Jag har läst ett par böcker om agil testning. Referensverket är Boken Agile Testing och för certifieringen är Boken Testing In Scrum relevant. Något som återkommer, och som även är med i kursmaterialet för certifieringen är Agila Testkvadranter - ett bra verktyg som jag själv försöker använda som checklista i samband med testplanering.

Ibland grubblar jag även på hur Lean Utveckling och mina gamla tankar om Agil Testprocess som jag inte kunnat släppa. Jag har även jobbat i flera år i miljöer som säger sig vara agila eller jobba enligt scrum. Som jag upplever det har ingen haft järnkoll på Scrum. Det var därför det var så skönt att plugga in sig i ämnet, och då inte bara ut ett test-perspektiv. Men jag tror att tack vare test-perspektivet så faller vissa bitar på plats för mig.

När jag pluggade inför certifieringen så sökte jag upp en kollega i Göteborg som haft rykte om sig att vara bra på agil kvalitet. Jag bjöd in honom för att hålla en gästföreläsning, som han senare höll. Det var otroligt nyttigt och tack vare den sittningen föll ännu mer bitar på plats.

Denna text handlar i princip om hur Scrum ska vara, med mina tillägg och kommentarer. Speciellt vill jag lägga till saker som handlar om kvalitet. För den "officiella" versionen av Scrum kan jag tipsa om The Scrum Guide (se [1], eller [2] för en svensk version), jag kan även mycket varmt rekommendera Boken Testing In Scrum av Tilo Linz.

Scrumteamet

• Produktägaren: "Produktägaren ansvarar för att maximera värdet av produkten och utvecklingsteamets arbete. Hur detta går till kan variera mycket mellan organisationer, scrumteam och individer. Produktägaren är ensam ansvarig för hanteringen av produktbackloggen..." (Från Scrumguiden.)
• Utvecklingsteamet: "Utvecklingsteamet består av yrkesmänniskor som genom sitt arbete levererar ett potentiellt releasebart inkrement av en 'klar' produkt i slutet av varje sprint. Bara medlemmar i utvecklingsteamet bidrar till att ta fram produktinkrementet..." (Från Scrumguiden.) Jag skulle vilja tillägga att:
  • Scrum struntar i om folk vill identifiera sig som något annat än utvecklare - alla är utvecklare! Som framförallt testare gillar jag inte den terminologin (den gör mig "bitter och kränkt"). Jag tror det kan vara en av orsakerna till att agilt går dåligt så ofta. Man kastar bort allt utom utvecklare och hoppas på det bästa.
  • Hela teamet är ansvariga för produktens kvalitet. Om vi nu har ett korsfunktionellt team (som är en annan bra idé när det gäller agil utveckling) så är det inte bara, till exempel, testaren som ska bry sig om kvalitet.
• Scrummästaren: "Scrummästaren ansvarar för att säkerställa att Scrum förstås och efterlevs. Scrummästare gör detta genom att se till att scrumteamet håller sig till scrumteori, tillämpning och regler..." (Från Scrumguiden.) Min erfarenhet är att en av de viktigaste uppgifterna som scrummästaren har är att på ståmötet checka av om någon sitter fast och bolla med teamet hur man kan få arbetet att gå vidare.
• Stakeholders/Intressenter: Denna kategori människor är extremt perifer i den officiella scrumguiden. Det är lite synd tycker jag, det är den här kategorin människor som ska ta del av leveransen och jag tycker det känns orimligt att teamet inte ska interagera med dem.

Artefakter

• Produktbacklogg: "Produktbackloggen är en ordnad lista över allt som kan komma att behövas i produkten. Det är den enda källan till krav för ändringar som ska göras i produkten. Produktägaren är ansvarig för produktbackloggen inklusive dess innehåll, åtkomst och ordning..." (Från Scrumguiden.) Att ha en ordnad lista med krav tycker jag är en bra idé. Problemet här, tycker jag, är att produktägaren hela tiden förväntas ha den i perfekt ordning. Jag funderar även på vad som händer när ett krav är utvecklat - jag skulle vilja att man pusslar in det i någon form av övergripande kravdokument för att få en överblick av vad produkten kan göra. Scrum verkar istället ha lite slit-och-släng över krav: deras mål är att man utvecklar.
• Iterationsbacklogg: Notera här att jag föredrar termen iteration över det mer officiella sprint. Scrumguiden säger "Sprintbackloggen är den uppsättning av poster från produktbackloggen som valts ut för sprinten plus en plan för att leverera produktinkrementet och nå sprintmålet. Sprintbackloggen är en prognos gjord av utvecklingsteamet för vilken funktionalitet som kommer med i nästa inkrement och för vilket arbete som behöver utföras för att leverera den funktionaliteten som utgör det 'klara' inkrementet..." Typiskt här så sätter man lappar på en tavla över krav som behöver utvecklas. Något som verkligen måste förtydligas är att varje utveckling behöver följas av en lapp om hur den ska kvalitetssäkras, eller att det ingår i arbetet. Begreppen Definition av Redo och Definition av Klar är extremt viktiga när de gäller dessa mini-arbetspaket.
• Inkrement: "Inkrementet är summan av alla poster från produktbackloggen som färdigställts under en sprint och värdet av inkrementen från alla föregående sprintar. I slutet av en sprint måste det nya inkrementet vara 'klart', vilket betyder att det måste vara i användbart skick och uppfylla scrumteamets definition av 'klart'..." (Från Scrumguiden.)
• Kvarstående arbete (Burndown): Detta är inte en officiell del av Scrumguiden, men det är något som ofta förekommer. I princip handlar det om ett par steg:
  • Man uppskattar arbetet som krävs för olika arbetspaket.
  • Man fyller sprinten med en hållbar mängd arbete.
  • Man plottar sprintens kvarstående arbete över tid.
  • Med lite erferenhet och datainsamling kan man nu uppskatta teamets arbetsderivata. Detta kan vara till hjälp i nästa sprint.

Ritualer

• Releaseplanering
• Iterationsplanering, här borde Agila Testkvadranter med.
• Iteration
• Ståmöte
• Granskning
• Återblick

Kvalitet

Som jag tolkar det ser man Scrum som någon som automatiskt ska ge kvalitet. Men jag vill nog gärna se att man anstränger sig lite, kanske har lite fler grindbeslut och inte bara tror att kvalitet kommer av sig självt.

Scrumguiden innehåller ett tydligt kvalitetverktyg, och ett naturligt tillfälle för test. Jag skulle vilja fördjupa mig lite i dem och ett tillägg som jag lärde mig om i Boken Testing In Scrum.

Definition av Klar

Från scrumguiden: "När en post i produktbackloggen eller ett inkrement beskrivs som 'klart', måste alla förstå vad som menas med 'klart'. Även om detta varierar avsevärt mellan scrumteam så måste medlemmarna ha en gemensam förståelse av vad som menas med att arbetet är komplett, för att säkerställa transparens."

Varför är det viktigt med Definition av Klar? Detta är en av de viktigaste elementen i Scrum Och Kvalitet, utan den har man bara en smutsig säck med kod. Detta steg i Scrum fungerar som en kvalitetskontroll - man kan inte känna att jobbet är klart innan det är "klart". Vad det innebär att något är klart beror på typen av arbete.

En variant är att företaget definierar vad som krävs för att ett arbete ska vara klart. Risken med en sådan approach är att man tar i för mycket, definitionen blir inte anpassningsbar till alla olika slags arbeten och i slutändan kanske man helt enkelt struntar i den.

En annan approach, som en kollega i Göteborg berättade om, är att teamet definierar vad det innebär att ett arbete är klart. I deras team hade de en checklista med fem steg när det gällde ny kod:

• Koden granskad. Eller parprogrammerad. Jag tänker att IEEE 1028 och deras Metod För Formell Granskning kanske är lite overkill - men i ett säkerhetskritiskt system kanske man behöver en sådan anpassning av Scrum. Granskning är billigt och effektivt. Genom att vara två som tittar på koden så får man även en kunskapsöverföring som kan vara mycket viktigt för teamet.
• Statisk kodanalys. Jag kan bara hålla med om att det är ett bra drag. Jag berör det lite för python i en text om att One Does Not Simply Document Code och även i Testing In Visual Studio Part 1.
• Kommentarer eller dokumentation. Jag tänker att man oftare läser kod än skriver den så det är ju otroligt viktigt. Mina tankar går även till hur man ska dokumentera, i just Python är det PEP-257 som är den rådande normen. Men i andra team kan man ju tänka sig att kodkonventioner och konventioner för hur man ska kommentera eller dokumentera kan vara viktigt.
• Testat. Men hur det ska vara testat kan säkert variera. På samma sätt kan nog spårbarheten till den genomförda testningen variera.
• Versionshanterat. Man hade checkat in i vad man jobbade med i vad man nu jobbade i för system. (Jag sökte lite bland mina gamla texter i Min Blogg och hittade två gamla godingar från 2007 och 2008 när jag kikade på Bazaar Version Control och Trac Plus Subversion)

Kollegan i Göteborg hade även liknande listor för andra artefakter; dokument, releaser, buggar och så vidare.

I dagarna pratade jag med en säkerhetsmänniska på uppdraget (jag hoppas han ska bli min livlina till Q4 i Agila Testkvadranter). Vi var rörande överens om att man måste tänka på kvalitet och säkerhet tidigt i utvecklingsprocessen. Tanken vi har just nu är att mer på djupet undersöka vilken verktygslåda (eller test subprocess enligt terminologin som kommer med Software Testing Standard Iso Iec Ieee 29119) vi har. Vi vill få koll på verktygslådan, och inkludera saker som statisk kodanalys och granskning, som kanske traditionellt brukar anses vara utvecklares aktiviteter. Då kan vi för varje fall, eller arbetspaket, definiera vad som behövs innan det paketet är "klart".

Så vad är det jag säger egentligen? Jo, att man kan definera klart på många olika sätt. Till exempel:

• Vi säger att alla arbeten blir klara på samma sätt - allt ska och bör testas på samma sätt.
• Vi kan säga att varje team ska ta fram ett batteri med klardefinitioner. En för mjukvara, en för release, och så vidare. Varje definition av klar bör kunna fungera som en checklista med saker teamet står bakom.
• Ett annat sätt är att för varje arbete ta fram en lista på vad som behövs för att kunna säga att det arbetspaketet är klart (hmmm, det känns nästan som V-modellen).

Kan man tänka sig andra sätt? Ja, säkert. Huvudsaken är att man, när ett arbete är klart, kan svara på om det är "klart" eller "verkligen klart" (Ibland används termen done respektive done-done).

Apropå checklistor så är Boken The Checklist Manifesto en gudagåva för oss som gillar sådana.

Demo

I ritualen granskning (iterationsgranskning, sprintgranskning, eller sprint review) ingår det, som man kanske hör av namnet, att granska vad iterationen kommit fram till.

Definition av Redo

"Poster högre upp i produktbackloggen är vanligtvis tydligare och mer detaljerade än de längre ned. Mer precisa estimat görs baserat på den högre graden av tydlighet och detaljkännedom; ju längre ner en post finns, desto färre detaljer. De poster i produktbackloggen som kommer att sysselsätta utvecklingsteamet under kommande sprint är så små att en enskild post rimligen kan bli 'klar' inom sprintens tidsram. De poster som kan göras 'klara' av utvecklingsteamet inom en sprint anses 'redo' för att bli utvalda under en sprintplanering. Produktbackloggens poster når denna grad av transparens genom de ovan beskrivna förfiningsaktiviteterna." (Från Scrumguiden.)

Scrum och Krav

ISTQB och REQB har en agil utökning nu för tiden.

[Texten om användarberättelser...]

[Denna text skulle kunna utökas.]

Relaterade begrepp och ämnen

Scrums tre pelare

• Transparens
• Inspektion
• Anpassning

Det Agila Manifestet

Agila värden:

• individer och samspel framför metoder, processer och verktyg.
• körbar programvara framför omfattande dokumentation.
• kundsamarbete framför kontraktsförhandlingar.
• anpassning till förändring framför att följa en statisk plan.

Alla ovan nämnda saker är värdefulla, men de till vänster värderas högre än de till höger.

Agile metodens tolv grundprinciper

1. Tillfredsställa kunden med värdefull mjukvara.
2. Välkomna förändring.
3. Leverera ofta.
4. Arbeta tillsammans.
5. Motiverade individer.
6. Konversation på plats.
7. En fungerande programvara är framsteg.
8. Hållbar utveckling.
9. Förstklassig teknik.
10. Enkelhet.
11. Självorganisera.
12. Reflektera.

Se också:

• ISTQB Syllabus for Agile Tester: [3]
• REQB Syllabus for Agile Requirements Engineer: [4]
• The Scrum Guide: [5], eller [6] för svenska
• Boken Testing In Scrum, av Tilo Linz
• Svenska Wikipedia om Agil systemutveckling: [7]
• Agile Sweden: [8]

Denna sida tillhör Kategori Test (typ)