lördag
mar032012
Hur man jobbar med en backlog i ett agilt projekt
lördag 3 mars, 2012 Även om agil utveckling egentligen inte är är ett testämne skulle jag ändå vilja ta upp en diskussion kring det eftersom det ändå påverkar en testares vardag ganska så mycket. Antag följande exempel på uppstart av ett nytt agilt projekt som skall utveckla ett defekthanteringsprogram:
Produktägaren sätter upp nedanstående backlog efter samtal med slutanvändare:
1. Som en medlem av teamet vill jag kunna se en lista av defekter sorterad i prioritetsordning för att kunna veta vad teamet skall korrigera härnäst.
2. Som en medlem av teamet vill jag kunna rapportera en defekt för att den skall rättas vid ett senare tillfälle.
Produktägaren tar nu ett samtal med arkitekten i teamet för att försäkra sig om att den ser bra ut. Arkitekten säger: "Jodå det ser bra ut men det är några saker till som vi behöver lägga till i backloggen innan vi kan börja jobba med dessa saker":
- Beställa, installera och sätta upp en databas för att kunna lagra defekter.
- Installera Eclipse på alla utvecklardatorer för att kunna utveckla någon kod.
- Installera och konfigurera Hibernate för att slippa skriva all SQL-kod manuellt.
"Ok, tack", säger produktägaren och funderar på hur han skall prioritera backloggen. Efter en stund inser han att han måste fråga arkitekten igen eftersom vissa av sakerna i backloggen inte riktigt är hans område.
Arkitekten säger att: "Ja, vi måste nog börja med att sätta upp Eclipse, därefter sätta upp en databas och sedan givetvis Hibernate. För att kunna lista några defekter så måste man ju kunna rapportera några defekter, så rapportera en defekt behöver komma innan man kan lista några."
Efter Arkitektens förslag ser backloggen ut så här:
1. Installera Eclipse på alla utvecklardatorer för att kunna utveckla någon kod.
2. Beställa, installera och sätta upp en databas för att kunna lagra defekter.
3. Installera och konfigurera Hibernate för att slippa skriva all SQL kod manuellt.
4. Som en medlem av teamet vill jag kunna se en lista av defekter sorterad i prioritetsordning för att kunna veta vad teamet skall korrigera härnäst.
5. Som en medlem av teamet vill jag kunna rapportera en defekt för att den skall rättas vid ett senare tillfälle.
Nu vill jag ställa en fråga till er, gott folk, är detta projektet på god väg eller finns det något som skulle kunna förbättras i deras sätt att arbeta?
Om författaren
Michel Nass är testkonsult på Inceptive med många år i branschen. Han är expert på test, testmetodik, agil utveckling och har högsta kompetens inom avancerade testverktyg.
Michel Nass är testkonsult på Inceptive med många år i branschen. Han är expert på test, testmetodik, agil utveckling och har högsta kompetens inom avancerade testverktyg.
Reader Comments (9)
Jag skulle nog vilja se ”backlog” punkt 1-4 som tasks nedbrutna från punkt 5 ”user storien: Som en medlem av teamet vill jag kunna rapportera,….
Produkt back log item nummer 5 skulle eventuellt kunna vara en ”epic” ”user storie” som i sin tur skulle behöva brytas ner ytterligare om den är för stor för att passa in i en sprint.
//Thomas Stjern
5an bör komma före 4an som du mycket riktigt skriver (men inta har översatt i listan)
Punkt 1 får varje utvecklare ta i samband med sin första task, ska inte ligga i backlogen utan kanske mer i en wiki för utvecklare.
Punkt 2 är inte kritiiskt för att gå igång med utvecklingen men bör ligga med som en task i första storyn.
Punkt 3 är inte heller kritisk utan kan ligga som en task i någon av punkterna i första sprinten
Undvik alltså att lägga arkitektuella punkter i backlogen, de får drivas av användarberättelserna. Produktägaren ska alltså kunna prioritera backlogen utan att ta hänsyn till arkitekturella krav.
/Olle Persson
Ja, du såg att jag av misstag förväxlade ordningen på item 4 och 5! Dock så tycker jag att ordningen bör vara prioriterad av produktägaren i första hand och bara i absoluta undantagsfall göra avsteg från den regeln! Det är ytterst sällan något faktiskt måste utvecklas före något annat. I detta fallet hade man lätt kunnat lägga in några exempel defekter med SQL utan att behöva ett gränssnitt.
Jag och Michel har "bråkat" lite om just den här frågan i vårat nuvarande uppdrag;-)
Jag håller med era kommentarer ovan - det som primärt ska ligga i Product Backloggen ska ha ett värde i sig och kunna förstås och prioriteras av Produktägaren. Det är oerhört viktigt.
Men jag anser också att det finns vissa undantag då det är rimligt att ha tekniska uppgifter i en Backlog.
Ett konkret exempel baserat på ovan skulle kunna vara att om det uppstår en diskussion 3 år in i framtiden om att byta till en annan O/R mapper istället för Hibernate så tycker jag att det är ett exempel på en teknisk uppgift som Produktägaren faktiskt har rätt att besluta prioritet på.
Det kanske är ett dåligt exempel pgg av att just Hibernate är en mogen produkt. Och andra sidan har jag varit med om just det scenariot, fast för en annan O/R mapper.
I det fallet rörde det sig om ett ganska stort arbete, flera personer under flera sprintar för att göra jobbet.
Vem ska fatta det beslutet?
Jag anser att Product Owner som har resultatansvar för produkten som gör det. Man behöver väga risker och fördelar och kundbehov och annat mot vartannat för att fatta ett bra beslut eftersom det är något som har stor påverkan på vad vi kan leverera under de sprintar vi gör det här tekniska arbetet.
Det är naturligtvis teamets ansvar attt förklara och sälja in varför det här tekniska arbetet borde göras.
Produktägaren fattade i det här fallet beslut om att han accepterade risker och problem med att behålla den befintliga produkten (behålla tillsvidare - det nådde aldrig tillräckligt hög prioritet för att genomföras). Det ledde till en del fortsatta problem och störningar tack vare buggar i den här 3:e parts produkten. Men produktägaren var väl medveten om att de var en konsekvens av det beslutet och accepterade det. Det fanns en risk att det skulle kunna leda till allvarliga problem, men det blev aldrig någon katastrof.
I slutändan stabiliserades produkten och problemet försvann.
Hade teamet fått bestämma hade de bytt - med stora konsekvenser för hastighet i ett flertal sprintar.
Sammanfattningsvis anser jag att det är en balansgång.
Normalläget är att produktägaren inte behöver bekymra sig om tekniska detaljer. Men det finns lägen då den som ansvarar för affären bör ha rätt att fatta beslut som har stor påverkan. Vi hade ett flertal andra scenarier av liknande dignitet där produktägaren fattade beslut (med hjälp av teamet) i prioritet mot allt annat i Backloggen.
Och om alternativen är att huvudsakligen ha tekniska uppgifter i backloggen alternativt inte några alls så ser jag andra alternativet som långt bättre, det här handlar alltså om undantagsfall.
/ Thomas Karlsson, Softhouse
Kan inte det tekniska problemet (eller undantaget) som du beskriver, Thomas, bottna i något icke-funktionellt problem som skulle kunna beskrivas i backloggen istället för lösningen? Dvs istället för att skriva den tekniska lösningen - "byta O/R mapper" istället beskriva det i stil med "öka tillförlitligheten på informationen i systemet". Lösningen för detta kanske skulle fixas med att byta O/R mapper men kunde kanske även lösas på annat sätt.
Initiativet kommer då från business sidan istället för att initieras från den tekniska sidan. Om det inte finns något problem, idag eller i framtiden, för slutanvändaren så kanske den befintliga implementationen är god nog även om utvecklarna inte är stolta över den.
Jag ser helst inte tekniska "user storys" i backloggen, men jag har själv många gånger varit frestad att lägga in dom.
Jag väljer att se 1,2,3 som saker som gör att velocityn för teamet kommer att vara låg tills dessa saker är fixade.
Under sprint planning kommer teamet kanske endast att kunna välja punkt 5 eftersom de har så mycket tekniskt som "stör".
Dock tycker jag att teamet skall vara med och berätta för product owner vilka user storys som är bäst att göra först från ett tekniskt perspektiv, men i slutändan är det upp till PO om det har betydelse för prioriteringen.
Om det är något som MÅSTE göras för att teamet skall kunna utveckla en viss User Story så skulle man även kunna baka in det i estimatet för den US.
Detta skulle jag dock använda i ett senare skede när grunden har satt sig eftersom det annars resulterar i stora förändringar i antalet points mellan olika sprintar.
Om vi t.ex inte har någon databas så måste alla stories som bygger på att man har en databas estimeras högre eftersom uppsättandet bakas in i alla dessa men så fort man har en databas så måste dessa estimeras om.
@Michel
Jag håller med om din tanke att uttrycka värdet och det som förstås av PO och andra intressenter som grundprincip.
I det här fallet (och några andra fall) tyckte vi att det blev krystat.
Problemet var att det fanns tre skäl att byta produkten:
1. Minska risk för allvarliga buggar i framtiden
2. Bli av med några befintliga buggar och störande buggar vi inte hittat workaround för
3. Göra det enklare att arbeta med utveckling (slippa göra workarounds för att parera kända buggar)
Eftersom vi efter lite funderande inte hittade ett bra sätt att på ett tydligt och konkret sätt sammanfatta detta, så "fuskade" vi med att lägga in en teknisk uppgift i backloggen (eller snarare bad PO:n göra det). Den hade förklarande kommentarer som vi försökte göra begripliga. Vi hade även ett beslutunderlag där vi tittat på vilka alternativ som fanns för att hantera problemet. Huvudalternativet (billigare i tid) fanns också i backloggen.
Risken finns väl att något som är konkret och tydligt (åtminstone för en del) ibland blir vagt och flummigt när man försöker vara för renlärig. Samma sak med User Stories, vi använde grundformatet när det kändes vettigt och när det blev krystat skrev vi något som kändes naturligt.
Generellt är det viktigaste för mig i den här frågan:
1. Bra kommunikation så alla som behöver förstår i tillräcklig utsträckning vad det handlar om - och framförallt att PO förstår tillräckligt för att fatta prioriteringsbeslut
2. Att PO får fatta beslut om prioritering av stora tekniska uppgifter som har uppenbar påverkan på sprintleveranser för att kunna väga tex risker och annat mot tex kundkrav och affärsaspekter.
Många delar inte uppfattningen att PO ska fatta den typen av beslut så jag är medveten om att jag sticker ut hakan här;-)
/Thomas
Kan hålla med om att det i det fallet kunde kännas onödigt att klä in det i en annan formulering än den rent tekniska lösningen. Även om jag dock tror att man ofta förhastar sig när man genast gör en teknisk slutsats, om man hade gått tillbaks till grundproblemet som användaren har så kan man ofta sedan hitta alternativa lösningar.
Hursomhelst så är jag dock mycket rädd för att råda "Agila" team att det är ok att stoppa in tekniska (tasks) items i backloggen. Om man vet vad man håller på med, som du och jag Thomas, så gör det förmodligen ingenting att göra ett undantag då och då men problemet uppstår när man då börjar lägga in saker som jag gav exempel på ovan utan att inse att man är ute på djupt vatten!
Om man har en sådan backlog (mitt andra exempel med 5 items) så kommer antagligen första sprinten (och kanske ett par till efter det) att bara innehålla administrativa uppgifter som att sätta upp miljöer, men de kommer inte att leverera något kundvärde till slutanvändaren. Vissa kommer tom hävda att de faktiskt levererat kundvärde eftersom de ju satt upp en del av infrastrukturen som ju ingår i kommande lösning. Har inte någon av er samma erfarenhet att detta ofta händer i många projekt som är ovana med Agila metoder?