Come visto nel precedente post della serie, Disciplined Agile ha al centro della propria azione Disciplined Agile Delivery (DAD) ovvero la capacità di realizzare soluzioni in modo disciplinato con team che fanno propri i Valori, i Principi e le Pratiche più consolidate del mondo Agile e Lean.
DAD è anche storicamente la prima area di Disciplined Agile ad essere stata formalizzata e, come già accennato nel post precedente, consiste in un approccio hybrid-agile allo sviluppo di soluzioni IT, in cui le Persone coinvolte fanno propria una cultura basata sull’apprendimento costante.
DAD si basa su 8 principi portanti:
- People-first, sono le persone a condizionare i processi e non viceversa
- Goal-driven, focus su goal chiari
- Hybrid agile, scegliere le pratiche opportune da diversi framework/metodologie
- Learning-oriented, apprendimento continuo
- Full delivery lifecycles, dall’idea alla consegna
- Solution focused, soluzioni consumabili, non solo “finite”
- Risk-value lifecycle, gestione esplicita e profonda del rischio
- Enterprise aware, consapevolezza aziendale
e affronta in modo esplicito tutti gli aspetti della realizzazione di un nuovo prodotto, attraverso tre fasi esplicite:
- Inception, la fase di inizializzazione del progetto, in cui gli elementi fondamentali per la sua riuscita prendono corpo e si valutano aspetti come il Rischioe la Sostenibilità;
- Construction, la fase di realizzazione, ovvero dove la soluzione viene concretamente implementata;
- Transition, la fase che si occupa degli aspetti di Deployment.
Fasi di DAD
Se l’utilizzo di fasi può sembrare qualcosa di “strano” all’interno di un framework Agile, bisogna evidenziare come esse non siano da intendersi alla waterfall, bensì come “contenitori di scopo” che non limitano alcuna review delle decisioni prese. Il loro obiettivo è quello di focalizzarsi, nei diversi momenti, su ciò che è tipicamente richiesto dalla lavorazione di un prodotto, così come esplicitato dagli specifici process goal annessi ad ogni singola fase.
The process goals of Disciplined Agile Delivery (DAD)
Nella figura precedente sono anche visibili dei goal raggruppati in una “virtual phase” chiamata Ongoing: si tratta di obiettivi trasversali che accompagnano il team nell’intera realizzazione del prodotto.
Nel rispetto del principio portate “choice is good” (si veda il primo articolo della serie), e della continua evoluzione organizzativa, le fasi prendono forma e si specializzano in 4 lifecycle specifici: Agile/Basic, Lean/Advanced, Continuous Delivery (Agile/Basic) e Continuous Delivery (Lean/Advanced).
DAD Lifecycles
Ad essi se ne aggiunge un quinto, Exploratory (Lean Startup) in cui le fasi precedenti non sono presenti, avendo uno scopo diverso e specifico: supportare le organizzazioni nella fase di customer delivery. Esempio tipico sono le “vere” startup.
Diamo ora uno sguardo più di dettaglio ai diversi lifecycle.
Agile/Basic Lifecycle (Extending Scrum): si tratta del lifecycle pensato per i team nuovi al mondo Agile o a quelli che già lavorano con Scrum e hanno la necessità di scalare le proprie attività.
Agile/Basic Lifecycle
È indicato quando è possibile identificare, prioritizzare e stimare le diverse funzionalità da realizzare, caratterizzandosi 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: Iterationvs 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, DAD preferisce il concetto di Work Item a quello di Product Backlog. Questo per evidenziare che nello stack non sono presenti solo User Storyo Featureda 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 che lavorano in chiave di 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.
Lean/Advanced Lifecycle
È indicato quando è possibile suddividere le attività in unità minimali di lavoro ed è difficile fare previsioni su di esse, caratterizzandosi per:
- Continuous flow of delivery, la delivery avviene ogni volta che è disponibile un nuovo Incrementsignificativo, 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, i vari eventi (retrospettive, refinement, ecc...) vengono eseguiti 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-drivene 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 (Agile/Basic): si tratta della naturale evoluzione del lifecycle Agile/Basic, con iterazioni di una settimana o meno.
Continuous Delivery (Agile/Basic)
La differenza primaria è che la fase di Inception viene completamente assorbita da quella di Construction e anche la fase di Transition si riduce al minimo. Inoltre, rispetto all’Agile/Basic il rilascio avviene concretamente al massimo alla fine di ogni iterazione, e quindi almeno ogni settimana. Le sue caratteristiche sono:
- Iteration Based(al massimo di 1 settimana)
- Non-Scrum Terminology
- Inputs from outside the delivery lifecycle
- Work item list, not Product Backlog
- Explicit milestones
Continuous Delivery Lifecycle (Lean/Advanced): si tratta della naturale evoluzione del lifecycle Lean/Avanced in cui il tempo di delivery è ridotto al minimo necessario, anche con frequenza di più volte al giorno, sfruttando strumenti di automazione (deploy) e processi standardizzati nel tempo.
Continuous Delivery (Lean/Advanced)
Per la fase di Inception e Transition vale quanto già detto per il Continuous Delivery Lifecycle Agile/Basic, mentre le caratteristiche rilevanti sono:
- Continuous flow of delivery
- Practices are on their own cadences
- Work item pool
Exploratory (Lean Startup) Lifecycle: è il lifecycle ispirato a Lean Startup, pensato per le startup o le nuove iniziative, 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.
Exploratory (Lean Startup) Lifecycle
L’obiettivo è quello di ridurre al minimo gli investimenti iniziali, favorendo, attraverso piccoli esperimenti, azioni testate sul mercato e misurate con metriche significative. Si caratterizza per:
- 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 Deliverypuò ritenersi conclusa ed è opportuno passare alla fase di ingegnerizzazione, preferibilmente, tramite uno degli altri modelli di sviluppo presentati
Una caratteristica che abbiamo osservato è quella che prevede la graduale scomparsa (o assottigliamento delle fasi), pian piano che si evolve nell’adozione dei diversi lifecycle.
Phases Disappearing
Non bisogna però pensare che, in generale, una fase sia migliore dell’altra, ma lavorare su quella più adatta al contesto temporale e valutare possibili evoluzioni, anche come suggerito da DAD stesso nel tipico percorso di adozione relativo.
Typical Adoption Paths
Dal percorso resta ovviamente escluso l’Exploratory (Lean Startup) Lifecycle che ha un compito specifico e temporalmente limitato e che, una volta completato, viene sostituito con uno degli altri quattro.
Si conclude così il nostro terzo appuntamento dedicato a PMI DA. Nel prossimo approfondimento guarderemo più da vicino Disciplined DevOps.
Stay tuned J
