Utvärdera processeffektivitet med värdeflödesanalyser
När du skapar en värdeströmskarta, eller VSM, hjälper det dig att analysera din aktuella versionscykelprocess. Syftet med en värdeflödesanalys är att visa var i processen ett team skapar värde och var det förekommer spill. Målet är att komma fram till en process som levererar maximalt värde till kunden med minimalt avfall. En VSM kan hjälpa dig att hitta de områden som antingen inte bidrar med något värde eller som faktiskt minskar produktens värde.
Nu ska vi se hur Tailspin gör ifrån sig.
Mara som är ny i teamet ska skapa en värdeflödesanalys så att hon bättre kan förstå den befintliga processen. Med en VSM får hon en uppfattning om var teamet passar in i DevOps-mognadsmodellen. Det har visat sig att mognare team i allmänhet släpper mer stabila versioner med färre buggar snabbare än andra team.
Mara vet att hon inte förstår allt än, så hon kommer att skapa en snabb VSM på whiteboarden i mötesrummet. Det kommer att finnas några luckor och obesvarade frågor, men det är okej. Det är en bra början. När hon har gjort så mycket hon kan ska hon visa den för teamet. VSM ger alla en gemensam utgångspunkt för att identifiera de första stegen mot att förbättra hur Tailspin utvecklar och släpper sina webbplatser.
Vi tar en titt på hennes analys.
Förstå den nuvarande processen
Mara samlar teamet i mötesrummet för att presentera sin värdeflödesanalys.
Mara: En VSM hjälper oss att mäta var en process har värde för kunden och var den äter upp tiden utan att producera något värde. Vår karta börjar längst upp till vänster med den funktionella specifikationen för programvaran. Vi följer bara en funktion för att se hur den går igenom vår aktuella lanseringscykel.
Några på mötet himlar med ögonen, men Mara fortsätter.
Utvecklingsprocesser
Skapandet av en ny funktion börjar för närvarande med att skapa en etikett i källkontrollen 
. Vi har en person som kan skapa etiketter och det är Andy. Vi begär en etikett via e-post. Vi använder ett centraliserat versionskontrollsystem, så Andy väntar tills all befintlig kod är incheckad och stabil innan han skapar etiketten. När etiketten har skapats får vi ett e-postmeddelande om att vi kan börja arbeta. Den här processen tar upp till tre dagar och har inget värde alls för kunden. Saker utan värde för kunden ska ta så lite tid som möjligt.
Kodning av en funktion tar ungefär fyra dagar för en person när vi har åtkomst till alla filer vi behöver 
. Vi måste vara inloggade i företagsnätverket för att komma åt källkodskontrollen. Den här tiden har värde för kunden. De vill ha den här funktionen.
Testprocesser
När vi har bestämt oss för att vi har en stabil version uppdaterar vi ett kalkylblad för att berätta för Amita att det finns en version som är redo för testning och var du hittar den 
. Det tar två dagar för henne att få meddelandet.
Amita testar versionen 
manuellt . Den här processen tar längre tid när kodbasen växer. Vi antar att det är tre dagar nu. Hon skickar sedan ett e-postmeddelande till Andy med buggrapporter. Testningen tillför inget värde, men den är nödvändig.
Andy måste sedan ta sig tid att sortera buggarna och tilldela arbete . Det kan ta ytterligare tre dagar för Andy att komma till botten med problemen och skicka dem vidare till rätt utvecklare.
Operativa processer
När Amita har godkänt en version lämnar hon den till Tim. Tim måste distribuera den här versionen till förproduktionsservrarna för mer testning. Ofta är förproduktionsservrarna osynkroniserade med de senaste korrigeringarna och uppdateringarna som behövs för att köra webbplatsen. Det tar Tim ungefär två dagar att distribuera till förproduktion och köra några tester. Även om distribution till förproduktion inte lägger till värde, är det nödvändigt 
.
När en version är klar för produktion måste ledningen godkänna versionen innan den kan distribueras. Godkännandet sker i ett möte. Det tar fyra dagar att få ledningen att mötas och granska versionen.
Så småningom distribuerar Tim funktionen och funktionen gör den till kunden här i det övre högra hörnet av VSM. Om konfigurationen av produktionsservern har varit osynkroniserad med förproduktion måste Tim först uppdatera den, vilket tar en dag 
.
Beräkna kundvärdesmåtten
Nu kan vi titta på de viktigaste prestandamåtten och se hur vi mäter upp.
Total ledtid är den tid det tar för en funktion att nå kunden. Här är den totala tiden 22 dagar. Processtiden är den tid som spenderas på en funktion som har ett värde för kunden. Här omfattar processtiden fyra dagar för kodning plus en dag för att distribuera funktionen, vilket ger totalt fem dagar.
Aktivitetsförhållandet är processtid dividerat med total ledtid:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
Det här är vår effektivitet. Multiplicera effektiviteten med 100 för att få en procentandel. Resultatet är större än 0 % och vanligtvis mindre än 100 %. En högre procentandel innebär högre effektivitet.
Om vi sätter in våra siffror får vi det här:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
Multiplicera resultatet med 100 så får du 23 %.
Som ni ser finns det stort utrymme till förbättring. Och 22 dagar är för lång tid för att utveckla en funktion.
Tim: Så hur hjälper detta oss?
Hur vi går vidare?
Mara: Det hjälper till att se var vi är nu så att vi kan hitta de områden där det finns avfall. Vi vill minimera den tid vi spenderar som inte har något värde för kunden. Jag tror vi verkligen kan förbättra vår effektivitet genom att använda en DevOps-metod. För det första kan vi automatisera många av dessa steg, vilket definitivt minskar i tiden.
Jag föreslår inte att vi överger våra nuvarande processer helt, men jag tror att vi kan byta till mer effektiva processer gradvis utan att störa processerna vi använder just nu.
Låt oss titta på ett par områden där vi kan förbättra oss.
Andy: Vi kan lika gärna börja i början. Det tar mig lång tid att få en etikett för koden så att vi kan komma igång med den nya funktionen. Jag måste gå runt bland utvecklarna och be dem checka in det som är färdigt så att vi kan börja bygga och testa. Om du kan komma på hur du ska påskynda det, får du min uppmärksamhet.
Dessutom tänkte jag på att du inte avsätter någon tid i analysen för själva bygget. I nuläget tar det en halv dag. Det skulle vara bra att korta ned den tiden.
Amita: Och dev uppdaterar inte alltid kalkylbladet så att jag vet att det finns en ny version som behöver testas. Det skulle spara tid om det fanns något sätt att se till att den delen blir klar.
Mara: Bra! Jag tror att DevOps kan hjälpa oss med alla de här problemen.
Andy: Vi har inte tid att ändra processen nu. Ni hörde vad Irwin sa. Det är krisläge nu!
Mara: Jag förstår. Låt oss göra som vi alltid har gjort så länge. Men vi kan alla tänka igenom vår del i processen och hur vi kan förbättra oss. Vi kan börja göra mindre ändringar parallellt med våra nuvarande processer. Vi kan sedan se om DevOps hjälper oss utan att störa det vi har. Jag behåller den här analysen och resultatmåtten. Om vi börjar använda Azure DevOps-metoder kan vi gå tillbaka till siffrorna. Vi kanske kan uppdatera värdeflödesanalysen senare.