Per Erik Strandberg /cv /kurser /blog

http://www.pererikstrandberg.se/blog/scrum-and-quality.png

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

Artefakter

Ritualer

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:

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:

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

Det Agila Manifestet

Agila värden:

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å:


Denna sida tillhör Kategori Test (typ)