{"id":4499,"date":"2025-10-26T13:38:23","date_gmt":"2025-10-26T12:38:23","guid":{"rendered":"https:\/\/www.fullo.net\/blog\/?p=4499"},"modified":"2025-10-26T13:38:26","modified_gmt":"2025-10-26T12:38:26","slug":"pensiero-critico-in-quarta-elementare","status":"publish","type":"post","link":"https:\/\/www.fullo.net\/blog\/2025\/10\/26\/pensiero-critico-in-quarta-elementare\/","title":{"rendered":"Pensiero critico in quarta elementare"},"content":{"rendered":"\n

TL;DR:<\/strong> Ho passato sei mesi con quasi 1000 bambini pensando di insegnargli a programmare. Invece mi hanno riprogrammato. Mi hanno insegnato che fallire va bene se capisci perch\u00e9, riuscire senza capire non va bene, e che osservare gli errori altrui \u00e8 efficienza, non pigrizia. E che tutto questo vale soprattutto per noi adulti.

Racconter\u00f2 questa esperienza in dettaglio all’AgileDay 2025<\/a> organizzato da Italian Agile Movement. Se siete curiosi, non leggete oltre ci vediamo l\u00ec, altrimenti questa che segue \u00e8 la prima bozza della trascrizione del talk.<\/p>\n\n\n\n\n\n\n\n

Mi sono seduto a un tavolo. Davanti a me: un quaderno chiuso, un astuccio chiuso con dentro alcune penne. Di fronte: venticinque bambini di quarta elementare che mi guardavano curiosi.<\/p>\n\n\n\n

“Ecco le regole<\/em>,” dico. “Uno per volta mi darete istruzioni precise per scrivere il vostro nome sul quaderno. Potete venire a vedere quando volete, anche quando non \u00e8 il vostro turno.<\/em>“<\/p>\n\n\n\n

Il primo bambino, chiamiamolo Quattrocchi (non tanto per gli occhiali che non aveva ma per l’atteggiamento), parte sicuro: “Scrivi sul quaderno il mio nome.<\/em>“<\/p>\n\n\n\n

Io, con la faccia pi\u00f9 seria possibile, prendo l’astuccio e scrivo sulla copertina del quaderno, usandolo come una immaginaria penna, in grande: “IL MIO NOME”<\/strong>.<\/p>\n\n\n\n

Risate. Frustrazione. “No! Non cos\u00ec!<\/em>“<\/p>\n\n\n\n

“Ma hai detto ‘scrivi il mio nome’,” rispondo innocente. “E io ho scritto ‘il mio nome’. Cosa c’\u00e8 che non va?<\/em>“<\/p>\n\n\n\n

Partono le iterazioni, come in un debug di gruppo fatto ad alta voce. “Apri l’astuccio.<\/em>” “Prendi una penna.<\/em>” “No, stappala!<\/em>” “Girala con la punta verso il basso!<\/em>” “Apri il quaderno!<\/em>” “No, su una pagina bianca!<\/em>” E poi, finalmente, lettera per lettera: “Scrivi Quattrocchi. Q-U-A-T-T-R-O-C-C-H-I.”<\/p>\n\n\n\n

La cosa che ancora mi colpisce? Chi \u00e8 venuto a vedere gli altri tentativi, anche quando non era il suo turno, ha capito il pattern quasi subito. Chi invece ha aspettato “educatamente” il proprio momento ha ripetuto gli stessi identici errori. Come quando in un team tutti fanno lo stesso errore perch\u00e9 nessuno legge davvero le post-mortem.<\/p>\n\n\n\n

Non stavo insegnando precisione nelle istruzioni. Stavo insegnando che imparare dagli errori altrui non \u00e8 barare, \u00e8 efficienza. E che osservare attentamente spesso riduce il lavoro pi\u00f9 di mille tentativi alla cieca.<\/p>\n\n\n\n

Quella lezione non prevedeva computer, robot o codice. Solo un quaderno, una penna, e la volont\u00e0 di sbagliare insieme.<\/p>\n\n\n\n

Il patto sociale <\/h2>\n\n\n\n
\n

\u00abLo sviluppo sostenibile \u00e8 uno sviluppo che soddisfi i bisogni del presente senza compromettere la possibilit\u00e0 delle generazioni future di soddisfare i propri.\u00bb <\/p>\n\n\n\n

Rapporto Brundtland, UN 1987<\/em><\/p>\n<\/blockquote>\n\n\n\n

La definizione del Rapporto Brundtland del 1987 \u00e8 chiara, ma quando pensiamo a sostenibilit\u00e0 pensiamo (giustamente) a CO2, energia, economia circolare. Raramente pensiamo al sapere, ai metodi, alla cultura che lasciamo.<\/p>\n\n\n\n

A cavallo tra l’inverno 2024 e la primavera 2025 ho deciso di prendermi sei mesi per un esperimento. Ho lavorato con quasi 1000 bambini dalla terza elementare alla prima media, non per formare futuri developer, ma per provare a formare future persone raziocinanti. Persone che sappiano ragionare autonomamente, abbiano spirito critico, non abbiano paura di sbagliare, e soprattutto apprendano dai loro errori e da quelli altrui.<\/p>\n\n\n\n

Premetto che non sono un pedagogo e non ho dati quantitativi da sbandierare. Non so quanti diventeranno developer, manager o astronauti, e onestamente non mi interessa. So per\u00f2 cosa ho imparato io, e penso valga la pena condividerlo.<\/p>\n\n\n\n

La Theory of Change<\/h2>\n\n\n\n

Quando racconti di aver passato sei mesi con bambini per un obiettivo che si vedr\u00e0 tra dieci-quindici anni, la prima obiezione \u00e8 sempre: “Ma come fai a sapere se funziona?<\/em>” La risposta breve: non lo so. La risposta lunga passa dalla Theory of Change<\/a>.<\/p>\n\n\n\n

La Theory of Change non \u00e8 una teoria astratta da accademici, \u00e8 un modo di pensare a come avviene il cambiamento nel tempo. L’idea base: parti dal goal a lungo termine che vuoi raggiungere, poi lavori all’indietro per identificare tutte le condizioni che devono essere presenti perch\u00e9 quel goal si realizzi. Non \u00e8 “faccio X e spero in Y<\/em>“, \u00e8 “voglio Y, quindi mi servono le condizioni A, B, C, che a loro volta richiedono le condizioni D, E, F, e allora faccio le attivit\u00e0 X che creano quelle condizioni<\/em>“, per chi ha seguito i miei corsi sugli OKR<\/a> sa bene di cosa parlo.<\/p>\n\n\n\n

Nel mio caso il ragionamento \u00e8 stato questo. <\/p>\n\n\n\n

Goal a lungo termine: tra dieci-quindici anni voglio che almeno alcune di quelle persone siano “raziocinanti”. Cosa significa raziocinanti (almeno per me)? Persone che ragionano autonomamente, hanno spirito critico, non hanno paura di sbagliare, apprendono dai loro errori e da quelli altrui.<\/p>\n\n\n\n

Bene, lavoriamo all’indietro. Perch\u00e9 questo accada, quali condizioni devono essere presenti? Devono aver sperimentato che sbagliare non \u00e8 catastrofico. Devono aver capito che osservare gli errori altrui \u00e8 efficienza. Devono aver avuto feedback immediato sulle loro azioni. Devono aver iterato pi\u00f9 volte sullo stesso problema. Devono aver vissuto un ambiente dove la precisione conta ma l’errore \u00e8 parte del processo.<\/p>\n\n\n\n

E ancora all’indietro: perch\u00e9 queste condizioni si creino, cosa serve? Serve un ambiente sicuro dove sbagliare \u00e8 permesso. Serve che il feedback sia chiaro e non interpretabile. Serve che ci sia tempo per iterare. Serve che vedano altri sbagliare e imparare. Serve che i vincoli siano espliciti e non arbitrari.<\/p>\n\n\n\n

E allora le attivit\u00e0: giochi dove il fallimento \u00e8 parte delle regole, robot che danno feedback inequivocabile, carte condizione che rendono espliciti i vincoli, gruppi dove tutti vedono tutti, cinque tentativi invece di uno solo, capogruppo che ruota per distribuire responsabilit\u00e0.<\/p>\n\n\n\n

La Theory of Change mappa il “missing middle”, quello spazio tra “faccio un gioco con i robot” e “tra quindici anni queste persone penseranno meglio”. \u00c8 onesta nel dire: ecco tutte le cose che devono succedere perch\u00e9 il mio goal si realizzi, e ecco perch\u00e9 penso che queste attivit\u00e0 possano innescare quelle condizioni. Pu\u00f2 non funzionare, certo. Ma almeno so perch\u00e9 sto facendo quello che sto facendo e magari innesco in qualche testa la giusta scintilla.<\/p>\n\n\n\n

Il collegamento con la sostenibilit\u00e0 \u00e8 diretto. La sostenibilit\u00e0 richiede di ragionare su scale temporali lunghe, di accettare che l’impatto di oggi si vedr\u00e0 domani, di investire in condizioni che oggi non danno risultati immediati. La Theory of Change \u00e8 lo strumento per farlo senza andare a caso. Non \u00e8 garanzia di successo, \u00e8 garanzia di consapevolezza<\/strong>.<\/p>\n\n\n\n

Non avevo KPI da dashboard. Non avevo metriche di conversione. Avevo un’ipotesi su come funziona il cambiamento e la voglia di testarla sul campo, sapendo che i risultati veri non li vedr\u00f2 direttamente io. Ma questo non rende l’investimento meno valido, rende solo pi\u00f9 onesta la discussione su cosa significa “impatto”.<\/p>\n\n\n\n

Serious Play, sessant’anni di ricerca<\/h2>\n\n\n\n
\n

\u201cGiocare \u00e8 una cosa seria. \u00c8 il modo migliore per imparare.\u201d ed anche \u201cSe ascolto dimentico, se vedo ricordo, se faccio capisco.\u201d
<\/p>\n\n\n\n

Bruno Munari<\/em> – Laboratorio Giocare con l\u2019Arte<\/p>\n<\/blockquote>\n\n\n\n

So che qualcuno penser\u00e0 “Ah, quindi ti sei creato una scusa per giocare con i bambini per sei mesi”, facciamo un passo indietro ed introduciamo il secondo tassello di questo piano macchiavellico: il serious play, che ha radici profonde e solide.<\/p>\n\n\n\n

Seymour Papert al MIT nel 1967 inventa LOGO, il primo linguaggio di programmazione per bambini. Non per fare di loro dei programmatori, ma perch\u00e9 sosteneva che “non puoi pensare sul pensiero senza pensare a qualcosa di concreto<\/em>“. Il coding era solo un “qualcosa” utile, come potrebbero esserlo gli scacchi o le ricette di cucina. Papert chiamava il suo approccio costruzionismo<\/strong>: impariamo costruendo cose, non ascoltando lezioni.<\/p>\n\n\n\n

Papert era stato allievo di Jean Piaget, lo psicologo che negli anni Sessanta aveva teorizzato il costruttivismo: la conoscenza non si riceve passivamente come un bicchiere che si riempie, ma si costruisce attivamente nella mente attraverso l’esperienza. Sembra una banalit\u00e0 oggi, ma all’epoca era rivoluzionario contro la scuola trasmissiva del “io spiego, tu ascolti, tu ripeti<\/em>“. Piaget diceva: impari facendo esperienza, non ascoltando lezioni.<\/p>\n\n\n\n

Papert va oltre. Non basta l’esperienza, serve costruire oggetti esterni, tangibili, condivisibili. Non solo “learning by doing” ma “learning by making”. Quando costruisci qualcosa di concreto – un programma che disegna, un robot che si muove, una struttura LEGO hai feedback immediato, hai qualcosa da mostrare agli altri, hai qualcosa da iterare. L’oggetto esterno diventa l’ancoraggio per concetti astratti. Il costruzionismo aggiunge il layer della materialit\u00e0 al costruttivismo: le mani aiutano la testa a capire.<\/p>\n\n\n\n

Ancora prima, Maria Montessori nel 1912 scriveva che “il gioco \u00e8 il lavoro del bambino<\/em>“. I bambini apprendono manipolando oggetti, provando, sbagliando. Gli adulti hanno solo dimenticato come farlo, ma il meccanismo funziona ancora benissimo a trenta, quaranta, cinquant’anni.<\/p>\n\n\n\n

Stuart Brown, neuroscienziato, nel 2009 pubblica ricerche che mostrano come il gioco non sia un lusso evolutivo ma una necessit\u00e0 biologica per l’apprendimento. Gli studi sulla retention lo confermano: una lezione frontale ti lascia addosso circa il cinque percento dopo ventiquattr’ore, il learning by doing circa il settantacinque, insegnare ad altri circa il novanta.<\/p>\n\n\n\n

\"il<\/a><\/figure>\n\n\n\n

Negli anni Novanta nasce LEGO Serious Play<\/a> da una collaborazione tra LEGO Group, IMD Business School e MIT. Il principio base: “thinking with your hands<\/em>“: le mani sanno cose che la testa non sa ancora. La NASA lo usa per strategic planning dal 2010. Non \u00e8 “roba” da bambini, \u00e8 “roba” che funziona.<\/p>\n\n\n\n

Il gioco funziona con gli adulti per almeno tre motivi. Primo, bypassa l’ego: quando “giochi” puoi sbagliare senza difendere il tuo status. Secondo, crea psychological safety: puoi fallire perch\u00e9 \u00e8 parte delle regole. Terzo, d\u00e0 feedback immediato: il robot si ferma, il calcolo non torna, il risultato \u00e8 sotto gli occhi di tutti senza possibilit\u00e0 di interpretazione.<\/p>\n\n\n\n

Il “serio” in serious play non \u00e8 il contrario di “divertente”. \u00c8 serio perch\u00e9 ha obiettivi chiari e impatto misurabile. E soprattutto perch\u00e9 quando impari giocando, impari davvero.<\/p>\n\n\n\n

Dal quaderno ai robot <\/h2>\n\n\n\n

Ho usato strumenti diversi per et\u00e0 e concetti, ma con un pattern comune: problema chiaro, vincoli espliciti, feedback immediato, iterazione consentita. Non “coding for kids”, ma problem solving through play.<\/p>\n\n\n\n

Il gioco del quaderno l’ho gi\u00e0 raccontato. Funziona perch\u00e9 non ha barriere tecnologiche e forza il focus sul processo. Ed \u00e8 replicabile con qualsiasi compito procedurale: preparare un t\u00e8, disegnare una casa, spiegare come fare il deploy di un’applicazione.<\/p>\n\n\n\n

Per i bambini di quarta elementare ho creato Games for Bees, un gioco che usa robot programmabili, le BeeBot, piccole api gialle che si muovono su una griglia combinati con carte condizione. Il setup \u00e8 semplice: una griglia quattro per quattro sul pavimento, un robot che si muove di casella in casella, carte direzione (avanti, indietro, gira a destra, gira a sinistra), carte condizione (rock per gli ostacoli da aggirare, “usa meno carte”, “usa pi\u00f9 carte”), carte partenza e arrivo.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Ogni gruppo di quattro-cinque bambini ha un nome e un capogruppo che cambia ogni giorno. Il capogruppo pu\u00f2 parlare solo se tutti sono d’accordo. Hanno cinque tentativi per completare la sfida. Ogni sfida ha un punteggio. \u00c8 pair programming travestito da gioco, \u00e8 code review mascherata da sfida, \u00e8 retrospettiva con le api robot.<\/p>\n\n\n\n

Nel mio caso con i bambini: quando costruiscono una sequenza di carte per la BeeBot, non stanno solo “facendo esperienza di programmazione”. Stanno costruendo un artefatto fisico e condivisibile che possono mostrare, discutere, debuggare insieme. Le carte sul pavimento sono il loro programma, visibile a tutti. Questo \u00e8 costruzionismo.<\/p>\n\n\n\n

I concetti che ho insegnato, senza mai dire “questo \u00e8 un if-then-else” – emergono dai giochi stessi. <\/p>\n\n\n\n

Le condizioni: “Vai a fare la spesa, se al supermercato ci sono almeno due confezioni di uova comprane due, altrimenti non comprare nulla.<\/em>” Mostro tre scenari con le uova disegnate. <\/p>\n\n\n\n