In solitaria con il Pomodoro: considerazioni psicologiche e rapporti con il cliente

Ormai sono rientrato a lavorare da due settimane e (purtroppo) sto lavorando da solo. Solitamente il ritorno dalle vacanze e la mancanza di un compagno portano a poca concentrazione e soprattutto a vagare con la mente su vari task, arrivando spesso a fine giornata con la sensazione di aver “sprecato un giorno”. Questi aspetti uniti al desiderio di tracciare in modo più preciso il tempo speso sulle storie e ad un metodo sistematico per migliorare le stime mi hanno portato alla prima esperienza con la pratica del Pomodoro ideata da Francesco Cirillo.

In due parole un Pomodoro è un timer (meglio se da cucina ed a forma di pomodoro) che si carica a 25 minuti durante i quali si sviluppa senza alcuna interruzione (no telefono, no email, no messenger, no musica); al driiin si ricarica su 5 minuti durante i quali si fa ciò che si vuole (si telefona, si leggono le email, si messaggia, si ascoltano i Guns, si chiacchiera). Ogni due ore si fa una pausa più lunga (15 minuti). Al termine di ogni pomodoro o a metà giornata si traccia quanto fatto sul proprio sistema di tracking preferito (attualmente per me è Excel con grafici committed/estimated e altre metriche).

Precondizione all’utilizzo di questa pratica è che il programmatore/i sappiano a cosa si devono dedicare nei prossimi 25′, e che l’ambiente che ci circonda (es. cliente o altri team) conosca la pratica per minimizzare interruzioni e distrazioni.
Ritengo degni di nota i motivi per i quali solo ora ho sperimentato questa pratica. Sostanzialmente si tratta di motivi psicologici e sociali più che tecnici:

• il countdown inviterà alla corsa?
• porterà ad una sorta di “ansia da prestazione”?
• aumenterà lo stress da lavoro?
• limiterà la mia libertà personale?
• sarò più controllato dal cliente e dai colleghi?

Effettivamente quando parlo del Pomodoro con i miei colleghi sento in modo più o meno esplicito le stesse remore. Invece dopo circa dieci giorni di applicazione della pratica, molti dei timori si sono rivelati infondati. Infatti a fine giornata si arriva con la sensazione di aver lavorato sodo ma senza stress forse perché avere stabilito un ritmo lavoro-pausa in modo sistematico, porta ad avere i propri spazi senza rimorsi, nè sensi di colpa. Inoltre unità di lavoro piccole portano a costruire sin da subito la sensazione di avanzamento verso un obiettivo. Il fatto di “chiudere” tutte le distrazioni permette di lavorare con più tranquillità e di incanalare le energie verso un task alla volta, con grande beneficio per la propria capacità di rimanere lucidi a lungo. Allo stesso tempo durante lo scorrere del pomodoro ho percepito meno ansia perché consapevole che in qualche modo lo sforzo che stavo impiegando sarebbe stato comunque riconosciuto perché tracciato. Il ritmo 25′-5′ si è rivelato abbastanza flessibile da permettere di richiamare il cliente che ci ha cercato, o semplicemente di potersi sgranchire le gambe prima della saturazione cerebrale. Ad ogni modo mi è capitato di cedere alla tentazione di saltare i 5′ di break, ma la maggior parte delle volte mi sono pentito di non aver “sganciato un attimo” soprattutto per non fossilizzarsi troppo a lungo su un’unica soluzione del problema.

Indubbiamente nei giorni in cui non ci si è potuti dedicare come si desiderava allo sviluppo dei task, se il tracking viene condiviso con il cliente ci si trova molto probabilmente a dover fornire delle giustificazioni. Tuttavia non considero questo aspetto negativo a-priori per lo sviluppatore, perché può far emergere ad esempio un’eccesso di interruzioni da parte del cliente stesso, e comunque facilita la ricerca dei colli di bottiglia nel processo fornendo le basi per una contromossa (ad es. uomo muraglia). Quest’ultimo aspetto porta anche a riflettere sul cosa tracciare: Ron Jeffries in “Extreme Programming Installed” consiglia di tracciare e di stimare lo spazio dell’implementazione della soluzione, quindi non l’analisi o tutto ciò che si fa a contorno dell’implementazione (pensare alla soluzione). Questo però non permette di isolare in maniera precisa il tempo dedicato al task (nella sua completezza) ed il tempo che invece si dedica ad altro anche forzatamente. Personalmente ad esempio mi interessava quantificare le interruzioni. Per questo motivo ad oggi ho deciso di tracciare in pomodori anche il tempo dedicato all’analisi del task ad esempio nel chiarire con il cliente i punti oscuri.

Nel caso in cui si vogliano condividere i dati con il cliente è comunque molto importante esplicitare cosa verrà tracciato dell’attività lavorativa e cosa invece non ci interessa tracciare, per evitare spiacevoli incomprensioni ed un effetto boomerang che si può ripercuotere sui programmatori e sulla serenità dei rapporti cliente-fornitore.

Un’ultima considerazione di natura tecnica: rispetto al classico suggerimento XP di non tracciare in modo così fine, ma di calcolare la velocità semplicemente in base alle storie completate a fine iterazione e di confrontare questo numero con quanto stimato, il Pomodoro permette di comprendere se è sul versante “bontà delle stime” che dobbiamo migliorare, o al contrario se le stime erano corrette, ma il tempo effettivo è stato influenzato da più interruzioni del previsto. Questo è importante per comprendere se dobbiamo migliorare le stime o se invece il constraint è altrove.