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 di Inception: 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

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme