Agile Managing

I clienti possono realizzare progetti di successo grazie alla tecnologia agile by design, a team compatti e multidisciplinari, ad un approccio incrementale, ad un’organizzazione per unità di lavoro elementari e ad una focalizzazione sull’essenziale.

 

Nella realizzazione di una soluzione software una metodologia agile da sola basta?

Oppure una metodologia agile richiede una piattaforma di sviluppo agile?

Siamo da tempo nell’era dell’agile methodology, ma è molto difficile dire se questo abbia realmente trasformato il nostro modo di fare progetti software, quanto questa metodologia sia utilizzata ed efficace e in quali ambiti. È quindi dirimente fare alcune considerazioni importanti sull’utilità delle metodologie agile:

  • va verificato se e in quali casi queste metodologie siano opportune, in ragione del tipo di progetto e soluzione, del modello organizzativo e di processo, del contesto ambientale.
  • vanno individuati e indirizzati alcuni misunderstanding e “false friends” che prescindono dalla metodologia, ma che ne inficiano l’utilizzo.

Sulla piattaforma Irion gestiamo da anni progetti in diverse realtà e contesti realizzando soluzioni end to end nell’ambito dell’Enterprise Data Management, sistemi di data governance, motori di data aggregation and reporting, soluzioni di data quality, sistemi di data reconciliation e data migration.

Questo ci ha permesso di conoscere, analizzare e sperimentare, diverse modalità e metodologie più o meno formalizzate e anche di evidenziare alcuni dei principali limiti e problemi che minano spesso il successo delle iniziative IT.

Quattro esempi tra i tanti possibili.

La rilevazione dei requisiti: Agile o assente?

Spesso si pensa che una metodologia Agile elimini la necessità di individuare chiaramente i requisiti, la cui rilevazione strutturata è vista a volte come un impedimento alla agilità stessa e una causa di rallentamento.

Abbiamo rilevato invece come questo nasconda alcuni problemi di fondo e ne crei o amplifichi altri:

  • L’assenza di requisiti chiari o la difficoltà a descrivere in modo completo un’esigenza nasconde spesso la scarsa competenza o la dispersione di competenze sui processi di business. Spesso ci si limita a lavorare solo su slogan, titoli, passaparola, in fondo con la paura di un confronto vero con il business.
  • L’assenza dei requisiti mina alle basi il processo di costruzione ed è paragonabile all’assenza di fondamenta, con le conseguenze che derivano.

Il vantaggio di un approccio Agile deve invece concretizzarsi nella possibilità di un’analisi rapida e focalizzata dei requisiti:

  • individuando in poco tempo gli elementi fondanti di una soluzione e traducendoli in un numero limitato di driver e di assunzioni semplici, chiare, facilmente comprensibili.
  • descrivendo ed inquadrando l’essenza del bisogno.
  • permettendo una rapida ed efficace valutazione di costi, tempi e rischi.

L’analisi e il disegno: Agile nella forma, ma rigida nella sostanza?

Talora, pur in presenza di qualche requisito, l’approccio Agile rimane solo sulla carta quando prassi, tecniche e template utilizzati dalle aziende –o proposti dai consulenti– sono in realtà legati ad un approccio all’implementazione tradizionale, dove l’attenzione viene immediatamente spostata al dettaglio: descrizione dettagliata delle interfacce con i sistemi, tracciati record da documentare fin da subito con la massima precisione, descrizione dettagliata della UI, mock up molto completi, descrizioni dei report accuratissime.

A ciò si aggiungono processi di validazione lunghi che allontanano dall’obiettivo.

Sono elementi che poco hanno a che fare con l’esigenza principale, ma che in fondo sono ancora rigidamente necessari perché uno sviluppatore possa veramente procedere alla realizzazione adottando uno qualunque degli strumenti “tradizionali” a sua disposizione.

Implementazione e configurazione: cicli di sviluppo brevi o ricicli inevitabili?

La volontà di lavorare nell’implementazione per “sprint”, con cicli di sviluppo brevi e facilmente verificabili, si scontra con la difficoltà pratica ad attuare questo approccio perché:

  • i requisiti sono tremendamente instabili anche nel breve e la stabilità del requisito è condizione necessaria per lavorare a sprint;
  • viceversa l’analisi è ancora imperniata su una logica a waterfall, monolitica e infarcita di dettagli senza alcun approccio incrementale;
  • non sono espressi risultati intermedi raggiungibili ed è difficile individuare e lavorare per unit of work indipendenti e consistenti;
  • gli strumenti in uso sono inadeguati rispetto a modelli e logiche di incremental building.

Va sottolineato come un approccio basato sull’incremental building esiga strumenti che lo supportino, per evitare che “incremental building” si traduca con “possibilità di riciclo e rifacimento continuo di un’applicazione costruita secondo logiche tradizionali”.

Questo non ha nulla di Agile e comporta tempi e costi sempre crescenti, dove ogni riga di codice ha un peso.

UAT (User Acceptance Testing) & Roll out: così Agile che non è quello che mi aspettavo

Come quarto punto consideriamo che la realtà mostra spesso un’insoddisfacente fase di certificazione di un’applicazione da parte degli utenti, perché è mancata l’esplicitazione dei criteri atti a definire che quanto è stato realizzato corrisponde a quanto desiderato (“definition of done”, “use case test”, “success criteria”).

Il tanto famigerato UAT si traduce quindi nel far vedere all’utente qualcosa che probabilmente non conosce, alla cui realizzazione non ha partecipato, chiedendogli di verificare se è in linea con quanto si aspettava (o non sapeva di aspettarsi). Cronaca di una morte annunciata: l’assenza di una definizione chiara dei criteri di successo fa virare i progetti verso una miriade di ricicli, contestazioni e rifacimenti che spesso non portano a nulla.

Al contrario un approccio Agile efficace deve fondarsi sull’esplicitazione iniziale dei criteri di soddisfazione su cui il progetto lavorerà.

La nostra esperienza ci fa dire che una certificazione o UAT dovrebbe essere condotta non rispetto a generiche aspettative, ma rispetto a criteri di successo definiti ed esplicitati possibilmente in casi di test riscontrabili e indipendenti da fattori esogeni.

Esiste un’alternativa? La tesi da dimostrare non è l’inefficacia delle modalità Agile, ma proporre un’alternativa almeno nel contesto EDM: in Irion abbiamo deciso di invertire il paradigma e prima di pensare all’applicazione nei nostri progetti di una metodologia Agile abbiamo deciso di rendere Agile l’Applicazione.

Al di là del gioco di parole, Irion EDM è una piattaforma Agile by design che permette di essere estremamente agili nei progetti e nella realizzazione di soluzioni di enterprise data management.

La nostra metodologia è Agile perché è Agile la piattaforma su cui lavoriamo. E la piattaforma è Agile perché basata su un paradigma dichiarativo che ribalta molti degli assunti dello sviluppo tradizionale. È nella combinazione di questi fattori che sperimentiamo il successo dei nostri progetti.

Perché?

Proviamo a tornare rapidamente sui punti critici analizzati.

Rilevazione dei requisiti

La disponibilità di una piattaforma basata su un paradigma dichiarativo permette di ragionare veramente secondo un approccio Agile e goal driven nella fase di definizione del requisito.

  • Ci concentriamo sul capire veramente qual è l’essenza, il bisogno, l’obiettivo.
  • La nostra rilevazione dei requisiti è estremamente rapida e accurata perché è basata su pochi fondanti driver che guidano il modello dichiarativo sottostante.
  • Ci basiamo sulle assumption che definiscono il perimetro e tralasciamo dettagli irrilevanti per la valutazione dei rischi e dei costi di progetto.
  • Forniamo la valutazione di progetti complessi dando stime fixed price, che hanno un livello di attendibilità elevato.
  • Per noi una change request è qualcosa che esce in modo oggettivo, inequivocabile e condiviso dallo scope iniziale, non una qualunque modifica nelle specifiche di dettaglio o nelle analisi funzionali o richiesta di fine tuning del sistema.

Analisi e disegno

L’analisi di un progetto Irion EDM based non richiede mai faticosi documenti di decine di pagine, ma un documento che declina i requisiti utente in un disegno di alto livello e nel relativo modello di funzionamento: quanto basta per avviare le fasi successive.

Nel nostro modello dichiarativo, inoltre, la piattaforma EDM genera in modo automatico la documentazione della soluzione, sulla base di quanto implementato e configurato e la tiene aggiornata in ragione delle sue successive evoluzioni.

È la piattaforma che rende Agile il progetto. Questo è abilitante perché la metodologia Agile non resti sulla carta.

Implementazione

Se l’ambiente di sviluppo è tradizionale e rigido, in fase di implementazione non si potranno mettere realmente a terra i vantaggi di una metodologia Agile.

Irion offre invece una piattaforma e un ambiente integrato di lavoro pensato “by design per l’incremental building grazie al modello dichiarativo che sottende. Così si può realmente procedere per iterazioni successive di build, design review e rilascio, accorciando la filiera e anticipando molto l’onboarding degli utenti finali.

In un progetto Irion viene fortemente semplificato tutto ciò che rende spesso difficile, lungo e costoso lo sviluppo, come la realizzazione e modifica dei processi di lettura e trasformazione dati, la predisposizione delle strutture e degli archivi, le modifiche alla UI e al reporting, il debug, i processi di change management.

Ecco alcuni esempi, rapidi ed efficaci:

  • In modo molto semplice si può configurare la soluzione con una logica a “building block indipendenti e autoconsistenti, dove ciascuna parte può essere realizzata e verificata autonomamente e parallelamente aumentando overlapping e riducendo i tempi. La modifica di una componente non inficia quindi mai l’intera soluzione.
  • Il sistema non prevede interfacce dati predefinite. È molto semplice lavorare con dati di prova o dummies in attesa che i “producer” delle informazioni necessarie rendano disponibili i dataset reali.

Grazie al modello dichiarativo chi disegna una soluzione in Irion:

  • non deve prevedere in modo rigido e predefinito il modello fisico dei dati poiché le strutture dati sono autoadattative e autocontenute in un set di database il cui modello fisico dei dati è gestito in automatico dalla piattaforma;
  • non deve preoccuparsi di gestire le dipendenze di esecuzione e la loro modifica;
  • demanda al sistema l’ottimizzazione dei piani di esecuzione e l’adeguamento delle procedure in ragione dei volumi dati.
  • Il rilascio di componenti, moduli o parti avviene senza la necessità di compilazione del codice pian piano che questa viene costruita.

Con Irion l’implementazione può essere veramente ottimizzata, suddivisa in sprint e basata su cicli brevi di build & review che garantiscono ongoing e non solo alla fine la rispondenza della soluzione ai requisiti.

UAT & Roll Out

Alla fine di un progetto si raccoglie ciò che “oggettivamente” si è seminato: seguendo l’approccio Irion i criteri di successo di un progetto possono essere già definiti ed impliciti e sono verificabili nei rilasci prototipali della soluzione, che sono oggetto di design review periodiche con gli utenti.

  • La fase di UAT può essere distribuita sui rilasci intermedi senza il rischio di inconsistenza complessiva.

Nella pratica e in sostanza, avanti tutta con la Agile, ma senza fermarsi alla metodologia e orientandosi su strumenti abilitanti che l’Agile lo hanno reso “vivo” e che cambiano radicalmente il modo di fare progetti.

Se poi si parla di EDM allora Irion è la risposta e chi è riuscito con noi a invertire il paradigma ora non torna più indietro.

Post Correlati