Il mondo dello sviluppo software una volta era differente: il metodo usato era il waterfall, i processi erano strutturati sequenzialmente, ogni blocco rappresentava un grave problema e un ritardo certo, su tutta la pipeline di lavorazione.
Oggi con le metodologie agile la pipeline di sviluppo è molto più reattiva ai problemi, il metodo consente di non restare bloccati mai, anche in caso di disastro in altre sezioni dello sviluppo, problemi dovuti a scarsa analisi, imprevisti.
Se questo è vero nella ideale teoria del metodo, non lo è per le persone del team, che devono imparare a non bloccarsi davanti alle difficoltà.
Davanti ad un blocco lo sviluppatore spesso, dopo qualche indecisione, segna il task come bloccato, chiede lumi in giro e al responsabile, attende.
Un grave errore che fa diventare la metodologia agile uguale al waterfall.
Ecco come si deve procedere secondo me:
- Si trascina il task in blocco.
- Si spiega nei commenti al task in maniera esaustiva cosa causa lo stop.
- Si scrive nei commenti al file o nei commenti al task, ogni informazione per la prosecuzione dello stesso in futuro.
- Si avvisa del blocco il responsabile, che sarà autonomo nel leggere in modo asincrono le spiegazioni dei motivi.
- Si pesca dal backlog un task che non ha blocchi e lo si affronta.
In questo modo la pipeline non si interromperà, il responsabile avrà il tempo necessario per trovare una soluzione al blocco, riorganizzare la lavorazione del task, informare lo sviluppatore della decisione presa.
Lo sviluppatore completerà con serenità il task preso in sostituzione e poi recupererà quello bloccato: se ha scritto bene le informazioni per proseguirlo, non sarà difficile ricominciare.
La produttività del team deve sempre crescere nel team stesso, sulla propria cultura aziendale e di processo, cercate di guidare i vostri team sempre verso soluzioni autonome, se vi comportate come un oracolo, il team attenderà sempre voi.
