Tag: Education

Agile@School 2022 – Final Boss!

di Pier-Paolo Mammi.

I ragazzi dell’Agile@School giungono finalmente allo scontro finale con l’ultimo boss del gioco: la temibile presentazione! Avranno acquisito sufficiente esperienza per uscire indenni o quasi dalla sfida? Scopriamolo insieme.

La sfida

L’obiettivo finale del corso si basava su due cose:

  • una presentazione del progetto che ne descrivesse la realizzazione e i punti di forza per un ipotetico investitore
  • il videogioco vero e proprio, eseguibile e testabile da noi

Il tutto seguendo il più possibile la filosofia DevOps illustrata negli incontri fatti a scuola e utilizzando gli strumenti aziendali di uso comune, quali Azure DevOps e Git.

Ready? Fight!

Anche quest’anno, sia per avere un’opinione “esterna” rispetto a noi che abbiamo seguito i ragazzi, sia per portare prova tangibile della bontà del formato, ci ha accompagnato Alex che ha partecipato qualche anno fa all’Agile@School e che da un paio di anni lavora brillantemente in azienda con noi! Riporteremo le sue osservazioni per avere un altro punto di vista più oggettivo.

Tutti Unity – Ein

I ragazzi del team Tutti Unity hanno realizzato un solo livello del gioco, in cui Ein, il protagonista (che, ricordiamo, è l’ultimo dei cloni di Hitler creati a seguito di un esperimento e scampato al loro sterminio) deve fuggire dal laboratorio in cui si risveglia privo della memoria. Plot twist inaspettato, Ein è in realtà una ragazza! 😀

Il gioco è stato sviluppato pregevolmente con grafica in pixel-art e tutti gli aspetti grafici sono stati realizzato da zero. Non c’è stato molto tempo di introdurre interattività con l’ambiente o con altri personaggi, ma nel complesso è risultato molto apprezzabile e interessante.

Anche la presentazione è stata fatta con cura e ha illustrato i possibili sviluppi futuri del gioco, ipotizzando un rilascio a episodi.

Alex: trama veramente interessante e particolare, grafica top (apprezzabile lo stile retrò), meccaniche un po’ trascurate con risultato di un gioco che finisce subito senza fare particolari azioni.

AppeninTech – The IRA Tale

Il gioco segue le vicende di un giornalista ai tempi dell’IRA: l’impostazione è quella più classica di un libro-game, ma arricchita di alcune funzionalità che lo rendono più dinamico, come un “allineamento” fra governo e terroristi che incide sulle probabilità di sopravvivenza del protagonista e un sistema di avvenimenti casuali.

Questo progetto è risultato il più “tecnico” in quanto il codice realizzato si presta particolarmente ad essere convertito in una sorta di framework riutilizzabile.

Da evidenziare la presentazione, in quanto aveva una forte impronta volta al marketing: abbiamo poi scoperto che il ragazzo che ha contribuito alla realizzazione ha aspirazioni di social media marketing!

Alex: presentazione professionale che punta ad eventuali investitori, mostrando una roadmap dettagliata sul progetto. Molto strutturato a livello di storyline, meccaniche semplici, ma efficaci per la storia che seguono. Questo è un classico esempio dove si ha una parte backend molto elaborata a scapito della parte frontend, che risulta quindi un po’ spoglia.

Anonymous – Skyrish Adventure

Il gruppo degli Anonymous, a dispetto di aver meno competenze tecniche rispetto agli altri, è riuscito a realizzare un gioco che forse è il più in linea con la richiesta iniziale di creare un libro-game. Nonostante l’impostazione più “grafica” (invece di pagine testuali, hanno utilizzato pagine web graficamente ricche), il risultato è stato un divertente viaggio fantasy tra omaggi più o meno velati ai vari videogame del genere.

È evidente quanto i ragazzi si siano divertiti nella creazione del gioco, questa è sicuramente una componente importante nella buona riuscita di un progetto!

Alex: trama interessante (cavaliere che deve sconfiggere un boss finale), carente un po’ di animazioni dovuto a qualche intoppo, ma in generale storia corposa e ben strutturata.

What-A-Kingdom

Questo è probabilmente il progetto che ha puntato più in alto di tutti in quanto i ragazzi hanno voluto realizzare il gioco (non più un libro-game, ma un vero e proprio gestionale di un regno) utilizzando il motore Unreal Engine 5, nonostante fossero molto più ferrati con Unity. I WAK sono forse il gruppo che ha maggiormente provato sulla pelle gli effetti di una scelta tecnologica coraggiosa, in quanto non solo hanno dovuto imparare un framework per loro nuovo, ma hanno anche utilizzato una versione cutting-edge, uscita dalla beta proprio mentre creavano il gioco, e quindi più soggetta a instabilità. Come conseguenza, il gioco è sicuramente risaltato fra gli altri dal punto di vista grafico, ma i ragazzi hanno dovuto tagliare gran parte dei personaggi inizialmente pianificati per poter rispettare le scadenze.

Alex: progetto ambizioso dal punto di vista delle tecnologie utilizzate (unreal engine 5). Presentazione efficace e risultato grafico degno di nota.

Conclusioni

La nostra prima considerazione emersa dopo aver visto i progetti presentati dai ragazzi è che ogni anno il livello tecnico si alza un po’ di più. Anche nelle edizioni passate ne abbiamo viste delle belle, ma quest’anno siamo rimasti particolarmente soddisfatti sia delle presentazioni che dei giochi.

Tutti i progetti erano testabili e funzionanti, nonché divertenti da giocare. Chiaramente ci sono degli spigoli da smussare, dovuti a mio avviso più che altro all’entusiasmo e alla troppa voglia di fare dei ragazzi, che in alcuni casi li ha portati a sottostimare l’entità di quello che avrebbero voluto introdurre, ma sono errori (mai come in questo caso) di gioventù!

Penso che l’obiettivo dell’Agile@School sia stato raggiunto pienamente. La realizzazione del progetto è un mezzo per dimostrare ai ragazzi cosa voglia dire lavorare in azienda, e ancora di più farlo utilizzando metodologie agili unite alla filosofia DevOps, ma soprattutto per far sperimentare loro le difficoltà tipiche che ci si trova ad affrontare, spesso in modo inaspettato, sul mondo del lavoro.

In definitiva, complimenti davvero a tutta la classe!

Agile@School 2022 – Episodio 2

Articolo di Pier-Paolo Mammi, il docente che da anni segue le lezioni con i ragazzi.

Finiva due settimane fa il secondo sprint del progetto che coinvolge la classe 4a dell’IISS Gadda. Mi ritrovo a scrivere il post con colpevole ritardo, anche se in realtà un (buon) motivo c’è e ne parlerò in seguito.

I progressi

Vediamo innanzitutto i progressi dei ragazzi. Premettiamo subito che per alcuni team all’inizio dello sprint è ancora risultato difficile entrare nell’ottica di integrare le fasi dello sviluppo con il tracciamento delle proprie attività su Azure DevOps. Insistendo però sui concetti e grazie al supporto del professore siamo riusciti a recuperare la situazione e alla fine tutte le board erano correttamente popolate.

Contemporaneamente, in queste tre settimane abbiamo affrontato svariati argomenti che, pur non influendo direttamente sul mero sviluppo, dovrebbero comunque essere apprese per poter essere efficaci in un contesto aziendale.

Dato che i ragazzi avevano già utilizzato le funzioni basilari di Git, ci siamo quindi concentrati sugli aspetti più avanzati, come il branching e i “flow“, evidenziando in particolar modo come (e perché) noi stessi lo utilizziamo in azienda.

Un altro argomento “scottante” è stato quello dello unit testing, che abbiamo dovuto approfondire in una giornata aggiuntiva, anche qui portando esempi concreti.

Le domande

Al di là di tutto questo, devo ammettere di essere rimasto molto colpito dalla curiosità dei ragazzi nei confronti della “vita da ufficio”. Alcuni di loro hanno infatti posto domande che non mi sarei aspettato, per esempio: “cosa succede se non riesco a rispettare le scadenze del progetto?” oppure: “se sono rimasto indietro con gli sviluppi, è permesso portarsi a casa il lavoro per continuarlo?”, o ancora: “come faccio a capire a chi devo scrivere, se ho bisogno di chiedere qualcosa su quello che sto facendo?”. Le prime domande scaturiscono evidentemente dall’ambiente scolastico, che prevede scadenze ben definite (beh, dovrebbe essere così anche sul lavoro 😅) e che “non ha orari” visto che i ragazzi devono studiare in continuazione! Ma l’ultima di queste domande ha attirato la mia attenzione, perché il problema è reale e si presenta in molti ambienti lavorativi. Questa è stata una buona occasione per parlare nuovamente di come affrontiamo concretamente certe questioni applicando la filosofia DevOps.

Il cerchio che si chiude

Nel terzo e ultimo sprint abbiamo deciso di saltare un paio di lezioni per lasciare un po’ di respiro ai ragazzi: in queste settimane saranno infatti messi a dura prova perché non solo avranno diversi esami e dovranno studiare parecchio, ma soprattutto li aspetta anche il periodo di alternanza scuola-lavoro in cui potranno mettere a frutto quanto imparato finora.

E qui arriva il motivo del ritardo nel post: due dei ragazzi della classe verranno infatti a svolgere l’alternanza proprio nella nostra azienda! Volevo quindi verificare come si sarebbero integrati da noi e devo dire che finora si sono comportati molto bene, anche se per ora ammettono di preferire andare a scuola invece che in ufficio 😄

Chiudiamo con un’altra bella notizia dell’ultimo minuto: la scorsa settimana abbiamo assunto ufficialmente una ragazza della classe che aveva partecipato all’Agile@School 2020, che nel frattempo si è diplomata. Una bella soddisfazione per tutti e un’ulteriore conferma della bontà del format!

Ci risentiamo presto per il post di chiusura del progetto, dopo la giornata finale in cui i ragazzi ci presenteranno i propri risultati.

Agile@School 2021 – La serie completa

Per chi volesse dare una letta alla stagione 2021 di Agile@School qui sotto le puntate. Ogni episodio è dedicato a un personaggio o a un gioco, proprio per la natura del progetto:

Agile@School – Giornata conclusiva

Ultimo appuntamento di Agile@School 2021. Per questa occasione ci racconta l’incontro Alex, una new entry che qualche anno fa prese parte a questa iniziativa proprio come i ragazzi. Siamo finalmente arrivati all’appuntamento che pone sotto i riflettori l’impegno e la dedizione dei ragazzi ovvero i progetti ultimati.

L’idea di fondo proposta era quella di avere una presentazione composta da una panoramica del progetto a 360 gradi partendo quindi dalla descrizione di quest’ultimo per poi procedere con pregi, difetti, punti di forza, difficoltà incontrate e motivi accattivanti per spronare un possibile giocatore ad acquistare il prodotto per poi concludere con la presa visione del progetto e la conseguente prova dello stesso da parte di noi supervisori momentaneamente nei panni di “gamer”.

Presentazione dei progetti

Una volta superata la tensione generale il Team Cromosomi# ha preso l’iniziativa e, anche se non al completo causa assenze, è riuscito a presentare un progetto interessante caratterizzato da un gameplay che assume dinamicità grazie anche al cambio di musica in base alle scelte fatte dal giocatore.
Il gioco è stato presentato su console application e salvo qualche inserimento di dato non previsto non presentava problemi che ostacolassero la giocabilità. Un paio di consigli proposti per migliorare il tutto sono stati l’inserimento di un valore per indicare la vita del giocatore e l’inserimento di immagini che seguono il cambiamento musicale per incrementare il coinvolgimento in game.

A seguire ha preso parola il Team Fisher, team in questo caso al completo.
Presentazione ben organizzata che ha principalmente fatto focus sulle molte tecnologie utilizzate caratterizzata anche da un video realizzato su misura per l’occasione. Ben strutturata anche la storia narrativa che sta dietro al progetto. In questo caso il gioco è stato lanciato direttamente con il proprio eseguibile ed è stato provato dal sottoscritto, che non ha perso tempo per una citazione di alto calibro (infatti ho inserito subito come nome del protagonista della mia partita Rohan Kishibe… ed ho detto tutto). Gameplay con una profonda trama che fa quasi pensare ad un libro-game e che da luogo a una moltitudine di finali raggiungibili variando le scelte del nostro personaggio giocando più volte. Un problema relativo al cambio di musica durante il gioco non ha comunque influito sulla giocabilità in generale.

È stato poi il momento del Team MonkeTeck anche loro al completo.
Idea molto promettente per il progetto di questo team che grazie alla loro presentazione molto ben organizzata hanno centrato l’obbiettivo di dare informazioni che spieghino il processo creativo ma allo stesso tempo attirino il giocatore spiegando il Perché e il Come ponendo anche l’attenzione sul fattore curiosità. Gameplay che si distingue come tema dagli altri avendo come protagonista una nave a scelta che può compiere diverse azioni che possono portare anche alla distruzione della stessa se si azzerano i punti salute. Nota di merito va proprio a quest’ultimo punto, ovvero la vita o salute che finalmente vediamo implementata in uno dei progetti, l’unico fino ad ora. Molto accattivante anche la differenziazione delle statistiche in base alla nave scelta. In questo caso i consigli dati per possibili feature sono stati l’inserimento di immagini o suoni che rendano più coinvolgente la battaglia tra due navi.

Ultimo ma non per importanza è il Team GentsAndLady.py purtroppo in carenza di componenti ma carico abbastanza da sopperire alla mancanza. Presentazione abbastanza esaustiva, anche nel loro caso sarebbe stato ottimo avere una parte dedicata al Perché del gioco ma hanno compensato questa mancanza parlandone direttamente a voce, almeno per far capire a noi l’intenzione che c’era dietro. Anche in questo caso troviamo un gioco in console application preso di mira stavolta da Pier-Paolo, ormai diventato game-tester della giornata che non si è fatto sfuggire l’occasione di mettere qualche dato per far “scoppiare” tutto. Tralasciando piccoli problemi non gestiti nel complesso il gioco segue quanto promesso, quindi la storia di Napoleone in parte romanzata ma che segue un filo logico che permette lo studio giocando più volte.

Fine della corsa

Arrivati a questo punto devo ammettere che siamo stati molto sorpresi e soddisfatti dei ragazzi in quanto nonostante difficoltà, membri mancanti e tester improvvisati rompi scatole sono tutti riusciti a portare a termine un prodotto che, anche se imperfetto, risulta comunque completo.
Anche personalmente sono rimasto particolarmente stupito nel vedere i lavori realizzati dai ragazzi in quanto anche io, giusto qualche anno fa, ero al loro posto e, come loro, avevo realizzato il mio personale progetto con Engage. La differenza che ho notato maggiormente è stata la dedizione riposta in questi lavori. Quando frequentavo la scuola, non c’era questo livello nei progetti ed erano quasi tutti realizzati giusto perché “andavano fatti”. Nel mio caso il gruppo di lavoro era costituito da me :-). La voglia di fare che avevo non era particolarmente condivisa, di conseguenza, seppure non sia stato un progetto rivoluzionario, la mia “chat bella che funzionante tra smartphone e pc” l’avevo portata a termine (soddisfazione alle stelle).
Sono convinto che avvicinandosi sempre di più alle loro passioni si avrà un consenso sempre maggiore a questa iniziativa e una conseguente qualità dei progetti in continuo aumento.

Spero vivamente di poter partecipare nuovamente in futuro proprio per assistere di persona a questa evoluzione e per inserire qua e là qualche citazione di alta classe… Yare yare daze.

Agile@School – Anno sesto, terzo incontro

Arriviamo oggi al terzo appuntamento di Agile@School 2021. Pier-Paolo ci racconta l’attività dal punto di vista della programmazione.

Negli incontri precedenti abbiamo cominciato a tracciare la strada delle attività (come vedremo, non tutte strettamente legate alla programmazione vera e propria) che i ragazzi dovranno svolgere per arrivare al loro obiettivo, cioè rilasciare un videogioco in stile libro-game.

Lungo questo percorso vogliamo insegnare loro non solo gli aspetti “tecnici” di realizzazione di un software, ma anche quello che sta “al contorno” di un progetto di questo genere: parliamo ovviamente dell’approccio Agile – DevOps, quindi tutta una serie di pratiche e cerimonie volte a facilitare la collaborazione, la condivisione delle conoscenze e la gestione dei progetti. È risultato evidente come sia già consolidato l’utilizzo degli stand-up meeting all’inizio di ogni lezione, tant’è che oggi sono stati i ragazzi stessi a proporsi per un veloce aggiornamento sullo stato dei progetti, dal quale sono emersi spunti molto interessanti legati agli aspetti di software selection di cui si era parlato nel post precedente.

Infatti, due dei gruppi che avevano scelto di utilizzare Unreal Engine per la realizzazione del loro progetto si sono resi conto che non avrebbero fatto in tempo a produrre qualcosa di funzionante entro la fine degli sprint: questo non li ha però scoraggiati e, messe da parte le loro preferenze personali, hanno avuto un buon senso di responsabilità nel decidere di intraprendere una strada di sviluppo differente, pur mantenendo intatta la trama principale scelta inizialmente.

Il Team Fisher ha quindi deciso di realizzare il videogioco tramite una web application, fruibile quindi da browser, con l’intenzione di integrare nel gioco dei file multimediali precostruiti. Il Team GentsAndLady-py ha invece deciso di implementare una console application in Java; anche loro hanno dichiarato di voler utilizzare grafica e audio per aumentare il coinvolgimento all’interno del gioco.

In entrambi i casi, tale decisione è stata presa non tanto in base alla difficoltà della creazione del software tramite lo stack tecnologico scelto, quanto alla valutazione delle tempistiche di rilascio del software stesso. Questa a mio avviso è stata una scelta molto oculata, soprattutto se considerata in un contesto aziendale in cui i tempi sono fondamentali forse più che la tecnologia scelta.

Dopo una rapida revisione delle board di ogni team è seguita una parte di suggerimenti e correzioni delle user story inserite dai ragazzi: la scrittura di questi item talvolta non è facile neanche per chi segue le pratiche Agile da molto tempo, per cui era facile aspettarsi qualche sbavatura. Ci aspettiamo che per la prossima lezione le user story vengano migliorate, e soprattutto che vengano utilizzati in maniera più intensiva i task per la suddivisione delle attività.

A questo proposito, una nota positiva viene dal Team Fisher che ha chiesto se fosse corretta la suddivisione delle attività da loro individuate fra più persone in parallelo e l’affiancamento di due persone su una stessa attività di programmazione: non solo questo è corretto, ma è proprio quello che si auspica con l’adozione delle pratiche Agile! E pur non sapendolo (non ne avevamo ancora parlato), ne hanno messo in evidenza uno degli aspetti chiave, cioè il pair programming. Molto bene!

Il resto della lezione è proseguito con l’introduzione del software per il controllo del codice sorgente Git, che però temo non abbia avuto l’impatto sperato. Purtroppo, non siamo stati in grado di effettuare degli esercizi live, un po’ perché non è stato possibile installare il software sulle postazioni usate dai ragazzi, un po’ per problemi logistici (noi e i ragazzi siamo lontani “fisicamente”, chi in classe, chi da casa, e la connessione instabile non permetteva una condivisione dello schermo). Abbiamo comunque chiesto a ciascuna squadra di creare un repository su GitHub, sia per poterlo connettere successivamente ad Azure DevOps e dimostrare come si possano collegare i task alle modifiche del codice, sia per iniziare a caricare i file del proprio progetto.

See the source image

Con questo appuntamento si concludeva in teoria il primo sprint, ma fra cambi di tecnologia e necessità di adattamento all’Agile i ragazzi non sono ancora riusciti produrre nulla di significativo, ma non disperiamo, c’è tutto il secondo sprint!

Agile@School – Anno sesto, i progetti

In questo secondo episodio, relativo all’incontro di ieri mattina di tre ore di sessione, ho assistito alla panoramica di ogni progetto. Ricordiamo i team che partecipano:

  • Fisher
  • Cromosomi#
  • GentsAndLady.py
  • MonkeTeck

Ogni team ha avuto la sua idea e ognuno di essi ha dovuto sottostare a tre vincoli: Il progetto deve essere una storia con decisioni e conseguenze (massimo tre), deve avere a che fare con almeno una materia e deve esistere già una tecnologia scelta. Quest’ultimo punto è stato il requisito della giornata di ieri. Ma vediamo come si sono mossi i ragazzi.

Team Fisher

Il team è composto da persone che sembrano essere interessate tantissimo allo sviluppo software, tanto da arrivare a parlare di tecnologie come Unreal Engine e Unity. Questo è il loro pregio e, allo stesso tempo, il loro più grosso problema. Il tempo è poco, e approfondire così tanto da implementare un gioco graficamente pronto è decisamente una missione impegnativa. Ma perché bloccarli? Del resto, non sono sempre stato alla ricerca di un progetto complesso anche io durante il periodo della scuola? L’unico consiglio che ho cercato di dargli è quello di focalizzarsi sull’idea che “Fatto è meglio che perfetto” (Done is better than perfect) e che un prodotto non completo ma “bello da vedere” a volte è meno efficace di uno più semplice, ma terminato e con una storia avvincente.

Fare tante skin di un gioco sempre uguale (e non metto titoli altrimenti rischio di essere insultato) non è sicuramente il modo giusto di avere un prodotto autentico, al contrario di quello che fanno alcuni titoli indipendenti che sono fenomenali in ogni loro parte.

Mia citazione 🙂
Un esempio di titolo dalla storia di spessore con grafica a bassa definizione

I ragazzi hanno le idee chiare e il livello di dettaglio è ampio, spero sinceramente in un grande risultato. E mi aspetto molto da loro, vedremo se non tradiranno le aspettative.

L’idea

L’idea alla base del gioco è quella dietro al “delitto” in un edificio. Si ambienta nella scuola e la modalità con cui si è svolto l’omicidio al centro della storia è basata sulla chimica, la materia inclusa nel progetto.

Team Cromosomi#

Senza saperlo, questo team affronterà una storia molto simile a quella del team Fisher. I ragazzi hanno provato a giustificarsi perché, in effetti, potrebbe sembrare una copia dell’altro progetto, ma li ho subito tranquillizzati e ho provato a far capire loro che è normale avere un competitor sullo stesso business. La loro missione (e anche quella dei Fisher) sarà quella di cercare di creare un prodotto autentico, alla Cluedo, con una sana competizione di mercato. Chissà chi riuscirà a convincermi di più.

See the source image
Cluedo, il gioco in scatola

L’idea

Nel progetto, tuttavia, vi sono delle sostanziali differenze. Innanzitutto i ragazzi di questo team hanno pensato alla censura, proponendo due soluzioni, una per i maggiori di 15 anni e uno per i minori di tale età. Il contenuto si adatterà a scenari meno violenti per essere esteso a più realtà, non male come idea. Poi, ogni stanza verrà trattata con una materia differente, il che rende il progetto interessante anche a livello multi disciplinare. Avremo una stanza di storia, una di inglese, e via discorrendo, con vari quesiti ed enigmi su cui si baseranno la decisione.

Il consiglio che ho dato loro è di cercare di avere quanto prima le idee più chiare di ora, perché sembra esserci tanta carne al fuoco ma non una vera e propria idea definitiva.

Team GentsAndLady.py

I ragazzi in questo caso hanno deciso di affrontare la storia di una vita estremamente popolare: quella di Napoleone Bonaparte. La materia, ovviamente, storia. Si tratta di una serie di scelte che sono focalizzate ad orientare chi gioca verso la formazione di uno degli argomenti più importanti del nostro passato. In questa linea del tempo vengono affrontati i momenti salienti del personaggio e il giocatore vive il tutto impersonando proprio il condottiero francese. Un ottimo punto di vista!

Napoleon: Total War, SEGA 2010

Il consiglio che ho dato ai ragazzi è quello di cercare di aggiungere piccoli spunti non per forza reali per confondere il giocatore, in modo da non far semplicemente rivivere la vita di Napoleone, bensì di indurre all’errore l’utente finale, senza stravolgere la storia ma, di fatto, rendendo ancora più interessante il prodotto finale.

L’idea

Immaginate di essere proprio Napoleone e di trovarvi a determinare come affrontare una delle sue battaglie più famose. Come vi comportereste? Che succede per ogni possibilità? Ecco, questa è l’idea dietro al gioco, dal quale spero di vedere tante interazioni interessanti.

Team MonkeTeck

Qui si passa ad un argomento completamente diverso: la navigazione. Interessante vedere come i ragazzi abbiano improntato tutto in mare, con un percorso definito che porta ad un successo di una missione o al suo totale fallimento. Purtroppo il team aveva pensato di arricchire di attributi ogni personaggio, tuttavia il consiglio che ho voluto dare loro è quello di fare attenzione ad aggiungere troppe caratteristiche, poiché ogni personaggio si sarebbe trovato una programmazione completamente diversa dall’altro, e oltretutto molto più complessa. Meglio tenere semplicemente il concetto di “energia vitale” che può calare o aumentare ad ogni snodo della storia.

ATLAS, Grapeshot Games

L’idea

Questa è sicuramente l’idea più personale. Il personaggio è una nave (selezionabile) e ogni nave può effettuare una missione proprietaria, durante la quale può perdere o acquisire risorse di vario genere per essere “pronta” nello step successivo. Molto interessante!

Conlcusioni

Come potete ben capire sono molto emozionato, per vari motivi. Il primo su tutti, ho un sacco di aspettative dai team. Successivamente, ho notato un interesse immediato grazie all’argomento che quest’anno ho deciso di trattare: il mondo videoludico. Oggi un videogame non è più qualcosa che serve solo per passare il tempo, si tratta di un industria enorme che da lavoro non solo dall’interno (vedi architetti software, designer, sviluppatori, e altre figure classiche aziendali) ma anche a chi “gioca”. Lo scrivo tra virgolette perché oggi è possibile essere anche atleti. Gli e-sports stanno spopolando e ormai, volenti o nolenti, sono il fenomeno delle nuove generazioni. C’è tanto altro su internet, come la parte di youtube, twitch e simili. Si tratta del mondo del contenuto online, live o registrato che sia. Questo è il mondo che oggi sta volando e chissà che declinazioni prenderà anche a breve termine. A proposito di questo vi consiglio vivamente questa serie di Rudy Bandiera: The Gamer.

Io spero di poter aiutare questi ragazzi a vivere l’informatica per quello che è a mio avviso: uno strumento che necessita di organizzazione, tenacia e creatività.

Agile@School – Anno sesto

Siamo ancora in pandemia. Abbiamo una buona percentuale di vaccinati, ma ancora dobbiamo avere a che fare con relazioni in remoto. Lo stesso vale per il nostro amato e inarrestabile progetto: Agile@School. Siamo arrivati al sesto anno consecutivo e questa volta, con un’idea orientata al mondo videoludico.

Non a caso l’immagine di copertina richiama uno dei giochi punta e clicca più conosciuti di tutti i tempi, col quale ho perso ore e ore nei pomeriggi della mia adolescenza: The Secret Of Monkey Island tm.

Il cosa

“Facciamo un gioco, sì, produciamolo. Pur semplice che sia, ma creiamo qualcosa di nostro”. Questa è la missione che i ragazzi hanno quest’anno. Il tipo è quello della saga di “Lupo Solitario” (Lone Wolf), un famoso libro game di qualche tempo fa. Abbiamo deciso di far fare agli studenti un piccolo motore basato su “decisioni –> conseguenze”, un grafo in cui una storia viene sviluppata e diventa la strada di un personaggio con una semplice caratteristica, l’energia vitale.

Il come

Decidano i ragazzi. C++? Java? Angular? Javascript? Python? Quello che vogliono. Ci sono solo tre vincoli:

  • La storia deve essere derivata dal programma di una materia, anche per coinvolgere altri professori.
  • La storia deve essere un’avventura semplice, per arrivare ad un lavorato funzionante in un solo mese.
  • Le scelte possibili devono essere al massimo 3, con altrettante conseguenze: avanti senza subire danni, avanti subendo danni, fine del gioco prematura (fine energia vitale improvvisa).

Gli strumenti

La gestione del progetto sarà in Agile, e con SCRUM. Per implementare la parte di gestione, abbiamo creato 4 team con altrettanti backlog, solo Product Backlog Item e Task. Utilizzeremo git come source control manager e, in generale, ogni editor di codice legato alla tecnologia scelta dai ragazzi.

Infine, le presentazioni prevedono un piccolo video, una serie di mock grafici nell’arco del progetto e una bella demo del software alla fine di tutto.

I team

I ragazzi hanno già scelto i nomi dei team:

  • FISHER: “perché abbiamo tutti un soprannome comune che richiama tale nome”
  • CROMOSOMI#: “un joke per il linguaggio C++”
  • MONKETECK: “due parole, e la seconda per esprimere senso di tecnologia”
  • GENTS&LADY.PY: “gentlemen e una ragazza, in python, o almeno ci proviamo”

Ogni team è di 5/6 persone e le figure che abbiamo identificato sono:

  • PO: product owner, uno per team, che si riferirà a me per lo stato dei lavori (non dimentichiamo che io sono il cliente del gioco).
  • Marketing: figura che curerà la presentazione.
  • Tech lead: figura che seguirà le implementazioni anche a livello decisionale, riferimento di Pier-Paolo, che anche quest’anno sarà il loro appoggio tecnico.
  • Developer: chiunque partecipi al progetto e sviluppa parti del gioco

Insomma, ci sarà da divertirsi. Aspettatevi qualche post nel breve, perché i ragazzi hanno già iniziato a buttarsi a capofitto nel progetto. La passione sembra averli abbracciati.

Stay Tuned!

Serie completa: Agile@School 2020

Eccovi la lista degli episodi, per condividere con voi il progresso di quest’anno con l’IISS Gadda di Fornovo Taro (TAG# Agile@School):

Anche quest’anno grandissima esperienza. Un grazie a Christian Memoli (docente di Tecnologia) e al nostro istruttore Pier-Paolo Mammi, che ha fatto veramente un bel lavoro.

Strumenti utilizzati: Azure DevOps services, Microsoft Teams, GitHub.

Alla prossima!

Agile@School – Anno quinto, ep. 8

Siamo infine giunti al termine della nostra avventura “agile” coi ragazzi del I.I.S.S. Gadda; è stato un viaggio pieno di concetti nuovi, di abitudini per lo più sconosciute e difficili da fare proprie, soprattutto in un percorso così breve. Cosa avranno imparato i ragazzi e cosa sarà rimasto loro per il futuro? Intanto, scopriamo com’è andata la presentazione dei progetti.

Esaminare il file README e le grafiche delle applicazioni

Nella precedente lezione Pier-Paolo ha dato un paio di esercizi: compilare il README.md dei progetti GitHub, visualizzato in automatico all’apertura del repository da browser e realizzare alcuni mock-up dell’interfaccia grafica per le applicazioni che hanno sviluppato finora. Eravamo curiosi di capire come i ragazzi si sarebbero immaginati la propria applicazione, così come quale sarebbe stata la loro “sensibilità” verso la user experience.

Già dalle diverse modalità con cui i progetti sono stati presentati abbiamo notato con piacere il buon livello di organizzazione e affiatamento dei team. In particolar modo ci ha colpito il team TEP, che non solo ha realizzato un file readme corposo, con una descrizione estesa delle funzionalità dell’applicazione e istruzioni piuttosto dettagliate per l’apertura in locale del loro progetto, ma anche ricco di linee guida da seguire per la creazione della parte grafica, con i colori dell’applicazione, gli stili, ecc.

Le diverse schermate sono poi state descritte dai rispettivi creatori, tuttavia risulta evidente la coerenza generale con cui queste sono state ideate. Nonostante la grafica fosse minimale (com’è giusto che sia in un mock-up), questa risultava di immediata comprensione e fruibilità da parte di un possibile utente finale, per cui sarebbe stata tranquillamente impiegabile in una app reale.

Durante la visione del codice è risaltato il corretto utilizzo del branching negli sviluppi (affrontato in prcedenza) portati avanti dai vari membri.

Il secondo gruppo a dare soddisfazione è stato quello che ha progettato il Casinò. File readme ben compilato, è vero, ma degno di nota è stato soprattutto il mock-up della loro applicazione: una sola schermata, ma molto vicina ad una vera pagina iniziale di un sito di gaming, poiché costruita con molto colore e con tanta grafica. Non solo, anche funzionante!

Gli altri due gruppi sono riusciti a realizzare dei mock-up significativi, ma con qualche “pecca”: quello presentato dal team CUP, impaginato bene ma troppo simile a un sito vero e proprio, tanto era ricco di contenuti. Non è stata sottolineata la modalità di utilizzo dell’applicazione. I ragazzi del team ClasseViva sono stati più “in tema”, ma le schermate presentavano qualche incertezza a livello di esperienza utente. Pier-Paolo ha quindi suggerito di scegliere i componenti dell’interfaccia in modo da renderla più intuitiva e immediata per l’utente finale (ad esempio, prediligere i pulsanti invece delle tendine di selezione e via discorrendo).

Tirando le somme

In queste otto lezioni abbiamo parlato di come ci si approccia allo sviluppo “agile”: cosa sono le user story e come queste diventano work item in un sistema di gestione dei progetti (in particolare Azure DevOps); cosa sono le boards, come si utilizza il backlog e la presa in carico dei task; infine, come sia importante abituarsi alle cosiddette cerimonie (stima dei work item, review quotidiana, etc.). Abbiamo poi complicato il tutto coinvolgendo Git e le sue caratteristiche più avanzate, come ad esempio il branching e la risoluzione dei conflitti, nonché la necessità di collegare la gestione del codice ai work item per tracciare contemporaneamente gli sviluppi e l’andamento del progetto. Infine abbiamo condito il tutto con qualche concetto normalmente tralasciato quando si parla di sviluppo, come la creazione della documentazione (tecnica e funzionale) e la realizzazione di mock-up per la UI.

Conclusioni

A ben guardare, anche se per me il tempo è quasi volato, abbiamo fatte vedere davvero tante cose a questi giovani. Confidiamo che per gli studenti il corso (seppure il nome è riduttivo vista l’esperienza) non sia stato semplicemente uno fra tanti, ma che sia visto come un punto di partenza, uno stimolo in più per approfondire e fare propri tutti i concetti, soprattutto per quando si troveranno ad affrontare un’esperienza lavorativa. In più, la difficoltà imprevista della quarantena (a nostro avviso, affrontata alla grande) ci ha “costretti” a condurre il corso in modalità online. Beh, possiamo ritenerci decisamente soddisfatti.

Chiudo (un po’ a malincuore) ringraziando in primis il professor Christian Memoli e i dirigenti dell’I.I.S.S. Gadda, che ci hanno nuovamente dato fiducia nel portare avanti il progetto Agile@School; naturalmente i ringraziamenti si estendono, al nostro docente ormai ufficiale, Pier-Paolo, che ha svolto un lavoro eccellente, di cui ero praticamente certo.

Last, but not least non posso che ringraziare anche i ragazzi stessi, sia per aver sopportato le nostre pressioni, sia per aver ascoltato e messo a frutto quanto imparato: senza di loro questo progetto non avrebbe neanche senso di esistere!

Stay tuned per il prossimo anno…

Agile@School – Anno quinto, ep. 7

Settima lezione. Questa volta non parleremo dell’essere “online” a lezione come precedentemente descritto, ormai è un dato di fatto. Notizia di oggi, invece, quella che oltre agli esami di maturità effettuati online, in caso di protrarsi della situazione di emergenza, a settembre tutte le lezioni verranno tenute in didattica a distanza. In tal caso direi che siamo già pronti.

In questa lezione, i ragazzi hanno potuto provare con mano cosa accade quando non si applica una metodologia agile; il professore si infuria! Ma quali sono stati i passi falsi? Proviamo a vederli più in dettaglio, al fine di analizzare meglio la problematica ed evitare che si ripeta in futuro.

Uso scorretto degli strumenti e disorganizzazione

In un caso, il codice scritto da ciascuno dei membri di un team non è stato portato sul repository GitHub, bensì unicamente memorizzato sul proprio computer. E non è nemmeno stato installato il software necessario per interfacciarsi al source control. Nell’altro, non siamo stati in grado di vedere nulla. Indovinate il motivo… nessuno dei membri del gruppo aveva a disposizione un computer dal quale poter condividere lo schermo, poiché erano tutti collegati solo tramite smartphone.

Entrambi i casi rappresentano punti critici nell’adozione dell’agile development:

  • nel primo, la mancata adozione degli strumenti e dei processi scelti, che in un ambito aziendale hanno una precisa ragione d’essere. Possibili conseguenze sono disallineamento nel codice e introduzione di anomalie, se non addirittura perdita di codice (“se si rompe il PC?”);
  • il secondo, la mancanza di organizzazione, che è un sottoinsieme della mancanza di comunicazione, punto chiave della mentalità agile: in questo caso, pensate alla “brutta figura” che si fa nel non presentare nulla ai committenti perché nessuno ha un computer. Quasi anacronistico. E pensare a un piano di riserva?

Torniamo alla teoria: la documentazione

Siamo certi che i ragazzi abbiano imparato tanto da questa serie di difficoltà. Tuttavia, nonostante il blocco, la lezione è andata avanti con un po’ di teoria. Oggi è stato il momento della documentazione, aspetto spesso trascurato, se non frainteso, dello sviluppo del software. Avete sentito bene, dello “sviluppo del software”. Nessuno si può salvare, nemmeno gli sviluppatori.

Pier-Paolo ha quindi evidenziato la differenza fra la documentazione tecnica e quella funzionale, entrambe necessarie, ma diverse sia nell’obiettivo/destinatario che nella stesura. Se nella prima è possibile adottare un linguaggio di settore e scendere nel dettaglio delle implementazioni (pratica consigliata per favorire la documentazione interna del team), nella documentazione funzionale troveremo una descrizione dell’operatività, corredata di schermate ed esempi concreti. Non dimentichiamo che quest’ultima è rivolta soprattutto all’utente finale del software.

Per far capire meglio questo aspetto abbiamo mostrato ai ragazzi alcuni esempi di quanto realmente realizzato sul lavoro e abbiamo dato loro due semplici esercizi: uno, provare a compilare il file README.md sul repository GitHub, con una descrizione del proprio progetto e le istruzioni per scaricarlo e aprirlo; due, disegnare alcune schermate di come immaginano l’interfaccia utente che il loro software deve avere, utilizzando gli strumenti di mocking che preferiscono.

Conclusioni

La lezione si è chiusa con la presentazione del codice degli altri gruppi, quelli che hanno commesso meno errori dei primi. Una cosa ci ha colpito in particolare, la realizzazione del progetto “Casinò online”, in quanto i ragazzi hanno già adottato una soluzione che facilita l’integrazione del codice in un’interfaccia grafica; un approccio quasi da architetti software, bravi!

Ci avviciniamo purtroppo alla fine del nostro percorso, alla sfida finale, quasi al boss di fine gioco. La prossima volta i ragazzi dovranno presentare tutto quanto fatto. Siamo proprio ansiosi di vedere come lo step finale verrà affrontato da ognuno di loro. Le scelte di chi presenterà, come, gli strumenti ed, ultimo ma non per importanza, come gestiranno i tempi.