Parto quotanto la parte incriminata

Per ogni fase ci possono essere un numero limitato di user stories, in questo modo si possono facilmente identificare eventuali stalli, fasi problematiche, sprechi di vario genere ecc…, peccato che tutto questo sia molto lontano dall’essere Agile… perchè? Semplice il limite è imposto sulle fasi, si presuppone quindi che ogni fase sia un sottosistema dimensionabile a piacere per equilibrare il flusso delle user stories fino al loro completamento, una fabbrica insomma, alla fine siamo tornati al waterfall (il cravattato ci prova sempre, non c’è niente da fare)

Molto più Agile e sensato sarebbe limitare la capacità produttiva del team sulle dimensioni del team stesso, banalmente una user story per sviluppatore, al limite per coppia di sviluppatori. Ad ogni sviluppatore assegnamo una calamita, le user story appese alla lavagna sono in lavorazione, una user story può essere appesa usando solo una di quelle calamite, una calamita può essere usata solo con una user story alla volta ed il gioco è fatto. Le fasi possono essere ancora conservate, possono essere utili per stanare certi problemi, ma l’enfasi dovrebbe essere sugli sviluppatori e non sulle fasi (“Individuals and interactions over processes and tools” vi ricorda qualcosa?)

Premettendo che ognuno può fare quello che vuole (ammesso che ne paghi direttamente le conseguenze), sarebbe meglio che lo facesse sapendo quello che sta facendo e perchè lo fa. Quello che ho notato è che chi ha adottato le Kanban Board lo ha fatto senza porsi delle domande fondamentali: qual’è l’oggetto della limitazione? Qual’è la misura del miglioramento? Come misuro la capacità produttiva del mio sistema? Ecc…

Ok lo ammetto, è una mia supposizione il fatto che la maggior parte non si ponga queste domande. Questa supposizione derivata dal fatto che mi sembra applicata troppo “by the book”, dove il “book” non riguarda affatto la produzione del software ma una catena produttiva manifatturiera.

Le Kanban Board nel mondo del software generalmente sono divise per fasi e la limitazione è applicata appunto su queste fasi, perchè? Partendo dal presupposto che lo scopo è quello di stabilizzare e velocizzare il flusso delle user story nelle varie fasi, stiamo dicendo che è possibile “dimensionare” ogni fase a piacere? Quindi, per esempio, chi sviluppa non fa deploy di quello che ha sviluppato? Evidentemente, altrimenti non si spiega perchè la fase dello sviluppo è dimensionato a 5 user story e il deployment a 1

Sempre a proposito delle fasi, negli impianti manifatturieri il fatto che ogni fase sia limitata è una coseguenza banale del fatto che le linee produttive sono per loro natura limitate, ma vale la stessa cosa nel software? Nel nostro team siamo in 5, non possiamo essere nella fase di test tutti e 5? O non possiamo fare deploy tutti e 5? Perchè? A meno che non ci siano 3 analisti che si occupano della fase di analisi, 5 sviluppatori che si occupano della fase di sviluppo, 2 persone che si occupano dei test, ecc… Allora sarebbe un’altra storia, ma trattare il team a dipartimenti specializzati e ridimensionabili a piacere è quello che vogliamo? Personalmente mi fa venire la nausea, ma basta esserne consapevoli

Domanda ancora più importante: il total flow in questo caso come lo si immagina? O meglio, qualcuno misura il Lead Time? Domanda lecita visto che non ne sento molto parlare, almeno non tanto quanto sento parlare di Kanban Board, e visto che la riduzione del Lead Time dovrebbe essere l’obiettivo finale…

Insomma, non vorrei che il seguire una moda possa fare più male che bene, sopratutto quando non ci si prende la briga di studiarla, di comprenderne il funzionamento e sopratutto senza domandarsi come misurare il miglioramento secondo i propri obiettivi. In particolare l’applicazione classica per fasi mi sembra pericolosa da questo punto di vista e suggerivo un’alternativa che mi sembrava meno rischiosa. Dato che l’approccio è di tipo sistemico, una volta messa in campo una Kanban Board “storta” si corre il rischio di stortare tutto :-)

Prima si è iniziato a parlare di Lean, poi qualcuno ha iniziato ad usare e a parlare di Kanban Board, infine adesso Kanban è diventato quasi il nome di una metodologia. Adesso quando uno parla di Kanban non so a cosa pensare:

• Starà parlando di Kanban come sinonimo di Lean? Si ma Lean come sinonimo di Lean Thinking, ovvero la filosofia Lean o Lean Development, ovvero l’applicazione della filosofia Lean allo sviluppo del software?
• Starà parlando di Kanban come sinonimo delle board che adesso vanno tanto di moda negli Agile shop?
• Starà parlando di Kanban come di una non meglio precisata metodologia? Come lo ScrumBan, ovvero uno Scrum che fa uso di Kanban Board o come Kanban, ovvero l’uso delle Kanban Board misto a qualche pratica presa da XP?

Insomma un delirio, la salvezza come al solito sta nella conoscenza: bisogna tornare alle origini della parola, studiarne l’evoluzione per capirne le implicazioni ed un eventuale contesto d’uso

Kanban si traduce in cartellino: I giardini imperiali giapponesi sono curati all’ossessione e sono considerati un patrimonio del giappone, per questo solo poche (supponiamo 100) persone alla volta sono autorizzate ad entrare, per garantirlo vengono usate delle tessere di plastica bianche, ne esistono solo 100, una persona può entrare solo se possiede una di queste tessere che possono essere prelevate da un contenitore all’ingresso, quando il contenitore è vuoto nessuno può entrare, quando una persona esce deposita la sua tessera che verrà automaticamente trasferita nel contenitore all’ingresso consentendo a qualcuno di prelevarla ed entrare. Le tessere di plastica sono Kanban

Quindi i Kanban sono la rappresentazione sistemica del vincolo sulla capacità produttiva dell’impianto. Cosa significa quesa frase e come può tornare utile allo sviluppo del software lo spiego subito

L’applicazione del pensiero Lean porta ad eliminare una classe di problemi e/o di sprechi nell’attività produttiva attraverso un approccio sistemico ovvero creando un ambiente di lavoro che rende difficile commettere errori. Un esempio tipico sono i connettori la cui forma impedisce fisicamente di sbagliare verso. Un altro bell’esempio ce lo forniscono gli ospedali in cui si applica il pensiero Lean, nei quali tutte le attrezzature hanno un posto dedicato che solitamente viene marcato con un’immagine stilizzata del tipo di attrezzo che dovrebbe occupare quello spazio, in questo modo

• E’ molto semplice accorgersi se uno strumento è fuori posto perchè ci sarebbe l’immagine dello strumento senza lo strumento stesso
• Nei momenti d’emergenza non devi metterti a pensare dove si trova uno strumento perchè sta sempre nello stesso posto
• L’ordine non è più una questione di gusto personale :-)
• Essendo la distribuzione degli strumenti così rigorosa è possibile fare esperimenti per capire se un’eventuale riorganizzazione (che è quasi sempre microscopica seguendo il principio del Kayzen) produce un miglioramento o meno

Quando si ha a che fare con dei sistemi complessi è molto più efficiente ed efficace applicare un controllo indiretto invece che tentare di forzare le singole parti al proprio volere, basta pensare all’acqua, le singole particelle costituiscono un sistema complesso con proprietà emergenti, come fai a trasportare l’acqua? tenti di convincere le singole particelle? La sposti fisicamente? O crei un canale e lasci che felicemente scorra seguendo le proprie leggi ma finendo esattamente dove vogliamo Quest’ultimo può essere definito un approccio sistemico

Ahhhh se solo la maggior parte dei manager sapesse… il mondo girerebbe diversamente, ma la resa dei conti arriverà presto caro cravattato dall’ignoranza bovina… ma sto divagando

Le Kanban Board creano un ambiente di lavoro dove è difficile commettere una serie di errori classici della produzione: avere molte user stories in lavorazione (semilavorati) che non portano valore al sistema, evitare il sovraccarico di lavoro del team, individuare molto velocemente eventuali parti critiche dello sviluppo di una user story, ecc… Bene, ma dove sono i Kanban nelle Kanban Board che si usano nella produzione di software? Non sono le carte delle user stories (come banalmente si potrebbe pensare), i kanban rappresentano i limiti della produttività del sistema, in questo caso il limite è sul numero delle user stories che possono essere in lavorazione ovvero i kanban sono i singoli “posti” che possono essere occupati dalle carte delle user stories.

Per ogni fase ci possono essere un numero limitato di user stories, in questo modo si possono facilmente identificare eventuali stalli, fasi problematiche, sprechi di vario genere ecc…, peccato che tutto questo sia molto lontano dall’essere Agile… perchè? Semplice il limite è imposto sulle fasi, si presuppone quindi che ogni fase sia un sottosistema dimensionabile a piacere per equilibrare il flusso delle user stories fino al loro completamento, una fabbrica insomma, alla fine siamo tornati al waterfall (il cravattato ci prova sempre, non c’è niente da fare)

Molto più Agile e sensato sarebbe limitare la capacità produttiva del team sulle dimensioni del team stesso, banalmente una user story per sviluppatore, al limite per coppia di sviluppatori. Ad ogni sviluppatore assegnamo una calamita, le user story appese alla lavagna sono in lavorazione, una user story può essere appesa usando solo una di quelle calamite, una calamita può essere usata solo con una user story alla volta ed il gioco è fatto. Le fasi possono essere ancora conservate, possono essere utili per stanare certi problemi, ma l’enfasi dovrebbe essere sugli sviluppatori e non sulle fasi (“Individuals and interactions over processes and tools” vi ricorda qualcosa?)

Concludo dicendo una cosa ovvia: più si studia uno strumento/pratica/tecnica e più è facile utilizzarlo saggiamente nel contesto in cui ci si trova per raggiungere i nostri obiettivi, il pericolo è quello di abusarne o peggio essrne abusati :-)

Vorrei costruire una casa fatta esattamente in questo modo. Quanto ci metti a costruirmela? Quanto mi costerebbe?

Il costruttore stoicamente risponde

Tre mesi e 100.000 euro

L’uomo, guarda il costruttore con uno sguardo diretto… semplice… come se stesse parlando delle condizioni metereologiche

Ti do una settimana e 5.000 euro

Il costruttore rimane sbigottito… non sa se lo stanno prendendo per il culo o se fanno sul serio: se lo stanno prendendo per il culo è il momento d’incazzarsi, se fanno sul serio è il momento di mettersi a piangere; decide in buona fede di cercare di capire meglio

Scusami, ammesso e non concesso che umanamente sia possibile farlo in una settimana, significherebbe utilizzare molte più risorse di quelle spese per farcela in tre mesi… quindi al limite ti costerà di più di 100.000 euro, perchè dovrebbero bastarne 5.000???

L’uomo, sempre con la stessa faccia risponde

Accidenti, ma quanto vorresti guadagnare in una settimana?!?!?!

… Ve lo dico io, non c’è dubbio, ci stanno prendendo per il culo

A questo proposito faccio un appello a chiunque può essere interessato, secondo me c’è (e crescerà sempre di più) un oceano blu, ovvero un mercato di opportunità non ancora esplorato, che è quello del “Procuratore per sviluppatori”

Il procuratore dovrebbe trovare il cliente (anche se non è necessario, potrebbe trovarlo direttamente lo sviluppatore) e trattare gli aspetti economici e burocratici del progetto per conto dello sviluppatore, in cambio il procuratore si becca il 20% del fatturato, gli aspetti tecnici vengono gestiti direttamente dallo sviluppatore, esattamente come succede per i calciatori/sportivi (anche se ammetto di non saperne molto ;-P)

Ci sono molti dettagli che devono essere definiti, ma potrebbe funzionare, da gennaio/febbraio sto lavorando in questo modo e sono abbastanza soddisfatto, se qualcuno è interessato, mi contatti direttamente :-)

Il desiderio di controllo nasce dalla paura di non averlo

Da cui una metrica molto semplice da misurare per colui che si definisce professionista

Tutte le volte che un cliente ti chiede a che punto sei in merito ad un lavoro che stai facendo per lui, hai perso 10 punti. Se non rispondi in tempo reale, hai perso 1000 punti

Inutile dire che perdere punti è molto più semplice che guadagnarli… Quello che penso è che il “command & control” non lo voglia spontaneamente nessuno, neanche il cliente, ci si arriva quando costretti, sopratutto per la mentalità italiana dove il 90% della popolazione vorrebbe fare “l’intermediario” nullafacente

Analizziamo il processo mentale del cliente

• Gli ho chiesto di fare questa “piccola” cosa due giorni fa e non ho più saputo niente, cosa starà facendo? Starà lavorando? E’ una cosa importante, deve essere pronta per questa sera… Forse è meglio lasciarlo lavorare, fra poco si farà sentire…
• Sono le 16:00 e non si è ancora sentito nessuno… eh no, adesso basta, gli faccio il culo, non è possibile, aveva detto che avrebbe consegnato prima di sera e sono due giorni che non si fa sentire, gli mando una e-mail
• Non risponde neanche alle e-mail!!! Lo sapevo, non ha fatto niente!!! Per questa sera non sarà pronto niente e sarò nella merda!!! La prossima volta non ci casco più!!!

Ora, poco importa se il nostro “professionista” era in meditazione per riuscire a finire in tempo, poco importa se effettivamente la consegna è avvenuta in tempo, l’ansia e il dubbio sono comunque entrati nella mente del cliente che vorrà avere sempre più “controllo”, anche se la sua forma di “controllo” sarà letale per il progetto :-)

Ogni volta che un vostro cliente vi chiede informazioni su qualcosa, lo fa perchè si sente obbligato a farlo, se potesse eviterebbe, confrontatevi immediatamente con lui per capire come fornigli in anticipo le risposte ai suoi dubbi, siate veri professionisti, non ve ne pentirete

L’atmosfera e il clima sono stati perfetti per un barcamp: bel posto (tra l’altro ero in poltrona in prima fila, l’unica cosa difficile è stata mantenere la lucidità dopo pranzo), bella gente, Luca è stato un ottimo padrone di casa e sopratutto le competenze dei presenti erano molto eterogenee (programmatori, designer e product manager/owner)

Personalmente mi sono giocato la presentazione sui kata della programmazione

La stessa che ho portato al javaday

Se siete interessati al tema vi consiglio di iscrivervi alla ml del milano-xpug e/o a quella del milano-codingdojo, stiamo organizzando alcune attività anche non strettamente legate all’area di Milano :-)

P.S. Alla fine del talk dico di aver seguito la scuola di Martin Fowler del Clean Code, imperdonabile errore, ovviamente stavo parlando di Robert C. Martin :-)

Maggior conoscenza acquisiamo sui nostri utenti, maggiori saranno le probabilità che la prossima funzionalità pensata/implementata sarà apprezzata (aumentando il valore dell’applicazione). Minore sarà il tempo/costo d’implementazione di una nuova funzionalità, maggiori saranno le funzionalità che potremmo utilizzare per acquisire conoscenza sui nostri utenti

Cosa possiamo fare per minimizzare i tempi/costi d’implementazione? Chiaramente possiamo intervenire da un punto di vista tecnico migliorando la nostra capacità di produrre software, mantenendo sempre pulita la nostra base di codice, migliorando costantemente gli aspetti di project automation e di autonomation, ecc… insomma avete capito

L’altra cosa che possiamo fare è splittare in maniera creativa ed aggressiva le user story esistenti del prodotto. Prima possiamo iniziare a selezionere un minimo set di user story in grado di dare dignità di prodotto al nostro progetto, poi possiamo iniziare a considerarle singolarmente e a capire cosa possiamo togliere da ogni user story conservando la possibilità di poter utilizzare il risultato come MVP

Un esempio? Avevo 10 giorni (nessuna domanda please sul perchè di questo numero magico…) di tempo per realizzare un’applicativo piuttosto complesso, ovviamente c’era di mezzo uno storage, ovviamente il cliente aveva richiesto un’interfaccia di amministrazione/gestione di questo storage e ovviamente non aveva tralasciato nessun “goodies”: utenti, gruppi, ruoli, permessi, editing, viste configurabili sui dati, ecc… praticamente mi sarebbero serviti molti più giorni di quelli a disposizione solo per questa parte accessoria del sistema. Volevo iniziare dal vero prodotto, ma volevo anche che il cliente lo potesse utilizzare da subito, così ho installato phpMyAdmin e ho fatto vedere al cliente come utilizzarlo: ho creato utenti, viste, maschere, ecc… alla fine il cliente mi ha detto che è esattamente quello che voleva :-D Ok, sono stato fortunato, ma è stata una vera epifania

Un’altro esempio un po’ più creativo? Kent Beck qualche hanno fa ha tenuto un workshop sullo split delle user story usando un esempio alquanto “ardito”: il gioco del tetris… qual’è secondo voi la prima user story per Beck? Una colonna, un quadratino 1×1 che scende a velocià costante, quando un quadratino tocca il fondo parte un altro quadratino, il nuovo fondo è il quadratino precedente, quando il fondo arriva in cima alla colonna “game over” :-D

Ancora una volta una conferma del fatto che il business (il problem team come lo chiama Ries) e la tecnologia (solution team) non si possono/devono ignorare a vicenda

• Pianificazione: identificare le User Story tenendole ad una granularità/indipendenza sufficiente da poter realizzare prima quelle con il più alto valore di business. Inutile dire che la valutazione del valore di business di ogni singola user story è fondamentale
• Esecuzione: migliorare costantemente la velocità di realizzazione delle suddette User Story

L’obiettivo supremo è sempre quello di massimizzare la quantità di valore consegnato nell’unità di tempo e in subordine la capacità di produrne in futuro, il resto sono chiacchere

E’ un concetto estremamente semplice, ma estremamente efficace se dovete introdurre a qualcuno le pratiche proprie delle metodologie Agili. Detto questo però se avete poco tempo a disposizione per catturare l’attenzione di qualcuno, se dovete fare un elevator pitch, vi serve qualcosa di molto immediato, vi servono delle metafore

Negli ultimi due anni ne ho raffinata una per spiegare come funziona la pianificazione e visto che è risultata essere particolarmente efficace la condivido con tutti, la scrivo come la racconto di solito

Supponiamo che dall’altro lato di quella porta (nda. di solito c’è una porta nelle vicinanze :-)) ci sia un team di programmatori che deve iniziare un progetto per il quale sono necessarie determinate conoscenze, queste conoscenze possono essere acquisite attraverso lo studio di alcuni libri, il vostro compito è quello di fornirglieli

Il materiale che vi viene dato consiste in 15m^3 di libri e di uno scatolone di 10m^3, se vi state chiedendo “esiste una metodologia in grado di far entrare 15m^3 di libri in uno scatolone di 10m^3?” la risposta è no! Anche le metodologie Agili non fanno eccezione :-)

Quindi cosa facciamo? Se seguissimo alla lettera i vincoli che ci sono stati dati e se non fossimo abbastanza svegli da misurare i volumi che abbiamo a disposizione, probabilmente spenderemo la maggior parte del nostro tempo a tentare di organizzare i libri per riuscire a farceli stare tutti nello scatolone. Una volta arrivati in prossimità della scadenza ficcheremo il maggior numero possibile di libri all’interno dello scatolone per poi spingerlo finalmente al di là della porta dove ci sono i programmatori che lo aspettano

Evidentemente non è una strategia molto furba… come possiamo migliorarla? Ci chiediamo: “qual’è il reale obiettivo di questo lavoro?” Massimizzare al quantità di conoscenza da passare al team di programmatori che sta al di là della porta, “la quantità di conoscenza erogata è indipendente dal libro?” Ovviamente no, quindi una cosa che possiamo fare è scegliere i 10m^3 di libri in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che la scelta delle user story da implementare è il primo passo verso la massimizzazione del flusso di valore)

Bene, possiamo migliorare? Ci chiediamo “ogni capitolo all’interno di un libro eroga la stessa quantità di conoscenza?” Nella maggior parte dei casi no, sicuramente non erogano conoscenza le copertine cartonate, le prefazioni, i ringraziamenti, ecc… Quindi possiamo procedere con un approcio creativo e stracciare ogni libro tenendo solo i capitoli migliori e quindi scegliere i 10m^3 di materiale in grado di fornire la maggior quantità di conoscenza (nda. in questo caso stiamo dicendo che splittando le user story possiamo prendere la maggior parte del valore minimizzando il costo)

Ottimo! Possiamo ancora migliorare? Ci chiediamo “chi è che decide la quantità di conoscenza erogata da un testo?” Fino a questo momento siamo stati noi ma effettivamente è un assunto grave, cosa succederebbe se avessimo torto? La nostra strategia sarebbe ancora valida, ma le nostre misurazioni sarebbero pura speculazione, non possiamo essere sicuri di aver realmente erogato la maggior quantità di conoscenza possibile. “chi potrebbe valutare con maggiore accuratezza?” Sicuramente il team di programmatori che sta dietro alla porta

Quindi possiamo essere ancora più creativi e possiamo chiedere di barattare lo scatolone da 10m^3 con 10 scatoloni da 1m^3, nel primo scatolone ci mettiamo quello che noi riteniamo essere il miglior metro cubo di materiale possibile e lo spingiamo fuori dalla porta chiedendo ai programmatori di chiamarci una volta letto tutto. Quando i programmatori ci chiameranno chiederemo il loro feedback sul materiale, sulla base di queste informazioni sceglieremo cosa mettere nel prossimo scatolone. In questo modo non solo avremo una corretta valutazione del valore consegnato, ma abbiamo anche la possibilità di adattarci al contesto del progetto (nda. in questo caso stiamo dicendo che le funzionalità individuate all’inizio del progetto e la stima di valore che ne viene fatta è nella maggior parte dei casi errata e che quindi serve un reale strumento di feedback)

Secondo me funziona bene perchè

• All’inizio non ti aspetti di poter migliorare molto, quando capisci che puoi farlo è una bella sensazione :-)
• I 15m^3 in 10m^3 danno quella sensazione di claustrofobia che tutti hanno provato nei progetti “fixed *” (leggi: dove tutto è prefissato)
• Si capisce chiaramente che il modo per migliorare dipende poco dalla capacità di fare stime “corrette” quando dall’organizzazione del flusso di lavoro e di feedback

Cosa ne pensate? Possiamo ancora migliorare? :-)

• The customer is the most important thing in your business
• The best business plan is to sell people the things they want
• Your business is successfull if your earnings are higher than your spendings

Troppo spesso le startup vengono fondate su una vision di progetto che esiste solo nelle menti degli stessi fondatori, Eric Ries dice sempre nelle sue presentazioni “vision not delusion”, che potrebbe anche essere “vision not illusion”. Il compito principale di una startup è quello di validare/raffinare nel più breve tempo possibile la propria vision di progetto confrontandosi con l’unica fonte di verità: gli utenti

VC: “Interessante la vostra idea, potete mostrarci il vostro business plan?”
Startup: “Inizialmente avevamo questo set di funzionalità, poi abbiamo eliminato queste funzionalità ed abbiamo aggiunto queste altre e siamo passati da X utenti a 3X utenti, a partire da questa informazione abbiamo modificato il nostro posizionamento nel mercato, abbiamo validato queste informazioni passando da 3X utenti a 10X utenti aggiungendo queste altre funzionalità in accordo con quanto avevamo scoperto. Ora ci aspettiamo di raggiungere i 100X utenti, quindi una revenue di Y, togliendo queste funzionalità e aggiungedo queste altre nei prossimi 2 mesi”

Questo è un business plan nel quale metterei dei soldi…

I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. [...] Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. [...] Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.

Estratto da l’ultimo articolo di Tom DeMarco. Consideriamo anche che DeMarco non è proprio uno di quei “giovani rivoluzionari delle metodologie Agili che non hanno ancora capito niente e che vogliono reinventare la ruota”, è uno dei padri fondatori che si è sparato un po’ tutte le ere geologiche dell’informatica. Il problema è che di solito passa qualche lustro prima che il pensiero degli illuminati diventi di comune dominio… speriamo di esserci quando avverrà :-)

Il succo del discorso è che fare scelte è molto impegnativo, la situazione peggiora se:

• gli obiettivi non sono chiari
• non è chiaro come una scelta potrebbe influenzare il raggiungimento dell’obiettivo
• le scelte sono molte

Provate a pensare al nostro lavoro, o in generale al lavoro creativo dove le possibili scelte sono infinite, dove l’obiettivo è soddisfare un’utente che nella maggior parte dei casi non conosciamo, ecc… capite che non siamo messi molto bene :-)

La tecnica del pomodoro per lo meno ti consente di separare i momenti in cui devi effettuare una scelta (cosa fare e quando farla) e i momenti in cui devi eseguire. La possibilità offerta è quella di eliminare lo stress continuo della scelta, ovvero di eliminare quella vocina che continuamente si chiede “sto facendo la cosa giusta? Potrei fare anche quall’altra cosa! Ah e poi devo fare anche quell’altra! Non sarebbe meglio se quell’altra cosa la facessi subito? Caxxo quante cose ho da fare! Riuscirò a farle tutte in tempo? Ecc…”, ovvero un context switch mentale continuo, uno stress altissimo che non porta sicuramente a nessun risultato

Nei 25 minuti del pomodoro non sei autorizzato a pensare ad altro oltre a quello che stai facendo, quando hai finito hai la possibilità di utilizzare il risultato del tuo lavoro per poter operare delle scelte informate, limitando le speculazioni mentali e diminuendo notevolmente l’ansia

Sostanzialmente è quello che fanno le metodologie iterative ed incrementali a livello di progetto, la tecnica del pomodoro ti consente di applicare lo stesso principio e di ottenere gli stessi vantaggi ad una granularità più fine e direi più umana