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.

Diagram shows significant waste between the lead time of 123 days and the process time of 39 days. This amounts to a wait time of 84 days.

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%.

Diagram shows there is only a 35% overlap between features being tested and those being used.

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. Diagram shows that we should use measurement and impact to generate improvement. The measurement should lead to a positive behavior change. Organizations should evolve to a practice of continuous learning and feedback to create Continuous Improvement on software delivery performance.

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.

Diagram shows the relation between metrics, KPIs, habits and business outcomes. Metrics support KPIs, which should align with habits to achieve the business outcomes. KPI examples include lead time, deployment frequency, mean time to restore, and change fail rate. These KPIs should be aligned to habits like: team autonomy and organization alignment, customer focus, production-first mindset, and shift quality left and fast. This alignment helps achieve business outcomes like a quicker time to market, higher quality, less waste, and end-to-end security.

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

Diagram shows the cycle of continuous feedback. We start with ideas, build the code, and measure results to collect data. The date will help us learn and generate new ideas. Continuous feedback minimizes the total time through the loop.

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.

Diagram shows the stages of the delivery process. Lead time is the total time on all stages. Idle time is the time between two stages. Process or cycle time measures the duration of a stage.

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.

Diagram shows that lead time includes unnecessary and necessary non-value-adding process time, as well as value-adding process time.

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.

Diagram shows the flow of the DevOps journey. Teams begin transformation and identify quick wins. Automation helps low performers progress to medium performers. Automation increases test requirements, which are dealt with manually. A mountain of technical debt blocks progress. Technical debt and increased complexity cause additional manual controls and layers of process around changes, slowing work. Relentless improvement work leads to excellence and high performance! High and elite performers leverage expertise and learn from their environments to see jumps in productivity.

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.