Introduzione

Dopo aver parlato di come le iniziative IT vengono allineate ai prodotti indentificati come strategici [1][2], siamo pronti a scoprire il cuore operativo di Disciplined Agile 2, Disciplined DevOps. Essendo i relativi aspetti costituenti di notevole impatto, dedicheremo questo e il prossimo articolo alla loro scoperta, iniziando dai modelli di delivery nel senso più ampio del termine.

Da DevOps a Disciplined DevOps

Come suggerisce il nome Disciplined DevOps, DA2 sviluppa l’azione di delivery (e in estrema attuazione quella di deployment, ovvero il delivery automatizzato in produzione) intorno allo sviluppo di una cultura DevOps, motivo per il quale vale la pena soffermarsi brevemente su cosa sia effettivamente DevOps, vista la confusione generale che attanaglia questo acronimo:

“DevOps è un approccio culturale in cui l’intera Line of Business si assume la responsabilità della creazione di valore per il cliente. In tale scenario, Developers e Operations sperimentano continuamente nuovi modi di lavorare insieme, andando a standardizzare e padroneggiare i processi attraverso la ripetitività e la pratica.” [FP]

Si tratta, quindi, di avere una visione complessiva delle attività da realizzare, combinando gli aspetti di Development in chiave Agile e quelli di Delivery in funzione della loro ottimizzazione. DevOps si posiziona nel panorama del mondo Agile e Lean, aggiungendo una forte attenzione ai tool, indispensabili per rendere i processi di automazione efficienti.

Per quanto riguarda il termine “Disciplined” definiamo Disciplined DevOps come:

“….the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.”

Nella concezione di DA2, non solo i Dev e gli Ops sono quindi chiamati a collaborare per il successo delle diverse iniziative IT, ma lo è l’intera Line Of Business. Questo è un aspetto fondamentale poiché ogni attività, progetto, elemento, deve essere sempre facilmente collegabile ad uno specifico prodotto! Se non è possibile, allora bisogna fermarsi e riflettere se ciò che si sta realizzando non sia un “tecnoware”, ovvero un’attività fine a sé stessa.

L’approccio suggerito è quello di estendere gradualmente DevOps alle varie funzioni aziendali, in modo da far maturare progressivamente, nel proprio contesto, la Cultura necessaria a tale cambiamento.

Attuare l’approccio Disciplinato

Come è facile immaginare, il punto di partenza è proprio quello più immediatamente collegabile a DevOps, ovvero l’abbattimento dei Silos e delle barriere che separano Dev e Ops, come suggerito dalle “Three Ways” di Gene Kim [3] e dalla loro declinazione pratica:

System Thinking

• Utilizzare un singolo Repository per codice e ambienti;
• Tenere sotto version control tutti gli artefatti, sia di Dev che di Ops;
• Creare un processo di release deterministico;
• Preparare gli ambienti di Dev, Test e Produzione prima dell’inizio dello sviluppo, tenendoli consistenti;
• Sottoporre il codice a commit giornaliero;
• Dotarsi di test di regressione automatici;
• Rilasciare le feature in produzione su base giornaliera;
• Abbattere il Lead-Time e aumento del Cycle-Time in chiave «pull».

Amplify Feedback Loops

• Revisionare alla «Pari» il codice e i cambiamenti agli ambienti;
• Utilizzare i test automatici per consentire ai team di lavorare e collaborare proficuamente;
• Monitorare proattivamente gli ambienti di produzione;
• Risolvere rapidamente i difetti e i problemi di sicurezza;
• Incentivare una Cultura basata sulla fiducia;
• Aumentare la sinergia tramite comunicazione e coordinamento;
• Incentivare la produttività individuale, di team e cross-team.

Culture of Continual Experimentation and Learning

• Dedicare una parte consistente delle attività (15-20%) al pagamento del Debito Tecnico;
• Iniettare volontariamente «bug e fault programmati» per testare la resistenza del sistema;
• Fare quanto è possibile per alzare l’asticella della produttività;
• Condividere le esperienze di successo e di fallimento, in modo da imparare da esse e aumentare la competitività sul mercato.

Il tutto è meticolosamente pensato (lasciando alla specifica realtà di adattarlo e contestualizzarlo) per ridurre al minimo il Value Canyon, ovvero il gap che divide lo sviluppo dall’erogazione della soluzione.

Proprio queste aree, non obbligatoriamente presenti in modo esplicito all’interno della propria organizzazione, hanno una serie di specifiche esigenze che DA2 raccomanda di bilanciare tra loro attraverso la scelta di opportune strategie ad esse annesse:

• Development Strategies, incentrate sulle diverse pratiche che consento al development di supportare al meglio le attività di Delivery. Si spazia, quindi, dagli aspetti di testing a quelli di Continuous Integrarion/Delivery/Deployment;
• Operations Strategies, incentrate sulle diverse pratiche che consento a operations di supportare al meglio le attività di Delivery: si pensi all’automazione del provisioning degli ambienti o al monitor delle applicazioni;
• Support (Help Desk) Strategies, focalizzate sugli aspetti di supporto applicativo. Si va dalle classiche FAQ alla capacità delle applicazioni stesse, grazie ad appositi tool di monitoring, di segnalare prontamente al team e agli utenti eventuali problemi;
• Release Management Strategies, incentrate sulle strategie di Release che, come vedremo in seguito, possono prevedere una funzione esplicita o essere demandate al team;
• Data Management Strategies, con focus su una gestione disciplinata dei dati che diventano una ricchezza per il miglioramento continuo;
• Enterprise Architecture Strategies, in cui vengono proposte delle possibili strategie per la creazione e gestione di una efficiente ed efficace architettura IT di riferimento a livello aziendale.

In aggiunta, DA2 prende in considerazione un’ulteriore set di aspetti trasversali, raccolti sotto il cappello General e Teaming Strategies.

General, in particolare, si occupano di definire le strategie complessive di un approccio Disciplined DevOps: troviamo così una particolare enfasi, ad esempio, sugli aspetti collaborativi e sull’importanza dell’automazione dei processi.

Teaming si focalizzata sulle possibili strategie di integrazione delle attività, e quindi di team, con particolare attenzione ai Dev e agli Ops.

Tutte le aree, quindi, sono caratterizzate da specifiche strategie che vengono definite “DevOps-friendly” e supportano diversi livelli di adozione, bilanciando il rischio di adozione, l’effort di adozione e i risultati attesi.

Focus sulle azioni di Delivery

Dal contesto che si sta descrivendo, emerge come Disciplined DevOps abbia un focus esplicito sulle attività di delivery, costruite su quelli che sono i cardini portati della precedente versione di Disciplined Agile [Delivery][DAD, 4].

Il presupposto è che ogni team è unico e tale è anche la soluzione che ci si accinge a sviluppare, per cui è opportuno prevedere più modelli di Application Lifecycle Management (ALM), generalizzabili comunque secondo un pattern che prevede tre fasi primarie:

• Inception, la fase di inizializzazione del progetto, in cui gli elementi fondamentali per la sua riuscita prendono corpo e si valutano aspetti come il Rischio e la Sostenibilità;
• Construction, la fase di realizzazione, ovvero dove la soluzione viene concretamente implementata;
• Transition, la fase che si occupa degli aspetti di Delivery e Deployment.

Le fasi di Construction e Transition, quando si approccia alla Cultura DevOps, diventano fortemente correlate tra loro, anche mantenendo una ovvia sequenzialità logica, mentre se si estende il campo di osservazione, è evidente come il ciclo di delivery sia strettamente legato agli aspetti di pianificazione complessiva, fino al Product Management[2] e al Reuse Engineering[2].

DA2 specializza questo meta-modello di riferimento in funzione della terna Team-Solution Context, proponendo quattro modelli di riferimento specifici

Agile/Basic Lifecycle (Extending Scrum)

si tratta del lifecycle pensato per i team che già lavorano con Scrum e hanno la necessità di scalare le proprie attività. Questo approccio si caratterizza per essere:

• Iteration Based, esattamente come Scrum la soluzione è sviluppata con un approccio time-boxed e ogni intervallo di sviluppo è definito Iteration;
• Non-Scrum Terminology, di base la terminologia Scrum è sostituita con una duale più generica (es: Iteration vs Sprint), anche se ciò non è un must;
• Inputs from outside the delivery lifecycle, vengono evidenziati gli elementi esterni primari in grado di condizionare la soluzione e generare cambiamenti durate la sua realizzazione;
• Work item list, not Product Backlog, DA2 preferisce il concetto di Work Item List a quello di Product Backlog. Questo per evidenziare che nello stack non sono presenti solo User Story o Feature da realizzare, ma anche requisiti, difetti, aspetti non funzionali, ecc…. In pratica il Product Backlog contiene tutto quanto necessario al successo della soluzione (e non allo sviluppo del prodotto/progetto), comunque ordinato secondo diversi criteri;
• Explicit milestones, sono previste milestone esplicite che consentono una governance efficace delle attività, e rappresentano spesso il momento di Deployment concordato con il cliente.

Advanced/Lean DAD Lifecycle

si tratta del lifecycle pensato per team maturi che lavorano in chiave di Continuous Value Stream, rilasciando gli Incrementi quando sono pronti, senza avere una finestra specifica di riferimento, e sforzandosi di ridurre al minimo il tempo che intercorre tra due rilasci. Questo approccio si caratterizza per:

• Continuous flow of delivery, il delivery/deployment avviene ogni volta che è disponibile un nuovo Increment significativo, senza vincolarsi ad alcuna Iterazione. Le nuove attività sono “tirate” dal team nel flusso di lavoro appena si ha la capacità per farle e non “spinte” in funzione di una pianificazione time-boxed (pull vs push);
• Practices are on their own cadences, le varie cerimonie (retrospettive, grooming, ecc…) vengono eseguite quando ha senso farle e non secondo una cadenza pre-stabilita;
• Work item pool, non tutti i work item sono uguali. Alcuni sono risk-value driven, altri value-driven e altri ancora data-driven (si pensi ai vincoli normative). Per questo motivo un Work Item pool ha molto più senso che uno stack ordinato per priorità generica.

Continuous Delivery Lifecycle

si tratta di un Advanced/Lean DAD Lifecycle in cui il tempo di delivery/deployment è ridotto al minimo, anche con frequenza di più volte al giorno, sfruttando strumenti di automazione e processi standardizzati nel tempo.

Exploratory (Lean Startup) Lifecycle

è il processo contemplato da Lean Startup, pensato per le startup o le Line of Business di ricerca che devono prima di tutto validare la sostenibilità della propria idea, andando a scoprire il mercato con una serie di Minimum Viable Product (MVP) e una specifica implementazione del ciclo Build-Measure-Learn. Questo modello è caratterizzato da:

• Envision, si tratta di esplorare la nuova idea e formulare le relative ipotesi che potrebbe attrare i potenziali clienti;
• Build a Little, sviluppare velocemente quanto necessario per validare le proprie ipotesi: Minimum Viable Product (MVP). Non è importante concentrarsi sulla qualità tecnica e tecnologica, bensì essere estremamente veloci e capaci di evidenziare le caratteristiche peculiari;
• Deploy, l’MVP deve essere reso velocemente fruibile agli early-adopter in modo da poterne testare l’interesse;
• Observe & mesure, una volta in erogazione, è necessario monitorare il comportamento degli early-adopter “instrumentando” l’MVP. In tal modo è possibile rendersi conto se quanto realizzato va nella direzione giusta o è necessario eseguire un pivot;
• Cancel, dopo aver testato le idee portanti e sfruttato i pivot, potrebbe essere necessario decidere di abortire lo sviluppo della soluzione perché non è di interesse per i potenziali clienti. Se ciò deve avvenire, meglio che avvenga in un tempo ristretto, limitando le risorse impiegate e massimizzando il know-how acquisito;
• Productize, se il prodotto trova il proprio spazio, la fase di Customer Delivery può ritenersi conclusa ed è opportuno passare alla fase di ingegnerizzazione, preferibilmente, tramite uno degli altri modelli di sviluppo presentati.

La presenza di 4 diversi lifecycle è una precisa scelta in chiave “no-prescribing” di DA2, che riconosce come naturale il fatto di potersi/doversi adattare ai diversi contesti, oltre a prevede l’evoluzione in funzione della Cultura aziendale, dalla maturità del team, delle tecnologie e delle mutate condizioni di mercato.

Tutto questo ha chiaramente un costo, poiché avere persone in grado di adattarsi alle specifiche connotazioni dei vari modelli non è cosa da poco, ma il risultato è sicuramente più efficace del costringere i team a seguire un approccio pre-determinato, eventualmente poco consono allo specifico contesto.

Conclusioni

Con questo terzo appuntamento, abbiamo iniziato ad analizzare le caratteristiche della macro-area Disciplined DevOps, entrando nel vivo delle azioni a supporto del delivery, grazie alle diverse strategie e i diversi modelli proposti, e proponendo una visione diretta di quello che si cela dietro lo sbandierato approccio DevOps.

Nel prossimo appuntamento andremo a completare l’esplorazione di Disciplined DevOps, concentrandosi sulle attività aggregate: Release Managament, Operation, Support e Data Management.

Come sempre vi invito a contattarmi per feedback, chiarimenti e approfondimenti.