Riprendendo uno degli argomenti del post precedente (quello “della ruspa”, per intenderci …), penso che un settore in cui l’approccio agile, inteso in un senso molto lato, possa dare un grosso contributo è quello della formazione.
Secondo quanto ho vissuto come studente prima e docente poi, i contenuti dei corsi sono sempre presentati in modo sequenziale, affrontando separatamente i vari argomenti, ognuno al livello di approfondimento richiesto dal corso.
Questo approccio non favorisce i collegamenti tra un argomento e l’altro, perché potrò collegare il primo e l’ultimo argomento solo a fine corso; i collegamenti, a mio avviso, non sono qualcosa di secondario ed è solo attraverso di essi che è possibile capire a fondo anche le entità oggetto del collegamento. Mi sembra uno dei soliti errori in cui la nostra forma mentale ci fa cadere: tendiamo a vedere qualsiasi sistema come indipendente da altri sistemi (nel senso di definito in sé), seppur ad essi relazionato. Secondo la mia esperienza sono invece portato a dire che ogni sistema è quello che è soprattutto per le relazioni che ha (potrei dire: “dimmi che relazioni hai e ti dirò chi sei”); perché allora cercare di capirlo senza curarsi di queste relazioni? E’ un po’ come esplorare una mappa osservandone vari punti al livello di dettaglio massimo senza mai allontanare la visuale; sfido a capirci qualcosa.
Un approccio agile invece, che affronti i vari argomenti in modo iterativo, consente di delineare in modo più preciso, iterazione dopo iterazione, le varie entità e le loro relazioni (se volete pensate ai nodi e agli archi di una rete). E’ come esplorare una mappa partendo dalla vista di alto livello e scendendo man mano ad un livello di dettaglio maggiore.
Leggendo il libro di Larman (Applying UML and Design Pattern) ho constatato con piacere che i capitoli centrali sono proprio approntati secondo questo approccio, approfondendo in modo iterativo i contenuti.
Io stesso, come docente, ho sperimentato la bontà dell’approccio: dopo aver tenuto corsi di Access che seguivano il percorso classico (struttura db in profondità prima, creazione interfaccia dopo), ho visto che sfruttando tre iterazioni (una prima passata introduttiva molto veloce, una seconda passata in cui vedere solo le relazioni uno-molti e giocare un po’ con l’interfaccia, e poi una terza passata in cui approfondire le temutissime relazioni molti-molti e il loro impatto sulla progettazione dell’interfaccia), i discenti hanno faticato molto meno ad assimilare i contenuti ed il corso è risultato più “divertente”.
Ciao a tutti e, per chi ci sarà, a domani (forza janky!).