Author Archives: Alessandro Alpi

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! 

Agile@School – quarta puntata del 18/03/2016

Lo sprint 2 è stato completato con successo. Questa è stata un’ottima notizia, e quando ho sentito la frase pronunciata dai ragazzi ho provato una sensazione di benessere che non mi aspettavo. Certo, abbiamo sbagliato qualcosa, ci siamo dimenticati qualche iter o elemento, ma ci sta, siamo in fase di apprendimento, non solo per quello che riguarda la formazione dei ragazzi, ma anche per il progetto in sè. Essendo in fase sperimentale, dobbiamo capire i problemi anche dall’alto e non solo nel team di sviluppo.

Un mese fa ho lasciato i ragazzi con cinque PBI da implementare ed ecco come me li trovo dopo 20 giorni, considerando una capacity molto bassa di ogni sviluppatore:
Grande risultato! Ma non è tutto.. I ragazzi hanno anche associato i changeset ai task ed hanno aggiunto allegati laddove necessario.
E pensare che avevo il sospetto, prima di iniziare, che un progetto del genere potesse fallire. Ho cambiato idea, vedo proattività negli studenti, vedo gli sforzi che fanno e vedo pure quanto si impegnano ad usare gli strumenti. Nel tempo, anche slack è cresciuto. Siamo arrivati ad aggiungere un canale per ogni PBI che si affronta e abbiamo iniziato a “pinnare” media sui canali, anche se poco spesso per ora: 


Gli strumenti sono utilizzati, ma non abbiamo di certo ignorato le cerimonie. Nell’ultimo incontro infatti abbiamo affrontato lo stand up meeting. Per essere sincero non mi aspettavo tanta disciplina ed ordine, quasi meglio dei team di sviluppatori professionisti!

Nel prossimo incontro andremo ad affrontare le cerimonie finali dello sprint. Vedremo come funziona una review, affronteremo una retrospettiva utilizzando il diagramma Starfish (grazie Felice) ed inizieremo ad aggiungere elementi non ancora visti, come la parte di design, di documentazione e di test. Intanto i nostri neo sviluppatori continueranno ad implementare le parti mancanti del progetto “Annuario Studenti”.

Speriamo di poter vedere qualcosa nel prossimo mese, stiamo raggiungendo il giorno dell’esame e dovremo impacchettare il tutto per bene, al meglio delle nostre possibilità.

Stay tuned! 

Agile@School – terza puntata del 04/03/2016

Il progetto Agile@School prosegue, e finalmente siamo entrati nella parte corposa del progetto.

In questo terzo incontro abbiamo utilizzato la sala colorata a mo’ di Google e i tavoli rotondi, più adatti ai planning poker.
Certo, agli occhi degli esterni, potrebbe sembrare un semplice gioco di carte, ma in realtà, per farlo, i ragazzi hanno saltato pure l’intervallo, e sapete quanto è difficile per loro non fare pause!
Gabriele ed io avevamo già pronte tutte le user story, quindi, abbiamo creato il nostro backlog di prodotto, andando a definire l’effort di ogni PBI. Il risultato è questo:
I primi effort sono stati presi insieme a scuola durante le ore di “progetto”, mentre quelli che mancano erano l’esercizio per i ragazzi. Per l’occasione ho preparato le carte da planning poker (un ringraziamento come sempre a Daniela), un mazzo per ogni partecipante:
Una volta impostato il backlog di prodotto, valutando con attenzione le user story, gli acceptance criteria e le personas, abbiamo anche creato il primo sprint backlog, con già i primi backlog items e le capacity di ognuno dei ragazzi:
Il progetto prende sempre più una forma concreta.
E non è tutto, abbiamo creato anche un team in slack, ora, abbiamo il gruppo AgileSchool. 
Una chat collaborativa, con già i canali impostati per la discussione sul progetto, un backlog di prodotto, un backlog di sprint, tutte le figure già pronte.
Ora non resta che andare a verificare lo stato di avanzamento dei lavori, un po’ di coaching per capire lo stato del progetto.
Stay Tuned! 

Agile@School – seconda puntata

Agile@School procede con la sua seconda puntata.

L’ultima volta, abbiamo introdotto il progetto e valutato lo spazio all’interno del quale tutto avrà luogo.
Nel secondo appuntamento, nel quale ho portato con me Gabriele, che studia informatica all’Università di Parma, abbiamo conosciuto con certezza il numero dei partecipanti, che sono ben nove.
L’obbiettivo finale è fare un solo team e affrontare il progetto proposto dai professori di informatica e tecnologia.
Ma andiamo per passo.
Scrum master
Gabriele, il mio aiutante nel progetto, è una figura fondamentale non solo per l’aiuto di supporto, ma soprattutto per avere una persona al di fuori dei processi di project management o di coaching, che possa fare da scrum master, completamente esterno.
Il progetto
Il nome del prodotto che dovremo andare a costruire nei prossimi mesi è “Annuario Ex-Studenti“. Con esso, vogliamo andare a creare una base dati di studenti che hanno frequentato la scuola ed un gestionale relativo di backend. In aggiunta, anche un’applicazione di front end atta alla navigazione del dato, integrabile direttamente sul sito web della scuola stessa.
Il team
Abbiamo detto nove studenti, tra quarte e quinte superiori. Nel prossimo incontro dovremo capire le attitudini e lo skill impiegabile nello sviluppo del progetto. Già ad un primo sguardo, si nota chi ha del gusto e chi invece non vede l’ora di mettere le mani nel codice e nella base dati.
Il prossimo incontro, verosimilmente il 5 Marzo, andremo a sviscerare tutte le user story che sono nate dai requisiti funzionali dettati dai professori che stanno seguendo con noi l’iter. Abbiamo un documento ricco di specifiche e anche i mock grafici, pronti per essere realizzati direttamente sull’interfaccia. Per ogni storia, andremo ad analizzare le Personas in esse indicate, ed infine, andremo a giocare al Planning Poker. Proprio in questi giorni, infatti, stiamo stampando i mazzi di carte per la fase di pianificazione. L’obbiettivo dell’incontro sarà:
– aver inserito ogni user story su VSTS (sotto forma di PBI)
– aver assegnato l’effort dei PBI 
– aver estratto lo sprint backlog
– aver creato le attività (task) per ogni PBI di sprint
– aver determinato team, expertise e capacity
– aver determinato la durata dello sprint e delle cerimonie


E da qui, si comincia a sviluppare!

Stay Tuned!