Nell’ambito di Disciplined DevOps, le attività di delivery sono costruite su quelli che erano i cardini portati della precedente versione di Disciplined Agile.
DA2, IT Delivery
Il presupposto da cui DA2 parte è che ogni team è unico e tale può essere anche la soluzione che ci si accinge a sviluppare, per cui è opportuno prevedere più modelli di ALM, generalizzabili comunque secondo un modello 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.
Delivery general
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 Portfolio e al Reuse Engineering.
DA Delivery extended context
DA2 specializza questo meta-modello di riferimento in funzione delle variabili 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:
- 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 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.
DA2 Base
- 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.
DA2 Advanced
- 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.
DA2 Continuous Delivery
- Exploratory (Lean Startup) Lifecycle: è il processo contemplato da Lean Startup, pensato per le startup o le LOB 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 ipotesi in relazione alla possibile idea 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, 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 è sulla 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.
DA 2 Exploratory
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.