Tillbaka till bloggen
De dolda fördelarna med aktivitets- och tidsspårning för en DevOps-transformation
Continuous Delivery och DevOps är kanske de viktigaste trenderna inom programvaruteknik under de senaste 10 åren, och utvecklare har alltid älskat automatisering av repetitiva uppgifter som deployments och releaser.
Vem uppfann dessa metoder?
Som med alla bra saker inom programvaruteknik uppfanns inte DevOps-metoderna av en enda individ.
Alla bästa metoder är ett resultat av lagarbete och utveckling genom experiment och förbättringar av dussintals team i olika organisationer.
Den klassiska boken för att förstå kärnan i DevOps är boken "Continuous Delivery". En av de mest intressanta berättelserna från boken är utvecklingen mot kontinuerlig leverans av HP LaserJet-programvaruutvecklingsteamet. Den fantastiska DevOps-omvandlingen av HP LaserJet Firmware Team (Gary Gruver) - IT Revolution
Omvandlingen började med en enkel och utmanande fråga:
Hur kan vi förbättra produktiviteten och leverera nya värden till användarna?
En enkel fråga gav teamet ett tydligt uppdrag och satte igång en avancerad experimentprocess för att förbättra produktiviteten.
Teamet utvecklades genom en Kaizen-process med stegvisa förbättringar över tid, vilket ledde till en process som är mycket lik stereotypen för DevOps.
Hur genomför man stegvisa förbättringar för att skapa en högeffektiv organisation?
Det finns tre grundläggande steg för att skapa ett högproduktivt team och automatisera repetitivt arbete:
Slutmålet är att öka leveransflödet av funktioner som kan påverka verkliga användare och samtidigt minska aktiviteter som inte skapar nytt värde.
Det första steget mot Continuous Delivery liknar ett skalbarhetstest eftersom vi mäter baslinjeprestanda genom detaljerad spårning för att förstå vilka typer av aktiviteter som blockerar värdeskapandet och leveransflödet inom teamet.
Det vi vill få fram är insikter som "Vi lägger 24% av vår tid på att åtgärda buggar" eller "Endast 30% av vårt team arbetar med nya funktioner"
Vi skulle lätt kunna dra slutsatsen att vissa typer av aktiviteter skapar omkostnader för teamet och kvantifiera den tid som läggs på dessa aktiviteter. Målet är att öka värdeproduktionen och minimera overhead och tidsåtgång för mindre viktiga aktiviteter.
Detta kallas aktivitetsspårning och kan vara en av de smartaste sakerna ett team kan göra för att optimera kontinuerlig leverans och flöde av nytt värde genom systemet och samtidigt minimera aktiviteter som minskar värdeskapandet (t.ex. support, underhåll etc.).
Sanningen är att det inte går att spåra aktiviteter utan att spåra tid.
Jag skulle vilja påstå att det är omöjligt att uppnå det som HP LaserJet-teamet gjorde utan att ha ett grundläggande arbetsfördelningsdiagram. Detta diagram kan inte beräknas korrekt utan detaljerad tidsuppföljning av aktiviteter.
Även om de flesta utvecklare anser att tidsregistrering är en ond och onödig aktivitet, kan det trots allt vara användbart för en sak ;)
När du har följt upp tiden för teammedlemmarna under en period kan du sammanställa ett diagram över arbetsfördelningen som ser ut så här:
När du har en tydlig mätning är nästa steg att sätta upp mål och börja med stegvisa förbättringar.
Att sätta upp SMART-mål är den viktigaste delen av den här processen eftersom vi måste veta vad det är för slutmål vi vill nå.
Jag anser att OKR är ett bra ramverk för att sätta upp mätbara mål.
Ett exempel på ett OKR kan vara:
Du kommer att märka att nyckelresultatet har en siffra (5%) och ett datum (Q3 2018), vilket gör det mätbart.
OKR kan vara det bästa verktyget för att fokusera teamet på att förstå vad som är målbilden och möjliggöra en smart experimentprocess.
Med ett tydligt mål kan du skapa uppgifter och deluppgifter för att uppnå slutresultatet.
En bra experimentprocess är inte normativ. Det finns ett slutmål, men aktiviteterna för att komma fram till en lösning är i hög grad öppna.
Oavsett process är det viktigt att genomföra Kaizen och stegvisa förbättringar mot slutmålet genom att snabbt lära sig och anpassa sig över tid.
Detta innebär att ett viktigt krav för experiment är autonomi för att göra experiment som påverkar KPI:erna, men också att ha en mätprocess för att kunna avgöra om det finns en förbättring eller inte.
Hur kan vi mäta exakt om vi har förbättrat oss i riktning mot vårt mål?
Återigen, vi behöver tidsspårning.
Om vår baslinjemätning av tid som läggs på "felsökningsaktiviteter" kan vara 25% och vårt mål är 5%, kan vi besluta att genomföra ett experiment för att göra mer parprogrammering i teamet under buggfixnings-/stabiliseringssprintar baserat på en hypotes om att det kommer att förbättra KPI.
När vi har kört det här experimentet kan vi extrahera tidsspårningsdata för att mäta om vi uppfyllde målvillkoret.
Resultatet kan bli att vi minskade tiden för felsökning till 14%.
När vi förstår att vi inte har uppfyllt målvillkoren kan vi samla in insikter och utforma nästa experiment.
Detta är ytterligare ett exempel på datainformerat beslutsfattande, där man förespråkar att data ska finnas tillgängliga före planering, prioritering och genomförande för att fatta bättre beslut.
Det är samma metodik som ligger till grund för bra metoder som Lean Startup, Design Thinking, A/B-testning etc. Data är den viktigaste tillgången för att fatta bättre beslut.
Nästa gång du tycker att tidrapportering är av ondo, kom ihåg att alla stora saker börjar med en mätning.
"Du kan inte styra det du inte kan mäta." - Peter Drucker