DA2, IT Delivery: lifecycles

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.