[10 years] Pianificazione e priorita (seconda parte)

Priorità: considerazioni

Errore diffuso di chi ha il compito di decidere le priorità è considerare le più recenti funzionalità come le più importanti (strategia LIFO= last in first out). 

Può anche essere corretto, purchè si analizzino le 'vecchie' funzionalità messe in backlog di cui magari non si ha più memoria.

Ma al di là di ciò che viene scelto, raramente ho visto lavorare per un obiettivo. 

Un progetto bancario prevedeva la riscrittura totale di un sistema di pagamento elettronico. L'obiettivo del primo rilascio era quello di dirottare i pagamenti del più semplice sistema di pagamento verso il nuovo sistema, mantenendo per tutti gli altri protocolli il vecchio sistema. L'obiettivo era chiaro, ed ha permesso a pm e team di non aggiungere funzionalità speculative che non avrebbero aiutato nel raggiungimento dell'obiettivo.

Tante volte le date di consegna non sono associate a reali esigenze. Se il prodotto deve essere pronto entro il primo marzo perchè in quel giorno ci saranno pubblicità in televisione che sicuramente traghetteranno traffico, la data di consegna ha un senso. 

Spesso si creano date di consegna fittizie, passate le quali non succede niente: 

Niente di più demoralizzante aver lavorato sodo per raggiungere una data in cui non c'è reale esigenza. 

Non è mia intenzione suggerire di non creare date di consegna; il suggerimento è di associare un obiettivo.

I metodi agili generano fastidio

Il planning game ha il compito di esplicitare i rischi e gli obiettivi di un rilascio. Con quanto budget si riesce a raggiungere un set di funzionalità con ragionevole certezza. 

Il problema è che tanti manager non accettano di vedere i vincoli. Cosi le date di rilascio diventano mandatorie, e l'unica strategia suggerita più o meno esplicitamente è di ribaltare il rischio di consegna sullo sviluppatore, chiedendogli di fare straordinari.

Io non baserei il successo del mio progetto su quest' unica opzione. 

User story - le considerazioni assodate

In quasi tutti i team in cui ho lavorato si identificano le funzionalità da implementare con l'ausilio di cartoncini fisici o elettronici chiamati 'user story' o anche 'carte'. 

Anche se ho notato una certa uniformità mi piace ribadire alcuni importanti concetti oramai assodati: 

• ogni carta necessita di un solo responsabile. Anche se il team lavora in pair programming il responsabile rimane sulla carta dall'inizio alla fine.
• potrebbe essere utile, se il team lo ritiene, indicare in quale attività si è consumato il tempo della carta: se una carta ha richiesto 30 pomodori/coppia (ovvero circa 15 ore/coppie), quanti di questi sono stati dedicati al codice, o alla documentazione, o al deploy e così via?
• è utile riportare a fine giornata quanto manca alla fine della carta, e notificare al resto del team se ogni sera il remaining è maggiore di quello della giornata precedente
• ogni carta quando chiusa necessita della firma del cliente, che si assume così la responsabilità di aver verificato, assieme al team, il suo funzionamento.  

Come si velocizza il completamento di una carta? 

Talvolta un cliente chiede di accelerare il completamento di una carta e raramente ho visto sviluppatori trovare opzioni per riuscire a farlo. Certo, non è sempre possibile nè facile, ma non è nemmeno sempre impossibile.

Il classico metodo di 'divide et impera' è una buona tecnica. 

Se si segnano su una todo list tutte le micro attività si impara a poterle dare in carico a qualcun altro. Mi piace lavorare tenendo in mente che se un mio collega si libera posso sempre 'usarlo' al fine di velocizzare la chiusura di una carta.

Quindi quando si chiede: "qualcuno ha un task che posso fare?" è un buon obiettivo di team rispondere con una pletora di "io, io!!" 

[10 years] Pianificazione e priorita (prima parte)

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. 

[Agile] User story - what I have learned

Only one rule: clearness. 

It is not so important that a user story should be completed in few days as maximum, if this implies that it needs to become technical oriented.

An example
    We have a user story called 'multi currency' - actually our payment system manage only euro currency. This functionality is clear ; it is also big, so it is worth to think about some split, like 'multi currency only for protocol X'. A bad split is 'on database add a table named currencies'. Please don't do that.