Esplorare il miglioramento continuo

  • 5 minuti

Il miglioramento continuo è una delle otto funzionalità della tassonomia di DevOps.

Perché il miglioramento continuo è necessario

Il miglioramento continuo implica e richiede la misurazione. Come è possibile identificare i miglioramenti se non si misura?

Il report di Forrester Faster Software Delivery Will Accelerate Digital Transformation (L'accelerazione del recapito di software velocizzerà la trasformazione digitale), pubblicato nel 2017, mostra una perdita significativa tra il lead time e il tempo di elaborazione. Questo serve da promemoria del fatto che se non si misura non si conosce la differenza, né le perdite generate dall'organizzazione.

Dopo aver misurato l'effetto sul processo di perdite specifiche, diventa facile definire le priorità degli interventi per apportare miglioramenti.

Il diagramma mostra uno spreco significativo tra il lead time di 123 giorni e il tempo di processo di 39 giorni. Si tratta di un tempo di attesa di 84 giorni.

Fonte: Forrester, Faster Software Delivery Will Accelerate Digital Transformation (L'accelerazione del recapito di software velocizzerà la trasformazione digitale), 9 marzo 2017, di Diego lo giudice, Christopher Condo con Christopher Mines, Luis Deya

Ma come è possibile migliorare l'esperienza dei clienti se non si misura? La ricerca di Forrester ha dimostrato che "una piccola sovrapposizione tra le funzionalità testate e quelle usate indica che gli sviluppatori hanno bisogno di una migliore comprensione dei clienti". La sovrapposizione tra le funzionalità dell'applicazione testate e quelle usate è di circa il 35%.

Il diagramma mostra che è presente solo una sovrapposizione del 35% tra le funzionalità testate e quelle usate.

Come è possibile creare il software corretto se non si misura l'utilizzo e l'impatto delle nuove funzionalità? Con una probabilità del 65% di sbagliare, è fondamentale conoscere la differenza.

Che cos'è il miglioramento continuo?

L'osservazione continua e senza pregiudizi del processo DevOps consente ai team di identificare i possibili punti di miglioramento.

Tutti i miglioramenti richiedono cambiamenti, ma non tutti i cambiamenti sono miglioramenti. Ecco perché la misurazione è un fattore di successo fondamentale per le organizzazioni che usano DevOps. Come afferma Peter Drucker, "se non si può misurare, non si può migliorare".

La mancanza di un meccanismo di feedback efficace rende difficile migliorare l'impatto delle app sulle attività aziendali. Ecco perché è importante creare un ambiente che promuova un approccio incentrato sull'apprendimento per il miglioramento di DevOps, con particolare attenzione agli adeguamenti basati sui dati. Il diagramma mostra che è consigliabile usare la misurazione e l'impatto per generare miglioramenti. La misurazione dovrebbe comportare una modifica positiva del comportamento. Le organizzazioni devono evolversi in una pratica di apprendimento continuo e feedback per creare un miglioramento continuo sulle prestazioni di distribuzione del software.

Misurazione e metriche

Prima di tutto, si prenda la misurazione. Secondo il libro Accelerate di Nicole Forsgren, Jez Humble e Gene Kim, le quattro misurazioni più importanti per le prestazioni di recapito del software sono:

  • Lead time della modifica: una misurazione della tempistica delle prestazioni di recapito del software. Tempo necessario per passare dal codice di cui è stato eseguito il commit al codice eseguito nell'ambiente di produzione
  • Frequenza di distribuzione: una misurazione diretta o indiretta del tempo di risposta, della coesione del team, delle funzionalità degli sviluppatori, dell'efficacia degli strumenti di sviluppo e dell'efficienza complessiva del team DevOps.
  • Tempo medio di ripristino: il tempo impiegato in genere per ripristinare un'app o un servizio primario quando si verifica un evento imprevisto del servizio.
  • Percentuale di errori di modifica: la percentuale di modifiche all'ambiente di produzione (incluse, ad esempio, le versioni del software e le modifiche alla configurazione dell'infrastruttura) che non riescono.

È responsabilità della leadership di DevOps misurare elementi come metriche di integrità delle operazioni, utilizzo, velocità e integrità del sito live. In altre parole, misurare l'IMPATTO, non l'ATTIVITÀ. Una metrica è utile solo se è implementabile.

Sebbene i team Scrum misurino la capacità del team, la velocità del team, il burn-down e il numero di bug, queste metriche sono rilevanti solo nel contesto del team. Tuttavia, è importante che la leadership di DevOps rimanga concentrata sull'impatto.

Importante

Misurare l'impatto, non l'attività.

Cosa si misura:

Utilizzo

Velocità

Integrità del sito live

  • Acquisizione
  • Interazione
  • Soddisfazione
  • Abbandono
  • Utilizzo delle funzionalità
  • Tempo per la creazione
  • Tempo per il test interno
  • Tempo di distribuzione
  • Tempo per l'apprendimento
  • Tempo per il rilevamento
  • Tempo per la comunicazione
  • Tempo per la mitigazione
  • Impatto sul cliente
  • Elementi di prevenzione degli eventi imprevisti
  • Problemi di invecchiamento del sito live
  • Contratto di servizio per ogni cliente
  • Metriche del supporto tecnico

Aspetti non osservati:

  • Stima originale
  • Ore completate
  • Righe di codice
  • Capacità del team
  • Burn-down del team
  • Velocità del team
  • Numero di bug rilevati

Importante

Metriche che influiscono sui risultati.

L'allineamento degli indicatori KPI con le abitudini è importante. Aiuta a ottenere risultati aziendali positivi.

Le abitudini importanti per rafforzare gli indicatori KPI e preparare i team al successo devono includere:

  • Autonomia del team e allineamento organizzativo: cosa, come e perché si crea. Per consentire alla leadership e ai team delle funzionalità di collaborare in modo trasparente ed efficace, è necessaria una cadenza comune, o un "battito cardiaco", nell'intera organizzazione.
  • Attenzione al cliente: tutti gli sforzi devono avere un impatto diretto o indiretto sul valore del cliente.
  • Mentalità incentrata sulla produzione: una mentalità che non fa distinzioni nella gestione delle funzionalità e dei bug durante lo sviluppo, il test e il supporto operativo. Tutto dovrebbe essere automatizzato, controllato e ottimizzato nell'ambiente di produzione.
  • Shift left della qualità e risposta rapida agli errori: incoraggiare revisioni, convalide e approvazioni sia dei test che della sicurezza il prima possibile nel ciclo di recapito delle funzionalità per promuovere una mentalità orientata alla qualità e una rapida risposta agli errori.

Il diagramma mostra la relazione tra metriche, indicatori KPI, abitudini e risultati aziendali. Le metriche supportano gli indicatori KPI, che devono essere allineati alle abitudini per ottenere i risultati aziendali. Gli esempi KPI includono lead time, frequenza di distribuzione, tempo medio per il ripristino e frequenza di errori di modifica. Questi indicatori KPI devono essere allineati alle abitudini, ad esempio l'autonomia del team e l'allineamento dell'organizzazione, l'attenzione al cliente, la mentalità orientata alla prima produzione e il cambio di qualità a sinistra e veloce. Questo allineamento consente di ottenere risultati aziendali come un time-to-market più rapido, una qualità superiore, meno rifiuti e sicurezza end-to-end.

Feedback continuo

Ora si consideri come usare il feedback continuo per la collaborazione.

I moderni sviluppatori di app più famosi provengono da startup. Perché hanno così tanto successo? Poiché le loro procedure snelle non sono appesantite da anni di processi perfezionati.

Le startup snelle hanno stabilito un percorso ottimale per sviluppare, recapitare e perfezionare le idee, creando una cultura di feedback continuo incredibilmente positiva:

  • Rilasciare presto e spesso
  • Iniziare con un prodotto minimo funzionante
  • Usare lo sviluppo guidato da ipotesi
  • Miglioramento continuo sulla base del feedback dei clienti

Il diagramma mostra il ciclo di feedback continuo. Si inizia con idee, si compila il codice e si misurano i risultati per raccogliere i dati. La data ci aiuterà a imparare e generare nuove idee. Il feedback continuo riduce al minimo il tempo totale attraverso il ciclo.

Miglioramento continuo attraverso il mapping del flusso di valore

Quando si hanno misurazioni e feedback, il miglioramento diventa un esercizio guidato dai dati.

Un modo efficace per supportare il miglioramento continuo è offerto dal mapping del flusso di valore. Un flusso di valore è una sequenza di attività svolte da un'organizzazione per soddisfare la richiesta di un cliente.

Il mapping del flusso di valore è un modo estremamente efficace per imparare a individuare e risolvere le disconnessioni, le ridondanze e i gap nel processo. Non si tratta semplicemente di uno strumento, ma di una metodologia basata sul team che costituisce la base di una procedura di gestione collaudata.

L'analisi del flusso di valore consente di suddividere il processo di recapito e misurare il lead time, il tempo del ciclo e il tempo di inattività, il che consente ai team di adeguare il flusso di lavoro in base ai dati.

Queste misurazioni consentono ai team di pianificare, individuare le variazioni di efficienza e identificare potenziali problemi del processo.

Il diagramma mostra le fasi del processo di recapito. Il lead time è il tempo totale in tutte le fasi. Il tempo di inattività è il tempo tra due fasi. Il tempo di elaborazione o ciclo misura la durata di una fase.

Suggerimento

Minore è il lead time e il tempo del ciclo, più veloce sarà la velocità effettiva del team.

È necessario essere in grado di identificare la differenza tra operazioni non necessarie che non aggiungono valore e operazioni necessarie che non aggiungono valore per identificare le modifiche future per il miglioramento del processo.

Le operazioni non necessarie che non aggiungono valore sono lo spreco vero: il cliente non trae alcun valore e l'organizzazione non ne ha bisogno continuare a funzionare. Consumano risorse senza aggiungere alcun valore al prodotto.

Il diagramma mostra che il lead time include tempo di elaborazione che non aggiunge valore sia non necessario che necessario, oltre a tempo di elaborazione che aggiunge valore.

DevOps guidato dai dati: le metriche guidano il percorso

La trasformazione con DevOps è un percorso, e il modo migliore e più efficace per ricevere una guida attraverso il percorso DevOps è DevOps basato sui dati.

Il diagramma mostra il flusso del percorso DevOps. I team iniziano la trasformazione e identificano le vittorie rapide. L'automazione aiuta gli utenti con prestazioni basse a eseguire prestazioni medie. L'automazione aumenta i requisiti di test, che vengono gestiti manualmente. Una montagna di debiti tecnici blocca i progressi. Il debito tecnico e la maggiore complessità causano controlli manuali aggiuntivi e livelli di processo intorno ai cambiamenti, rallentando il lavoro. Il lavoro di miglioramento implacabile porta all'eccellenza e alle prestazioni elevate! I performer di alto livello e elite sfruttano le competenze e imparano dai loro ambienti per vedere i salti della produttività.

Si consiglia di definire un approccio olistico per misurare l'efficacia di DevOps e dare trasparenza alle iniziative di trasformazione di DevOps. Creare una cultura che promuova l'apprendimento e la sperimentazione richieste da DevOps concentrandosi sulle metriche che evidenziano il successo. Riconoscere questi successi celebrando i comportamenti corretti anziché punire quelli sbagliati.