Introduzione
Nel primo articolo della serie abbiamo iniziato a scalfire la vera anima di DevOps, evidenziando come si tratti di una sfida culturale che guarda a un approccio olistico per consentire alle aziende di confrontarsi al meglio con un mercato complesso e burrascoso.
In questo nuovo appuntamento, andremo a inquadrare DevOps rispetto all’Agile e al Lean che, come vedremo, hanno di fatto preparato il terreno alla sua comparsa. Inoltre, ci confronteremo sulle tre vie per DevOps, ossia i principi portanti che ne ispirano le pratiche operative.
Agile, Lean e DevOps: un unico ecosistema
Inquadrare in modo chiaro come Agile, Lean e DevOps si incastrino come tasselli di un puzzle rispetto all’Application Lifecycle Management è un’operazione complessa che, indipendentemente dal modello scelto, probabilmente non potrà mai essere completa o assoluta. Una possibilità di semplificazione, utile per l’approccio descrittivo che si sta usando, è quella racchiusa in figura 1.
Salta subito all’occhio come Lean sia l’elemento fondante dell’intera azione, essendo orientato all’ottimizzazione complessiva del flusso in ottica end-to-end, tanto che i framework di scaling ne declinano i principi e le pratiche in modelli specifici.
Il flow di DevOps copre quasi completamente gli stessi elementi, a esclusione di parte della fase di Envisioning: questo perché essa poco si presta ad azioni di ottimizzazione e standardizzazione, trovando nel rinnovamento continuo la sua stessa linfa vitale.
Nel cuore di DevOps troviamo elementi ricorrenti del mondo Agile e di Lean, utili a rendere l’azione efficace ed efficiente.
Non solo pratiche e strumenti
Provando a cercare qualche suggerimento in merito, in letteratura troviamo un interessante post di Sakshi Gaurav [1] che propone la sintesi di un’idea comune di DevOps rispetto all’Agile, secondo la quale: “DevOps è una pratica, laddove Agile è un processo”.
Ora, per quanto sia vero che comunemente Agile venga associato agli aspetti di sviluppo, mentre DevOps a quelli di rilascio, se si legge il tutto in chiave Lean — dove è importante ragionare in termini di Value Stream e di organizzazione complessiva e non locale — qualcosa non torna in tale schematizzazione. E anche i framework di Scaling, mixando il tutto, ne sono una dimostrazione.
Quindi, DevOps non può essere ricondotto solo a “pratiche e tool”, ma piuttosto deve essere associato a una visione complessiva che coinvolge anche team terzi — differenti da Dev e Ops — funzionali alla creazione di una soluzione consumabile, così come enfatizzato da Disciplined DevOps [2].
Tre parti di una stessa visione
Quindi è possibile affermare con convinzione che ha poco significato pratico provare a scegliere tra Agile, Lean e DevOps, ma che occorre invece maturare la comprensione che tutti e tre gli approcci sono parte di una visione complessiva indispensabile per ottimizzare l’intero flusso di creazione del valore:
- Agile è lo strumento principe per lavorare in chiave adattativa, velocizzando i feedback loop grazie a soluzioni incrementali e funzionanti. Il suo focus è relativo alla complessità e alla governance dell’incertezza, in modo da supportare cambiamenti rapidi e gestione integrata dei rischi.
- Lean è alla base di tutte le pratiche moderne di creazione di valore e ottimizzazione del flusso di lavoro. Offre un approccio olistico per rendere più efficace ed efficiente uno specifico processo o l’intera organizzazione, indipendentemente dal settore di riferimento.
- DevOps è focalizzato, più che sui soli dettagli tecnici, sulla creazione di una cultura del delivery in funzione del business.
Una sintesi operativa
L’obiettivo è l’incremento di valore e di qualità della soluzione realizzata, abbattendone tempi e costi di realizzazione grazie a strumenti ormai maturi a supportare l’automazione complessiva. Tutto ciò porta a vedere DevOps come una sintesi operativa, permettendoci di affermare che:
DevOps è la declinazione più efficace di Lean applicato al mondo delle soluzioni incentrate sulle tecnologie digitali, dove la capacità di operare in chiave Agile permette di rispondere adeguatamente ai rischi e ai cambiamenti che le caratterizzano in modo naturale [4].
Si realizza così un approccio complessivo che permette di creare un ponte per superare il “fossato”, il “Value Canyon”[4] che altrimenti verrebbe a crearsi tra le varie anime operative.
The Three Ways for DevOps
Alla luce di quanto detto finora, in che modo è possibile tracciare un percorso da seguire per raggiungere i massimi benefici relativi di una completa integrazione aziendale?
Una risposta di metodo ci viene da Gene Kim che sintetizza nelle “Three Ways” [3] un insieme di principi basilari, utili a guidare l’organizzazione nel proprio percorso di cambiamento. Non si tratta di “percorsi alternativi”, bensì di un unico viaggio composto da tre “strade” consequenziali che vanno percorse tutte per arrivare alla meta.
Un’ottima analogia è quella dello Shu–Ha–Ri, concetto delle arti marziali giapponesi che si riferisce alle fasi di apprendimento che conducono alla padronanza di una tecnica o di una materia.
Le tre vie di DevOps secondo Gene Kim
Le three ways descritte in The Phoenix Project sono riassumibili come segue.
- Flow, the first way: rendere veloce il flusso di lavoro da “sinistra” a “destra”, ossia dal business al cliente, passando per Dev e Ops.
- Feedback, the Second Way: aumentare il numero di feedback da “destra” a “sinistra”, ovvero dal cliente al business, passando per Ops e Dev.
- Learning, the Third Way: creare una cultura incentrata sull’apprendimento e la sperimentazione continua per migliorare costantemente.
The First Way
Abilitare un rapido scorrimento delle attività da sinistra a destra: passando per Development e Operations fino al cliente finale [4]
La “prima via” enfatizza la necessità di concentrarsi sull’ottimizzazione complessiva del Value Stream, cosa che non passa necessariamente per l’ottimizzazione di un silos o dipartimento specifico. Ancora una volta, si evidenzia come l’obiettivo sia quello di ottimizzare l’intero processo di creazione di una soluzione: dalla sua idea alla sua messa in esercizio.
La cosa interessante è che i singoli Work Center, i centri focali delle attività, non devono essere ottimizzati oltre il livello attuale se ciò va a scapito del processo globale, ovvero se sia ha un degrado della Value Chain.
La logica è quella “pull” del Lean: sono i Work Center a valle a dichiararsi pronti a prendere in carico una nuova attività, per cui è inutile che due Work Center adiacenti viaggino a velocità disallineate, perché si andrebbe a creare un’ inutile sovrabbondanza di attività in Ready-to-Pull.
La “prima via” responsabilizza i Work Center nella gestione dei difetti, sia di processo che di lavorazione, senza la presunzione che il problema verrà risolto da qualcun altro, in qualche modo. Inoltre, come evidenziato, porta all’ottimizzazione complessiva del Value Stream, attraverso una comprensione sempre più profonda dei processi ed evitando di sprecare risorse nell’ottimizzazione delle singole stazioni senza tener conto del disegno complessivo.
The Second Way
Feedback costanti e rapidi da destra a sinistra per risolvere i problemi alla radice ed evitare di trascinarli lungo tutto il Value Stream [4]
La “seconda via” pone l’accento sulla necessità di creare loop di feedback efficaci ed estremamente rapidi. Per migliorare i propri processi è indispensabile che i feedback arrivino velocemente e che l’origine del difetto sia identificato con precisione, andando a coinvolgere tutti gli attori interessati dal Value Stream.
Ciò porta a rispondere più adeguatamente alle esigenze dei clienti, esterni o interni che siano, aumentando la conoscenza complessiva sugli obiettivi da raggiungere e su cosa è realmente importante focalizzarsi.
“The Third Way”
Favorire una cultura orientata alla sperimentazione costante di nuove soluzioni e ottimizzazioni, in modo empirico e con l’accettazione del fallimento come motore di innovazione [4]
La “terza via” si concentra sulla necessità di creare una Cultura aziendale in grado di sperimentare continuamente, considerando il fallimento alla base dell’apprendimento e dell’abbattimento dei rischi. A tutto ciò si aggiunge un’attenzione esplicita sulla pratica e sulla ripetizione, ritenendole fattori indispensabili per padroneggiare le attività.
Si tratta di un approccio fondamentale che consente di esplorare anche le cosiddette “danger zones”, proprio perché il fallimento non viene visto come un qualcosa di cui vergognarsi, e quindi da evitare a tutti i costi anche a discapito di interventi che porterebbero a miglioramenti significativi: Fail Fast, Fail Often!
La “terza via” porta a benefici rilevanti che vanno dalla migliore ripartizione del lavoro a incentivi basati sull’assunzione dei rischi, fino all’approccio di introdurre volontariamente piccoli difetti — ricordate: siamo in regime di micro-esperimenti — per testare la resistenza dell’intero processo.
Conclusioni
Si chiude qui il secondo appuntamento con il nostro percorso alla scoperta di DevOps. Prossimamente parleremo dei “cinque pilastri di DevOps” e della DevOps Delivery Pipeline. Nel frattempo, aspettiamo il vostro feedback.