Agile Life

febbraio 2013 - Post

DAD, Enterprise Aware

Tranne se si è in una fase di start-up, è fortemente probabile che il nuovo progetto che si è chiamati a realizzare debba fare i conti con un contesto ben definito, proprio dell’azienda specifica, che abbraccia aspetti tecnici/organizzativi/economici.

Si tratta della Company Awareness, ovvero dell’essere “consapevoli” del contesto in cui ci si sta muovendo al fine di garantire il successo del nuovo progetto tramite una corretta strategia di governance.

La Company Awareness è un fattore chiave dei DAD, spingendo il professionista a ragionare in termini aziendali, e non personali, e abbracciando una strategia con chiari obiettivi di arricchimento dei vari asset aziendali. Si pensi, ad esempio, ad un Team che debba affrontare lo sviluppo di un nuovo sistema: è tipicamente più producente, sotto ogni punto di vista, sposare le tecnologie comunemente utilizzate in modo da riutilizzare moduli e competenze, oltre che arricchire il know-how complessivo di nuovi elementi.

La “consapevolezza” si basa su una serie di presupposti:

  • Lavorare a stretto contatto con i colleghi (whole enterprise mindset)

Il primo collega a cui far riferimento è sicuramente l’Enterprise Architect, in modo da avere una visione d’insieme della strategia aziendale e preparare la specifica Vision di Progetto. Il Software Architect è il riferimento ideale per avere indicazioni in merito agli aspetti IT dell’azienda, così come i vari Specialist IT Architect (Data, Security, ecc.);

  • Adottare e seguire le linee guida aziendali (guidance)

La propria organizzazione è probabilmente dotata di linee guida (guidance) che è doveroso seguire, evidenziando, eventualmente, dove è opportuno discostarsi da esse. Il loro utilizzo favorisce la Consistency (coerenza) e la Maintainability(manutenibilità) e impatta, ad esempio, su: convenzioni nella scrittura del codice, user interface, security, ecc…;

  • Sfruttare le risorse aziendali (assets)

Il riutilizzo degli asset aziendali è fondamentale, permettendo di massimizzare il ritorno dell’investimento relativo e diminuire l’effort specifico di ogni nuovo progetto. In modo molto esemplificativo si pensi al riutilizzo di una libreria di servizi comune all’intera infrastruttura IT aziendale. Il tutto permette, inoltre, di rafforzare e far evolvere gli elementi riutilizzati, oltre a renderli più maturi;

  • Migliorare gli aspetti organizzativi (organizational ecosystem)

L’utilizzo di DAD permette di migliorare gli aspetti organizzativi aziendali, soprattutto in quelle società che adottano un processo di sviluppo classico o che non ne adottano alcuno. Ciò avviene con un forte coinvolgimento dell’Enterprise Architect, oltre che dalle varie figure chiave IT/NON-IT;

  • Adottare una cultura DevOps (DevOps culture)

I membri di un DAD Team ragionano in modo naturale in ottica DevOps, abbracciandone cultura e strategia, vista l’importanza della sinergia tra sviluppo ed erogazione;

  • Condividere la conoscenza (know-how sharing)

I DAD Team sono per propria natura learning-oriented, e uno dei modi migliori per apprendere è quello del trasferimento diretto di know-how. Così come è fondamentale far proprie le esperienze/competenze altrui, i membri di un DAD Team devono essere preparati a condividere la propria conoscenza (ed i propri miglioramenti) con il resto dell’azienda. Tale “trasferimento” può avvenire in più modi: diretto, wiki, conferenze, ecc…;

  • Adottare un’appropriata strategia di governance (governance)

La scelta di una corretta strategia di governance è essenziale. Tipicamente un progetto che adotta DAD predilige una governance basata sulla motivazione, fiducia e collaborazione, affiancando il tutto con una strategia focalizzata all’abbattimento delle barriere che possono rappresentare un limite per lo svolgimento ottimale delle attività del Team.

Come ottenere tale risultato dipende, chiaramente, dal contest specifico, tenendo sempre presente quelle che sono le line guida in essere.

Quello che andrebbe evitato (il condizionale è in questo caso d’obbligo) è un approccio di tipo command-and-control, fortemente burocratizzato e gerarchico che, per inciso, è tutt’altro che Agile;

  • Approcciare ad un monitoraggio chiaro ed aperto (clean-and-open)

La fiducia è alla base di una efficace strategia di governance, ma è pur vero che un approccio intelligente spinge ad avere una soluzione del tipo “trust but verify and then guide” (che con un po’ di libertà potremmo tradurre in: “dare fiducia, ma verificare i progressi e guidare l’evoluzione”).  Il monitoring di un progetto è fondamentale, sia per essere certi di impiegare in modo valido le risorse (tra cui i membri del Team) sia per evidenziare eventuali impedimenti che vanno rimossi. Tale obiettivo può essere raggiunto attraverso una serie di metriche quanto più automatizzate possibile (in modo da non produrre ulteriore effort), condivise con il Team e gli Stakeholder al fine di favorire un auto-miglioramento,

In sintesi, perché essere Company Awareness è così importante? La risposta è individuabile in tre fattori primari:

  • Ottimizzazione (riduzione) dei tempi e dei costi, grazie ad un apprendimento ed utilizzo degli asset esistenti: inutile reinventare la ruota!
  • Incamminarsi nella direzione giusta, lavorando a stretto contatto con chi ha una visione d’insieme del contesto aziendale (enterprise professionals);
  • Contribuire a far evolvere l’intera organizzazione e non solo quella afferente al proprio progetto, in un’ottica di apprendimento continuo (continuous learning).

Il raggiungimento di tale obiettivo è chiaramente un fatto Culturale che deve superare anche i pregiudizi degli Agilisti “puri” che ritengono tutto ciò un inutile overhead. Un secondo aspetto è quello di Capire come attuare tale obiettivo, cosa non di poco conto visto le diverse esperienze che possono caratterizzare il panorama aziendale interno. Si tratta di una Sfida fondamentale che richiede forte disciplina e sforzo, ma che da enormi benefici, sia aziendali che personali, tanto da legare indissolubilmente DAD al concetto di enterprise aware, caratterizzando il framework a partire dalla fase di Inception (Goal: Align with enterpsise direction, obiettivi in rosso).

aware inception

Chiaramente il tutto interessa anche i Goal trasversali, ovvero i General Goals, ed in particolare:Leverage and Enhance Existing Infrastructure (obiettivi in rosso).

aware general goals

DAD, 3C Rhythm

 

Il concetto di qualità è uno di quelli maggiormente abusati non solo nel contesto IT ma in qualsiasi ambito produttivo. L’obiettivo è, ovviamente, sempre quello di ottenere una soluzione ottimale in funzione del contesto e favorire il miglioramento di quest’ultimo.

In particolare, nel tempo, sono stati sviluppati dei modelli per il miglioramento della qualità generale a medio-lungo termine, tra cui uno dei più noti è il Ciclo di Deming (Deming Cycle) che prevede un miglioramento costante grazie ad una interazione tra ricercaprogettazionetestproduzione evendita. Il Ciclo si basa su quattro fasi (PDCA):

  • P - Plan. Pianificazione;
  • D - Do. Esecuzione del programma, dapprima in contesti circoscritti;
  • C - Check. Test e controllo, studio e raccolta dei risultati e dei riscontri;
  • A - Act. Azione per rendere definitivo e/o migliorare il processo

deming-wheel4

Ciclo di Deming

DAD contempla al suo interno un modello di qualità che prende il nome di 3C Rhythm, ovvero unRitmo (o se vogliamo Cadenza) scandito su tre Accenti: CoordinateCollaborate e Conclude.

3C rhythm è concettualmente simile al Deming Cycle:

  • Coordinate::Plan
  • Collaborate::Do e parte di Ceck
  • Conclude::parte di Check ed Act

3c rhythm

3C Rhythm

Nella figura precedente si evidenzia come il 3C si mappa sugli elementi temporali che contraddistinguono DAD:

  1. Release. In questo caso gli Accenti sposano 1 a 1 le tre fasi del framework:
    1. Coordinate::Inception;
    2. Collaborate::Construction;
    3. Conclude::Transition.
  2. Iteration. Una iterazione DAD comincia con l’Iteration Planning, dove il Team identifica in dettaglio i task che dovranno essere realizzati, completando una prima attività di modellazione. Successivamente si passa alla Collaboration in cui la soluzione (codice, testing, ecc…) viene implementata, per poi concludersi finalizzando la soluzione, effettuando le dovute verifiche (es: batteria di test automatizzati), valutando i risultati e i possibili miglioramenti da apportare alle attività, e mostrando il tutto ai key stakeholder. In sintesi si ha:
    1. Coordinate::Iteration Planning;
    2. Collaborate::Development;
    3. Conclude::Stabilize.
  3. Day. Una tipica attività giornaliera comincia con un breve Coordination Meeting in cui si discute dei task sviluppati nel giorno precedente e di quelli che si andranno a realizzare. Il Core della giornata è impiegato per completare parte dei task previsti per l’Iterazione, mentre il tutto si può conclude, caso ideale, con una build funzionante. In questo scenario si ha:
    1. Coordinate::Coordination Meeting;
    2. Collaborate::Daily Work;
    3. Conclude::Stabilize.

In conclusione, 3C interessa l’intera organizzazione che decide di abbracciare DAD, cadenzando le varie fasi ed attività.

 

Enterprise Architecture and Enterprise IT Architecture

Non di rado si sente parlare di Architettura Enterprise (Enterprise Architecture), riferendosi ad essa come l’Architettura di una complessa soluzione IT.

In realtà bisogna dire che il termine Enterprise Architecture ha un’accezione più ampia e complessa, non riferita esclusivamente all’aspetto informatico. Anzi, l’aspetto è paritario rispetto ad elementi quali: procedure operative, aspetti finanziari, aspetti logistici, marketing, ecc…

Si tratta di definire un Big Picture aziendale per raggiungere tre obiettivi primari:

  • Individuare e definire i cambiamenti necessari a raggiungere gli obiettivi aziendali;
  • Definire la governance per gestire i cambiamenti;
  • Preparare l’azienda ad abbracciare i cambiamenti e gestire i rischi.

In questo scenario è utile chiarire anche un ulteriore aspetto che spesso genera confusione, ovvero quello legato alle varie “tipologie” (se così si può dire) di Architect presenti in azienda.

L’utilizzo di Enterprise Architect in ambito puramente IT non è corretto e non bisogna incorrere nell’errore di definirsi “Enterprise Architect” solo per indicare che la propria attività è legata ad un ambito complesso. Per quanto possa sembrare un puro elemento lessicale, soprattutto in ambito IT, esistono profonde differenze tra un Enterprise Architect ed un Software Architect (che poi si specializza a sua volta).

architects

Architects

Partendo dalla figura 16 possiamo distinguere “gli Architect” in tre categorie:

  • Enterprise Architect, focalizzato sull’intero spettro aziendale e non su uno specifico dominio (IT, Process, Marketing, ecc). Si tratta di un professionista in grado di destreggiarsi abilmente tra i vari domini aziendali, anche senza avere competenze fortemente verticali in esse (deep knowledge). L’obiettivo di un Enterprise Architect è quello di guidare i vari asset aziendali per raggiungere i Goal prefissati, avvalendosi di strumenti come il TOGAF e lo Zachman Framework;
  • Software Architect, si tratta di un professionista focalizzato sull’aspetto IT del più ampio contesto Enterprise. In particolare il Software Architect è un professionista a cui viene demandata la responsabilità di scegliere le caratteristiche peculiari di un sistema IT. Nel caso di un Chief Software Architect la sua attività impatta direttamente sull’Enterprise IT Architecture;
  • Data Architect, Security Architect, Infrastructure Architect, ecc… hanno un ruolo diametralmente opposto: dispongono di una forte competenza verticale (deep knowledge), ma hanno una visione limitata al necessario del contesto aziendale. Questo evidenzia come siano di supporto al (Chief) Software Architect per affrontare le issue afferenti al proprio settore;
  • Solution Architect, ha uno skill molto specializzato, relativo a singole tecnologie o singoli prodotti.

Tipicamente questi ruoli, nonostante siano facilmente delineabili, vengono spesso assegnati ad una stessa persona, aumentando la confusione relativa alla loro specificità.

Tipicamente il Chief Software Architect è chiamato ad “abbracciare il cambiamento” in funzione delle nuove esigenze di business e all’evoluzione del mercato. Tale attività assorbe fin anche al 90% del proprio lavoro, relegando il restante 10% ad attività di management interno.

In sintesi: il Chief Software Architect è chiamato a produrre l’IT Vision Aziendale.

Il Chief Software Architect lavora congiuntamente con l’Enterprise Architect per definire le strategie di innovazione, focalizzandosi sugli obiettivi di Business (Goal). In particolare possiamo evidenziare le seguenti attività:

  • Implementare/Far Evolvere/Ottimizzare la metodologia di process e solution management;
  • Innovare le soluzioni IT in essere presso l’azienda tenendo presenti:
  1.  
    1. esigenze aziendali;
    2. trend di mercato;
    3. potenziali opportunità.
  • Stimare gli investimenti (in particolare il TCO) necessari per l’adozione (modernizzazione) di nuove tecnologie;
  • Stimare il possibile ROI derivante dalle innovazioni ipotizzate.

Un elemento accomuna i “vari” Architect: la necessità di essere continuamente aggiornati, sfruttandocanali ufficiali (IEE, ACM, ecc) e canali generici (Blog, Twit, ecc), e la voglia di migliorarsi continuamente, proponendo sempre soluzioni più efficaci ed efficienti, derivanti spesso da attività di ottimizzazione di quanto già in essere nel contesto aziendale.

DAD, Non-solo Programming

Devo ammetterlo, prima di approfondire con DAD la questione del non-solo Programming, la mia associazione era di 1:1 con il pair-programming di XP, ovvero la programmazione congiunta da parte di due sviluppatori davanti allo stesso computer.
La pratica non ha mai riscosso la mia particolare simpatia, sia perché non sempre è facile trovare il collega con cui sviluppare congiuntamente, sia perché i costi della relativa applicazione portano facilmente fuori budget il progetto.

In realtà bisogna riconoscere che il non-solo programming ha una sfumatura decisamente più raffinata, che non minimizza la questione alla "sola" scrittura di codice, ma la estende ad ogni aspetto del progetto, compresi quelli più avanzati.

nonsolo programming

Si pensi al Design: discutere con uno o più colleghi di soluzioni che abbraccino domini complessi è sicuramente più produttivo e costruttivo rispetto ad affrontare in solitario la questione. Inoltre questa pratica favorisce in modo naturale la condivisione del know-how, riducendo la necessità di documentazione. Anche la concentrazione e la motivazione trae beneficio dal lavorare "in coppia", visto che si è spronati a dare il massimo durante la propria attività.
Nel caso specifico della scrittura del codice si ottiene un miglioramento qualitativo generale di quanto realizzato, diminuendo la necessità di review dello stesso ed evitando di focalizzarsi su elementi di scarsa efficacia. Un caso specifico in cui è buona norma applicare il non-solo development è quello che vede coinvolti un senior ed uno junior developer, al fine di trasferire "sul campo" know-how e nozioni specifiche del dominio.
Un ulteriore ambito in cui il non-solo development dà grandi benefici è l'avvicendamento dei membri del team o il trasferimento delle attività di manutenzione a DevOps terzi: si abbattono così i tempi necessari al passaggio di consegne e si evitano di creare lacune che poi sono difficili da colmare, anche in presenza di documentazione aggiornata realizzata con la tecnica del Document Continuously.
Fattore da non sottovalutare, infatti, è l'abbattimento della dipendenza dal singolo sviluppatore che, così, smette (o almeno limita) di essere un "single-point-of-failure" perché il know-how specifico è condiviso con almeno un ulteriore membro del Team. In tal modo se un dev è assente, ad esempio per malattia, un altro membro del team, se necessario, può sopperire alla sua mancanza. Chiaramente ciò implica che quest'ultimo debba rimodulare le proprie priorità affinchè non abbia un over-head di lavoro che porta ad abbattere la propria efficienza.
In sintesi il non-solo programming è una pratica che consolida il Team in gran parte dei suoi aspetti, permettendo di ottenere una soluzione di migliore qualità ed eliminare rischi dovuti al fatto che solo un membro di esso sia in grado di operare su una parte del sistema.

DAD, Non Functional Requirements

 

Abbiamo avuto già modo di parlare ampiamente della questione dei Requisiti non-funzionali (NFRs, o di Qualità) di un sistema software, sia collegando la questione all'(Intentional) Architecture sia alle metodologie Core Agile.
Riprendiamo ora il discorso in ambito DAD.
Come è ormai chiaro, gli NFRs interessano direttamente l'intero sistema e gli stessi requisiti funzionali, anche se spesso sono tralasciati o considerati un "de facto" dagli stakeholder e dagli stessi Membri del Team.
In DAD vengono individuate tre strategie di base per catturare tali requisiti (che ricordiamo possono comprendere: requisiti di sicurezza, di performance, di availability, ecc...):

 

  • Technical Stories. Una "Technical Story" è un'unità documentale che cattura le specifiche caratteristiche di un requisito non-funzionale, consentendo di aggredirlo idealmente in una iterazione. In sintesi una Technical Story sta ad un NFR come una User Story sta ad un FR (Functional Requirement). Esempio: "La pagina web deve essere caricata in 3 secondi", così come: "Il dato deve essere trasmesso con un livello di cifratura a 128bit";
  • Acceptance Criteria. L'adozione dell'Agile implica che una User Story sia considerata completata quando supera i relativi criteri (test) di accettazione. E' possibile far sì che uno o più NFR appartengano ad una User Story e che quest'ultima contempli criteri di accettazioni che implicitamente validino gli annessi NFRs. Esempio: "La pagina web di amministrazione può essere visualizzata solo da un utente di tipo Amministratore" che afferisce ad una User Story del tipo: "Essendo un utente voglio una pagina web per amministrare il sistema";
  • NFRs Explicit List. Questa strategia contempla la "cattura" (documentazione) degli NFRs in un artefatto separato dalla Work Item List (WIL). Si tratta di appoggiarsi a quello che in Unified Process viene definito "supplementary specification", ovvero un documento di riferimento per i test di accettazione dei requisiti funzionali nel loro insieme e non nella specificità.

 


Chiaramente le tre strategie possono essere mixate tra loro all'occorrenza e hanno uno scope diverso: utilizzando una Technical Story si ha una visione legata al task specifico, mentre utilizzando una Explicit List si calano gli NFRs all'interno dell'intero sistema.

nfrs dad strategies

NFRs Capturing Strategies in DAD

In sostanza, ad ogni strategia sono chiaramente associati una serie di vantaggi e svantaggi:

  • Technical Stories. Con questa strategia gli NFRs vengono catturati in modo semplice ed esplicito, diventando parte della WIL. Il problema è che, spesso, gli NFRs sono cross-cutting aspects, ovvero interessano più User Story e difficilmente possono essere implementati all'interno di una singola iterazione. Questo porta con se il rischio che essendo l'item troppo problematico e costoso da affrontare, il Team decida di rimandarne l'implementazione alla ultime iterazione della fase di Construction;
  • Acceptance Criteria. Questo approccio consente di focalizzare il problema in funzione di una User Story, verificandone implicitamente il corretto funzionamento e, quindi, il soddisfacimento dei criteri di accettazione. I dettagli degli NFRs sono tipicamente individuati just in time (JIT), anche se uno stesso NFR può interessare più User Story e, quindi, il Team deve tener conto e bilanciare diverse varie esigenze. Tale strategia enfatizza il ruolo dell'Intentional Architecture come catalizzatore degli NFRs, al fine di ridurre i rischi ed evitare che alcuni di essi vengano dimenticati o erroneamente interpretati;
  • NFRs Explicit list. Questa strategia consente di individuare preventivamente gli NFRs e renderli disponibili per costrutti quali: l'Intentional Architecture, i Test di Accettazione, ecc. Il problema è che la lista può diventare particolarmente complessa e addirittura obsoleta, se non gestita correttamente e "dimenticata" da un Team non particolarmente attento.

Ambler e Lines suggerisco di mantenere una NFRs Explicit List ed utilizzarla per identificare gli opportuni Criteri di Accettazione. Tale soluzione sembra dare il miglior risultato, anche se è richiesta una certa maturità per gestire il processo in modo opportuno.

E' fondamentale sottolineare come per documentare efficacemente gli NFRs sia necessario ricorrere alla tecnica di "continuous documentation", la quale consente di tenere costantemente aggiornati (JIT) i documenti di progetto previsti, ovvero quelli che generano Valore aggiunto.