Che cos’è e importanza di una Discovery nel processo di sviluppo

Che cosa è una Discovery?

La fase di Discovery è una fase in cui si valutano le varie ipotesi per il proseguimento di un processo di sviluppo. In particolare, essa non riguarda soltanto un singolo progetto ma riguarda un sistema intero visto nel suo insieme, comprendente l’intera architettura.

Generalmente sono due i motivi che principalmente spingono a favore della decisione di adottare questo metodo in un processo di sviluppo:

1. identificare una soluzione architetturale dell’intero sistema, istruendo allo stesso tempo i nuovi collaboratori
2. selezionare i progetti per il programma di trasformazione dell’IT.

In questa fase sono coinvolti tutti gli stakeholder legati al progetto: possono essere i manager di business, il cliente vero e proprio (inteso come proprietà), gli analisti, gli architetti, ecc.

Visione condivisa

La proposta di un piano da presentare alla proprietà ha implicato la necessità di avere una visione globale dello stato dell’azienda nel presente (come è ora, da chi è composta, ecc.) e un’attenzione particolare ai processi complessivi presenti in essa, indicandoli, in un primo momento, soltanto ad alto livello. Limitarsi ad individuare i punti fondamentali ad alto livello garantisce il fatto di strutturare più efficientemente e di individuare l’architettura dell’intero sistema informativo aziendale, quindi non solo di un singolo progetto.

La potenza dell’agile sta proprio nella capacità di modulare la descrizione di un determinato ambito in relazione alle esigenze del cliente, senza entrare particolarmente nel dettaglio, ottenendo così una visione globale dell’architettura e dello scope.

La necessità di trasformazione verso questo approccio deriva dall’esigenza di definire una architettura enterprise e riorganizzare e qualificare la struttura del sistema informativo aziendale. Questo implica, inoltre, la correzione delle inefficienze e dei problemi presenti ora nel sistema ed il miglioramento dei processi.

Secondo l’agile il livello di dettaglio deve essere correlato alle esigenze e al momento in cui serve, in base al progetto che si decide di sviluppare. Non è necessario, come invece per le metodologie tradizionali, analizzare tutta la struttura in maniera molto dettagliata già all’inizio di un progetto. Basta avere uno schema scheletro che dia le informazioni sufficienti per iniziare il progetto stesso e poi raffinare progressivamente la conoscenza del contesto quando si affrontano man mano le funzionalità da sviluppare. Analizzare approfonditamente sin da subito potrebbe portare ad un impiego di tempo troppo elevato per delle cose che magari, dopo poco tempo, risultano obsolete e quindi non più necessarie, il che risulta essere controproducente. Il giusto livello di dettaglio consente di partire con un progetto con delle tecnologie e il design che fanno in modo di integrare facilmente del software nuovo o correggere qualcosa di esistente.

Il valore aggiunto che restituisce questa pratica è la visione complessiva e condivisa dell’architettura di sistema, arrivando ad un giusto dettaglio che consente di capire adeguatamente l’ambito.

Hopes & Concerns

Sono state, inoltre, individuate le aspettative (hopes) di tutti i partecipanti della riunione con le relative preoccupazioni (concerns), cioè le parti che potrebbero creare problemi in fase di sviluppo. Avere una visione globale e soprattutto condivisa dell’idea di business è un requisito fondamentale per progetti di grandi dimensioni e riguardanti clienti importanti perché garantisce chiarezza quando si discutono le soluzioni ai problemi.

Ciascun partecipante ha scritto successivamente le proprie opinioni su dei post-it e li ha poi appiccicati nella sezione appropriata, cercando di raggruppare per argomento i foglietti (procedimento conosciuto con il nome di grouping ) con quelli dei colleghi che erano già presenti. Quando tutti avevano terminato, sono stati analizzati tutti i post-it e si sono messe in relazione le idee ed i punti di vista in modo da creare una visione accettata e compresa da tutti.

Con questa tecnica sono emerse molte aspettative che delineano le principali problematiche che la trasformazione dell’IT dovrà risolvere, per esempio la realizzazione degli obiettivi elencati in precedenza, la riduzione del tempo da quando il cliente presenta un bisogno da soddisfare a quando l’applicazione specifica viene rilasciata, ecc… Gli hopes rappresentano quindi, dal punto di vista del partner tecnico e della divisione IT, i criteri di soddisfazione del cliente a cui fare costantemente riferimento. Per quanto riguarda le preoccupazioni sono emersi altri fattori più tecnici come il problema della lingua (i collaboratori del partner tecnico erano principalmente indiani e quindi è stato necessario parlare in inglese), la paura di non riuscire a pianificare bene i tempi delle sessioni e non riuscire a definire correttamente l’architettura e la visione del business, rischiando così alzare ulteriormente i costi dell’infrastruttura, ecc. I concerns rappresentano quindi, dal punto di vista del partner tecnico e della divisione IT, i potenziali rischi da tenere sotto controllo.