Author Archives: Alessandro Alpi
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!
DevOps@Work (#DOAW16), manca solo una settimana
Il 5 di febbraio si terrà il DevOps@Work a Roma (#DOAW16) grazie all’impegno di GetLatestVersion.it e DomusDotNet.
Si tratta di una giornata dedicata interamente all’universo DevOps. Due track, tanti speaker di valore nazionale ed internazionale per mostrare lo stato dell’arte della metodologia DevOps.
l’agenda è la seguente:
Come potete notare, gli argomenti saranno tanti, e questa volta riuscirò a parlare di due punti cardine del processo di Continuous Integration su database. Infatti, il ciclo di integrazione continua si basa su: Sviluppo ed invio dei changeset al source control, build automatizzata del database, unit testing e poi eventuale applicazione dei cambiamenti sull’ambiente dedicato al continuo miglioramento (quello utile a mostrare i cambiamenti tra una release e l’altra).
Con le due sessioni proposte, andremo ad approfondire l’integrazione di tool di terze parti e SQL Server Management Studio. Con la prima, capiremo come inviare i changeset al nostro source control manager, come gestire anche i dati statici, come filtrare ed escludere informazioni sul source control manager ed infine come associare item di backlog.
Con la seconda andremo invece a scrivere e ad eseguire test unitari sulle nostre stored procedure, in modo da evitare regressioni e da supportare lo sviluppo evolutivo in ottica di qualità.
A lungo i miei sforzi si sono concentrati su questo argomento, perciò, vedere che l’argomento diventa sempre più importante e richiesto (anche per requisiti di business) mi rende sempre più fiero.
Spero di trovarvi, come sempre, numerosi all’evento!
Mi piacerebbe scambiare due chiacchiere insieme.
Correte ad iscrivervi!
Il 2016 è l’anno di DevOps!
Un altro anno è già terminato ed uno nuovo è ormai iniziato. Frase fatta, vero. Ma questo 2016 porta grandi novità, soprattutto negli eventi che noi di GetLatestVersion.it seguiremo, fin dai primi mesi. Questo sembra essere l’anno di DevOps, un termine ormai utilizzato talmente tanto da essere applicato spesso a sproposito (chiaritevi le idee qui, grazie a Felice Pescatore).
Cosa avremo? Di certo, un febbraio ricco di sessioni.
GetLatestVersion.it e DomusDotNet organizza una giornata dedicata interamente all’universo DevOps. Due track, tanti speaker di valore nazionale ed internazionale per mostrare lo stato dell’arte della metodologia DevOps.
Potete scaricare la locandina qui. Tuttavia, l’agenda è la seguente:
DotNetCampania, in collaborazione con Microsoft Italia, organizza per il prossimo 26 Febbraio una giornata di formazione interamente dedicata al mondo DevOps. Scopriremo insieme ai più famosi esperti italiani sull’argomento, che cos’è DevOps e quale valore aggiunto può dare al ciclo di vita delle nostre applicazioni.
Con un taglio estremamente pratico, vedremo concretamente come la combinazione tra tool e metodologie possano trasformare l’IT in una vero e proprio centro di supporto al Business, automatizzando al massimo la catena di Valore che parte dalla concezione del prodotto e si completa con la sua messa in erogazione.
L’agenda è reperibile a questo link.
Inoltre, noi di GetLatestVersion.it vi porteremo una sorpresa a Roma. Già qualcosa è trapelato su twitter (@agileiotdotorg).
Vi aspettiamo numerosi!
Stay Tuned!
Progetto Agile@School – Introduzione
Sabato scorso ho presentato il progetto Agile@School alla scuola superiore in cui ho studiato per la maturità: l’ITSOS di Fornovo di Taro.
L’istituto, da sempre all’avanguardia per tutto quello che riguarda il mondo dell’informatica, ha anche una materia, tecnologia, per la quale il progetto proposto diventa ancora più importante.
Infatti, i professori che seguono la suddetta materia, affrontano durante l’anno la teoria sulle metodologie di sviluppo e di gestione dei progetti.
Idea
Dopo un paio di anni di riflessioni su come poter aiutare la scuola ad avvicinarsi al mondo del lavoro, nasce Agile@School (mi sono preso una licenza, non credo esista già questo nome), frutto dell’esperienza in campo Agile che mi sono fatto nel tempo, anche con gli utlimi anni da “gestore” di un team. Il progetto ha l’intento di applicare i “giochi” a cui l’Agile si appresta per far conoscere agli studenti la vera essenza del teamwork, unitamente al valore aggiunto che la produzione di software di qualità darà loro ed alla scuola, non solo in termini di progetto aggiuntivo, ma anche di preparazione di argomentazioni da presentare all’esame.
La scuola si presenta molto bene:
L’aula che si vede nelle foto è una sala multimediale, colorata in stile Google, con round table e sedie mobili. Il tutto si può definire già pronto ad accogliere alcune delle cerimonie distintive della metodologia.
Le basi ci sono, anche se dovremo lavorare sodo per applicare i cambiamenti ai pattern e per adattare i tempi alle regole che si dovranno seguire.
L’idea quindi è quella di prendere una decina di ragazzi, tra classi quarte e quinte, per sviluppare un semplice progetto, almeno in prima battuta, al fine di fare rodaggio degli iter e per fare formazione non solo degli alunni, ma anche dei docenti stessi.
Idea generale
La big picture è:
– Scelta di un progetto semplice, tipo “Gestione dell’inventario dei dispositivi informatici scolastici“, oppure “Gestione delle anagrafiche degli studenti e dei *palmares* degli alunni del passato“.
– Scelta di due team da 6/7 persone l’uno (es. 2 di quarda e 2 di quinta)
– Scelta delle specializzazioni e dei team di test (probabilmente i ragazzi di quarta)
– Scelta dei ruoli (A parte il sottoscritto, farò il coach, avremo un Product Owner, nella persona di un professore, ed uno scrum master, come facilitatore, probabilmente un ragazzo che mi aiuterà nel progetto)
– Comprensione degli skill professionali e delle attitudini dei membri del team
– Creazione delle milestone di progetto
– Creazione e popolamento del backlog
– Iterazioni e cerimonie
– Rilasci continui
Una volta che questa idea è consolidata e ben provata nel tempo, il passo successivo prevede l’integrazione di uno sviluppo non solo software, ma sistemistico, ed anche, ambiziosamente, IoT.
Pensiamo infatti ad uno scenario Internet of Things, nel quale uno smart device è implementato come progetto scolastico; nulla vieta di poter adattare ed estendere le metodologie agili su di esso (ricordo @agileiotdotorg 
).
).Feedback
Il feedback degli studenti è stato inaspettato, devo ammetterlo. Alla fine delle mie semplici slide, che ho cercato di tenere ad un livello alto per non tediare troppo i ragazzi, abbiamo fatto una dimostrazione di un daily meeting, con tanto di finto caffè. Cinque ragazzi in cerchio, con un bicchiere immaginario in mano, che parlano tra loro e che rispondono alle fatidiche tre domande. Hanno parlato del loro progetto in essere ed in base all’ultimo giorno passato in laboratorio.
Da coach ho fatto notare loro i problemi, come ad esempio:
– Grafica implementata durante l’implementazione di un bug (perdita di focus)
– Conoscenza di un solo sviluppatore vs progetto chiaro per tutti
– Problemi di collaborazione mancante (chi fa troppo vs chi non aiuta molto).
Alla fine del meeting fac-simile già si respirava aria di valore aggiunto. La dimostrazione di quanto metodo può essere messo anche nelle piccole cose è stata veramente efficace, anche per gli addetti ai lavori. Sia i docenti che i tecnici di laboratorio, infatti, hanno appoggiato appieno l’idea. La scuola non è così lontana dal mondo del lavoro come sembra. E i ragazzi sono interessati.
Strumenti e soluzioni
Come procederemo ora? Come prima cosa, faremo una giornata all’insegna dell’agile, in particolar modo dell’approfondimento dei termini, che dovranno diventare comuni a tutti. In secondo luogo, inizieremo a popolare il backlog di prodotto e decideremo come disegnare le iterazioni e le cerimonie. Utilizzeremo Visual Studio Online, sfrutteremo DreamSpark, così utile per le scuole, e molto probabilmente, scriveremo addirittura .net!
Cosa consiglierò? Lean? Scrum? DaD? Credo proprio che applicheremo un pattern custom, dedicato a questo strano tipo di iterazione. Infatti, non esiste la giornata di lavoro, e quindi l’iterazione può essere applicata solo alle ore di laboratorio, con l’aggiunta delle ore al di fuori dell’orario scolastico. Sarà veramente stimolante reagire a questa realtà.
Ed ora, si comincia, e vi terrò aggiornati.. Questa è solo l’introduzione.
Stay tuned!
Login