Dopo aver visto, nella prima parte di questa serie di tre articoli, la necessità di pianificare vedremo in questo secondo episodio perchè la pianificazione fallisce.
Introduzione
Quando si mollano gli ormeggi uno non va a Capraia ma parte per Capraia.
"Andare a" o "Partire per" sono due concetti che sembrano simili ma profondamente
diversi... (cit Marco Viganò: insegnante di vela, skipper, navigatore, imprenditore)
Partiamo da qui per riassumere i principali motivi, secondo Mike Cohn, per i quali la
pianificazione nei progetti fallisce:
- perché ragioniamo per attività
- perché i ritardi si accumulano e le attività non sono indipendenti
- il multitasking è dannoso
- ignoriamo l’incertezza
- le stime diventano “impegni
Ragionare per Attività
Nell’approccio tradizionale alla gestione dei progetti l’organizzazione e la suddivisione del
lavoro è fatto per attività anziché per feature, facciamo un esempio. In ambito IT una
attività può essere lo sviluppo di tutto il supporto per memorizzare i dati del back end, ad esempio
implementazione del database in cui memorizzare i dati. Al termine di questa attività non
potremo comunque dimostrare nulla all’utente perché la parte applicativa: le interfacce, le
pagine del sito, non sono ancora pronte. Quando verranno completate andremo dal nostro
committente per fare una prima demo e quasi sicuramente verremo “rimbalzati” con
alcune segnalazioni. Accogliere questi feedback può voler dire non solo modificare le
pagine del sito, ma anche scendere a livello di db e modificarne la struttura con tempi e
costi notevoli.
Se invece avessimo sviluppato la feature per memorizzare i dati di login e password,
avremmo contenuto i tempi per arrivare al primo rilascio senza sviluppare strutture non
necessarie e passibili di modifiche.
I ritardi si accumulano
Legge di Parkinson:
Il lavoro si espande fino a occupare tutto il tempo disponibile; più è il tempo e più il lavoro
sembra importante e impegnativo
Questo è vero in media, poi certamente ci sono eccezioni.
Prendersi tutto lo slot di tempo disponibile per quell’attività vuol dire che se sono in ritardo
non ho un buffer per espandermi ma finirò a passare il ritardo all’attività successiva. Inoltre
ragionando come detto per attività, vediamo spesso che queste non sono indipendenti fra
loro. Lavorare per feature limita questa dipendenza e isola i ritardi.
Il multitasking
Un falso mito. Per anni abbiamo pensato che svolgere attività in parallelo fosse
vantaggioso. In realtà è stato dimostrato come occuparsi di due task in parallelo aumenta i
tempi. Bisogna infatti considerare il tempo di switch per passare da un contesto di un task
all’altro. In alcuni ambiti e situazioni non sono immediati. Se devo riprendere un lavoro
complesso che ho abbandonato qualche giorno fa, può essere necessaria qualche ora
prima di ridiventare operativo.
Inoltre lo stesso "penny game" dimostra con un semplice gioco questa teoria. Lo potete vedere in un video su YouTube qui oppure descritto in tutti i suoi dettagli su Mokabyte.
In sostanza il multitasking costa energie mentali e psicofisiche, non produce benessere
per la persona, anzi, aumenta lo stress.
Ignorare l’incertezza
Pensiamo che una volta scritte le specifiche funzionali, fatta la stima , ottenuto e approvato
il budget, il progetto partirà e sarà stabile fino alla fine. Ma inevitabilmente le idee
cambiano, il committente ci darà nuove specifiche, incontreremo problemi tecnici e
gestionali (una persona si licenzia e va sostituita). In sostanza la differenza, come scritto
nella citazione iniziale di Marco Viganò tra partire per e andare a.
L’incertezza va prevista, accolta e ne va fatto un elemento che ci rinforza.
Le stime
Se io stimo un lavoro 5 giorni lavorativi ecco come verrà percepito.
Da me: ho detto 5 giorni quindi diciamo che in base al resto delle attività che ho da fare,
tra due settimane potrò rilasciarlo.
Dal cliente (lo stesso che mi aveva già assegnato altri task che non considera possano
occuparmi tempo…): mi ha detto 5 giorni, siamo a lunedì, quindi per venerdì ho tutto.
Una stima porta in sé un concetto di “probabilità” e quindi di incertezza. Non può essere
considerata come un commitment.
Quindi come possiamo pianificare e raggiungere delle stime in modalità Agile? Lo vedremo nell'ultima parte di questa serie di articoli.