Fortsätt till huvudinnehåll

Ä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.






Kommentarer

Populära inlägg i den här bloggen

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…