L'antipattern Analysis Paralysis (paralisi dell'analisi) è il secondo antipattern relativo al management che analizziamo. Anche in questo caso un'affermazione tipica di chi sta per incorrere in questo antipattern è: «Dobbiamo essere estremamente scrupolosi in fase d'analisi, non dobbiamo tralasciare nulla».
Contesto
La paralisi dell'analisi è riscontrabile in ogni fase del ciclo di vita del software ogni qual volta ci si pone come primario obiettivo quello del massimo dettaglio, si rispecchia con la maniacale esigenza di raggiungere la perfezione e si cerca, in ogni modo, di arrivare ad uno stato di completezza estremo.
Uno dei migliori approcci alla soluzione di un problema risiede nella sua scomposizione, cioè nel risolvere una serie di problematiche più semplici. Ma è sempre difficile stabilire un livello esatto di corretta "frammentazione" del problema.
- Quanto bisogna andare in dettaglio nella scomposizione?
- Quando è giusto fermarsi?
Dare una risposta a queste domande non è semplice, ma non cercarla può comportare la paralisi d'analisi.
Per molti sviluppatori il cercare di prevedere tutte le possibili esigenze (presenti, future e ipotetiche) del committente sembra essere un'efficiente metodo di progettazione, cercare il massimo dettaglio nella fase di design fa pensare d'aver semplificato il lavoro ed eliminato ogni ostacolo.
Sintomi
Come per tutti gli altri antipattern osservare con attenzione alcuni sintomi ci permette di riconoscerli e successivamente eliminarli. Le sentinelle di tale problema sono diverse:
- spese d'analisi che crescono in maniera esponenziale superando quelle preventivate
- perdita del rapporto diretto col committente che porta il progettista a rinchiudersi in una "solitaria"
analisi dei dettagli - difficoltà nel realizzare, testare e documentare il prodotto finale a causa delle eccessive analisi
effettuate
Cause
Le cause che portano all'introduzione di questo antipattern sono legate:
- ad una fase d'analisi esasperata e non controllata
- ad una mancanza di chiara e lucida visione degli obiettivi ed assenza dei limiti di dettaglio da raggiungere. Tutto questo si ripercuote a cascate in ogni fase del ciclo di vita del software, rendendo il suo sviluppo lento, oneroso e estremamente complesso
- ad una mancanza di fiducia nelle proprie capacità implementative che si pensa di poter colmare con una "pesante" fase d'analisi.
- al desiderio di voler realizzare un software completo che va oltre le reali esigenze del committente
Conseguenze
Le conseguenze di tale antipattern sono:
- un continuo aumento del costo d'analisi che spesso diventa troppo oneroso
- continui ritardi nella consegna
- "fuga" di sviluppatori dal progetto
- continue ramificazioni e deviazioni dal progetto iniziale
Soluzione
Per evitare che questo antipattern possa avere ripercussioni sul progetto possiamo adottare alcuni accorgimenti. L'aspetto essenziale è quello di seguire uno sviluppo incrementale, che permette di avere delle tappe intermedie per valutare lo stato d'avanzamento dei lavori e verificare, solo allora, l'eventuale necessità di ricorrere ad un'analisi più dettagliata.
Per ogni incremento sarà decisa un'adeguata soglia di dettaglio concordata all'interno del team. Gli incrementi possono essere:
- incrementi esterni: sono modifiche/aggiunte di funzionalità riscontrabili dall'utente (sono quelle di
maggior impatto estetico che tendono a colpire maggiormente il committente) - incrementi interni: permettono la costruzione di elementi di ampio uso che semplificano lo
sviluppo del sistema
Estensione
Tale antipattern è particolarmente interessante poiché estensibile ad altre fasi, come quella di codifica
dell'applicazione. Ad esempio quando si esasperano i concetti alla base del paradigma OO per fini non
strettamente legati allo sviluppo dell'applicazione, e quindi non realmente utili.
