Vad kan man vilja mäta i ett utvecklingsteam och varför? Är bara den klassiska burndown-grafen relevant? Hur kan man göra det i verktyg såsom Trello? Här kommer del två om att göra livet lättare med Trello som scrumboard.
När vi började med Trello fanns det några saker jag ville mäta, som verktyget i sig inte gav någon möjlighet till. Det första var genomströmning – hur lång tid det tar från en story att gå genom flödet, från planerad till produktionssatt. Jag ville genom detta kunna visualisera var flaskhalsarna låg. Jag ville även utreda hur våra estimat egentligen stod sig mot varandra och vår uppfattning av dem. Allt detta visade sig vara möjligt genom ett script som vi byggde. För er som är nyfikna på att testa, delar jag här med mig av både mina reflektioner och själva scriptet så att ni kan börja hämta ut statistik från era Trello-boards direkt.
Genomströmning och flaskhalsar
I vårt team var vi medvetna om att vi hade flaskhalsar och att vissa stories tog lång tid från planering till produktionssättning, men det var lite otydligt var och hur. På den fysiska tavlan ritade jag streck för varje dag en story låg i en viss kolumn, men det var knepigt att skilja på alla olika kolumner och det blev inte så tydligt eller tillgängligt. Förutom de självklara listorna “att göra” och “utveckling”, har vi en komplex värld med många olika stadier med olika personer inblandade, såsom kravavstämningar, acceptanstest och integrationstester. Därmed finns också många olika delar att skylla på.
Estimat och story points
Det är alltid farligt att börja prata tid i samband med estimat. Story points ska vara komplexitetspoäng och inte en översättning av arbetstimmar – absolut. Dock anser jag att en story som är flera veckors jobb är för stor och dåligt nedbruten. Om den har en rimlig storlek men ändå tar flera veckor, finns det förmodligen hinder som inte är tillräckligt tydliga och måste åtgärdas.
Det fanns en osäkerhet i teamet angående hur bra estimaten var. Vissa stories kunde ta väldig tid och andra kunde genomföras snabbt, på grund av helt andra faktorer än den faktiska utvecklingstiden, vilket eventuellt påverkade estimaten.
Det fanns tre intressanta saker att hämta ut ur Trello och möjligheten fanns via deras API. Jag tog hjälp och sällskap av min kollega (och bästa vän) Johan Östling, och så satte vi igång och klurade och kodade.
Teknik och magi
När vi började använda Trello hittade jag ett Google Docs-skript som importerade stories från ett kalkylark till Trello. Det var fantastiskt tidssparande att importera alla våra stories till Trello istället för att behöva lägga in dem manuellt. Jag hittade även ett skript som hämtade ut alla stories till ett kalkylark för backup. Det gjorde att jag visste att det gick att anropa Trellos API via ett dokument i Google Drive och då väcktes ganska snabbt tanken att använda samma teknik för att skapa den statistik jag ville ha, direkt i ett spreadsheet.
Faran med att mäta
Så fort skriptet fungerade så satte jag igång och mätte och sparade undan statistik från olika veckor för teamet. Vissa delar av statistiken var lite förvånande, andra delar var glada överraskningar. Flaskhalsarna blev mycket tydliga och statistiken kunde användas för diskussioner inom teamet och andra vi samarbetar med. Våra estimat visade sig vara fantastiskt väl avvägda i jämförelse med varandra vilket var en stor lättnad.
Det viktiga nu är att ta statistiken för vad det är och inte börja försöka optimera flödet utan en ordentlig funderare på konsekvenserna. Om vi koncentrerar oss alltför mycket på att minimera en flaskhals finns risken för att vi försöker suboptimera och istället döljer problemen någon annanstans. “Ajdå, systemtest tar evigheter, men om vi låter automattesterna vara en del av utvecklingen istället?” och den vägen leder bara till vansinne, för att uttrycka det på svengelska. Det finns spaltmeter skrivna om suboptimering och faran med att mäta och försöka göra framsteg utan analys, så det är inget jag kommer att gå in på här förutom denna försiktiga varning.
Mitt mål är inte att slänga upp de här graferna en gång i veckan och försöka mäta någon sorts diffusa framsteg utan istället då och då slänga en blick på dem och se vad som händer och upptäcka förändringar – både medvetna och omedvetna.
Om du vill prova skriptet så är det delat med världen här i form av ett Google Docs-kalkylark. Ingen programmering behövs, det är bara att ta en kopia och börja fylla i efter instruktionerna nedan och i dokumentet.
Att använda skriptet
I dokumentet finns ett blad vid namn Control där du kan göra dina inställningar. Du använder länkar och menyval för att hämta din Trello App key, Trello token och godkänna att skriptet får åtkomst till ditt Trello-konto och alla boards. Du får välja hur många dagar du vill skapa en rapport för, förslagsvis en sprint eller en månad (dock max 1000 actions via Trellos API).
Skriptet räknar bara tid under arbetsdagar mellan 8-18 lokal tid, vilket givetvis är konfigurerbart under Calendar-fliken, både för att ändra arbetstid och lägga till eller ta bort arbetsdagar för lokala helgdagar.
Det finns ett meny-alternativ som heter Trello script där alla funktioner anropas. Först importerar du alla händelser med “Update data” och sedan väljer du att skapa en rapport med “Create report”. Då skapas “Report Daily” och “Report summary”-flikarna med allt spännande data du kan vilja ha! Sedan är det upp till dig att tolka och skapa fina grafer för datat.
Tekniken bakom
Skriptet är skrivet i Javascript i ett Google Docs kalkylark. Genom Google Apps Engine skickas våra requests till Trellos API och allt data om de olika objekten i Trello returneras som JSON-objekt. Scriptet importerar allt som hänt sedan förra importen och sedan är det bara en fråga om att analysera datat och sortera det på olika vis.
Skripteditorn är lite dold i Google Docs, men finns under menyalternativet Tools och har de basala funktioner man kan förvänta sig. Den stora fördelen är givetvis att allt sker i molnet direkt.
Tveka inte att höra av dig med feedback eller egna erfarenheter av scriptet och statistiken, och glöm inte att vara försiktig med vilka slutsatser du drar. Lycka till!