E tu, quanti pomodori fai in un giorno?

Giorno dopo giorno scopro che c’è sempre meno gente che è a conoscenza di una fantastica tecnica di studio/lavoro… la cosiddetta “Tecnica del Pomodoro”!

Prendo in mano questo argomento ora, approfittando del fatto che proprio ieri ho parlato dell’agile programming. La tencica del pomodoro infatti è “sponsorizzata” dall’ xPlabs .

Cercherò ora di riassumere tutta la suddetta pratica, invitandovi però a leggere tutto il paper su tecnicadelpomodoro.it, vi assicuro che la lettura è molto interessante nonchè a tratti ironica (sfido chiunque a non ridere almeno un po’ leggendola, con la ovvia conseguenza di ritrovarsi poi ad annuire ad ogni frase)

Iniziamo.

Innanzitutto è bene dire che questa tecnica è stata inventata da Francesco Cirillo nel 1996 e successivamente perfezionata da lui ed il suo team.

Si basa su alcuni semplici concetti, semplici ma troppo spesso sottovalutati e poco considerati, come ad esempio “il tempo”.

Per molte persone infatti il tempo rappresenta un nemico. L’ansia relativa al “tempo che passa”, soprattutto in presenza di scadenze, genera comportamenti non efficaci nel lavoro e nello studio e, per questa via, sviluppa la tendenza a procrastinare.

La Tecnica del Pomodoro nasce con l’obiettivo di utilizzare il tempo come un utile alleato per realizzare le proprie attività nel modo desiderato e consentire un continuo miglioramento nel proprio processo di lavoro o studio.

Tre sono le ipotesi di lavoro alla base della Tecnica del Pomodoro:

• Un diverso modo di “vedere” il tempo, non più centrato sul concetto di divenire, riduce l’ansia e, per questa via, porta ad aumentare l’efficacia personale;
• Un migliore impiego della propria mente consente di ottenere maggiore lucidità,consapevolezza, focalizzazione, e facilita l’apprendimento;
• L’impiego di strumenti semplici da usare e poco intrusivi riduce la complessità diapplicazione della Tecnica, favorendone la continuità, e consente di concentrare gli sforzi sulle attività da realizzare. Molte tecniche di gestione del tempo falliscono perché impongono, a chi le utilizza, un alto livello di complessità aggiuntivo rispetto alla complessità intrinseca dell’attività da realizzare.

Per realizzare la Tecnica del Pomodoro è sufficiente dotarsi di:

• Un Pomodoro: un timer da cucina
• Un foglio delle “Attività da Realizzare Oggi” , redatto quotidianamente a inizio giornata e composto da: Una intestazione con luogo, data e autore; Una serie di righe con la lista delle cose da fare nella giornata in ordine di priorità; Una sezione intitolata “Urgenti Non Previste” nelle cui righe inserire le attività non previste che devono essere realizzate entro la fine della giornata. Attività quindi potenzialmente in grado di alterare la programmazione del giorno.
• Un foglio del “Magazzino di Attività” , composto da: Una intestazione con il nome dell’autore; Una serie di righe sulle quali si annotano le varie attività da svolgere mano a mano che si presentano e dal quale, a fine giornata, si depennano le attività realizzate.
• Un foglio delle “Registrazioni”: che rappresenta l’insieme di dati grezzi necessari per produrre i report e i grafici di interesse. A seconda degli obiettivi posti sotto osservazione contiene un diverso insieme di campi. In genere contiene la data, la descrizione e il numero di Pomodori di sforzo necessari per realizzare l’attività. L’aggiornamento di questo foglio avviene almeno una volta al giorno, tipicamente a fine giornata.

La tecnica del pomodoro si pone alcuni obiettivi fondamentali, quali:

1. Rilevare lo sforzo per ogni attività:

• Il Pomodoro non è interrompibile. I 25 minuti sono quindi 25 minuti di puro lavoro.
• Il Pomodoro non è divisibile. Non esistono i mezzi Pomodori o i quarti di Pomodoro.
• L’unità atomica di tempo è un Pomodoro.
• Se il Pomodoro viene definitivamente interrotto da qualcuno o qualcosa, quel Pomodoro è da considerarsi nullo, mai caricato, e si proseguirà dando la carica ad un nuovo Pomodoro.
• Lo squillo del Pomodoro sancisce la fine perentoria, anche se temporanea, dell’attività. Non è quindi ammesso continuare l’attività per “altri due minuti”, anche se ci si sente convinti che in quei “due minuti” la si potrebbe completare.
• Nella pausa non si deve assolutamente continuare a pensare a quanto realizzato negli ultimi Pomodori.

2. Ridure le interruzioni

Il periodo di 25 minuti del Pomodoro sembra sufficientemente breve da consentire di resistere alle diverse forme di interruzione. Nell’esperienza però, quando si inizia a praticare la Tecnica del Pomodoro, le interruzioni possono essere problematiche da gestire. Di qui la necessità di una strategia per ridurre le interruzioni “non gestite” ed arrivare progressivamente ad aumentare il numero costante di Pomodori realizzati senza interruzioni.

Esistono vari metodi per la gestione sia delle interruzioni interne (ovvero dentro di noi) che per quelle esterne. Rimando a questo punto alla lettura del paper, che consiglio vivamente.

3. Stimare lo sforzo delle attività

4. Rendere più efficace il Pomodoro

5. Definire un orario

Sono diversi i motivi per cui non bisogna sottovalutare l’importanza di definire e rispettare un orario:

• Un orario definisce un limit. I limiti, quando sono realmente eprcepiti come non violabili, aiutano ad essere “concreti”.
• Un orario definisce la separazione tra il tempo in cui lavorare ed il tempo libero, dove per tempo libero si intende lo svolgere attività non finalizzate o non programmate. Questo tempo è la benzina per la propria mente. Senza tale benzina si perde creatività, interessem curiosità, ci si stanca fino ad esaurire le energie.
• Un orario misura i risultati della giornata. Se arriva il termine dell’orario e non si sono completate tutte le attività pianificate per la giornata, si cerca di capire cosa non ha funzionato

Nella tecnica del pomodoro non è importante rilevare il tempo perso, quanto il numero di Pomodori realizzati. L’indomani si considererà quel numero per definire i Pomodori disponibili e si assegneranno attività solo fino al raggiungimento di quel numero di Pomodori. Il rischio principale degli orari è che è facile sottovlutarne l’importanza e cadere nell’errore di non rispettarli.

In conclusione.

La sensazione di avere avuto più tempo per fare cose e non averlo usato proficuamente è spesso paralizzante. La nostra mente inizia a vagare tra passato e futuro stimolando sensi di colpa e creando situaizoni di ansia per cose che si sarebbero potute fare ma che non si è fatto.

La Tecnica del Pomodoro consente sempre di focalizzarsi sul Pomodoro corrente, o una volta terminato, sul prossimo Pomodoro. L’attenzione è rivolta “qui e ora”.

Quando ci si sente perduti è possibile destinare un Pomodoro ad attività esplorative per riordinare le priorità e organizzare unnuovo piano. Se si hanno invece già le idee chiare e manca “qualcosa”, forse la volontà, forse un po’ di coraggio, si carica il Pomodoro e si comincia a lavorarci su, senza aspettare il tempo!

…

Allora cosa ne dite?

Vediamo chi fa più Pomodori?

L’insostenibile leggerezza del progettare

Una  metodologia che ho sempre trovato molto affascinante è l’Agile Programming.

Per chi non lo conoscesse (male!!) ne farò ora una breve descrizione perchè credo che sia un’ottimo modo di procedere per garantire dei buoni prodotti finali.

Innanzitutto le metodologie di sviluppo agili si contrappongono con le classiche metodologie di sviluppo quale ad esempio lo sviluppo a cascata. Tali metodologie hanno l’obiettivo di organizzare il processo di produzione del software per renderlo prevedibile, affidabile, efficiente e ripetitivo ma per ottenere questi risultati richiedono anche di applicare in modo rigoroso una serie di linee guida, di controlli, di adempimenti  “burocratici”, tra cui molta molta documentazione.

In contrapposizione a tutta questa pesantezza sono nate le metodologie “agili”.

Tra i vantaggi di questa tecnica vediamo innanzitutto la necessità di produrre poca documentazione (cosa fantastica a mio parere. Ho sempre creduto poco nelle aziende e nei team di sviluppo che meticolosamente compilano rapporti ogni giorno e soprattutto sono convinti che questo serva!), successivamente c’è il fatto che si adatta anche a piccoli team di sviluppo, anzi, questi sono nettamente preferibili, che ha come obiettivo principale una buona usabilità e quindi semplicità del software da produrre e che lo sviluppo avviene in maniera incrementale, ovvero a piccoli rilasci successivi.

Caratteristiche a mio parere assolutamente affascinanti per una metolodologia di programmazione.

Le metodologie di sviluppo agili partono dalla considerazione che i requisiti utente cambiano in continuazione durante il progetto, per cui non ha molto senso svolgere una pesante attività di analisi, di progettazione e di documentazione prima di iniziare la codifica, in quanto molto di questo lavoro potrebbe essere sprecato (questa frase mi fa letteralmente venire voglia di gridare a sguarciagola “Evviva Evviva!!!”).

Si può inoltre mantenere la documentazione essenziale all’interno del codice sorgente stesso: così quando si modifica il codice a seguito delle variazioni di specifiche richieste dal cliente, si modifica anche la documentazione.

A questo punto è mio assoluto dovere citare una delle più note e diffuse metodologie agili: l’ eXtreme Programming (XP).

Alcune pratiche dell’eXtreme Programming sono:

• La ricerca della soluzione più semplice;
• L’estrema semplicità del codice;
• Standard di codifica rispettato da tutti, nel senso che chiunque deve poter comprendere il codice scritto da un altro membro del gruppo;
• La progettazione dei test prima della codifica;
• La programmazione in coppia (pair programming), ovvero un tipo di programmazione che vede solo due persone coinvolte, una scrive e l’altra supervisiona con la possibilità/necessità di interscambiarsi i ruoli (chi scrive il codice è focalizzato sul modo migliore per realizzare un metodo, una classe, un algoritmo, mentre il collega che gli sta dietro mentre lui scrive è focalizzato sui controlli da effettuare, su cosa potrebbe non funzionare, su possibili strade alternative);
• Interazioni brevi e frequenti;
• Integrazione continua, ovvero si basa sul fatto che il testing intensivo e soprattutto continuo garantisce che ad ogni rilascio successivo il sistema rimanga comunque stabile;
• Refactoring del codice, cioè sua ristrutturazione per contrastare il possibile degrado dovuto alle continue implementazioni;
• Cliente sempre disponibile: un suo rappresentante deve sempre essere a disposizione del team di lavoto per rispondere alle domande;
• Riunioni in piedi;
• Proprietà collettiva del codice: chiunque all’interno del team di lavoro può modificare qualunque parte del codice in qualsiasi momento.

Cosa dire di più? descritta così verrebbe voglia di applicarla subito sempre e comunque!

Purtroppo (in Italia soprattutto) questa metodologia è ben poco applicata.

Infatti, nonostante spiegata così possa sembrare assolutamente perfetta (oggi mi sento evidentemente molto positiva!), essa riserva anche qualche difettucio che si potrebbe dire causa della scarsa applicazione nel nostro Paese.

Uno dei principali “pregi” di questa metodologia è il fatto che coinvolge molte figure di alto livello che collaborano tra loro in periodi continuati di forte concentrazione. Bello sì, ma ovviamente anche molto costoso!

Inoltre il voler ottenere in tempi brevi prototipi o prime versioni funzionali del prodotto dalla qualità eccelsa e perfettamente in tempo per il mercato, significa anche bloccare completamente interi team di progettazione e sviluppo per tempi medio-lunghi. Team di lavoro che oltretutto richiedono una particolare attenzione e abilità nell’essere formati. Lavorare in modalità agile è una tecnica soprattutto psicologica, prima ancora che tecnica. Nel senso che dovendo lavorare a così stretto contatto con altre persone e con il proprio lavoro costantemente messo sotto pressione e sotto il giudizio dagli altri membri, non è cosa così facile spicologicamente sostenibile. Richiede molta apertura mentale e stima reciproca tra tutti i membri del gruppo, senza che ci sia nessuno che voglia sopraffare gli altri. Caratteristiche credo non molto facili da trovare…

Insomma, in parole povere è una metodologia potenzialmente costosa (uso questa parola perchè in fondo essa avrebbe anche come obiettivo la riduzione di tempi e costi tramite eliminazione del lavoro inutile e dei tempi morti, ma questo non è sempre visibile da subito).

Quando il budget totale è relativamente basso, è praticamente insostenibile mantenere un processo di creazione agile ed il team tende quasi sempre a passare ad una metodologia di sviluppo a cascata: “si fa quello che si può… come viene viene” si preferisce dire, e purtroppo questa è una realtà molto comune.

Non è da nascondere che nel nostro mercato non sempre si punta alla qualità e che i clienti chiedono spesso, a prescindere da tutto e soprattutto da tutte le belle parole dei progettisti sulla potenziale usabilità/qualità del prodotto, una chiusura del progetto in tempi brevi e con costi contenuti.

Succede così che chi fa “agile” si trova, in breve tempo a dover affrontare più progetti “mediocramente” perchè non ha i fondi per affrontarne uno “seriamente”.

Alla fine dunque il risultato è sempre lo stesso: prodotto incompleto e di scarsa qualità.

La domanda che a questo punto viene spontaneo porsi dunque è: ma bisogna cambiare la mentalità della clientela/mercato portandola a comprendere i vantaggi di questi processi oppure identificare nuove strade che intermedino il tutto?

Il tempo ci darà una risposta… speriamo!

(parte di questo post è stata presa da un articolo di qualche mese fa di Luca Mascaro “Sostenibilità dell’Agile design”… la citazione è d’obbligo, trovandomi in assoluto accordo con lui, o meglio, questo è uno di quei milioni di casi in cui io penso una cosa e poi scopro che qualcun altro ha già scritto a riguardo e non ho quindi potuto far a meno di usare alcune sue parole per un esplicita citazione!)