La bozza del curriculum CAPS di Coding e Robotica può sembrare la lista dei desideri di un’azienda tecnologica della Silicon Valley. Sulla carta chiede alle scuole di avvicinare gli alunni ad algoritmi, tecnologie di rete, cittadinanza digitale e sistemi meccanici. A un dirigente scolastico o a un consiglio d’istituto suona come una fattura immediata da centinaia di migliaia di rand fra portatili di fascia alta, kit di robotica proprietari e potenziamenti in fibra.

Ma il documento di policy e la realtà dell’aula sono due cose molto diverse. Tolte le parole d’effetto, i requisiti pedagogici veri del curriculum sono molto adattabili. Non serve comprare troppo. Anzi, le scuole che spendono di più in giocattoli didattici proprietari spesso ottengono il ritorno più basso, perché l’attrezzatura è troppo complessa da integrare in una normale ora da 45 minuti.

Fase per fase

Il curriculum è organizzato in tre fasi distinte, e i requisiti hardware non diventano seri prima della Grade 4. Ecco che cosa serve davvero per raggiungere gli obiettivi di apprendimento:

Nella Foundation Phase (Grade R-3) il curriculum è quasi interamente “unplugged”. Il centro è il pensiero computazionale: insegnare ai bambini a scomporre un problema in passi sequenziali. Lo si può insegnare benissimo con una griglia disegnata sul pavimento dell’aula, dove un alunno fa il “robot” e un altro scrive il “codice” con frecce di carta. Comprare costosi robot da pavimento ricaricabili per la Grade 1 è un lusso, non un requisito del curriculum.

Nella Intermediate Phase (Grade 4-6) gli alunni passano alla programmazione a blocchi su schermo. Lo strumento standard qui è Scratch, del tutto gratuito e dotato di un editor offline. Per la parte di robotica il curriculum introduce i microcontrollori. Una semplice BBC micro:bit costa all’incirca da R500 a R600. Integra sensori di luce, sensori di temperatura e una matrice di LED. Non richiede un telaio complesso né ruote per insegnare i concetti fondamentali di ingressi, processi e uscite.

Nella Senior Phase (Grade 7-9) inizia il passaggio alla programmazione testuale (di norma Python) e all’elettronica di base. Qui gli alunni devono capire come interagiscono componenti quali resistori, diodi a emissione luminosa (LED) e sensori a ultrasuoni. Anche in questo caso ci si arriva con kit di elettronica di base, invece che con telai robotici proprietari e preassemblati da migliaia di rand.

La trappola dell’acquisto eccessivo

L’errore più grosso delle scuole sudafricane è comprare kit di robotica a ecosistema chiuso. Questi kit, che spesso costano fra R8.000 e R15.000 a scatola, sono pensati per squadre di gara extracurricolari, non per classi da 40 alunni.

“Quando una scuola compra hardware proprietario non compra solo la plastica: entra in un ecosistema di licenze che spesso richiede internet ad alta velocità, ricambi costosi e software proprietario che sui portatili scolastici più vecchi non gira.”

Se si rompe un singolo sensore proprietario, sostituirlo può costare centinaia di rand e richiedere settimane di spedizione. Se invece si usa hardware open source, un sensore di ricambio costa meno di un caffè e si trova sul mercato locale. In più, le piattaforme open source garantiscono che le competenze acquisite dagli alunni siano trasferibili all’ingegneria del mondo reale, invece di restare legate all’interfaccia di un unico marchio di giocattoli.

La realtà: 40 alunni, 1 portatile

Come si fa con una classe numerosa e un solo carrello di portatili? La risposta sta nella rotazione e nella programmazione in coppia.

Non serve un rapporto di 1:1 fra dispositivi e alunni. Nell’industria del software il “pair programming” (due sviluppatori che condividono uno schermo) è una pratica standard che migliora la qualità del codice e la collaborazione. In una classe di 40, 20 dispositivi sono il limite gestibile da un solo insegnante. Se ne avete meno, dovete strutturare le lezioni intorno a postazioni a rotazione: il gruppo A lavora su rompicapi algoritmici unplugged, il gruppo B lavora sui portatili scrivendo codice e il gruppo C lavora al montaggio fisico dei circuiti.

In Sheen Robotics progettiamo i nostri servizi di implementazione per le scuole per aiutare gli istituti a mappare l’infrastruttura esistente sui requisiti CAPS, così che nessuna scuola compri hardware che non potrà realisticamente usare nella disposizione di un’aula normale.

Il filtro infrastrutturale: load-shedding e WiFi

Qualsiasi piano curricolare che dipenda da una connessione internet costante e veloce fallirà nella scuola sudafricana media. Le reti WiFi scolastiche, in particolare quelle che usano protocolli di sicurezza WPA2-Enterprise, bloccano di frequente le porte che servono ai microcontrollori didattici per caricare il codice dagli editor web.

Per costruire un programma di coding resiliente, i vostri strumenti devono soddisfare tre criteri:

• Funzionamento offline: software come Scratch Desktop e gli IDE Python offline (come Thonny) vanno installati localmente sulle macchine.
• Consumi ridotti: microcontrollori come la micro:bit si alimentano direttamente dalla porta USB di un portatile o con un semplice pacco di pile AA. Non hanno bisogno della rete elettrica per funzionare.
• Portatili con batteria: se il vostro laboratorio si regge interamente su PC desktop, un solo blocco di load-shedding cancella il tempo di lezione. I carrelli di portatili, che si ricaricano durante l’orario scolastico e vanno a batteria durante i blackout, sono l’unica opzione affidabile.

Il curriculum CAPS di coding e robotica è del tutto realizzabile se si ignora il rumore di fondo del marketing. Partite dal pensiero computazionale unplugged, salite al software offline gratuito e usate hardware open source a basso costo quando passate al physical computing. Il vostro bilancio, e i vostri insegnanti, vi ringrazieranno.