Utvärdera processeffektivitet med värdeströmskartor
När du skapar en värdeströmskarta, eller VSM, hjälper det dig att analysera din nuvarande utgivningsprocess. Syftet med en VSM är att visuellt visa var i processen ett team skapar värde och var det finns avfall. 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 mäter sig.
Mara, som är ny i teamet, kommer att skapa en VSM som hjälper henne att förstå den befintliga processen. Med en VSM får hon en uppfattning om var teamet passar in i DevOps-mognadsmodellen. Det visar sig att mer mogna team vanligtvis släpps snabbare, med större självförtroende och med färre buggar än mindre mogna 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 början. När hon har gjort så mycket hon kan, kommer hon att dela det med 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.
Låt oss ta en titt på hennes karta.
Förstå den aktuella processen
Mara samlar teamet i mötesrummet för att presentera sin VSM.
Mara: A 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.
Vissa rullar ögonen, men Mara trycker på.
Utvecklingsprocesser
När du skapar en ny funktion börjar du 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 som säger att vi kan börja arbeta. Den här processen tar upp till tre dagar och har inget värde för kunden. Saker utan värde för kunden bör 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 i företagsnätverket för att få åtkomst till källkontrollen. Den här tiden har värde för kunden. De vill ha den här funktionen.
Testprocesser
När vi har bestämt 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 henne två dagar att bli meddelad.
Amita testar bygget manuellt 
. Den här processen blir längre när kodbasen växer. För tillfället, låt oss säga tre dagar. Hon skickar sedan e-post till Andy med buggrapporter. Testning lägger inte till värde, men det är nödvändigt.
Andy måste sedan ta sig tid att sortera buggarna och tilldela arbete . Det kan ta ytterligare tre dagar för Andy att förstå problemen och få dem till rätt utvecklare.
Verksamhetsprocesser
När Amita godkänner ett bygge överlämnar hon det 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örproduktionsmiljön och köra några tester. Även om distribution till förproduktion inte ger något 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 träffas och granska versionen.
Så småningom distribuerar Tim funktionen, och den når 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ärdemå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 ta sig till kunden. Här är den totala tiden 22 dagar. Processtid ä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.
Det aktivitetsförhållande är förhållandet mellan processtid och total ledtid.
$${Aktivitetskvot\ =\ }{\dfrac{Procestid}{Total\ ledtid}}$$
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 indikerar större effektivitet.
Byt ut våra nummer så får vi:
$${Aktivitetskvot\ =\ }{\dfrac{5\ dagar}{22\ dagar}}{\ =\ ,23}$$
Multiplicera resultatet med 100 så får du 23%.
Som ni ser har vi mycket utrymme för förbättringar. Att det tar 22 dagar att utveckla en funktion är för lång tid.
Tim: Så hur hjälper det oss?
Vart ska vi härifrån?
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 att vi verkligen kan förbättra vår effektivitet genom att anta 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 släpper våra nuvarande processer, men jag tror att vi kan arbeta mot en effektivare process i små steg utan att störa det vi för närvarande har på plats.
Låt oss titta på några områden där vi kan förbättra oss.
Andy: Vi kan lika gärna börja från början. Det tar lång tid för mig att få en etikett på koden så att vi kan starta den nya funktionen. Jag måste gå runt till utvecklarna och be dem att checka in vad de har så att vi kan bygga och testa. Om du kan komma på hur du ska påskynda det, får du min uppmärksamhet.
Dessutom märkte jag att du inte har tid där inne för själva bygget. Det tar en halv dag just nu. Det skulle vara trevligt att se att tiden förbättras.
Amita: And 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 dessa problem.
Andy: Vi har inte tid att ändra processen nu. Du hörde Irwin. Vi är i krisläge här!
Mara: jag förstår. Nu ska vi göra det vi alltid gör. Men vi kan alla tänka på vår del i processen och hur vi kan förbättra oss. Vi kan börja göra små ä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 kartan och prestandamåtten. Om vi börjar använda Azure DevOps-metoder kan vi gå tillbaka till siffrorna. Vi kanske kan uppdatera VSM någon gång.