Valutare l'efficienza dei processi con le mappe dei flussi di valori
Quando si crea una mappa di flusso del valore, o VSM, è possibile analizzare il processo del ciclo di rilascio attuale. Lo scopo di un VSM è quello di mostrare visivamente dove nel processo un team crea valore e dove c'è spreco. L'obiettivo è arrivare a un processo che fornisca al cliente il massimo valore con il minimo spreco. Un VSM consente di individuare le aree che non contribuiscono ad alcun valore o che riducono effettivamente il valore del prodotto.
Vediamo come Tailspin misura le misure.
Mara, il nuovo team, creerà un VSM per aiutarla a comprendere il processo esistente. Con un VSM, otterrà un'idea del punto in cui il team si inserisce nel modello di maturità DevOps. Man mano che si scopre, i team più maturi in genere rilasciano più velocemente, con maggiore fiducia e con meno bug rispetto ai team meno maturi.
Mara sa di non aver ancora capito bene tutto, quindi creerà una VSM rapida sulla lavagna nella sala riunioni. Ci saranno alcune lacune e domande senza risposta, ma è normale. È un inizio. Quando ha fatto tutto il possibile, lo condividerà con il team. La VSM fornirà a tutti un punto di partenza comune per identificare i primi passaggi per migliorare il modo in cui Tailspin sviluppa e rilascia i siti Web.
Diamo un'occhiata alla sua mappa.
Comprendere il processo corrente
Mara raccoglie il team nella sala riunioni per presentare il suo VSM.
Mara: Un VSM ci aiuta a misurare dove un processo ha valore per il cliente e dove sta consumando tempo senza produrre alcun valore. La mappa inizia in alto a sinistra con la specifica funzionale per il software. Seguiremo solo una funzionalità per vedere come si muove attraverso il ciclo di rilascio attuale.
Alcune persone rotolano gli occhi, ma Mara preme.
Processi di sviluppo
Al momento la creazione di una nuova funzionalità inizia con la creazione di un'etichetta nel controllo del codice sorgente 
. Abbiamo una persona che può creare etichette, ed è Andy. Richiediamo un'etichetta tramite posta elettronica. Usiamo un sistema di controllo della versione centralizzato, quindi Andy attende che tutto il codice esistente sia sincronizzato e stabilizzato prima di creare l'etichetta. Dopo aver creato l'etichetta, viene inviato un messaggio di posta elettronica che indica che è possibile iniziare a lavorare. Questo processo richiede fino a tre giorni e non ha alcun valore per il cliente. Le cose senza valore per il cliente devono richiedere il minor tempo possibile.
La creazione di codice di una funzionalità richiede circa quattro giorni per una persona dopo aver ottenuto l'accesso a tutti i file necessari 
. Dobbiamo trovarsi nella rete aziendale per accedere al controllo del codice sorgente. Questa volta ha valore per il cliente. Vogliono questa funzionalità.
Processi di test
Quando riteniamo di avere una build stabile, aggiorniamo un foglio di calcolo per comunicare ad Amita che è disponibile una build pronta per il test e le indichiamo dove trovarla 
. Ci vogliono due giorni per ricevere una notifica.
Amita testa manualmente la build 
. Questo processo diventa più lungo man mano che aumenta la codebase. Per il momento, diciamo tre giorni. Poi invia un messaggio di posta elettronica a Andy con segnalazioni di bug. Il test non aggiunge valore, ma è necessario.
Andy deve quindi prendersi del tempo per valutare i bug e assegnare il lavoro . Possono essere necessari altri tre giorni per Andy per comprendere i problemi e portarli agli sviluppatori giusti.
Processi operativi
Quando Amita approva una costruzione, la consegna a Tim. Tim deve distribuire la build ai server di pre-produzione per un ulteriore test. Spesso, i server di pre-produzione non sono sincronizzati con le patch e gli aggiornamenti più recenti necessari per eseguire il sito Web. Per la distribuzione alla pre-produzione e l'esecuzione di alcuni test a Tim servono circa due giorni. Anche in questo caso, benché la distribuzione alla pre-produzione non aggiunga alcun valore, è necessaria 
.
Dopo che una compilazione è pronta per la produzione, la leadership deve approvare la versione prima di poter essere distribuita. L'approvazione avviene in una riunione. Ci vogliono quattro giorni per ottenere la leadership per incontrare e rivedere il rilascio.
Infine, Tim distribuisce la funzionalità che diventa disponibile per il cliente, qui nell'angolo superiore destro della VSM. Se la configurazione del server di produzione è stata spostata e quindi non è sincronizzata con la pre-produzione, Tim deve prima aggiornarla e questa operazione richiede un giorno 
.
Calcolare le metriche dei valori dei clienti
A questo punto è possibile esaminare le metriche delle prestazioni chiave e vedere come si misurano.
Il lead time totale è il tempo necessario per una funzionalità per renderla al cliente. In questo caso, il tempo totale è di 22 giorni. Il tempo di elaborazione è il tempo dedicato a una funzionalità che ha valore per il cliente. In questo caso, il tempo di processo include quattro giorni per la codifica più un giorno per distribuire la funzionalità, che fornisce un totale di cinque giorni.
Il rapporto attività è il tempo di elaborazione diviso per il lead time totale:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
Questa è la nostra efficienza. Moltiplicare l'efficienza per 100 per ottenere una percentuale. Il risultato è maggiore di 0% e in genere minore del 100%. Una percentuale più elevata indica una maggiore efficienza.
Sostituire i numeri e ottenere:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
Moltiplicare il risultato per 100 e ottenere il 23%.
Come si può notare, abbiamo un sacco di spazio per migliorare. E la durata di 22 giorni per sviluppare una funzionalità è troppo lunga.
Tim: Allora come ci aiuta?
Dove andiamo da qui?
Mara: Aiuta a vedere dove siamo ora in modo da poter individuare le aree in cui ci sono rifiuti. Si vuole ridurre al minimo il tempo trascorso che non ha alcun valore per il cliente. Credo che possiamo davvero migliorare la nostra efficienza adottando un approccio DevOps. Per un motivo, possiamo automatizzare molti di questi passaggi e questa operazione ridurrà definitivamente il tempo.
Non sto suggerendo di eliminare i nostri processi attuali, ma penso che possiamo lavorare verso un processo più efficiente in piccoli incrementi senza interrompere ciò che abbiamo attualmente in atto.
Esaminiamo solo un paio di aree in cui possiamo migliorare.
Andy: Potremmo anche iniziare all'inizio. Ci vuole molto tempo per ottenere un'etichetta sul codice in modo da poter avviare la nuova funzionalità. Devo andare in giro per gli sviluppatori e chiedere loro di controllare cosa hanno in modo da poter compilare e testare. Se riesci a capire come velocizzare questo, avrai la mia attenzione.
Inoltre, ho notato che non hai tempo in lì per la compilazione stessa. Ora ci vuole mezza giornata. Sarebbe bello vedere che il tempo migliore.
Amita: E lo sviluppo non aggiorna sempre il foglio di calcolo per segnalarmi che c'è una nuova compilazione che richiede test. Sarebbe possibile risparmiare tempo se ci fosse un modo per assicurarsi che la parte venga eseguita.
Mara: Ottimo! Credo che DevOps possa aiutarci a risolvere tutti questi problemi.
Andy: non abbiamo tempo per modificare il processo ora. Hai sentito Irwin. Siamo in modalità crisi qui!
Mara: Capisco. Per ora, facciamo quello che facciamo sempre. Ma possiamo tutti pensare alla nostra parte nel processo e al modo in cui possiamo migliorare. È possibile iniziare a apportare piccole modifiche in parallelo ai processi correnti. Ciò ci consentirà di capire se DevOps ci aiuterà senza compromettere ciò che abbiamo. Manterrà questa mappa e le metriche delle prestazioni. Se si adottano le procedure di Azure DevOps, è possibile rivedere i numeri. Forse è possibile aggiornare vsm a un certo punto.