Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

219 luglio
, anno 2016

Disciplined Agile 2

I parte: Un “framework olistico” per governare soluzioni complesse

Avatar

Felice Pescatore

Felice Pescatore è Innovation Manager e Microsoft MVP.
Nel suo lavoro, impiega quotidianamente approcci Lean/Agile per lo sviluppo di soluzioni software enterprise.
Nell’ultimo periodo si è dedicato particolarmente al mondo delle Startup con Lean Startup e all’ottimizzazione della Value Chain tramite DevOps, con uno sguardo sempre più ravvicinato al mondo della Internet of Things (IoT).

MokaByte

Disciplined Agile 2

I parte: Un “framework olistico” per governare soluzioni complesse

Felice Pescatore

Felice Pescatore

  • Questo articolo parla di: DevOps, Lean/Agile

Disciplined Agile 2.0: una nuova visione olistica del delivery

Lean, Agile e, più recentemente DevOps, sono approcci mirati alla creazione di una mentalità in grado di liberare le potenzialità della propria organizzazione dalle catene della burocrazia, consentendo di concentrarsi su ciò che realmente è utile al raggiungimento degli obiettivi complessivi di business.

Non si tratta di metodologie da “imparare ed applicare” meccanicamente, ma di valori, principi e pratiche che mettono al centro dell’azione la creazione di valore — per quanto quest’ultimo possa essere diverso nei vari contesti — e la soddisfazione degli stakeholder.

Scalare Lean/Agile ai diversi livelli

Non è quindi difficile intuire come l’adozione di Lean, Agile e DevOps sia estremamente pervasiva e attraversi tutti i livelli organizzativi tipici: dal team level, dove gli artefatti vengono “concretamente” realizzati, al top level, dove vengono prese le decisioni strategiche di mercato.

Per supportare tale adozione sono nati svariati “framework” spesso definiti di Scaling, proprio a indicare che, a differenza delle principali metodologie agili, si rivolgono non al singolo team di sviluppo, ma all’intera organizzazione aziendale: SAFe, DA2, LeSS, Nexus e altri sono tutti estremamente interessanti e con una specifica declinazione.

 

Da DAD a Disciplined Agile 2.0

In questa serie parleremo specificamente di Disciplined Agile 2.0, il framework sviluppato da Scott Ambler e Mark Lines, che è focalizzato sulla governance dei processi di realizzazione di soluzioni end-to-end complesse.

Il nostro viaggio comincia nel 2012, quando Scott Ambler e Mark Lines presentano ufficialmente DAD (Disciplined Agile Delivery) rendendo disponibile il testo ufficiale [1] e il blog di riferimento [2].

Entrambi gli autori non hanno bisogno di particolari presentazioni, soprattutto Ambler, già noto per la sua minuziosa attenzione all’Application Lifecycle Management e all’impatto delle scelte architetturali nella modellazione di soluzioni complesse. Ma DAD non nasce all’improvviso: c’è una lunga serie di esperienze che porta al suo concepimento.

Da Rational Unified Process ad Agile Unified Process…

DAD trova le proprie radici in Agile Unified Process, a sua volta nato come semplificazione di Rational Unified Process (RUP, Rational/IBM), ritenuto troppo strutturato e difficile da adottare. È interessante sottolineare come lo stesso Ambler avesse contribuito fortemente a RUP mettendo le basi per la versione enhanced comprendente la fase di produzione.

RUP contempla un approccio iterativo prevedendo che tutte le discipline tradizionalmente impiegate per la creazione di un prodotto software siano spalmante, con pesi differenti, durante 4 fasi primarie: inception, elaboration, construction e transition [3].

Figura 1 – Il ciclo di vita RUP (Rational Unified Process).
Figura 1 – Il ciclo di vita RUP (Rational Unified Process).

 

Si tratta di un deciso passo in avanti rispetto agli approcci tradizionali, waterfall in primis. Il RUP negli anni ha riscosso un discreto successo ma ha anche sofferto di un continuo aumento di complessità e di una aggravio di burocrazia dovuti alla volontà di estenderne continuamente il campo applicativo.

Inoltre, RUP nasce con quello che potremmo definire il “peccato originale” per un framework di sviluppo moderno: esso è infatti use-case driven e non goal-value driven, per cui resta fortemente legato a una gestione dei requisiti molto formale e concentrata nelle due fasi iniziali [4].

…a Disciplined Agile Delivery

Tornando a Disciplined Agile Delivery, è fondamentale sottolineare che esso si fonda sui valori e sui principi del Manifesto Agile, riprendendo l’organizzazione a fasi di RUP per supportare la realizzazione di un prodotto dal suo concepimento alla sua dismissione.

Figura 2 – DAD base lifecycle.
Figura 2 – DAD base lifecycle.

 

Ma perché “Disciplined”? Ebbene, i due co-autori pongono l’enfasi su tale termine per evidenziare e sottolineare come l’adozione dell’Agile sia un viaggio tortuoso e che la meta può essere raggiunta solo se si procede con estrema disciplina.

 

Le caratteristiche di Disciplined Agile Delivery

Presentato nel 2012, Disciplined Agile Delivery fa leva su princpi e valori tipicamente Lean/Agile, ma non scarta a priori alcune “conquiste” dei paradigmi strutturati precedenti. Vediamo una serie di caratteristiche di DAD.

Fasi/obiettivi

Il punto di forza di DAD è l’impostazione goal-driven, pensata per spingere il delivery team a essere concentrato su specifici e chiari obiettivi raggruppati in tre specifiche fasi (small-batch): Inception, Construction e Transition.

La fase di Elaboration, utilizzata in RUP per dettagliare i requisiti e testare l’architettura del sistema, scompare, non essendo proprio in linea con un approccio Agile o Lean che si voglia.

Figura 3 – DAD Goal MapMind.
Figura 3 – DAD Goal MapMind.

 

Viene così a crearsi una matrice fasi/obiettivi che consente di estendere il raggio di azione dell’Agile da quello legato esclusivamente agli aspetti di sviluppo, a quello relativo all’intera gestione dei processi di realizzazione di un prodotto. Ciò viene fatto combinando strategie e pratiche “prese in prestito” dalle metodologie più affermate, che connotano DAD come un hybrid-framework.

Lifecycle

Nella sostanza viene creata una “estensione virtuale” di Scrum (lifecycle basic), in modo da coprire i diversi aspetti metodologici spesso fonti di incertezza: si pensi alla famosa “Iteration 0” spesso introdotta per rispondere alla domanda: “Ma quando creo il Product Backlog?”.

Senza voler entrare per ora nel dettaglio, è doveroso evidenziare che DAD prevede 4 diversi lifecycle: Basic/Agile, Advanced/Lean, Lean Continuous Delivery ed Exploration, pensati per abbracciare diversi contesti e sui quali torneremo nei prossimi appuntamenti.

L’esplicita introduzione della fase di Inception e di Transition non deve far credere, però, che siamo difronte ad una sorta di water-scrum-fall [5], in quanto sono fasi di durata estremamente breve, i cui risultati sono costantemente ri-valutati e il cui scopo primario è quello di abbattere i rischi annessi, rispettivamente, all’avvio del progetto e al suo dispiegamento e manutenzione in produzione.

Milestone

Esattamente come le fasi, inoltre, può inizialmente far storcere il naso il fatto che vengano prescritte delle esplicite milestone: i prodotti complessi spesso vedono coinvolti molti team auto-organizzati e paralleli e risulta quindi normale individuare dei punti di allineamento in cui condividere il know-how al fine di creare una cultura condivisa a livello aziendale, sia metodologica che tecnico/tecnologica.

Questo è, appunto, l’obiettivo delle milestone di DAD, basti pensare, come esempio, alla presenza della milestone Proven Architecture all’interno della fase di Construction che fa propri alcuni aspetti della soppressa fase di Elaboration di RUP affidandoli direttamente ai team.

Extended Product Backlog

In ragione di tutto ciò, non sorprende, inoltre, come in DAD il concetto di Product Backlog sia “extended”, passando da strumento atto a elencare e priorizzare le funzionalità da realizzare, a strumento che consente di mettere in evidenza tutte le attività da gestire: si pensi alle azioni di riduzione del debito tecnico o a quelle di risoluzione dei bug.

 

Da DAD a Disciplined Agile 2.0

Quanto appena descritto rappresenta la struttura portante di DAD, ancora estremamente valido se si considerano singole iniziative specializzate all’interno della propria struttura.

Dal 2012 ad oggi, però, molte cose sono cambiate. In particolare, l’avanzata del movimento DevOps, unitamente ai Microservices e al Cloud come mainstream architetturale, ha portato Ambler e Lines a rivedere l’impostazione originale del loro hybrid-framework, rilasciando, ad agosto del 2015, Disciplined Agile 2.0 (DA2), che estende il campo di applicazione all’intera organizzazione sempre però con forte riferimento all’IT, oggi come non mai elemento essenziale di ogni iniziativa di business.

Disciplined Agile 2.0… senza Delivery?

In questa nuova forma, scompare il termine delivery dalla definizione, e resta solo Disciplined Agile. Questo non significa che in DA2 il delivery di un prodotto o di una soluzione non sia presente o importante, ma siccome si tratta di una sola parte del quadro generale, l’esplicito riferimento scompare dal nome del framework. Disciplined Agile 2.0 ora si caratterizza come: “A Process Solutions Framework for Enterprise IT”.

Figura 4 – Il poster di DA2.
Figura 4 – Il poster di DA2.

 

Tre macroaree: Disciplined Initiative, Disciplined DevOps, Disciplined Growth

La nuova versione dell’hybrid-framework propone tre macroaree di attenzione, strettamente correlate tra loro in modo inscindibile. Le vediao di seguito

  • Disciplined Initiative, ossia tutta la parte organizzativa dell’IT che è a stretto contatto con le funzioni strategiche aziendali. L’obiettivo è quello di creare un legame diretto tra ogni singola iniziativa IT e un preciso obiettivo di business.
  • Disciplined DevOps, è il cuore pulsante del framework in cui il delivery prende forma e la struttura si auto-organizza per rispondere il più rapidamente possibile ai nuovi obiettivi.
  • Disciplined Growth, focalizzata sul management e sulla governance delle persone impegnate nell’IT.

È doveroso evidenziare che i termini “Disciplined Initiative” e “Disciplined Growth” non sono presenti in modo esplicito in DA2, ma sono un’astrazione qui utilizzata per semplificare la nostra trattazione.

DA2 evidenzia in modo efficace l’interrelazione tra tali aree, evidenziando come esse debbano lavorare con estremo sincronismo per poter ottenere benefici reali e miglioramenti tangibili.

Disciplined Initiative: la strategia

A livello strategico troviamo l’area Disciplined Initiative che mette un cappello a tutte quelle funzioni necessarie ad una integrazione tra le iniziative concrete di business e le attività della divisione IT.

Questo collante è fondamentale affinché ogni attività dell’IT sia direttamente e facilmente riconducibile ad un’azione di business (alias “di mercato”) in modo da poterne misurare il valore e il beneficio relativo. Se si fatica a trovare tale correlazione è necessario investigare sulla specifica iniziativa e capire perché la si sta attuando.

In questo scenario non sorprendono le attività di gestione inerenti al Portfolio Management, Product Management, Enterprise Architecture e Reuse Engineering legata al riutilizzo degli asset già presenti nella propria struttura.

Figura 5 – Disciplined Initiative
Figura 5 – Disciplined Initiative

 

Tutte e quattro queste attività di gestione sono strettamente legate tra loro da una fitta rete di dipendenze, mai gerarchiche, ma sempre cicliche, in chiaro allineamento con la logica di continuous and fast feedback del mondo Agile.

Disciplined DevOps: il braccio operativo

Il braccio operativo di DA2 trova posto nell’area Disciplined DevOps in cui la soluzione viene realizzata in allineamento agli specifici aspetti di delivery e deployment. Il tutto è supportato dalle funzioni di Program Management, Agile Delivery, Release Management, Data Management, Support e Operation.

Figura 6 – Disciplined DevOps.
Figura 6 – Disciplined DevOps.

 

Ritroviamo qui molto di quanto proposto già in DAD, ma con una nuova spinta verso il mondo DevOps, ossia verso un’integrazione e una collaborazione tra le varie aree interessate alla realizzazione della soluzione, supportate da un’automazione dei processi che sottendono il raggiungimento dell’obiettivo di un Continuous Delivery/Deployment in grado di reagire prontamente agli stimoli del mercato e alle mutevoli esigenze degli stakeholder.

Disciplined Growth: la governance del capitale umano

La terza area è Disciplined Growth e si rivolge agli aspetti di governance del proprio “capitale umano”. Se c’è una cosa che Agile e Lean hanno insegnato ai “burocrati” nel corso dell’ultimo decennio è che il successo di un’organizzazione dipende, prima di tutto, dalle persone che vi lavorano, per cui è fondamentale adottare le giuste azioni per favorire una cultura di crescita, collaborazione e continuous improvement.

Figura 7 – Disciplined Growth.
Figura 7 – Disciplined Growth.

 

Troviamo così le funzioni di IT Governance, Continuous Improvement e People Management, tutte orientate alla “cura” del nostro capitale umano.

 

Conclusioni

In questo primo articolo abbiamo cercato di capire il modo in cui Disciplined Agile 2.0 si è evoluto a partire da esperienze precedenti: dagli approcci iterativi e incrementali degli anni Novanta fino alla rivoluzione Lean/Agile di questi ultimi anni.

Come emerge da questa prima “spulciata” a DA2, molte delle novità sono state introdotte per creare maggiore sinergia aziendale (company’s awareness) e supportare lo sviluppo di soluzioni sempre più complesse con le più moderne soluzioni metodologiche e pratiche e con un time-to-market sempre più ridotto.

Nel prossimo appuntamento cominceremo ad entrare nel dettaglio del framework, concentrandoci sull’area qui denominata Disciplined Initiative, evidenziandone obiettivi, funzioni chiave e relazioni tra esse.

Nel frattempo vi invito a contattarmi per feedback e domande, tramite mail, Twitter o anche tramite il gruppo Agile@Scale Italy su LinkedIn.

 

Facebook
Twitter
LinkedIn
Avatar

Felice Pescatore

Felice Pescatore è Innovation Manager e Microsoft MVP.
Nel suo lavoro, impiega quotidianamente approcci Lean/Agile per lo sviluppo di soluzioni software enterprise.
Nell’ultimo periodo si è dedicato particolarmente al mondo delle Startup con Lean Startup e all’ottimizzazione della Value Chain tramite DevOps, con uno sguardo sempre più ravvicinato al mondo della Internet of Things (IoT).

Felice Pescatore

Felice Pescatore

Felice Pescatore è Innovation Manager e Microsoft MVP. Nel suo lavoro, impiega quotidianamente approcci Lean/Agile per lo sviluppo di soluzioni software enterprise. Nell’ultimo periodo si è dedicato particolarmente al mondo delle Startup con Lean Startup e all’ottimizzazione della Value Chain tramite DevOps, con uno sguardo sempre più ravvicinato al mondo della Internet of Things (IoT).
Tutti gli articoli
Nello stesso numero
Loading...

Better Software 2016

Apprendere (e divertirsi) con i workshop

Metriche Kanban per il miglioramento continuo

VI parte: “Probabilistic forecasting” e la (sottile) differenza tra stima e previsione

Storytelling: storie, narrazione, comunicazione

II parte: Il lavoro per immagini e lo “scheletro” della storia

L’Agile e il management

II parte: Radical Management all’opera

Nella stessa serie
Loading...

Disciplined Agile 2

V parte: Disciplined Growth per valorizzare le persone

Disciplined Agile 2

IV parte: Disciplined DevOps, un ecosistema disciplinato

Disciplined Agile 2

III parte: Disciplined DevOps, uno sguardo al delivery

Disciplined Agile 2

II parte: Disciplined Initiative

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte