Scrivere codice è una di quelle attività che funziona meglio senza interruzione invece che in multi-tasking Il codice risulta migliore e il lavoro richiede meno tempo Punto.
Nel mondo reale può capitare che le cose cambiano senza preavviso (una data, un requisito, una priorità è cambiata) anche cose che hanno conseguenze sul codice che si sta scrivendo. E può capitare che un collega o un cliente in ritardo abbia un grosso bisogno di aiuto per cavarsela.
Ecco perchè saltare come una molla da una cosa all'altra funziona tanto quanto (il suo opposto ossia) chiudersi in una bunker e uscire solo a iterazione completata. Cioè poco.
Il punto quindi è trovare la misura che funziona meglio nella propria specifica situazione. Ecco alcune indicazioni.
Riguardo le piccole interruzioni da colleghi e utenti/clienti ad ogni richiesta la si può annotare e promettere di richiamarli appena finita la cosa in corso: si può aspettare di finire il pomodoro in corso o più pomodori (= più mezzore) senza mai interrompere un pomodoro iniziato.
Quante ragioni di "interruzione" sono già note allo stand-up e possono essere schedulate nella giornata senza causare task-switch improvvisi ? Quanti pomodori i colleghi e gli utenti/clienti possono aspettare prima di ricevere risposta ? E quante interruzioni lo sviluppatore riesce a fare senza deteriorare il suo lavoro?
La risposta si può scoprire con la pratica, provando e ragionandoci a posteriori alla retrospective.
Riguardo il cambio dei piani durante l'iterazione da utenti o clienti a meno che non sia un abort della interazione anche qui si può annotare la richiesta e promettere di incontrare l'utente o cliente appena conclusa l'interazione in corso.
Quanti dubbi o incertezze del piano sono già note al Planning Game e le user story relative possono essere spostate all'iterazione successiva quando i dubbi sono risolti? Fino a quanto gli sviluppatori riescono a spezzare una richiesta in user story di pochi giorni ? E quanti giorni possono aspettare utenti o clienti per cambiare il piano in corso ?
Anche queste risposte si possono trovare con la pratica, provando interazioni di mezza-1-2 settimane e ragionandoci a posteriori alla retrospective.
Tags : Team Work | Agile | Pratiche |
Print | posted @ giovedì 21 agosto 2008 23:34