Är vi klara snart, eller?

Vad betyder det egentligen att vara klar med något? Det är svårt att komma överens om det, eftersom vi har olika mål, perspektiv och behov. En begriplig och gemensam definition av vad det innebär att vara klar med en ny funktion kan göra utvecklingsarbetet både effektivare och mindre frustrerande för alla inblandade.

Utvecklare tycker ibland att arbetet är klart när de funktioner som efterfrågats finns implementerade i kod. Testare brukar vilja fylla i med att funktionerna måste vara testade också. Folk i supporten brukar lägga till att buggarna man hittade under test gärna får vara lösta innan man levererar ut funktionen till användarna. Nyanställda utvecklare brukar gräma sig över att den kod som skrevs innan man själv började är så grötigt skriven att det nästan är omöjligt att sätta sig i den. Därför vill de lägga till att koden ska vara snyggt skriven och väl designad.

Scrums definition på att vara klar med något är ganska krävande. De flesta organisationer får jobba länge på att lära sig nå upp till Scrums klarkriterium.

I Scrum är en funktion klar när:

• Funktionen fungerar som den ska för användaren, som därför kan använda den nya funktionaliteten för att uppnå sina mål och lösa sina problem.
• Den är implementerad i välskriven kod som går att jobba vidare med.
• Vi har testat funktionen så att vi kan göra ett tryggt uttalande om produktkvaliteten.
• Buggar som vi hittat under testningen har fixats inom ramen för sprinten (”what happens in the sprint stays in the sprint”) och behövs det användardokumentation har vi tagit fram den med.
• Dessutom har funktionen de kvaliteter som vi förväntar oss av den, när det gäller till exempel snabbhet och säkerhet.
• Det enda sättet att uppnå Scrums krävande klardefinition sprint efter sprint är att bryta ned arbetet i små fristående delar, och utveckla delarna en i taget.

Målet är att varje sprint ska sluta med potentiellt levererbar produkt.

Potentiellt levererbar betyder att om vi skulle vilja leverera produkten till användarna, så skulle vi kunna göra det. Det betyder inte att vi alltid gör en leverans till användarna efter varje sprint. Ibland väntar vi med leveransen av affärsmässiga skäl. Några sådana skäl kan vara att:

• Vi vill invänta mer funktionalitet för att produkten ska bli mer komplett
• Vi inte vill tynga användarna med att lära sig ny funktionalitet för ofta
• Vi vill synkronisera leveransen med marknadsaktiviteter

I praktiken är det oerhört utmanade att utveckla potentiellt leverbar produkt i varje sprint. Att vara klar i Scrum är kräver ett dubbelt fokus: dels behöver vi samsyn om hur slutmålet ser ut, dels behöver vi samsyn kring hur utvecklingsarbetet ska genomföras. Med andra ord: vi behöver både tydliga krav och en gemensam utvecklingsprocess.

Oklart arbete: kraven
När det är svårt för utvecklingsteamet att verkligen bli klara med något i sprinten kan det tyda på att vi lyfter in krav som inte är redo. I Scrum är ett krav redo när utvecklingsteamet tillsammans med produktägaren bedömer att kravet är möjligt att realisera i sprinten. Det betyder att när vi har ett stort och otydligt projekt att genomföra, så behöver vi bryta ut en liten väl definierad bit och utveckla den i sprinten. Idealet är att varje sprint slutar med att vi demonstrerar faktiskt användbar produkt, något som användaren inte kan vänta på att få lägga vantarna på.

Ett effektivt sätt att bedöma om vi har samma förväntningar på slutresultatet är att fantisera om att vi redan sitter på sprintgenomgången och får en demo av den planerade funktionaliteten. Vi berättar helt enkelt för varandra vad vi tänker oss att vi ser på demonstrationen. De detaljer som kommer upp ser vi till att fånga upp skriftligen (gärna på en whiteboard så att alla kan se). Sedan diskuterar vi tills vi är överens om vad som ska ingå i sprinten, och vad som inte ska ingå.

Oklart arbete: utvecklingsprocessen
En annan stor anledningen till att vi inte blir klara med funktionalitet vi lyfter in i sprinten är att vår utvecklingsprocess ännu inte räcker för att ta oss hela vägen från krav till potentiellt levererbar produkt under en sprint. För att lyckas med detta krävs solida utvecklarpraxis, till exempel:

• Förmågan att skapa och upprätthålla en design på kodnivå som går att jobba vidare med, utan att vara överdrivet generaliserad
• Att kunna testa med en kombination av mänsklig och automatiserad testning för att säkerställa att ny funktionalitet fungerar som den ska, samtidigt som vi har koll på att sådant som brukade fungerar inte har gått sönder nu
• En effektiv bygg- och leveransprocess som är automatiserad så långt som möjligt
• Fortlöpande integration och testning av hela produkten
• Gemensamt ansvar för den tekniska kvaliteten, så att vi inte får ”fickor” av hög eller låg kvalitet i produkten baserat på vem i utvecklingsteamet som jobbat med en viss funktion

Framgång med Scrum kräver att vi satsar på att snabbt utveckla såväl vår förmåga att arbeta effektivt med kraven, som vår förmåga att effektivt gå hela vägen från krav till potentiellt levererbar, klar, produkt under sprinten.