Introduzione
Nel primo articolo di questa serie [1] abbiamo visto una panoramica di Disciplined Agile 2, in breve DA2, partendo dalle motivazioni e dagli aspetti portanti che hanno fatto evolvere DAD in chiave olistica, scalando rispetto ai diversi livelli aziendali [2].
In questo secondo appuntamento cominceremo a esplorare una delle tre marcoaree in cui idealmente è diviso il framework: Disciplined Initiative, Disciplined DevOps e Disciplined Growth. Ci concentreremo infatti su Disciplined Initiative.
Ulteriori novità: DA 2.1
Prima di procedere, però, è interessante segnalare che proprio durante il mese di agosto Ambler e Lines hanno presentato un’evoluzione del poster di DA2: in pratica si è passati dalla versione 2.0 alla versione 2.1 (figura 1).
Il framework è rimasto praticamente immutato, anche se sul poster live del sito sono comparsi una serie di ruoli specifici annessi a diverse funzioni. Nel prosieguo di questo articolo, utilizzeremo immagini tratte a adattate dal nuovo poster, escludendo però i ruoli, che ad oggi sono ancora in versione beta. Chiaramente, in futuro, se e quando saranno ufficialmente validati, non mancheremo di parlarne.
Disciplinare la strategia aziendale
La macroarea Disciplined Initiative fornisce un quadro d’insieme dei processi e delle azioni da implementare per ottenere un’efficace integrazione tra le iniziative di business e le derivate azioni intraprese dall’IT, siano esse relative a nuovi prodotti o alla trasformazione di servizi in essere.
L’obiettivo primario è quello di consentire una governance chiara e trasparente delle diverse iniziative di un’organizzazione IT, consentendo di misurarne il valore e i benefici ottenuti.
Process blade
DA2 contempla quattro processi espliciti (definiti process blade) a supporto di tale obiettivo: Product Management, Portfolio Management, Enterprise Architecture e Reuse Engineering.
Tutti e quattro questi processi sono strettamente legati tra loro da una fitta rete di dipendenze, mai gerarchiche, ma sempre cicliche e in chiaro allineamento con la logica di continuous and fast feedback del mondo Agile.
Nello specifico, gli archi relazionali rappresentati nel poster evidenziano gli elementi di congiunzione, gli “artefatti” se si vuole, che i diversi process blade si scambiano per allinearsi sugli aspetti che li condizionano in modo congiunto. Di seguito vedremo un po’ meglio i processi espliciti.
Product Management
Il Product Management process blade si occupa della gestione dei prodotti da realizzare dalla propria organizzazione o, se siamo al di fuori dell’ambito puramente IT, dalla propria divisione di Information Technology.
Un prodotto può essere associato ad un unico progetto o diviso in più sotto-progetti, associati a uno o più team (DAD team), cosa che richiede una esplicita azione di coordinamento gestita da uno specifico Program Team coordinato da un Leadership (sub) Team.
Le responsabilità del Program Team
Nel caso di un solo progetto e un solo team afferente, il Leadership Team e il DAD sub–team relativo saranno, chiaramente, lo stesso. Indipendentemente dalle dimensioni, il Program Team ha in carico diverse responsabilità primarie:
- Business concerns: si tratta degli aspetti di business legati al prodotto che vengono gestiti dal sub-team di Product Management (o anche Product Owner Team) formato dai Product Owner dei diversi team di sviluppo coinvolti.
- Technical concerns: focalizzati sugli aspetti architetturali di riferimento del prodotto, sono indispensabili per avere un allineamento tra i vari progetti annessi. La relativa gestione è affidata all’Architecture sub-team (o anche Architecture Owner team) di cui fanno parte gli Architecture Owner dei differenti team.
- Management concerns: relativi agli aspetti afferenti direttamente alla gestione e all’organizzazione del team, lavorando in stretto contatto il People Management process blade di cui parleremo nel prosieguo. Anche qui il sub-team (Product Delivery team o Management team) è formato dall’insieme dei Team Lead dei vari team coinvolti.
- Itself: si tratta degli aspetti relativi al coordinamento dei differenti Leadership (sub) Team, garantendo il fatto che essi lavorino in stretta sinergia e si occupino efficacemente degli aspetti generali e di quelli afferenti ai singoli team. Tipicamente, tali attività sono affidante ad un Program Manager.
I compiti del Product Owner Team
La complessità di gestione è direttamente proporzionale a quella del prodotto e ciò rende particolarmente delicato il compito del Product Management (Product Owner) team a cui spetta di allineare l’iniziativa IT a quelle di business, andando a focalizzarsi sui seguenti elementi:
- Identifying the initial scope of the program: si tratta di identificare le opportunità e i bisogni degli stakeholder che spingono alla messa in campo della nuova iniziativa.
- Ongoing requirements elicitation: i requisiti vengono definiti, discussi, allineati e validati, con il supporto diretto dei diversi team, riducendo al minimo il feedback loop e coinvolgendo tutti gli stakeholder interessati.
- Assigning requirements to sub teams: i requisiti vengono presi in carico dai diversi Product Owner e quindi assegnati ai relativi team di riferimento.
- Managing requirements dependencies: è necessario individuare le dipendenze tra i diversi requisiti e gestirle adeguatamente in modo da mantenere il processo di sviluppo efficiente.
- Developing a product roadmap, va definita una road-map di riferimento dei rilasci, allineata con le aspettative e le esigenze del business e degli stakeholder.
Come evidenziato dalla figura 4, il Program Owner team è coordinato da un Chief Product Owner che può essere eletto tra i differenti PO o esplicitamente ingaggiato con tale compito esclusivo. Resta fondamentale che il team si allinei periodicamente e sia in grado di auto-organizzarsi per rispondere al meglio ai diversi cambiamenti che sicuramente interesseranno l’intero processo di realizzazione del prodotto.
Gli artifacts del processo Product Management
Come evidenziato dal poster, il Product Management process blade è l’unico ad avere esclusivamente artefatti in output (->) che vanno a condizionare il resto del sistema organizzativo, evidenziando implicitamente come si tratti del fulcro delle decisioni strategiche:
- Epic & Features [-> Solution Delivery]
- Work Items / Stories [-> Solution Delivery]
- Business Roadmap [-> Enterprise Architecture, Portfolio Management e Disciplined Dev]
- Strategic Themes [-> Portfolio Management]
Tutti questi artefatti sono abbastanza noti per cui non ci si soffermerà su di essi in questo contesto.
Portfolio Management
Ogni nuovo prodotto genera una serie di iniziative da perseguire che vengono gestite grazie al Portfolio Management process blade, pensato per supportarne l’identificazione, l’organizzazione e la governance.
È doveroso evidenziare come DA2 interpreti il Portfolio in modo diverso rispetto a quanto fatto tipicamente da altri framework di Scaling, SAFe [3] in primis, contemplando, appunto, solo le attività annesse all’IT, mentre molte di quelle relative agli aspetti di business sono gestite tramite il suddetto Product Management process blade.
Sette obiettivi specifici per il Portfolio Management
Attraverso 7 obiettivi specifici, il Portfolio Management process blade si occupa di ottimizzare le azioni scatenate dall’approvazione di un nuovo prodotto o una nuova release:
- Identify potential value: individuare le iniziative IT che rappresentano una potenziale opportunità.
- Explore potential endeavors: esplorare ed approfondire gli aspetti relativi a nuove potenziali iniziative, soprattutto se appartenenti a un nuovo dominio e quindi particolarmente rischiose.
- Prioritize potential endeavors: priorizzare le iniziative andando a bilanciare i diversi fattori afferenti, dal valore alle scadenze improrogabili come quelle legate ad una normativa.
- Initiate endeavors: mettere in cantiere la nuova iniziativa sfruttando anche approcci esploratori (lean-startup oriented) per validare concretamente la validità di mercato di una nuova iniziativa.
- Plan IT capability: allocare le risorse necessarie a realizzare la nuova iniziativa (ossia prodotto).
- Manage vendors: curare tutti gli aspetti relativi ai fornitori, in modo da allinearli agli obiettivi specifici.
- Govern the portfolio: “governare il portfolio”, ossia allinearlo e rivederlo in funzione dell’evoluzione a breve e medio termine delle iniziative e del prodotto in generale.
Il flusso di relazione con gli altri process blade e i diversi aspetti organizzativi è riassunto nella figura 5 che evidenzia come l’attività di Portfolio Management “attinge” e condivide informazioni con le diverse funzioni al fine di riallinearsi costantemente con lo stato reale delle attività grazie a quella che viene definita Development Intelligence.
Gli artefatti del Portfolio Management Workflow
In merito a questa tipologia di rappresentazione (che DA2 chiama semplicemente Workflow), è importante sottolineare che sugli archi è evidenziato il modo in cui vengono scambiate le informazioni, a differenza del poster dove invece, come già evidenziato, sono riportati gli artefatti scambiati.
Se si guarda agli artefatti in input (<-) e output (->) si evidenziano i seguenti elementi:
- New Initiative [-> Solution Delivery]
- Strategic Themes [<- Product Management]
- Business Roadmap [<- Product Management]
- Technology Roadmap [<- Enterprise Architecture]
Enterprise Architecture
Se il Product e il Portfolio process blade si occupano delle iniziative annesse a uno specifico prodotto, è evidente come nel complesso sia necessaria una specifica azione di omogeneizzazione degli aspetti portanti organizzativi e tecnologici. Questo porta alla necessità di avere un’efficace — e possibilmente efficiente — Architettura Enterprise. Per chi non avesse dimestichezza con il concetto di Enterprise Architecture (EA) è utile riportare una delle sue definizione più apprezzate:
“L’Enterprise Architecture descrive la struttura di un’organizzazione, nonché i suoi processi operativi, i sistemi informativi a supporto, i flussi informativi, le tecnologie utilizzate, le localizzazioni geografiche e i suoi obiettivi.”
Si tratta, quindi, di una sorta di “big picture” aziendale: nulla a che vedere con l’architettura software di uno specifico prodotto. Da questa si evidenzia tutta l’importanza e la responsabilità di effettuare scelte che tengano conto sia del contesto attuale sia di quello a tendere.
Un approccio disciplinato in cui le divere aree sono allineate è indispensabile, diventando così volano di un cambiamento e un rafforzamento progressivo dell’intera organizzazione. Per tale motivo, DA2 contempla la specifica figura di Enterprise Architect che ha il compito di supportare la definizione e l’evoluzione proprio dell’architettura enterprise.
Gli elementi dell’Enterprise Architecture
In ottica di delivery di soluzioni software, possiamo evidenziare i principali elementi che rendono l’EA un fattore abilitante al suo successo:
- Common architecture enables agile teams to focus on value creation: la presenza di una EA consolidata consente ai team di non “reinventare la ruota”, e questo avviene, ad esempio, utilizzando metodologie di sviluppo rodate e asset già sviluppati. In tal modo ci si concentra solo su ciò che è necessario per perseguire una nuova iniziativa e quindi creare nuovo valore per l’organizzazione.
- Common technical guidance enables greater consistency: standard e convenzioni consentono di aumentare sensibilmente la qualità di quanto realizzato, favorendo una condivisione del know-how e la possibilità di spostamento dei diversi membri tra i vari team.
- Agile architectures enable disaggregation: avere architetture (software) agili, intese come microservizi con basso accoppiamento, favorisce la possibilità di suddividere più agevolmente le attività tra più team in modo da ridurre sia la complessità che il time-to-delivery / time-to-market.
- Common infrastructure enables continuous delivery: processi e infrastrutture di delivery automatizzate e consolidate — leggasi DevOps — consentono di velocizzare e rendere particolarmente efficaci le operazioni annesse.
- Enterprise architecture scales agile: una valida EA, supportata da un approccio disciplinato, consente di scalare orizzontalmente le strategie agili all’interno dell’area IT.
Otto obiettivi per una Enterprise Architecture disciplinata
DA2 contempla otto obiettivi primari nella definizione di una disciplined agile EA, rappresentati nella mind-map di figura 6.
Le possibili strategie d’azione connesse al quadro delineato nella mappa mentale appena vista sono le seguenti:
- Support stakeholders: l’Enterprise Architect lavora regolarmente con il business e l’IT per “accogliere” le loro necessità e creare un’architettura condivisa.
- Support delivery teams: il supporto al team di delivery è focalizzato sulla realizzazione di soluzioni e iniziative di qualità e inclini al riuso.
- Negotiate technical dependencies: vengono negoziate le opportune soluzioni alle dipendenze tra i diversi progetti.
- Tailor architectural framework: viene incentivato l’utilizzo di framework, sia tecnici che metodologici, a supporto della realizzazione dei diversi prodotti.
- Explore architectural views: i differenti punti di vista e il loro opportuno bilanciamento sono la vera ricchezza di una valida architettura enterprise.
- Evolve enterprise architecture: ogni aspetto dell’architettura evolve costantemente grazie ad una continua iterazione tra l’architetto e i diversi stakeholder.
- Capture enterprise architecture: l’architettura può essere, tipicamente, “catturata” in due modi, tramite documentazione oppure tramite live artifact e traning session. Quest’ultimo metodo è chiaramente il preferito in un ambito Disciplined Agile.
- Govern architecture: governare l’architettura significa coordinarne la direzione e darle una coerenza di fondo, lasciando costantemente aperte a tutti gli stakeholder le possibilità di collaborare alla sua evoluzione.
Come per gli altri process blade, anche l’Enterprise Architecture ha una fitta rete di relazioni e dipendenze con il resto degli elementi e processi dell’organizzazione.
Più process blade a un solo team: è possibile
Da evidenziare che alcune organizzazioni possono scegliere di affidare a uno stesso team la responsabilità di più process blade: è il caso, ad esempio, di EA e Reuse Engineering che sono fortemente legati tra di loro.
Anche in questo caso, troviamo specifici artefatti di input (<-) e di output (->):
- Technology Roadmap [-> Portfolio Management & Reuse Engineering]
- Technology Roadmap & Guidance [-> Disciplined DevOps]
- Business Roadmap [<- Product Management]
Reuse Engineering
Come evidenziato, uno degli aspetti portanti dell’Enterprise Architecture è quello di individuare e favorire una organizzazione in virtù della quale gli asset tecnologici (ma non solo) possono essere riutilizzati, diventando un elemento di valore indipendente dal prodotto di riferimento. DA2 propone uno specifico process blade denominato Reuse Engineering che ha lo scopo di creare una strategia di supporto, gestione e governance alla realizzazione di asset riutilizzabili.
Un approccio disciplinato a questi aspetti porta ad una serie di benefici evidenti:
- Quicker time to market: quanti più elementi è possibile riutilizzare, tanto meno sarà necessario realizzarne di nuovi e quindi tanto più si potrà essere veloci nel rilascio dei nuovi prodotti; semplice e ovvio.
- Improved return on investment: il riutilizzo di elementi già sviluppati aumenta sensibilmente il relativo ritorno economico rispetto all’investimento fatto per realizzarli.
- Improved consistency: il riutilizzo degli stessi componenti, piuttosto che la creazione di più componenti con funzionalità similari, favorisce una consistenza generale nei prodotti realizzati, consentendo anche una maggiore comprensione delle architetture software di riferimento.
- Easier updates to common functionality: diventa più agevole aggiornare le funzionalità comuni — che spesso si tramutano in layer di servizi infrastrutturali — e intervenire per la relativa manutenzione.
Gli obiettivi del Reuse Engineering
Tali benefici sono supportati da specifici obiettivi strategici di riferimento:
- Obtain assets: esistono diversi modi per ottenere asset riusabili che vanno dallo sviluppo interno, in linea con i criteri di riusabilità, all’approvvigionamento di specifiche soluzioni esterne: si pensi ai framework open source.
- Publish assets: è fondamentale avere un repository di condivisione per i propri asset riusabili, altrimenti gli stakeholder potrebbero addirittura ignorarne l’esistenza.
- Support delivery teams: il reuse engineering team può supportare i team di delivery in molti modi che spaziano dal training on the job alla formazione frontale. Il supporto è però anche indiretto attraverso le attività congiunte con l’Architecture Owner nella creazione di architetture in grado di riutilizzare il più possibile i diversi asset o crearne di nuovi riutilizzabili.
- Evolve assets: gli asset riusabili, come qualsiasi altro elemento tecnologico e organizzativo, si modificano nel tempo. Essi evolvono, si specializzano e vengono ritirati quando ormai sono obsoleti. Il team di reuse engineering supporta tutti questi aspetti riducendo al minimo l’impatto di questo necessario processo di evoluzione e obsolescenza.
- Fund reuse: le azioni di reuse engineering hanno un costo e ogni organizzazione deve decidere come coprirlo. È possibile immaginare di far pagare un costo ai team che riutilizzano gli asset, ma ciò ha un effetto contrario perché più riutilizzano e più pagano, spingendoli a non riutilizzare nulla. Probabilmente un approccio migliore è quello di inquadrare i costi negli aspetti di gestione generale e non associarli direttamente agli asset o a un singolo prodotto.
- Govern reuse: come per tutte le altre azioni di governance disciplinate, anche in questo caso la stessa è improntata su un approccio minimale e collaborativo.
I rischi del Reuse Engineering
Bisogna sottolineare che l’azione di riuso e, di conseguenza, il process blade di Reuse Engineering, è estremamente difficile da mettere in pratica essendo presenti un nutrito numero di fattori di rischio:
- There is a greater impact when reusable assets break: gli asset possono diventare dei colli di bottiglia e imbrigliare l’evoluzione dei sistemi poiché una loro modifica potrebbe essere troppo impattante sull’intero portfolio dei prodotti realizzati.
- Teams must go beyond the reuse of source code: non bisogna pensare al riuso in termini di codice, ma è più opportuno considerarlo a livello di componenti, servizi e altro, focalizzandosi sul comportamento e sull’interazione.
- Reuse requires enterprise awareness on IT delivery teams: bisogna avere consapevolezza dell’esistenza degli asset e del beneficio complessivo del loro utilizzo.
- Reuse requires investment: per creare e gestire asset riusabili è necessario coprire diversi investimenti, che vanno dal reuse engineering team al repository di gestione.
- Your approach to funding will make or break reuse: la strategia di funding è fondamentale per bilanciare positivamente il rapporto costo/benefici.
Per il Reuse Engineering process blade abbiamo un artefatto di input (<-) ed uno output (->):
- Technology Roadmap [<- Enterprise Architecture]
- Reusable Assets [-> Disciplined DevOps]
Conclusioni
In questo secondo appuntamento abbiamo esplorato la prima macroarea di DA2, Discipline Initiative: attraverso gli specifici process blade e i relativi archi relazionali, ha l’obiettivo di allineare le differenti iniziative al fine di massimizzarne il relativo valore. Nel prossimo appuntamento ci concentreremo su Disciplined DevOps, cuore pulsante dell’intero framework.
Nel frattempo vi invito a contattarmi per feedback e domande, tramite mail, Twitter o anche tramite il gruppo Agile@Scale Italy su LinkedIn.
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).