Agile Life

gennaio 2013 - Post

DAD, Ruoli e Skill Professionali

Un aspetto assolutamente distintivo di DAD è l’individuazione di un numero relativamente ampio di Ruoli e Skill professionali afferenti ad un DAD Team, distinguibili in

    • Ruoli Primari, che accompagnano l’intero ALCM del progetto;
    • Ruoli Secondari, che sono “spot” in base alle esigenze.

dad roles

DAD Roles and Skills (DAD Book)

Prima di evidenziare le caratteristiche specifiche dei vari ruoli, cerchiamo di rispondere ad una semplice ed ovvia domanda:

“perché rispetto alle pratiche CORE Agile (Scrum in primis) DAD contempla così tanti Ruoli?”

Ebbene, la risposta è “semplice” ed è intrinseca allo scopo stesso per cui DAD è stato creato: accompagnare l’interno ciclo di vita del sistema e non una sua fase specifica. Ecco perché DAD prevede, ad esempio, un Architecture Owner, figura non necessaria in Scrum perché tale metodologia non è contemplato l’aspetto Architetturale in modo diretto, ma solo come elemento di Design implicito all’interno delle Iterazioni (Sprint). Al contrario Agile Modeling contempla tale figura perché è più orientato alla modellazione del dominio e alla soluzione architetturale.

Chiarito tale aspetto, possiamo ora evidenziare i ruoli e le loro specificità:

Ruoli Primari

    • Stakeholder.  Uno Stakeholder è qualcuno “interessato” materialmente al prodotto che si sta realizzando ed ai processi annessi. Il concetto è più ampio del solo “Cliente”, perché interessa anche persone terze, come può essere il responsabile di una divisione aziendale interna che guarda con attenzione il progetto in ottica di miglioramento delle attività complessive (enterprise aware). La stessa struttura IT è uno stakeholder perché, al di là delle persone impiegate fattivamente sul progetto, ogni nuovo prodotto porta un arricchimento del know-how complessivo;
    • Team Member.  Il ruolo di Team Member è quello più ovvio, poiché impegnato fattivamente nella creazione del prodotto (non solo codice!) e quindi nella produzione di Valore per gli stakeholder. Il Team Member si dedica a: stesura del codice, testing, planning, stima dei costi, ecc. Chiaramente è impensabile che ogni componente del Team abbia gli skill necessari per assolvere a tutte le attività richieste, ma sicuramente dovrà avrà una buona base che gli permetta di partecipare alle varie attività: identificare, stimare, realizzare e aggiornare lo stato dei task di propria competenza. E’ interessante notare che rispetto alle metodologie Core Agile, non si parla di “developer” o “programmatore” perché non tutti i membri del Team sono chiamati a scrivere codice;
    • Team Lead.  Il Team Lead (o anche Project Lead) è l’evoluzione in chiave Agile del Project Manager, nella cui nomenclatura è proprio il termine “Manager” a non reggere l’evoluzione, evocando una gestione ed un accentramento di aspetti decisionali quali, ad esempio, pianificazione e stima dei tempi. Il Team Lead, al contrario, è una figura che ha il compito di facilitare e guidare il Team nel processo di “self-organization”, eliminando gli ostacoli che impediscono il raggiungimento degli obiettivi (Goal), come, ad esempio, la scarsa disponibilità di risorse o la necessità di acquisire nuovo know-how specifico. Ulteriore caratteristica di questo ruolo è quello di contemplare il coaching Agile, guidando il Team nell’applicazione pratica dei principi Agili e nel mantenimento del focus rispetto al Valore da produrre, in forte sinergia con il Product Owner.  E’ fondamentale evidenziare che una leadership autorevole è fondamentale per il successo del progetto;
    • Product Owner.  Il Product Owner è l’anello di congiunzione tra il Team, definibile come la “one voice of the customer”.  Il suo principale compito è quello di chiarire i dettagli (requisiti?) rispetto a ciò che dovrà essere realizzato, mantenendo e priorizzando i Work Item e la relativa Work Item List (WIL). Il Product Owner è responsabile di fare chiarezza, interpellando chi di dovere, sui dubbi relativi ai Work Item e al sistema complessivo, lavorando a stretto contatto con il resto del Team in modo da ridurre la necessità della stesura di documenti formali, ad ovvia esclusione di quelli che rappresentano un Valore per gli stakeholder (ad esempio: manuali operativi e documentazione di supporto per terzi). Anche la presentazione (demo) dei risultati ottenuti è, tipicamente, un’attività che rientra nello scope del Product Owner, che comunque si avvale sempre del supporto dell’intero Team;
    • Architecture Owner.  L’Architettura (Intentional Architecture) è lo strumento chiave per catturare i rischi tecnologici annessi ad un progetto ed è, quindi, indispensabile contemplare una figura che si occupi di questo aspetto cruciale. L’Architecture Owner è il mentore Architetturale del sistema e guida il Team nelle scelte inerenti, in particolare nel Design e nella sua evoluzione. Spesso lo specialista che ricopre il ruolo di Architecture Owner è lo stesso che ricopre anche quello di Team Lead, soprattutto nei progetti più piccoli, mentre si tende ad avere due figure diverse quando si impatta su progetti e Team di grandi dimensioni (@Scale). E’ fondamentale precisare che, nonostante, spesso, l’Architecture Owner sia il Senior Developer del Team (noto anche come Technical Architect, Software Architect o Solution Architect), ancora una volta tale ruolo non è un ruolo gerarchico e quindi una persona a cui gli altri membri del Team devono rappresentare il proprio lavoro. Bensì, l’Architecture Owner prende in carico dei Work Item esattamente come ogni altro Team Member anche se, il suo background e le sue competenze, gli permettono di discutere di aspetti più complessi e comportarsi come Mentore con i colleghi meno esperti.

 

Ruoli Secondari

    • Specialist. Lo Specialist è un ruolo in cui viene inquadrato uno Membro del Team con uno skill particolarmente spinto in uno specifico ambito. L’inserimento, temporaneo, di uno Specialist può avvenire per la necessità di “rafforzare” il Team, estendendo gli skill dei Membri a tempo pieno, o quando si raggiunge un livello @Scale che richiede maggiore coordinamento: si pensi, ad esempio, alla necessità di un Program Manager che coordini le attività dei sub-Team;
    • Domain Expert.  Il Product Owner ha un ventaglio di conoscenza tale da riuscire a catturare le esigenze generaliste di più stakeholder afferenti al progetto. Quando però si entra in Domini specifici, ad esempio i Tributi di un Ente Pubblico, potrebbe essere necessario (e a volte è indispensabile) affidarsi ad un Domain Expert che catturi le esigenze inerenti e aiuti il Product Owner a renderle chiare all’intero Team. Attenzione: l’obiettivo è di rendere tali elementi patrimonio di tutto il Team e non di creare un documento formale dei requisiti!
    • Technical Expert.  Il Technical Expert è un professionista esperto in un particolare ambito tecnologico: dalla User Experience (UX) alla Sicurezza (Security Expert). Tipicamente il Technical Expert viene iniettato nel Team per un periodo breve allo scopo di trasferire competenze specialistiche ad uno o più developer (membri del Team impegnati nello sviluppo), interfacciandosi con l’Architect Owner ed il Team Lead;
    • Independent Tester. Nonostante le attività di Test siano tipicamente assolte dal Team stesso, può essere utile contemplare (soprattutto @Scale) il supporto d parte di uno o piùIndipendent Tester (aka Indipendent Tester TEAM) che si occupino di validare parallelamente quanto realizzato. Tali test sono particolarmente utili in domini complessi che contemplano l’utilizzo di tecnologie eterogenee;
    • Integrator. Quando si è in un contesto @Scale con più sub-Team responsabili della realizzazione di sotto-sistemi, l’attività di integrazione di essi può diventa particolarmente complessa e delicata. Mentre caso dei piccoli Team è, tipicamente, l’Architecture Owner ad avere la responsabilità di accompagnare il processo di integrazione, nel caso @Scale può rendersi necessaria una figura ad-hoc che garantisca il raggiungimento dei risultati qualitativi attesi.

 

E’ fondamentale sottolineare in modo esplicito che tutti gli afferenti ai Ruoli (Primari e Secondari), ad esclusione degli Stakeholder, fanno parte del DAD Team! Inoltre i Ruoli non sono da interpretarsi in modo tradizionale, ovvero assegnati ed inderogabili, ma vanno considerati in funzione del progetto specifico (e quindi del relativo Team). Infatti un Architecture Owner può tranquillamente ricoprire il ruolo di Team Member in un altro progetto e viceversa.

In sintesi: quello che è importante in un DAD TEAM è il Team in sé, non gli specifici ruoli, e al suo interno tutti sono uguali se si considera lo scopo ultimo del progetto, ovvero generare Valore per gli Stakeholder.

DAD, Goal-Driven framework

 

Continuiamo nell’affascinate viaggio che ci porta a scoprire ed approfondire il Disciplined Agile Delivery framework.

DAD contempla tre macro-fasi operative che accompagnano il Ciclo di Vita del prodotto:

 

  • Inception (Inizio/Scoperta), si tratta della fase in cui l’idea progettuale nasce, viene approfondita e vengono validati i rischi e le opportunità annesse. Questa fase coinvolge, inoltre, attività di definizione del TEAM, strutturazione degli ambienti di lavoro, ecc;
  • Construction (Realizzazione), si tratta della fase operativa che implica la fattiva realizzazione del sistema;
  • Transition (Transizione), si tratta della fase che accompagna il prodotto in produzione e predispone tutto il necessario per il relativo supporto.

 

Le tre macro-fasi sono Goal-Driven, ovvero contemplano una serie di obiettivi da raggiungere per espletare le diverse fasi che interessano l’ALCM:


Goal Driven Phases (Disciplined Agile Delivery book)

Tale approccio consente al DAD Team di avere sempre ben chiari le problematiche da affrontare e gli elementi da snocciolare affinché il proprio lavoro sia finalizzato alla produzione di Valore per l’azienda e per gli stakeholder di riferimento.
Come in tutti i contesti Agili, tali Goal non vanno presi come ingredienti as-is di una ricetta pre-confezionata ma come un paniere di elementi da considerare per la propria attività. A tal proposito mi piace riportare quanto affermato da Ambler e Lines:

“…This means that you do not use a cookbook approach to deliver your solutions but rather adapt your techniques to follow the path that is best suited to you.”

[…Questo significa che l’approccio non è quello di considerare DAD un libro di cucina che fornisce gli ingredienti obbligatoriamente da usare, ma un insieme di elementi da utilizzare ed adattare al proprio contesto.]

E’ da evidenziare che esistono una serie di obiettivi che sono cross-phases (Ongoing Goals), ovvero non identificabili in una delle specifiche fasi evidenziate e che sono di arricchimento per il Team nel suo insieme, i singoli membri del Team e l’azienda stessa.

 

DaD Manifesto

 

Nel post precedente abbiamo cominciato a descrivere cosa c’è dietro al framework Disciplined Agile Delivery e perché risulta uno strumento decisamente forte e rilevante.

Riprendiamo il discorso con la definizione che gli stessi autori danno di DaD:

“The Disciplined Agile Delivery (DAD) process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value life cycle, is goal-driven,and is enterprise aware.”

in cui si evidenziano le fondamenta del framework stesso:

·         People first;

·         Learning-oriented;

·         Agile;

·         Hybrid;

·         IT solution focused;

·         Goal-driven delivery life cycle;

·         Risk and value driven;

·         Enterprise aware.

Vediamo, ora, di analizzare sinteticamente tutti i punti, cercando di catturarne l’essenza e la loro rilevanza.

People First: le persone e il modo in cui interagiscono/collaborano sono l’elemento primario che porta al successo (o al fallimento) di un progetto IT. Si tratta, inoltre, del primo dei 4 Valori del Manifesto Agile. DaD contempla Team: auto-organizzati (self organizing), auto-disciplianti (o auto-regolati, self-disciplined), indipendenti (self aware).

Learning-oriented: l’apprendimento è tutto. Sia Agile che Lean hanno tale elemento nel proprio DNA e DaD lo abbraccia nelle sue tre dimensioni: di Dominio, di Processo e Tecnico. Il framework promuove diverse strategie per abbracciare l’apprendimento ed utilizzarlo per il successo del progetto.

Agile: è il pilastro su cui si fonda DaD, che ne rafforza ed estende i valori ed i principi, “disciplinando” le attività in modo da massimizzare il Valore prodotto e la soddisfazione degli stakeholder.

Hybrid: DaD fa proprie molte delle pratiche annesse a diverse metodologie di sviluppo. Da Scrum ad XP, da Kanban a Unified Process (non proprio Agile), cercando di ricamare il tutto in quadro efficace ed efficiente per il contesto di riferimento.

IT solution focused: non solo software! Il vero valore è l’intera Soluzione che, oltre al codice, comprende sicuramente altri elementi: dal semplice aggiornamento hardware alla più complessa attività di Business Process Reengineering (BPR). DaD pensa in ottica di una soluzione “chiavi in mano”.

Goal-driven delivery life cycle: i delivery sono basati su Obiettivi che vanno al di là del codice prodotto in ogni singola iterazione. Anzi, lo spettro è ben ambio e per gestirli in modo opportuno, ognuno di essi è associato a tre specifiche fasi: Inception, Construction, Transition.

Risk and value driven: i rischi sono verificati e validati il prima possibile, consentendo così di ridurne le conseguenze. Inoltre il Valore di quanto prodotto è continuamente validato e comprovato dagli stakeholder afferenti.

Enterprise aware: un Team DaD non è una singolarità isolata rispetto al contesto aziendale, bensì interagisce in continuazione con gli altri Team ed il resto dell’azienda per ottenere il massimo in funzione degli obiettivi da raggiungere e per favorire la crescita dell’intera struttura.

 

DaD, Hello World

Normal 0 false 14 false false false IT JA X-NONE

Come tutti gli esperti del settore sanno, quando si apre un libro che insegna un nuovo linguaggio di programmazione, è scontato trovarsi difronte al classico listato “Hello World”.

Ma Disciplined Agile Delivery (DaD) non è un linguaggio di programmazione, bensì un framework per la governance dei progetti IT. In questo caso possiamo assimilare il nostro “Hello World” alla più ovvia delle domande che possono essere poste: perché DaD?

Una risposta esauriente non può essere certo data in poche righe, anzi verrà fuori in modo completo e convincente (spero) nel corso dei post e delle discussioni che si susseguiranno in questo gruppo. Cerchiamo però, ora, di riassumere gli elementi essenziali che possono spingere ad interessarsi di DaD.

Di Agile (e nel caso in cui si ha la fortuna di lavorare in aziende particolarmente attente al proprio processo gestionale, di Lean) si parla da tempo, spesso identificando e confondendo i relativi Valori e i relativi Principi con metodologie specifiche come Scrum ed XP. Ma Agile è molto più: si tratta di un modo diverso di concepire la produzione di software (Servizi) e ciò, qualunque sia la metodologia scelta, richiede una governance dell’intero ciclo di vita: dall’Idea alla Dismissione.

Su questo fronte le metodologie Agili “pure” risultano spesso inadeguate e, paradossalmente, le metodologie Tradizionali (da Waterfall al modello a Spirale) sono strutturate in modo più robusto per accompagnare l’intero Life Cycle Management (LCM).

Le metodologie Agili si concentrano sulla produzione di Valore, ma tale termine viene spesso assimilato alla produzione di codice, che se da un lato è il vero risultato del lavoro di una tipica azienda IT, dall’altro non è detto che sia l’unico costrutto a produrre valore. Un esempio: se gli stakeholder (non il solo Cliente!) richiedono un documento che descriva l’Architettura, tale documento è di per se un Valore e non c’è nessun motivo per sottovalutarne l’importanza, tutt’altro.

Ecco, possiamo considerare DaD come un framework orientato alla produzione di Valore, nell’accezione nobile del termine. E’ fondamentale sottolineare, in modo esplicito, che che DaD non è una metodologia ma, appunto, un framework che armonizza una serie di strumenti per consentire di gestire LCM in modo efficace ed efficiente, sfruttando profondamente il mondo Agile/Lean.

A questo punto si potrebbe obiettare: ma anche con Scrum è possibile gestire la produzione di software. L’affermazione è corretta, ma la produzione è solo una parte dell’LCM e la cosa si accentua nel mondo Enterprise. Si pensi ad esempio alla fase di analisi del Rischio ed Opportunità legate ad una nuova idea progettuale: come gestire la cosa con Scrum? o con XP? Probabilmente molti risponderebbero in modo “tradizionale”, introducendo una fase di Analisi che si avvicina a quanto fatto, ad esempio, con Waterfall. La cosa è più comune di quanto si immagini e, un’indagine di Forrester dello scorso anno (vedasi il post WATER-SCRUM-FALL) evidenzia proprio come quasi il 70% delle aziende mondali utilizzi un approccio ibrido (Agile/Tradizionale) per la gestione dei progetti IT piuttosto che un approccio Agile/Lean puro.

Visti questi dati ed evidenziata la necessità di una serie di strumenti che permettano un Agile Life Cycle Management (ALCM), possiamo rispondere alla domanda del “perché DaD” in modo semplice e chiaro:

DaD fornisce una serie di strumenti armonizzati tra loro (framework) utili ad una proficua gestione del Ciclo di Sviluppo del Software in chiave Agile.

In fin dei conti perché reinventare la ruota se Scott Ambler e Mark Lines, due Guru in ambito ALCM, hanno fatto il lavoro per noi? Semplice, non c’è nessun motivo! Quindi avanti con DaD e con la sua applicazione nei contesti operativi che ci vedono impegnati.


E’ doveroso evidenziare come DaD non sia l’unico framework pensato per l’ALCM. Possiamo, ad esempio, citare lo Scaled Agile Framework (SAFe) di Dean Leffingwell, che rappresenta una valida alternativa. Tuttavia DaD si adatta praticamente a progetti e contesti di tutte le dimensioni e supera alcune problematiche ostiche come la gestione di più Team che collaborano sullo stesso progetto: in tale frangete SAFe suggerisce di usare l’approccio Scum of Scrums, ma questo si è rilevato ostico e non particolarmente efficace.

Sperando di aver dato sufficienti elementi per lo Start del gruppo, chiudiamo questo primo post sul tema con la definizione che Lines dà di DaD:

“The Disciplined Agile Delivery (DAD) decision process framework  is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value life cycle, is goal-driven, and is enterprise aware.”