10 years: L'attività peggiore: la pianificazione
Pianificare è un'attività difficile, nonostante il planning game sia di per sè una pratica che rasenta il banale. In estremo sunto:
- gli sviluppatori stimano le attività da fare dal punto di vista tecnico
- il business sceglie sulla base delle priorità di business
Quello che tutti scoprono dopo pochissimo tempo sono delle sacrosante verità:
- gli sviluppatori sottostimano le attività
- l'errore di stima è solitamente significativo (circa un 30 % quando va bene)
- il business non considera tutto l'insieme delle attività da fare, ma solo le piu recenti
La mia sorpresa è che a fronte di queste banalità non ci sono tecniche di stima vagamente scientifiche che ho visto applicare.
Un falso mito: i punti complessità
Stimare in punti complessità è un errore. Questa tecnica è (forse) utile quando stai valutando un nuovo progetto, e, in caso parta, nella prima iterazione. Dalla prima iterazione in poi è assolutamente da evitare l'uso di questa tecnica.
Mentalmente le persone scoprono rapidamente una proporzione tra 1 punto di complessità e il tempo ideale corrispondente.
Quando per stimare il tuo pensiero è: "penso ci vogliano 2 giorni/ coppia, 1 punto di complessità vale circa mezzo giorno coppia, quindi dico agli altri 4 punti complessità" è chiaro che il beneficio delle tecnica è svanito.
Anche quando cominci a stimare le attività 3,25 punti complessità il beneficio delle tecnica viene a mancare.
Infine, se hai un pizzico di bravura nel partizionare le funzionalità del tuo sistema, difficilmente dovrai stimare un gran numero di attività 4/5 volte piu complesse di un'altra. Il consiglio in tal caso è di migliorare la capacità di fare split. Guarda qua: http://www.agileforall.com/splitting-user-stories/
Un esperimento per stimare meglio: verso la scientificità?
Quando stimi una attività devo considerare un paio di aspetti:
- quanto sei competente in materia? Se l'attività che devo stimare riguarda un ambito di competenza dove non sono preparato, ci metterò di piu!
Si potrebbe compilare una matrice di competenza: sulle righe i nomi dei membri del team e sulle colonne le competenze necessarie per lavorare sul progetto. Nella intersezione un voto, ricavato o da autovalutazione o da metodi piu strutturati.
- quanto è complessa l'attività richiesta? Sicuramente un aspetto di complessità è il numero di 'layer tecnologici' che devi attraversare. Ad esempio: se mi basta cambiare il codice è un conto, se devo cambiare una funzione javascript, il codice, un sottosistema esterno, un database etc. l'attività è molto probabilmente piu rischiosa quindi piu costosa.
Basterebbe moltiplicare con un fattore crescente la stima iniziale a seconda del numero di sottosistemi coinvolti. Il web, il database, il file system, il tuo codice, un servizio esterno, una coda di messaggi, sono tutti esempi di 'sottosistema'
I due errori piu comuni quando si stima
1: La naturale propensione di uno sviluppatore è di pensare solo all'happy path: il minimo necessario affinchè si possa considerare chiusa l'attività.
Per analizzare con più precisione è allora utile considere gli imprevisti - previsti, ovvero tutti i casi di fallimento più comuni che, nel proprio contesto, si sono presentati in passato. Ad esempio: cosa succede se il servizio esterno su cui ci si basa non risponde o se l'utente chiude il browser nel mezzo di una sessione.
2: Un altro errore è considerare solo le modifiche al codice sorgente necessarie.
Ci si dimentica di tempi per evenutali test manuali, o tempi di comunicazione con altri team di lavoro, tempi necessari per il deploy, per la configurazione..
Per ovviare a questo problema uso il concetto di tassa: quando devo modificare una virgola nel mio sistema software, quanto tempo è necessario affinchè quella minima modifica vada in produzione ? Questa tassa è relativamente facile da calcolare, e va aggiunta alla stima di ogni attività.
Sarà poi compito del team cercare di abbassare la tassa il più possibile.
Conclusione
Ho visto troppi team combattere contro i mulini a vento dell'errore di stima. Si vuole diminuire l'errore di stima per essere piu predicibili verso le date di consegna.
Penso che sia più proficuo usare un'altra strategia: migliorare l'abilità di dividere le grosse funzionalità in più funzionalità piccole tutte piu o meno stimabili in tre macro categorie: 1/2 giornata di lavoro , 1 giornata o 3 giornate.
Stimare con più precisione non porta a nessun reale vantaggio.
Il vero valore della fase di stima delle funzionalità è la condivisione nel team dell'analisi e degli obiettivi che ci si pone.
Nessun commento:
Posta un commento