Agile Life

marzo 2013 - Post

I Quattro Valori dell’Agile Manifesto: quarto valore

 

Oggi concludiamo questa mini serie di quattro post dedicati all’analisi degli altrettanti Valori dell’Agile e della relativa trasposizione in DAD. Vediamo allora com’è e come viene definito il Quarto Valore:

Valore 4: RISPONDERE AL CAMBIAMENTO più che seguire un piano

fatto proprio, nell’identica forma, anche da DAD.

 agile value4 mini

 

Questo Valore rappresenta, con molta probabilità, il silver bullet per una prima adozione di Agile in un nuovo contesto aziendale.

Spesso, infatti, l’Agile si tira fuori dal cilindro quando ci si trova difronte a questioni del tipo:

Come faccio a sviluppare il sistema con questi requisiti così fumosi (smoky)?”, “Possibile che debba aspettare che l’esperto di dominio abbia prodotto l’analisi esaustiva e definitiva prima di produrre qualcosa da mostrare agli stakeholder?

Ebbene, qui l’Agile mostra i muscoli e mette nero su bianco la comprovata impossibilità di definire in modo puntale i requisiti all’inizio del progetto, abbandonando la presunzione del modello waterfall puro. Chiaramente esistono eccezioni (si pensi a sistemi mission critical), ma nel 98% dei casi è effettivamente così.

Come si reagisce a questa incertezza? Abbiamo ormai imparato che non esiste una strada predefinita per l’adozione di Agile, infatti ogni Team trova la propria, affidandosi all’ esperienza maturata e derivata dall’applicazione disciplinata della metodologia (o del framework) che più ritiene congeniale.

Attenzione: l’Agile non è “buon senso”, tutt’altro. Esso implica disciplina e rigore, ma, soprattutto, un forte cambiamento culturale.

Sicuramente l’adozione di un framework @scale come DAD dà un supporto per imparare a governare l’incertezza di cui sopra. Ciò avviene, soprattutto, gestendo appropriatamente la fase diInception: si pensi, ad esempio, all’introduzione di opportuni sweet spot (o anche hot spot) nell’Intentional Architecture, consentendo così di apportare cambiamenti mirati e sostenibili laddove, durante le iterazioni (Construction phase), ci si accorga che l’Architettura debba essere modificata per supportare adeguatamente gli scenari contemplati. Un ulteriore suggerimento può essere quello di definire una user story attraverso 3 step (Concept, Review, Finalize) prima di inserirla all’interno di una iterazione.

La necessità di cambiamento non avviene, però, solo perché un requisito non è chiaro, ma anche perché esso è del tutto sconosciuto, visto che il key stakeholder ne ignora l’esistenza finché non comincia a “toccare con mano” la soluzione e si rende conto che ha bisogno di altro… qualcosa di cui si era “semplicemente” dimenticato!

Governare l’incertezza richiede: lavoro in stretta sinergia del Team (valore 1), coinvolgimento attivo degli stakeholder (valore 3), maggiore conoscenza del dominio di riferimento, raggiungibile tramite lo sviluppo di soluzioni incrementali e funzionali (valore 2) e…. chiaramente abbracciare il cambiamento(valore 4). Il cerchio si chiude!

Termina qui la nostra parentesi su quello che l’amico Fabio Armani definirebbe Back to Agile!, con un pizzico di DAD, ricordando che: se anche uno solo di questi Valori non è presente nel nostro lavoro (o nelle metodologie che applichiamo) non stiamo operando in un contesto Agile, per quanto dinamico esso sia.

Agile Manifesto Value

DAD Manifesto Value

GLI INDIVIDUI E LE INTERAZIONI più che i processi e gli strumenti

GLI INDIVIDUI E LE INTERAZIONI più che i processi e gli strumenti

SOFTWARE FUNZIONANTE più che la documentazione esaustiva

SOLUZIONI FUNZIONANTI più che la documentazione esaustiva

LA COLLABORAZIONE COL CLIENTE più che la negoziazione dei contratti

LA COLLABORAZIONE CON GLI STAKEHODLER più che la negoziazione dei contratti

RISPONDERE AL CAMBIAMENTO più che seguire un piano

RISPONDERE AL CAMBIAMENTO più che seguire un piano

 

Posted: 28 mar 2013 11:14 da felice.pescatore | con no comments
Inserito sotto: , ,
I Quattro Valori dell’Agile Manifesto: terzo valore

Eccoci al terzo appuntamento con il Manifesto Agile.

Scopriamo insieme il Terzo Valore, che nella forma originale cita:

Valore 3: LA COLLABORAZIONE COL CLIENTE più che la negoziazione dei contratti

mentre in DAD assume una forma che estende i destinatari della collaborazione:

Valore 3 (DAD review): LA COLLABORAZIONE CON GLI STAKEHODLER più che la negoziazione dei contratti

 agile value3 mini

Questo terzo Valore è probabilmente quello più contorto e criptico da digerire, soprattutto per chi ha responsabilità di gestione.

Chiunque entra in un nuovo business si aspetta, con estrema naturalezza, di regolare il rapporto tra se e la controparte con un dettagliato contratto che metta in chiaro cosa spetti ad ognuno.

Nel mondo del Software la situazione è un po’ più complessa: gli stakeholder (e in particolare i key stakeholder) all’inizio non hanno ben chiaro cosa realmente vogliono, per cui, qualsiasi cosa si andrà a contrattualizzate, probabilmente, sarà ben lontano dal risultato finale. Ciò si traduce nell’impossibilità di stilare un contratto dettagliato poiché si sa già che, appunto, qualunque cosa vi verrà inserito non corrisponderà a quello che verrà consegnato.

La questione si focalizza, quindi, su come risolvere questo grattacapo.

Ebbene, la parolina magica è Collaborazione (Collaboration): bisogna coinvolgere gli stakeholder (DAD docet, non basta pensare al Cliente come singola entità) in modo che la percezione del prodotto finale cresca omogeneamente man mano che si procede nel suo sviluppo.

In pratica è come se si introducesse un “contratto dinamico” (dynamic contract) che si modifica grazie all’interazione continua con gli stakeholder.

Ok, tutto bello, ma quando gli stakeholder devono essere presenti?

Teoricamente sempre, praticamente è possibile identificare delle mailstone in base al tipo di ALCM adottato. Nel caso di DAD, sicuramente i key stakeholder devono essere presenti alla fine di ogni iterazione della fase di Construction, così come il loro apporto è fondamentale in quella di Inception. In realtà l’approccio è molto più elastico e il Team non deve avere “paura” e farsi prendere dal panico se uno o più stakeholder decidono di partecipare ad uno qualsiasi degli Accenti del 3C Rhythm, indipendente dall’elemento temporale a cui si applica (vedasi DAD, 3C Rhythm).

In sostanza il contratto si traduce in un concordato di intenti su quelli che sono i fattori chiave del sistema (Intentional Architecture, Agile Planning e Costing, Themi, ecc.) aggiungendo maggiori dettagli man mano essi diventano chiari e condivisi.

In fondo su qualcosa bisogna pur convenire, altrimenti è impossibile definire i confine (boundary) in cui ci si muove.

Posted: 20 mar 2013 15:46 da felice.pescatore | con no comments
Inserito sotto: , ,
I Quattro Valori dell’Agile Manifesto: secondo valore

Eccoci al secondo appuntamento con il Manifesto Agile.

Scopriamo insieme il Secondo Valore, che nella forma originale cita:

Valore 2: SOFTWARE FUNZIONANTE più che la documentazione esaustiva

mentre in DAD assume una forma un po’ più robusta e orientata all’interno ALCM:

Valore 2 (DAD review): SOLUZIONI FUNZIONANTI più che la documentazione esaustiva

agile value2 mini

E’ interessante evidenziare come i quattro Valori siano sempre strutturati con due parti ben distinte: a sinistra, in maiuscolo, la parte predominante, a destra, in minuscolo, la parte subordinata alla prima, ma comunque rilevante per il raggiungimento dell’obiettivo:

Valore: [MAIN CONCERN] [secondary CONCERN]

Il secondo Valore del manifesto Agile pone l’accento sulla realizzazione del Software, che rappresenta il risultato principe di un progetto IT. Nell’accezione di DAD, più che di Software, si parla di SOLUZIONE, ovvero del risultato omnicomprensivo dell’intero Agile Life Cycle Management che comprende, ad esempio, anche il supporto durante la fase di esercizio.

Uno dei miti che va assolutamente sfatato è quello relativo all’eliminazione della documentazione. Si tratta di una interpretazione assolutamente errata di quanto indicato con il secondo valore, in cui effettivamente si dà la massima al software/prodotto, ma si considera comunque importante la realizzazione della documentazione prevista, spingendo affinché essa sia la minima possibile. Con DAD riusciamo anche a dare una definizione di “minima”: produrre la documentazione che genera Valore per gli stakeholder, tutto il resto è uno spreco che va evitato.

La riduzione della documentazione di sviluppo è possibile adottando tecniche che favoriscono, inoltre, un comprovato aumento della qualità del codice prodotto, come ad esempio l’utilizzo della pratica del Test Driven Design (TDD).

Indipendentemente dalla quantità della documentazione prodotta (che chiaramente dipende dallo specifico progetto e dallo specifico contesto), l’importante è che essa sia di qualità e che sia continuamente allineata con il resto della soluzione, in sintesi: Continuous Documentation.

Posted: 20 mar 2013 15:45 da felice.pescatore | con no comments
Inserito sotto: , ,
I Quattro Valori dell’Agile Manifesto: primo valore

Riflettendo sui vari post realizzati in questi mesi, mi sono accorto che spesso abbiamo parlato dei Valori del Manifesto Agile, richiamandoli più o meno indirettamente.

A questo punto ritengo sia utile fare un po’ di mente locale su di essi e soffermarci sulle loro caratteristiche.

Valore 1: GLI INDIVIDUI E LE INTERAZIONI più che i processi e gli strumenti

agile value1 mini

Si tratta di una rivoluzione copernicana nella gestione dello sviluppo del software.

Finalmente si mette nero su bianco che il successo di un progetto è legato principalmente al Team che lo realizza e all’affiatamento dei suo membri. Nessun processo o strumento, per quanto raffinato ed efficace possa essere, è in grado di sopperire a difficoltà di interazioni interne o alla demotivazione dei componenti del Team.

Elemento fondamentale del primo Valore è la comunicazione, sia per l’aspetto sociale che per il trasferimento efficiente del know-how. Quest’ultimo fattore è evidente a chiunque adotti Agile: tipicamente, se il Team è localizzato nella stessa struttura e non ci sono fattori @scale, si preferisce avere una lavagna e dei post-it su cui riportare l’attuale stato del progetto e le relative attività. In tal modo chiunque all’intero dell’azienda (e non solo i membri dello specifico Team) può dare una “sbirciata” a quanto sta accadendo e, possibilmente, un contributo.

Questo primo Valore enfatizza l’auto-organizzazione e l’auto-disciplina: si pensi, ad esempio, ai task che non vengono assegnati dal Project Manager (o Team Lead) ma vengono scelti direttamente dai membri del Team, in funzione delle capacità che ognuno di essi è conscio di avere.

E’ subito evidente la differenza rispetto agli approcci tradizionali, fortemente incentrati su rigidi protocolli gerarchici, anche se è utile sottolineare che l’adozione del primo Valore non conduce (e non vuole farlo) al loro abbattimento, ma a una riqualificazione dei ruoli in funzione della nuova ottica collaborativa.

Posted: 20 mar 2013 15:44 da felice.pescatore | con no comments
Inserito sotto: , ,