xebir logo mvp orizzontale psm1 small  cdacda consortium  safe sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo


Warning: count(): Parameter must be an array or an object that implements Countable in /web/htdocs/www.felicepescatore.it/home/templates/gk_magazine/html/com_content/article/default.php on line 13

La metafora del Mappazzone

Ebbene lo ammetto! Spesso mi diverto a guardare la nota trasmissione televisiva masterchef, non tanto per la gara in sé (a malapena so cucinare un piatto di pasta con il sugo pronto), ma per la capacità dei giudici di creare un’atmosfera che coniuga il momento gioviali all’interno di attività che richiedono forte concentrazione, preparazione e precisione.

In realtà, in masterchef troviamo molti elementi comuni del mondo Agile: timeboxed, capacità di adattamento (es: mistery box), l’importanza fondamentale di lavorare in team (brigate), l’obiettivo ultimo di soddisfare sempre l’utente (i giudici).

Potremmo, probabilmente, immaginare addirittura qualcosa di simile ad un’Agile Masterchef workshop.. e non è detto che prima o poi non lo faremo J

Quello su cui però voglio soffermarmi è un termine, preso in prestito proprio dalla trasmissione in oggetto, che mi è capitato spesso di utilizzare ultimamente nell’azione di coaching, soprattutto quando affrontiamo questioni tecniche inerenti al design applicativo: il mappazzone!

Il termine è usato dallo chef Bruno Barbieri e, come lui lo usa per descrivere un piatto che non ha anima, ma che è semplicemente l’insieme caotico di ingredienti mischiati alla meglio, così lo si può utilizzare per descrivere un cattivo design applicativo.

barbieri mappazzone

Ma cos’è un cattivo design applicativo? E ci mancherebbe altro che, da Coach, non rispondessi “dipende” J, anche se abbiamo a disposizione diverse linee guida: dai principi SOLID, a GRASP e quindi ai Design Pattern e ai concetti di Separation of Concern.

Per scoprire se quanto stiamo realizzando si sta trasformando in un mappazzone, suggerisco spesso ai team di sfruttare approcci come TDD o, se preferiscono qualcosa di meno stringente, Test First Programming, e farsi una semplice domanda: il codice è facile da testare? Riesco a creare uno o più test che mi verificano quanto realizzato in chiave end-to-end?

Ecco, se la risposta a queste domande è tendenzialmente no, stiamo creando un mappazzone!

È sempre interessante riuscire a parlare con i team in modo diretto, trovando formule di uso comune che, con semplicità, apra una riflessione e porti a delle azioni di miglioramento… a mio avviso, un bravo coach si riconosce spesso dalla capacità di sintesi, ovvero di riuscire a esprimere in con poche parole o metafore, concetti complessi, portando il team a farsi delle domande e cercare delle risposte… un po’ alla Lubrano.

Stay tuned J

Tagged under: agile, coaching,