Insegnare Agile

Università di Modena e Reggio Emilia Università di Bologna
Una didattica Agile
per la programmazione
Didamatica 2016 – Università di Udine
20.04.2016
Marcello Missiroli
marcello.missiroli@unimore.it
Daniel Russo
daniel.russo@unibo.it
Paolo Ciancarini
paolo.ciancarini@unibo.it

Programmare
●
È difficile!
●
È una “conoscenza tacita” acquisita nel
tempo, con pratica e non (solo) con lo studio
sui libri
●
Insegnare a programmare lo è ancora di più

Segnali positivi
Modalità “morbide”
per iniziare
I “Social”
Nuovi tools Stereotipi sdoganati

Tuttavia...
●
Tendiamo a insegnare in modo molto
tradizionale
●
Lezione frontale, esercizi artificiosi, studio a
casa da soli, verifica individuale
●
Realizzazione di progetti a lungo respiro rara
(una volta l'anno?)

Enter Agile

Manifesto Agile
Stiamo scoprendo modi migliori di creare software,sviluppandolo e
aiutando gli altri a fare lo stesso.Grazie a questa attività siamo arrivati a
considerare importanti:
●
Gli individui e le interazioni più che i processi e gli
strumenti
●
Il software funzionante più che la documentazione
esaustiva
●
La collaborazione col cliente più che la negoziazione
dei contratti
●
Rispondere al cambiamento più che seguire un piano
Ovvero, fermo restando il valore delle voci a destra,consideriamo più
importanti le voci a sinistra. interesse e successo nel mondo del lavoro

Manifesto Agile (in pratica)
●
Team autonomi e auto-organizzati
●
I clicli di sviluppo frequenti e rapidi
●
Proprietà condivisa del codice
●
Frequenti contatti con il cliente
●
Favorire la comunicazione interna ed esterna
●
Adattabilità ai cambiamenti
●
Gestione del fattore tempo
●
Accento sulla testabilità e flessibilità del codice

Movimento Agile
●
Grande interesse e successo nel mondo del
lavoro
●
Affinità con le moderne teorie didattiche
(cooperazione, collaborazione, auto-
organizzazione, comunicazione)
●
In Italia, poco diffuso e/o sconosciuto e/o
misconosciuto

Idee di fondo
●
Sperimentare le modalità di lavoro agile nella
scuola
●
Esporre i ragazzi a una nuova metodologia di
lavoro (vantaggio competitivo nel mondo del
lavoro)
●
Verificarne l'impatto in modo scientifico e
replicabile

Limitazioni
●
Rigidità della scuola: il “programma” è un
totem intoccabile.
●
Necessaria cooperazione dei colleghi

Limitazioni
●
Rigidità della scuola: il “programma” è un
totem intoccabile.
●
Necessaria cooperazione dei colleghi
●
Esperimento di breve durata
●
Contributo concreto di conoscenze agli
studenti → “Experiential Learning”

Il primo esperimento
●
Misura l'efficacia di alcune pratiche agili.
●
Target: studenti di 4° e 5°, ITIS, ITC, LSSA
●
Durata: 3 o 6 ore
●
Periodo: Dicembre 2014 – Maggio 2015
●
Ragazzi coinvolti: 84 (su 4 classi)

Pratica 1: Pair Programming
●
Programmazione in coppia
●
Alternanza stretta , scandita
temporalmente

Pratica 1: Pair Programming
●
Coppie di 6 tipologie di
studenti (omogenee ed
eterogenee)
●
Gruppo di controllo
●
Valutazione predittiva
basata sul voto corrente

Pratica 2: Timeboxing
●
Gli orari di consegna sono
definitivi e immutabili
●
Piuttosto, sacrificare altri
aspetti
●
Nessuna eccezione

Pratica 3: Test-Driven Development
●
Prima scrivere il test, poi il
codice
●
Quindi, rifattorizzare.
●
Richiede l'uso di test
automatici (JUnit o simile)

Pratica 4: User stories
●
Requisti in formato compatto
●
Descrittive, non ultimative
●
Condizioni di verifica
“oggettive”
●
Da sviluppare una per volta

I dati raccolti
●
Numero di feature o test
realizzati
●
Analisi statica del codice,
confrontata con codice
preesistente
●
Feedback studenti
●
Intervista docenti coinvolti
●
Survey territoriale

Gruppo Blu
(M-M)
Magenta
(M-S)
Ciano
(B-M)
Verde
(B-B)
Giallo
(B-S)
Rosso
(S-S)
Solo
Media 4
(-2)
5
(-0,5)
8,14
(+1,64)
7,5
(0,5)
7,4
(+1,4)
5
(+0)
5,7
(-0,5)
Varianza 3,5 5,5 2,48 4,3 0,8 4,5 6,8
Prestazioni

Analisi statica del codice
Test breve Test lungo
Complessità ciclomatica Forte peggioramento Lieve peggioramento
Quantità codice prodotto Lieve miglioramento Miglioramento
Linee di commento (1) Forte miglioramento Uguale
Linee duplicate Uguale Miglioramento
Problemi (issues) Pair: miglioramento
Solo: peggioramento
Pair: miglioramento
Solo: peggioramento
SQALE (2) Peggioramento Peggioramento
(1) Le righe di commento sono comunque molto poche
(2) I solo programmers hanno ottenuto risultati lievemente migliori

Gradimento (studenti)
Pair Solo
Pair Programming Esperienza positiva(++)
Imparato qualcosa(++)
Codice peggiore(-)
Meno codice (-)
Esperienza positiva(=)
Imparato qualcosa(=)
Codice peggiore(-)
Meno codice(=)
Test-First Development Codice più corretto(+), Aderenza alle specifiche(+)
Sviluppo più rapido (=), Trovare errori (=), Lo userò in
futuro(=)
User Stories &
Timeboxing
Utilità condizioni di accettazione(-), Valido strumento di
progettazione(-) Fonte di stress(+)
(+) D'accordo, (++) Forte accordo, (-) Disaccordo (–), Forte disaccordo (=) Indeciso

Interviste docenti
●
Test 2 considerato utile, Test 1 meno
●
Pair programming utile, facile da applicare
●
Effetti positivi sulla motivazione, e
sull'insegnamento in generale e perfino sui
voti
●
TFD peggiora le prestazioni
●
Indecisi su Timeboxing e User Stories
●
Sanno poco di Agile, frequenterebbero
anche corsi sull'argomento

Esperimento confermativo
●
Limitato al Test 1 (TFD, 4°)
●
Altri studenti ed altre scuole
●
Senza gruppo di controllo
●
Lievi modifiche ai test
●
In corso (finirà a Maggio)
●
I primi risultati in effetti, confermano i dati

Conclusioni
Consigliamo una introduzione, anche
graduale, di alcune pratiche tipiche dello
sviluppo agile. Il Pair programming, in
particolare, ma in misura minore anche le
User Stories.
La TFD ha una implementazione più
complessa, e richiede ulteriore preparazione
e studio

Secondo esperimento
●
Esperimento sulla efficacia didattica della
metodologia progettuale Agile rispetto alla
tradizionale (Scrum vs. Waterfall)
●
Ricalca il test lungo, ma senza limitazioni
metodologiche
●
Una dozzina di scuole coinvolte – tuttora in
corso.

Ricerche future
Effetti della cooperazione e della
competizione nella didattica dell'informatica
●
Olimpiadi dell'informatica
●
Olimpiadi a squadre
●
Olimpiadi problem solving

GRAZIE
DELL'ATTENZIONE

Paolo Ciancarini
Professore Ordinario
DISI - Università di
Bologna
paolo.ciancarini@unibo.it
Daniel Russo
Dottorando in CS&E
DISI - Università di
Bologna
daniel.russo@unibo.it
Marcello Missiroli
Dottorando in ICT
DIEF - Università di
Modena e Reggio Emilia
marcello.missiroli@unim
ore.it
Slide design base by Saqib Javed John

Links
●
Manifesto Agile
●
I dodici principi Agili
●
Dati e sorgenti dell'esperimento
●
ICSE 2016

Insegnare Agile

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Insegnare Agile

Similar a Insegnare Agile (20)

Más de Marcello Missiroli

Más de Marcello Missiroli (12)

Insegnare Agile