L'antipattern death by planning (morte da pianificazione) e uno dei piu particolari problemi del management, strettamente legato alla progettazione di una applicazione. Un'affermazione tipica di chi sta per incorre in questo antipattern è: "finché seguiremo il progetto non avremo problemi" (... le ultime parole famose).
Contesto
La morte da pianificazione non e altro che la fiducia, "cieca", riposta nel progetto iniziale di un sistema software da realizzare. Sebbene in molti campi il successo di un progetto sia legato alla sua accurata e fedele esecuzione, nell'ingegneria del software è bene seguire una pianificazione con grande elasticità a causa delle diverse incognite e problematiche che possono presentarsi.
In ambito informatico non tutto e prevedibile e considerare un progetto "perfetto e immutabile" ne comporta spesso il fallimento.
Esistono diversi tipi di pianificazione, i piu diffusi sono la progettazione unica e quella dettagliata.
Pianificazione "unica"
La progettazione (o pianificazione) unica prevede una pianificazione iniziale a cui si dedica molto tempo e viene considerata talmente precisa da escludere qualsiasi miglioria o aggiornamento in corso d'opera.
Tale concezione ha effetti rassicuranti sia sugli sviluppatori che guardano al progetto come una sorta di "oracolo", sia sui committenti che ritengono d'avere tutto sotto controllo.
Questa visione non tiene conto degli imprevisti o di eventuali migliorie che potrebbero essere introdotte e se e presente in origine un errore, questo viene portato inesorabilmente avanti.
Pianificazione "dettagliata"
La progettazione (o pianificazione) dettagliata, invece, si basa sulla realizzazione di una serie di progetti estremamente minuziosi (spesso molto complessi e articolati) relativi a tutte le figure coinvolte ed a tutti gli aspetti di sviluppo del software, questo modo di procedere da l'errata convinzione che tutto sia stato previsto.
Sintomi
È possibile, facendo attenzione a piccoli dettagli cha fanno da sentinella, riconoscere questo antipattern e poi adottare le misure necessarie per la sua rimozione. I sintomi sono:
- spasmodica attenzione alla fase di pianificazione
- bassa capacità di autonomia decisionale
- poca volontà, o capacità, di analizzare e risolvere problemiù
- mancanza di conoscenza sul reale stato di avanzamento dei lavori
- eccessiva attenzione (senza reali motivazioni) ai costi
Cause
Le cause che portano all'introduzione di questo antipattern sono legate alla scelta del tipo di pianificazione. Per entrambi vale la mancanza di una corretta visione elastica del progetto, ma alcune differenze sono significative:
- nella pianificazione unica, le cause sono riconducibili: al desiderio d'imporre nel progetto un proprio modo di intendere la concezione e lo sviluppo del software, alla mancanza di flessibilita e all'assenza di fasi di analisi intermedie;
- nella pianificazione dettagliata nasce tutto: dall'intendere la progettazione come principio infallibile, da una programmazione continua e meticolosa (eccessivamente dettagliata) e dall'esigenza del cliente di voler sempre tutto sotto controllo.
Conseguenze
Le conseguenze di tale antipattern nella programmazione unica si identificano con la necessita di nuovi investimenti per ogni problema sorto e non previsto, con la mancata conoscenza sul reale stato dei lavori e con risultati diversi da quelli realmente richiesti.
Nella pianificazione dettagliata le conseguenze confluiscono in una continua pianificazione e ripianificazione e in un ritardo, frequente, nel conseguimento del risultato.
In entrambi i casi il risultato finale e il fallimento del progetto e quindi la sua "morte".
Soluzione
Per evitare il "collasso" dell'intero progetto è possibile adottare alcune linee guida, che se applicate correttamente evitano d'incorrere in questo antipattern. Tali accorgimenti valgono per entrambi i piani di progettazione.
Innanzitutto prevedere flessibilità nella pianificazione in modo da poter inserire migliorie e correggere eventuali difetti.
Il piano dovrebbe contemplare delle fasi di analisi e validazione per ogni singolo componente, le scadenze per la loro realizzazione dovrebbero essere rigorose ma realistiche e sarebbe sempre opportuno avvalersi di strumenti idonei per la panificazione e monitoraggio delle fasi di sviluppo (ad esempio il diagramma di Gantt).
Realizzare una tale pianificazione non significa solo analizzare i tempi di sviluppo, ma anche:
- tenere sotto controllo tempi di consegna (reali e presunti)
- monitorare eventuali ritardi (con nuove date di consegna)
- identificazioni e analisi di difetti e problematiche
- proposte di soluzioni e di migliorie
- prevedere sempre un giusto margine di tempo per gli imprevisti
- assicurarsi che ogni componente del team sia a conoscenza degli stati della pianificazione
Avere costantemente queste informazioni permette, ad ogni verifica, d'avere una visione
concreta dello stato di sviluppo del software, analizzare il lavoro fatto e programmare quello futuro.