[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!!" 

Nessun commento: