Author Archives: Alessandro Alpi

DevOpsHeroes 2017 e SQL Saturday Parma 2017 alle porte

Settembre, un mese il cui inizio segna la partenza di tante cose. I bambini ricominciano la scuola, le aziende iniziano a riconsiderare investimenti, i progetti e gli eventi tornano a bussare alle nostre porte.

Come sapete, io amo veramente creare progetti ed organizzare eventi. Ma in questo post voglio focalizzarmi sui nostri due appuntamenti fissi e su quanto io sia veramente orgoglioso dei risultati degli ultimi quattro anni. Il tutto è stato possibile grazie alle community, agli sponsor, agli aiutanti presso le location, ai miei collaboratori. Ho organizzato per quattro anni i SQL Saturday di Parma, dal 2014 al 2016, trasformando la nostra piccola cittadina in una città firmata SQL Server. Chi l’avrebbe pensato possibile? Beh, a onor del vero, io ci speravo, ma un risultato come quello ottenuto nel tempo, no di certo. Il fallimento, quando si affrontano “missioni” come queste, è sempre dietro l’angolo. E invece, è partito come una “quest” da RPG per arrivare al SQL Saturday che conosciamo, che batte i record di presenza e che dimostra quanto Parma e i suoi cittadini siano vicini alla tecnologia e condividano la voglia di vivere una giornata di esperienze tecnologiche comuni. Una cosa di cui sicuramente andare fieri!

LocandinaSqlSaturdayParma2017

Tuttavia, due anni fa, ho sentito la necessità di creare un nuovo evento, che avesse la finalità di portare un nuovo modo di pensare l’IT ed i ruoli (almeno, all’epoca non andava tanto di moda in Italia, per quanto vedevo anche nelle mie esperienze professionali da consulente). Ed è stato proprio il periodo in cui il termine DevOps si è fatto sentire. Il problema era trasformare una buzzword ricca di rumori e di errati accostamenti concettuali in un termine che esprimesse profondamente una cultura, un modo di lavorare e di vivere in azienda, un approccio fondamentale non solo operativo. Combinando la mia passione per i Simpson (soprattutto per Homer) e DevOps, mi sono inventato DOH (esclamazione di Homer) ovvero DevOpsHeroes. E oggi, per il secondo anno consecutivo, le figure della parte Operation, i DBA, i PMO, i Developer verranno a Parma a condividere le proprie esperienze, relativamente a metodologie applicate, integrazione e cooperazione tra persone, al fine di rendere l’IT un’entità più produttiva ed efficiente, ma senza perdere di vista la qualità.

DOH_logo

Dopo l’introduzione, lasciatemi indicare i dettagli dei due eventi, dal più vicino al più distante nel tempo:

DevOpsHeroes 2017 – Parma (http://www.devops-heroes.net/)

Sql Saturday 2017 – Parma (http://www.sqlsaturday.com/675)

  • Data e Location: Saturday, 18th November @ Univeristy of Parma
  • Hashtag: #SQLSAT675
  • Costo di ingresso: free
  • Durata: dalle 8 (registrazione fino alle 9) alle 18.30
  • Registrazione: https://www.sqlsaturday.com/675/registernow.aspx
  • Durante la registrazione:
    • Utilizzerete SpeedPASS
    • Riceverete il lunch ticket
    • Riceverete il welcome kit
  • Lingue: ITA/ENG 

Cosa il futuro ci riserverà in materia di eventi a Parma? Potrei aggiungere un evento IoT, ad esempio, visto che giocando con Raspberry Pi3 e con i ragazzi di Agile@School, mi sono fatto un’idea di come il mondo si muoverà a breve (devo essere pronto anche col mio piccolo Giulio eh, io avevo i lego, lui chissà cosa avrà, oltre a quelli ovviamente  )

Oppure potremmo aggiungere un format, come un evento TED ad esempio. Chi lo sa! Tuttavia credo che avrò tutto l’aiuto possibile, così come quest’anno è successo. Sono partito praticamente da solo il primo anno e oggi siamo sei. Ancora una cosa di cui essere orgogliosi.

Stay tuned! 

Agile@School – Questa è la fine, per quest’anno

Tutte le buone cose hanno una fine, giusto? Il progetto Agile@School 2017 non fa eccezione. Ma nessun problema, abbiamo una grande notizia! Fra poco diventerò papà, e non posso sapere quanto tempo potrò investire in progetti come questi (anche se, di certo, non mi fermerò) ma, a partire dall’anno scolastico 2017/2018, molto probabilmente, avremo nell’equipaggio anche Michele Ferracin, un amico anch’esso membro di GetLatestVersion.it. Michele sta prendendo contatti con le scuole nel comune di Rovigo per portare Agile@School nel nord Italia. Abbiamo raggiunto l’obbiettivo “Portare il progetto in almeno due città” 
Ma le buone notizie non sono finite. Infatti, quest’anno posso dire di aver seguito ragazzi con una passione infinita per l’informatica e le nuove tecnologie. Ma questo lo sapete già, come descritto nel precedente post.
Gli esami di maturità stanno terminando, ma poco prima della fatidica data, gli studenti erano pronti e sul pezzo. Ed ecco cosa è stato presentato:

Software e Tecnologia

Il team Messinesi (Amanda e Alex) hanno preparato una presentazione in Prezi il cui obbiettivo è quello di mostrare gli strumenti coinvolti nello sviluppo della loro chat. In aggiunta, con l’ausilio di più dispositivi (si parla di portatili), la commissione ha potuto provare la loro applicazione real time.


Intelligenza Artificiale e Bot

Il team Random (Thomas e Luca) ed il team The Scrubs (Enea e Sebastiano) hanno creato tre mini pitch video per presentare il loro lavoro, con:

– un’introduzione a mo’ di presentazione (via Prezi e Power point)
– una spiegazione semplice per descrivere le tecnologie usate “dietro le quinte”
– un paio di interviste fatte a sè stessi

IoT

Il team Domotic (Nicodemo e Mattia) e il team Bar Santa (Simone e Mirko) hanno mostrato il funzionamento della loro Smart House e della loro automobile radiocomandata, anche con l’ausilio di questi video:


Cognitive Services

Il team Human Recognizers (Marco e Francesco) ha presentato un mini sito web ed un video di funzionamento dell’applicazione di riconoscimento facciale. Dimostrano come una webcam riconosce l’umore e le facce, partendo anche da una foto. Il tutto con un’applicazione mobile.


Questa è la loro presentazione Prezi.

Come avete potuto constatare, tutti hanno lavorato veramente bene. E questo è il diploma di quest’anno, come attestato della fine del progetto:


Quest’anno abbiamo raggiunto degli ottimi risultati e noi “coach” siamo veramente fieri del lavoro svolto insieme. Abbiamo anche chiesto un sondaggio, per carpire il gradimento del progetto:


Ed ora, un grosso “in bocca al lupo” a tutti i ragazzi, perchè l’esame passato è solo il primo che affronteranno! 

Stay tuned 

Agile@School 2017 – Quando i progetti diventano realtà

L’ulitmo appuntamento coi ragazzi a scuola è stato veramente appagante. Mi sarei aspettato seri problemi da risolvere, questioni da affrontare. E invece è andato tutto bene. Questo è il motivo per il quale qui di seguito allegherò tante immagini. Credo proprio che sia il miglior metodo per descrivere come gli studenti stanno realizzando le loro idee. Ricordiamoci tutti però che stiamo parlando di diciottenni e non di startup!

Dicevamo, le immagini parlano più di tante parole. Ma ecco i team:

Il team I Messinesi (Alex e Amanda) sta sviluppando una chat collaborativa real time, simile al famoso Slack. Oltre a realizzare il client, lo scopo dei ragazzi è quello di approfondire le conoscenze sulle tecnologie usate nel mondo del lavoro, come il .net framework, i pattern MVC e SignalR. In parallelo a questo progetto, infatti, i due stanno seguendo un corso sull’utilizzo di Visual Studio in modo da essere preparati al mondo dello sviluppo. Il nome del progetto è Notify.

 

Il team Random (Thomas e Luca) sta creando un bot a linguaggio naturale senza intelligenza artificiale, almeno per la prima release. Esso risponde automaticamente a domande relative agli scrittori italiani del passato. Mostra link, informazioni testuali ed immagini dell’autore richiesto. Ovviamente, l’utente può “chiacchierare” con il bot, che ad oggi sembra capire molto bene il dialogo. Il nome del progetto è Italian Authors ed è stato implementato su Wit.ai. Infine, potrà essere interfacciato a Facebook Messenger via Heroku. 


Il team Scrubs (Enea e Sebastiano) sta creando un bot a linguaggio naturale senza intelligenza artificiale, almeno per la prima release. Esso risponde automaticamente a domande relative a due argomenti che tutti noi dovrebbero approfondire, visto il loro calibro e i vantaggi che possono derivare. Parliamo di Sport e fotografia. Il bot mostra link, informazioni testuali ed immagini in base al percorso scelto dall’utente. Ovviamente, l’utente stesso può interagire con il bot. Il nome del progetto è CPP ed è stato implementato su Wit.ai. Infine, potrà essere interfacciato a Facebook Messenger via Heroku anch’esso. 
 


Il team Domotic (Nicodemo e Mattia), come il nome stesso descrive, sta realizzando un’applicazione real time che interagisce con un prototipo di “Smart House”. Con un semplice tap sul cellulare è possibile aprire e chiudere porte e finestre, accendere e spegnere le luci, ed, insomma, interagire con la casa. In questa release non è possibile pulire i pavimenti in automatico, ma per questo consiglio ai ragazzi di interagire con un robot in futuro . Il nome del progetto è Future House ed è stato creato utilizzando Arduino e php soprattutto.

 

Il team Human’s Recognizer (Marco e Francesco) sta creando un’app Android che, partendo da alcune fotografie di persone, ritorna informazioni sull’età e l’umore, stampando un messaggio di reazione in base all’umore stesso. Importantissima anche la gestione della privacy del dato, argomento sempre più importante ai giorni nostri. Il nome del progetto è iFinder ed utilizza lo sdk di Android e la Face API di Microsoft. 

Il team Bar Santa (Simone e Mirco) sta facendo invece “hacking” di una automobile radiocomandata. Il risultato è una super car con una videocamera a bordo, servomotori per le ruote, sensori e via discorrendo. Il tutto è racchiuso in una carrozzeria disegnata dai ragazzi, prodotta con la stampante 3D della scuola. Il nome del progetto è, appunto, Super Car (ricordate Kit?) ed è stata implementata sfruttando Raspberry Pi3 e Python come linguaggio di programmazione.

 

Infine, non voglio annoiarvi cL’ulitmo appuntamento coi ragazzi a scuola è stato veramente appagante. Mi sarei aspettato seri problemi da risolvere, questioni da affrontare. E invece è andato tutto bene. Questo è il motivo per il quale qui di seguito allegherò tante immagini. Credo proprio che sia il miglior metodo per descrivere come gli studenti stanno realizzando le loro idee. Ricordiamoci tutti però che stiamo parlando di diciottenni e non di startup!
 

Cosa posso dire? FANTASTICO! Questo è l’umore che ho proprio adesso. Sono contento perchè credo che gli studenti “spaccheranno” all’esame . Il prossimo post vi mostrerà i pitch video che stanno creando. Sono molto ansioso di vedere il lavoro, ma devo stare zitto, altrimenti rischio di fare spoiler, quindi…

Stay Tuned! 

Agile@School 2017 – I progetti

Sabato scorso, con i team definiti nell’incontro precedente, abbiamo parlato di analisi dei requisiti, partendo dalla customer journey che gli studenti hanno creato appositamente. Come mi aspettavo, quest’ultimo compito è risultato più arduo di quanto i ragazzi credessero. Non è infatti facile avere le idee chiare su quello che si vuole ottenere, anche se l’idea di fondo del progetto è apparentemente solida. Parlandone insieme e facendosi qualche domanda in più a mo’ di brainstorming, sono emerse tutte le normali lacune di chi non è abituato a pensare a veri progetti. 

Risultato? Non avevamo nemmeno una customer journey.
Come fare? Semplice, Gabriele ed io abbiamo seguito team per team, sia dando consigli sul “cosa fare” per chi era a corto di idee, sia discutendo la forma da seguire per ottenere risultati efficaci.
Come in ogni percorso, abbiamo perso un paio di ragazzi, i quali hanno preferito seguire un iter solitario. Parlo anche di queste persone perchè, nonostante la strada intrapresa, sono stati con noi, e ci hanno pure aiutato a costruire le board di cui parleremo a breve. Il tutto nello spirito di aiuto e condivisione. Ed è decisamente importante; un valore aggiunto non da poco. 
Possiamo dire di avere infine sei squadre, con altrettanti progetti:
Come si vede nella foto, il primo step è stato raccogliere una board. L’idea è quella di fare la story map, ovvero una bacheca in cui apporre post-it di colore differente, con la quale descrivere le funzionalità del software (o di altro, come l’utilizzo di hardware, il dialogo di bot, ecc.). Si tratta di un’implementazione molto semplice, se si conoscono già le funzionalità da offrire. Immaginate di avere una linea principale in cui rappresentare le feature principali ed almeno una secondaria in cui indicare le attività da implementare. Orizzontalmente le feature, e verticalmente il loro sviluppo. In verticale anche la profondità fino a cui arrivare, versione per versione. Ecco come appare:
La riga a matita, la quale esclude l’ultimo post-it blu, è la v1.0. Al di sotto di essa, la 2.0.
Dalla board ricaveremo le epiche e i PBI da aggiungere a Visual Studio Team Services, in modo da creare una rappresentazione virtuale della stessa. Utilizzeremo anche la funzionalità denominata swimlane, al fine di creare all’interno dello stesso spazio più board, una per ogni progetto/team. 
Da qui si inizierà con il vero sviluppo e con la riorganizzazione delle bacheche quando e laddove richiesto. I presupposti ci sono, le idee sono buone ed anche l’innovazione è presente nei pensieri dei ragazzi. Avremo, se tutto andrà come dovrebbe, un’automobile intelligente comandata da smartphone (Raspberry), un sistema di allarme domestico (Arduino), un paio di chatbot (senza intelligenza artificiale), una chat per la produttività dei team ed un progetto di riconoscimento facciale. Da rimanere a bocca aperta! Il problema è: “ce la faremo?”, proviamoci!
Stay tuned! 

Agile@School 2017 – Primo incontro

Il progetto Agile@School è ufficialmente ricominciato. E rispetto all’anno scorso, con una marcia in più, vista la grande partecipazione. Quasi una ventina di persone, tante idee e progetti, tanti team e quindi, cambiamento di metodologia. 

L’anno scorso abbiamo introdotto il concetto di Scrum ed i relativi principi e pratiche. Questa volta abbiamo pensato, proprio per la natura distribuita dei partecipanti, di passare a Kanban. Senza entrare troppo nel dettaglio metodologico, avremo:
– Alcuni micro team, che chiameremo “task force”, prendendo spunto da un termine usato (in modo diverso in realtà) da Mauro Servienti nelle sue slide sul suo lavoro in Particular
– Una Kanban board
– La definizione delle personas
– La definizione della customer journey e di una Story Map
– Alcune cerimonie utili all’allineamento delle persone nel complesso
Le task force
Come detto in precedenza, il termine è stato preso da un’interessantissima sessione di Mauro Servienti, in cui si racconta la sua esperienza sul suo posto di lavoro, una realtà molto distribuita, anche geograficamente, che necessita di una gestione ben studiata. Nelle slide si parla di task force per indicare un elenco di “volontari” che si uniscono per risolvere un problema (o una issue). Ogni task force effettua un meeting per capire come e cosa fare al fine di portare l’elemento dal backlog fino alla completa implementazione e, ovviamente, inizia a lavorare per portare a compimento l’implementazione stessa. Il tutto seguendo un ciclo di vita (lifecycle) che dura quanto serve a portare a termine il tutto. 
In Agile@School avremo quindi sei task force, sei gruppi di due o tre persone che prenderanno in carico le implementazioni e le relative analisi. Nel nostro caso avremo una task force per progetto, ed ogni progetto sarà una tesina differente da preparare entro i prossimi tre mesi.
La Kanban board
Vedendo l’insieme dei ragazzi come un grande team di circa venti persone, abbiamo deciso di organizzare la nostra Kanban board non solo con le colonne che identificano il processo di ogni elemento, bensì aggiungendo swimlane, ovvero linee orizzontali che distinguono ogni prima release di ogni progetto, e quindi, task force:
Sulla foto indicata ci sono tutti i termini propri di Visual Studio Team Service, e sono stati tutti descritti ai ragazzi. Abbiamo quindi un glossario comune, in modo da potersi esprimere con un linguaggio comune. Anche questo dà valore aggiunto.
Le personas
Ogni membro delle task force ha compilato una scheda appositamente preparata, per dare indicazioni interessanti su interessi, obbiettivi ed informazioni generali. Perché scrivere di sé? Perché conoscersi è il primo passo verso la costruzione di una fiducia reciproca e di trasparenza, necessarie per avere team solidi e produttivi. La scheda delle personas proposta, molto semplice, è la seguente:
Perché “ruolo nel team”? Perché volevamo capire anche l’interesse dei ragazzi. Si tratta di una forzatura, è vero, ma è interessante osservare come i partecipanti si vedono all’interno di una squadra. Alla fine, adattare la scheda porterà ad avere ancora più informazioni utili.
La customer journey
Al termine del percorso introduttivo, dopo aver condiviso il glossario e le idee sul progetto, abbiamo assegnato un lavoro importante ai ragazzi. Fare la customer journey del progetto che hanno in testa. Il compito non è semplice, poiché sarà necessario identificare le problematiche e i requisiti funzionali richiesti per l’applicazione. Ogni task force dovrà creare il “viaggio” dell’utilizzatore, con tanto di cambiamento di umore nei vari momenti e con l’indicazione dei punti più critici e di quelli che danno valore aggiunto.
Unitamente alla customer journey, nel prossimo incontro, andremo a creare la story map di ogni progetto, che utilizzeremo per aggiungere le attività sulla board. Da lì, inizieremo a sviluppare e a gestire ogni task force.
Le cerimonie
Abbiamo identificato un paio di cerimonie ereditate da Scrum, al fine di rendere l’esperienza dei partecipanti interessante anche a livello di rapporti interpersonali ed inter-task force. Il nostro obbiettivo è quello di fare una review dei progetti, per portare quell che in gergo chiamiamo Awareness (consapevolezza), in modo da rendere chiaro a tutti chi sta facendo cosa e come sta affrontando le problematiche. Il fine è quello di condividere anche l’esperienza ottenuta dalla risoluzione delle anomalie e degli impedimenti. Infine, una retrospettiva, per migliorare il processo incontro dopo incontro. A parte queste due, non serviranno “daily meeting” o altri momenti di incontro.
Per tutto il resto, il progetto rimane simile a quello dell’anno scorso. Utilizzeremo Slack, Visual Studio Team Services, e lasceremo la libertà ai ragazzi nella scelta degli strumenti di sviluppo. Saremo Gabriele ed io, anche se, come già indicato in un post precedente, vorremmo seriamente far partire il progetto in altre realtà, per chiunque fosse interessato, professori compresi!
Vedremo come proseguirà.
Come sempre,
Stay Tuned! 

Agile@School, si ricomincia!

Agile@School è un progetto nato l’anno scorso, per ora seguito solo dal sottoscritto e da pochi altri amici che mi hanno aiutato nello svolgimento delle attività. Tuttavia, seppure l’anno scorso fosse stato totalmente sperimentale, credo che possa diventare sempre più interessante, soprattutto se condiviso con chi vorrebbe partecipare.

Ad oggi non abbiamo nemmeno un sito che descriva di cosa si tratta, anche perchè non abbiamo ancora definito un reale contesto ed un insieme di step da seguire. Ed è proprio per questo che scrivo il post. Oltre a descrivere ed aggiungere dettagli su qualcosa che può diventare importante, sono qui a chiederVi disponibilità di partecipazione, ovunque vi troviate sul territorio nazionale. Ma andiamo per passo.
Cos’è Agile@School?
Si tratta di un’idea che si pone come obbiettivo quello di portare le metodologie Agili (a scelta di chi segue il progetto stesso in accordo con la scuola) all’interno di istituti di scuola superiore o di media inferiore (anche questo a scelta) al fine di gestire progetti scolastici, quali ad esempio tesine di esame, progetti paralleli, sviluppo di idee utili all’istituto stesso, e via discorrendo.
Ok, ma cosa si deve fare?
Seppure l’organizzazione sia in mano a chi si prende l’onere (e l’onore) di seguire il progetto, l’esperienza che ho avuto l’anno scorso mi permette di dare un paio di dritte:
– crearsi una board (con Trello, ad esempio)
– trovare un aiutante per le volte in cui ci si riuinisce con la scuola
– creare un team con una chat collaborativa (con Slack, ad esempio)
– concordare con i professori un referente a scuola
– prepararsi una sessioncina di 4/5 slide da presentare agli studenti, sessione semplice ed accattivante, non tediosa e già formativa (quello viene dopo)
– organizzare un primo incontro illustrativo per selezionare il team da seguire (il numero degli studenti è selezionato dai docenti stessi)
– cercare di seguire un team di massimo 7/8 persone, ma se la scuola ne offre di più, provare a fare due team, aumentando gli aiutanti (consiglio di partire con uno)
– organizzare con i prof. le date e le periodicità di incontro per seguire con il metodo scelto (Scrum, Kanban, ecc..) da coach
– istruire il vostro aiutante come un facilitatore, tipo uno ScrumMaster, per seguire insieme la “cosa” da esterni
– selezionare i ruoli nel team e determinare l’area di lavoro comune
– postare ogni incontro sul vostro blog (più social FB, Twitter, LinkedIn, ecc.)
Chi può aiutare?
Chiunque abbia voglia di impararsi le basi dell’agile (meglio se ha già esperienza) e soprattutto chi è già nel mondo del lavoro, il che aiuta davvero a capire come comportarsi. 
C’è una community?
L’unica community che, ad oggi, segue questa cosa, è GetLatestVersion.it, con la quale stiamo provando a promuovere questo progetto dal nord al sud Italia.
Periodo?
Questo è il periodo migliore per partire. L’inizio dell’anno. Ma possiamo intanto parlarne insieme in una call di pochi minuti per ulteriori delucidazioni.
Futuro?
Nel futuro penseremo a come accentrare le informazioni per realizzare un vero e proprio progetto con relativo Sito (e anche qui vedremo se usare strumenti comuni o meno). Una volta che avremo poi almeno un paio di realtà in più, faremo il nostro team su chat collaborativa (probabilmente Slack).

Contatti?
Alessandro Alpi (Io), Gabriele Etta (il mio aiutante), tutta la community di GetLatestVersion.it

Vi aspetto, in questo progetto credo davvero tanto, visto anche il successo dell’anno scorso!

Stay tuned! :)

Eventi post vacanze estive

Finalmente le vacanze estive stanno arrivando, un po’ di stanchezza si sta facendo sentire. Quest’anno ho impiegato tutte le mie forze in una marea di cose: il corso di inglese avanzato, i progetti esterni, i progetti a scuola, e, ovviamente, il grandissimo impegno in azienda. Tuttavia, questo non ha fermato l’organizzazione di due eventi.
SQL Saturday Parma 2016
Come negli ultimi due anni passati, il SQL Saturday passerà da Parma, ancora una volta nel campus universitario ed ancora una volta per vivere una giornata di condivisione delle esperienze sul mondo di SQL Server. Un intero sabato all’insegna dei database e di tutto quanto ruota attorno al nostro amato RDBMS. L’evento si terrà all’Università degli studi di Parma, il 26 novembre 2016, presso il dipartimento di Ingegneria dell’Informazione. Come sempre, il tutto è stato realizzato con l’aiuto del prof. Stefano Cagnoni.
Il sito dell’evento è qui, ed è già possibile inviare le proposte di sessione. L’hashtag è #sqlsat566.
La schedule sarà pronta per fine settembre.
DevOpsHeroes Parma 2016
Elfo ed Engage IT Services sono orgogliose di presentarvi il DevOpsHeroes 2016, il primo evento a Parma che si occupa dell’argomento DevOps. Questa è diventata una buzzword molto spesso utilizzata anche a sproposito. Ed è proprio per questo che l’evento vuole chiarire il più possibile quanto importanti siano le attività che stanno sotto a questo termine e quanto esse siano fondamentali ogni giorno per il nostro lavoro. 
Avremo Damian Brady (Visual Studio MVP, Solution Architect di Octopus Deploy) e forse, se tutto va come deve, una bella sorpresa da Microsoft Corp. Entrambi gli ospiti saranno live durante l’evento ed avremo la possibilità di intervistarli in diretta.
Il sito dell’evento è qui e la call for paper è già aperta, mandate le vostre proposte qui. L’evento si terrà il 29 di ottobre, sempre di sabato.
L’hashtag è #DevOpsHeroes e la schedule completa sarà pronta per i primi di settembre.
Un ringraziamento..
Ringrazio tutti coloro che mi hanno aiutato come al solito, sia per il SQL Saturday che per il DevOpsHeroes. In primis, Elfo, che ha organizzato con noi l’evento DevOps e sponsorizzato il SQL Saturday per la seconda volta. Daniela, che come sempre ci ha seguito per tutto il materiale di design e stampa, ideando anche il font per il logo del nuovo evento. Gabriele e Livia per la comunicazione e Mike, che mi supporta sempre sia durante l’evento sia per la parte di catering.
Come non ringraziare poi le community? GetLatestVersion non manca mai e da quest’anno abbiamo anche DotDotNet
E adesso tocca a voi
Ora non vi resta che caricare le vostre proposte e partecipare ad entrambi gli eventi, per passare un paio di giorni insieme e per condividere esperienze.
Stay Tuned! 

Agile@School – settima puntata del 11/06/2016

Nel precedente post abbiamo parlato di come il fallimento dello sprint ci ha colti. Ma avevamo anche sottolineato l’importanza di trovarsi in queste situazioni per capire come riprendersi e come raggiungere gli obbiettivi, con un nuovo spirito. Ed effettivamente è successo proprio tutto quanto ci aspettavamo Gabriele ed io. Nonostante gli sforzi impiegati per supportare le ultime implementazioni, possiamo dire che l’applicazione funziona e ha tutte le funzionalità pronte per essere valutate in sede di esame.

Vi presentiamo Students’ Yearbook!
L’ultimo incontro è stato più che altro un “debriefing” da una parte, ed una preparazione all’esame dall’altra.
Fase di “debriefing”
In questa fase abbiamo fatto nuovamente una review tecnica e funzionale dell’applicazione, questa volta utilizzandola pubblicata online. Già ad una prima occhiata è chiaro che i ragazzi sono riusciti anche ad utilizzare bootstrap nell’applicazione. E, per chi come chi li ha seguiti, ha visto la precedente versione, questa è una versione decisamente più gradevole. La review ha dato ottimi risultati sul piano dell’entusiasmo, seppure sia un momento decisamente complesso per gli studenti. Non dimentichiamo che manca un mesetto all’esame. 
Facendo un riassunto:
  – abbiamo valutato l’applicazione come “pronta per essere presentata”
  – abbiamo confermato il logo, totalmente studiato dai ragazzi
  – abbiamo valutato lo sprint e i comportamenti in relazione alle cerimonie e alle abitudini del team
  – abbiamo parlato di quanto fatto a mo’ di retrospettiva
  – abbiamo infine consegnato gli attestati di partecipazione al progetto (firmato anche dalla Preside)
La professoressa Pedullà ha creato l’attestato che segue e ha premiato i ragazzi per l’impegno e per la riuscita del progetto.
Come potete notare dalla firma della Preside, sembra proprio che il progetto avrà un seguito in questa scuola. E la cosa mi rende molto orgoglioso e felice allo stesso tempo.
Fase di preparazione all’esame
Questa è stata una parte impegnativa, che in realtà non ha proprio a che fare con il progetto in sé. Ho preparato un set di sette percorsi che i ragazzi possano seguire durante l’orale. Dopo aver tenuto le prime due “lezioni” sul glossario e sull’importanza di un vocabolario comune, nell’ottica della trasparenza, ho deciso di suddividere la proposta in due parti, una più accademica ed una più tecnica. Inoltre, ho deciso di separare ulteriormente gli insiemi in più generico (vedi agile manifesto) e più orientato a scrum. Insomma, ho pensato a:
  – percorso 1 – Agile manifesto e principi
  – percorso 2 – Scrum, glossario termini generale e ruoli
  – percorso 3 – Sprint, glossario termini e cerimonie
  – percorso 4 – Agile gamification (http://www.agilegamification.org)
  – percorso 5 – Documentazione del progetto (manuale utente e presentazione commerciale)
  – percorso 6 – Descrizione tecnica dell’applicazione (manuale tecnico e riferimenti tecnologici)
  – percorso 7 – Approfondimento su Visual Studio Team Services
I primi tre sono orientati ai principi, alle metriche, ai termini e alle cerimonie tipiche dello scrum e dell’agile in generale. Il quarto è molto particolare e viene definito come “l’utilizzo di meccaniche di gioco in contesti non di gioco, in modo da coinvolgere gli utenti nella risoluzione dei problemi e da guidarli per ottenere i comportamenti desiderati”. Si tratta di una pratica che rende stimolante il coinvolgimento dei membri del team in contesti non ludici tramite l’ausilio di giochi che allenino le persone a capire il vero teamwork.
Il quinto ed il sesto argomento sono orientati all’applicazione, alla documentazione allegata e ai risultati ottenuti tramite essa. Il settimo vuole aiutare chi è più tecnico e chi vuole parlare dello strumento che abbiamo utilizzato per gestire il progetto.
Su sette studenti, tre hanno scelto la parte accademica, in modo da poter sfruttare la cosa anche per l’interrogazione di inglese. Uno di loro porterà le definizioni interamente in inglese, così come il resto del suo orale. Gli altri ragazzi si sono divisi le documentazioni tecniche e funzionali, ma purtroppo nessuno ha scelgo la gamification, che personalmente trovo interessantissima.
Il risultato è più che soddisfacente, insomma.
Ed ora, un grosso in bocca al lupo ai giovani maturandi!
Stay Tuned! 

Agile@School – sesta puntata del 14/05/2016

Finalmente, i problemi sono arrivati.

Non sarebbe stato normale avere un progetto senza intoppi, anche se i ragazzi hanno sempre assunto un buon comportamento, sia per quello che riguarda le metriche, sia per il lavoro svolto. Non è da sottovalutare la particolarità del momento. La necessità di prepararsi alle prove che hanno in questo momento dell’anno scolastico, le varie simulazioni e la preparazione del materiale d’esame possono portare anche ad una perdita di focus generale.
I ragazzi non sono a tempo pieno su Agile@School, quindi le loro priorità possono essere spesso variabili.
Però, un impegno è un impegno, e poi, per molti di loro, Agile@School diventa anche il materiale che servirà loro nelle giornate di esposizione orale all’esame. Quindi, una correzione, dopo questo sprint “in calo” era d’obbligo, sia da parte dello Scrum Master, sia da parte del sottoscritto, in qualità di coach, e quindi, di riferimento principale, soprattutto sul comportamento di crescita necessario del team. E non siamo stati molto “morbidi”, proprio per far capire l’importanza del lavoro che stiamo facendo tutti.
Oggi non è stata una giornata felice per nessuno di noi, perché sono emersi i primi fallimenti. Ma senza questo punto di incontro di certo non si sarebbe raggiunta nemmeno l’ondata di ottimismo successiva, e nessuno avrebbe ripreso la “voglia di ripartire” per rimediare. 
Ma perché dopo cinque incontri così positivi, ora parliamo di fallimenti? 
Perché tramite essi ripartiremo e chiuderemo tutto alla grande, perché ho una grande fiducia in chi mi aiuta (la prof e Gabriele) e in chi sta lavorando per cogliere il valore aggiunto che questo progetto dà. Probabilmente, parte dei problemi è fisiologico, per i motivi di cui sopra e per una flessione normale che si ha nei processi di migrazione culturale. E non è tutta colpa di chi ha lavorato sul software. A volte, anche noi “dall’alto” sbagliamo, e sta a noi risolvere tali situazioni di stallo.
Quali sono stati i fallimenti?
Se vi ricordate, nel precedente post, abbiamo parlato di come presentare il lavoro, motivo per cui parte del team si è concentrato a creare presentazioni di business, manuali utente e tecnici. Nella fattispecie, abbiamo affrontato i seguenti topic:

– Testing

– User’s manual

– Technical documentation

– Business presentation (vorrei far capire l’importanza di presentare bene un progetto)

– Grafica e design (logo, colori, temi, brand, ecc.)

Testing
Il primo punto è quello che, purtroppo come spesso accade, ha fatto emergere maggiormente la scarsa qualità del lavoro in termini di funzionalità. Il distacco maggiore si è verificato soprattutto tra gli Acceptance Criteria e l’effettiva implementazione. Il 90% della frustrazione sta qui. I test sono falliti tutti, o quasi, e i bug creati sono proprio tanti. Il motivo? si sono letti con poca attenzione di PBI e i criteri. Come mai? Ragazzi non abituati a farlo, semplice. Problema di facile risoluzione.
Comunicazione interna al team
Nonostante la stesura di un manuale tecnico, di un manuale utente e di una presentazione di business siano tra loro collegati da un punto di vista di immagine (logo, colori, brand, temi, ecc.) nessuno, all’interno del team, si è posto il problema di condividere in un solo momento gli stili, l’idea di grafica di insieme. Risultato? Tanti contenuti un po’ disordinati e poca uniformità nella presentazione. Il motivo? Stiamo parlando di due classi quinte differenti, che hanno avuto la possibilità di collaborare fisicamente nello stesso posto insieme troppo poco tempo. Come mai? Si è lavorato solo a scuola. Anche questo è un problema di facile risoluzione, investendo tempo insieme (anche online) al di fuori delle ore in classe.
Comunicazione con il team
Abbiamo slack, un toccasana per il lavoro in collaborazione. Eppure, sembra non essere utilizzato o, quanto meno, capito. Il motivo? Nonostante questi ragazzi siano sempre sullo smartphone, hanno percepito slack come un tool “da computer” e non si sono (alcuni) nemmeno posti il problema di cercare l’app sul proprio cellulare. Strano, ma vero. Alcuni ragazzi propongono watsapp, ma è troppo dispersivo. Chi ha usato slack bene in questi ultimi tempi, convincerà ed allineerà i “ritardatari”. Problema quasi risolto, ma la correzione è stata necessaria.
Utilizzo dello strumento
Risulta tangibile il calo di attenzione sulla gestione dei task su Visual Studio Team Services. Stati errati, comunicazioni del progresso del lavoro frammentate. Il motivo? non è stato percepito a fondo il vero valore aggiunto di un software di team working. Come mai? maturità dei ragazzi, inesperienza, errori da parte del sottoscritto (sottovalutazioni). Il problema è da risolvere, ma probabilmente gli esempi più concreti fatti in questo incontro, potrebbero aver aperto gli occhi agli studenti. Ho preferito spiegare cosa succede pragmaticamente a tutti se non si usasse. Speriamo si possa definire almeno parzialmente risolto. Queste dinamiche non sono semplici da implementare nella mente di uno studente così giovane.
Conclusioni
Ad una prima lettura, si può pensare che sia tutto andato male. Al contrario, vedo tante cose positive. Ad esempio, il fatto che un processo di test sia già attivo, proprio QA, con tanto di test case, che si basano su user story scritte a puntino. In quanti possono dire di avere realmente processi ripetuti o team dedicati alla QA o anche solo momenti di test funzionale approfondito? In quanti investono sui processi che migliorino la qualità? E parlo di aziende, non solo di scuola.
Ma non è solo questo, è stato utilizzato uno strumento per la collaborazione (Slack) fin dall’inizio. E ogni lavoro è gestito da canali, da pin di elementi importanti, da video condivisi e da integrazioni con software esterni (wunderlist, dropbox, ecc.).
Ed infine, certo, ci sono problemi nel capire realmente l’utilità della gestione del lavoro con VSTS, ma esso è presente in tutta la scuola, sia per la parte di controllo del codice sorgente, sia per la gestione (da questo progetto in avanti) del teamworking.
Insomma, quello che voglio dire è che i problemi su processi esistenti sono risolvibili, mentre se un processo manca, si è in alto mare. Per questo confermo la mia visione. Finalmente abbiamo avuto problemi, che risolveremo e che ci daranno nuovi stimoli, per ripartire spediti verso l’esame!
Chiudo con una frase emblematica sul fallimento, di Michael Jordan: “I’ve missed more than 9000 shots in my career. I’ve lost almost 300 games. 26 times, I’ve been trusted to take the game winning shot and missed. I’ve failed over and over and over again in my life. And that is why I succeed.
Stay tuned! 

Agile@School – quinta puntata del 16/04/2016

E’ arrivato il momento di vedere il software prodotto, almeno durante l’incontro, purtroppo non possiamo ancora mostrare il tool in questo blog.
L’applicazione web su cui stanno lavorando i ragazzi sta arrivando verso la fine degli sviluppi. Non è così bella da vedere, è molto “developer” ma, da questo sprint, penseremo a come applicare cambiamenti grafici per renderlo gradevole alla commissione di esame.
Ad ogni modo, la review che abbiamo fatto è stata molto interessante. Tutto, o quasi, era funzionante, e l’umore era alto, come si può notare anche da questa foto:


Davide (il ragazzo in piedi davanti alla lavagna) è in posa, lo ammetto. Ma credetemi che l’umore è alto!

Come dicevamo, il software gira, la classe ha scovato ed aggiunto al backlog un paio di importanti bug che verranno presi in carico probabilmente nel prossimo sprint. Purtroppo questi bug sono emersi solo durante la review, il che mostra che il team non ha fatto sufficienti prove durante lo sviluppo o nella fase di test (che forse è proprio mancata). Per mancanza di tempo, purtroppo, non potremo insegnare ai ragazzi l’automazione dei test, e quindi non potremo nemmeno accennare in generale il concetto di integrazione continua, ma ci sta, almeno per ora. Di certo è materiale da retrospettiva.

Alla fine della review, abbiamo affrontato la prima retrospettiva tramite il diagramma Starfish:

This particular retrospective technique helps people by getting them to reflect on varying degrees of things that they want to bring up, without having it fit into the black or white category of ‘What Went Well’ or ‘Not So Well’ so I think it scales a little bit better

Ed ecco il risultato


Gli elementi sono:

– Start ognuno deve fare il suo changeset ed associarlo al task
– Start commentare il codice
– Start aggiungere documentazione tecnica e funzionale
– Start test funzionali
– More Of upload e pin dei media su slack
– More Of più punto di contatto tra le classi (i ragazzi fanno parte di due classi diverse)
– More Of utilizzo di slack, è comodo
– Less Of lavoro non notificato agli altri
– Stop fare eccessivo rumore con @here e @channel su slack (allertano tutti praticamente)
– Keep Doing canali basati su PBI di VSTS

Gli studenti vedranno l’importanza di questo meeting in qualche giorno, quando i problemi si risolveranno grazie alle azioni intraprese ai fini di non ridurre la produttività del team.
Nel prossimo sprint (che stiamo disegnando) andremo a gestire i seguenti nuovi “tipi” di attività:

Testing
User’s manual
Technical documentation
Business presentation (vorrei far capire l’importanza di presentare bene un progetto)
Grafica e design (logo, colori, temi, brand, ecc.)
Stay Tuned!