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 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.