Tag: Azure DevOps

Gestire l’on boarding con le wiki di Azure DevOps

Featured

Mai come negli ultimi tempi, ho iniziato a fare analisi riguardanti l’on boarding dei nuovi assunti in azienda. Per noi la parte di ricerca del personale e il conseguente percorso iniziale con il team sono argomenti di massimo interesse. Del resto, il futuro è basato per la maggior parte su come ci si muove fin dai primi istanti.

Devo essere sincero, fin dalla sua nascita, l’azienda è stata fatta sempre e solo di tecnici e, in quanto tali, abbiamo sempre dato molto peso all’approfondimento delle tecnologie e delle pratiche legate al mondo dello sviluppo.

Poi qualcosa è cambiato. Abbiamo iniziato a ragionare in termini davvero people-first, anche per necessità di crescita. Già dopo un paio di anni abbiamo iniziato ad assumere al di fuori di quel contesto costruito praticamente su amicizia e conoscenze comuni. Di recente, poi, è arrivata una crescita del personale del doppio delle unità e da qui la necessità di affrontarelne la selezione ancora più in maniera oculata e precisa.

In ogni punto del ciclo di vita aziendale abbiamo qualcosa definito in wiki.
[…] oggi le wiki sono piuttosto complete anche se, probabilmente per un tempo limitato

Insomma, l’on boarding diventa un momento in cui investire, non solo per chi deve crescere in quell’istante, ma anche per chi deve preparare materiale per il futuro e per chi arriverà. Per noi, il “dove” in cui mettere il sapere è la wiki di Azure DevOps. Una delle nostre principali alleate, tutti i giorni.

Come utilizziamo la wiki

In ogni punto del ciclo di vita aziendale abbiamo qualcosa definito in wiki. L’on boarding é il primo capitolo di uno strumento che accompagnerà i membri dei nostri team ogni giorno. L’elenco delle cose da avere, il nostro welcome kit, è anch’esso su di una pagina wiki che illustra a chi è stato assunto gli strumenti e gli accessi disponibili. Da lì, un “get started” fornisce gli step per creare la propria workstation e avviare la nostra piattaforma, come gira effettivamente in produzione, solo più effimera.

Di certo, ora è semplice a dirsi, l’implementazione degli strumenti descritti, come gli script di automazione del provisioning della sandbox o del database su container, ha richiesto anni di osservazioni e miglioramento continuo. Per cui solo oggi le wiki sono piuttosto complete anche se, probabilmente per un tempo limitato. Tuttavia, quando si entra nel mood del “continuous” è tutto all’ordine del giorno.

Per usufruire di questo vantaggio però, è necessario avere nel DNA aziendale concetti di cambiamento e miglioramento continui

La documentazione dei processi

Documentare un processo aziendale tramite una wiki può essere visto come un costo, soprattutto quando l’azienda cambia non poco spesso. Ma la wiki in sé non può definirsi tale, anche perché si trasforma subito in un ritorno dell’investimento non appena consumata dalle persone che lavorano in azienda. Per usufruire di questo vantaggio però, è necessario avere nel DNA aziendale concetti di cambiamento e miglioramento continui. Se si prevede nelle proprie pipeline di sviluppo una parte di wiki (attenzione, documentazione non di progetto semplicemente, ma di processo e di tutto quanto è il sapere dell’azienda) esso poi, col tempo, entra nel DNA di tutti e anche chi diventa il tutore di chi inizia il percorso con noi passa il modus operandi ai propri adepti, rendendo, di fatto, il procedimento inarrestabile. Uno di quelli di cui non si può più fare a meno.

Un modus operandi alla portata di tutte le realtà

Credo che questa abitudine sia assolutamente alla portata di tutti ma, allo stesso tempo, applicabile dipendentemente da vari fattori.

Partire daccapo ed ereditare situazioni

Per chi ha la fortuna di iniziare qualcosa daccapo, come un progetto o una migrazione culturale, direi che basta iniziare col piede giusto. Chi eredita, invece, situazioni Legacy, non orientate ad un approccio iterativo come vale per DevOps o Agile, potrebbe avere non pochi problemi. Perché comunque si parla di mindset.

Per ottenere risultati da un procedimento di questo tipo è necessario prima abbracciare la cultura del cambiamento e del miglioramento continuo. Se non si è pronti a ciò, il rischio è quello di avere una bella wiki all’inizio, derivante da un progetto dedicato alla sua creazione, e poi trovarsi a definirla obsoleta in poco tempo. Qualcosa di cui fare manutenzione che fa solo perdere tempo e, di conseguenza, che fa perdere fiducia nello strumento, nel suo utilizzo e nella metodologia.

Innestare tutto quanto nel processo di selezione del personale

Avendo una wiki per come fare le interviste e i colloqui, sia per la parte attitudinale sia per la parte tecnica, risulta tutto molto naturale. Gli stati della pratica di assunzione sono su di una board di Azure DevOps, in cui viene seguito il procedimento completo, dalla ricerca, ai colloqui, all’assunzione, alle licenze e fino alla burocrazia. A supporto di questo, gli step indicati sulla wiki alla sezione “hiring”, dedicata ovviamente all parte di assunzione. Come è facile capire, gli strumenti sono a supporto di una radicata cultura orientata all’organizzazione, nell’ottica di ridurre gli sprechi e le perdite di tempo, portando, di fatto, valore aggiunto tramite ogni cosa che si fa. O almeno ci si prova.

Crescita professionale e futuro della persona

Anche per questo abbiamo, guarda caso, wiki che descrivono come la persona verrà accompagnata e come pian piano, o meglio, nei tempi che il “tutore” decide essere consoni, crescerà. Proprio adesso stiamo lavorando ad una sezione in cui si gestisce parte del mantenimento del rapporto, la crescita professionale in generale e le posizioni aperte in azienda, tramite un organigramma che mostra cosa manca e cosa abbiamo. Personalmente, tengo allineate wiki private su progetti dedicati nelle quali vi sono i punti salienti dei nostri one-to-one trimestrali. Come viene fatto un incontro one-to-one è ovviamente descritto in wiki, tanto per cambiare.

Conclusioni e suggerimenti

Come per ogni cosa che metta in relazione uno strumento con un modo di procedere più culturale, è fondamentale che si parta dalla cultura, appunto, e che lo strumento sia un efficace supporto. Consiglio di cercare strumenti per fare wiki che siano vestiti sui vostri processi, in modo da evitare inutili sprechi di tempo. Considerate che ci sono voluti anni nella nostra realtà, che praticamente è nata su pilastri DevOps e Agili.
Inoltre, la wiki non deve essere un trattato approfondito di tutto lo scibile aziendale. Preferite la formula “bullet point”, quindi liste, piuttosto che scrivere paragrafi infiniti. E preferite che tutti possano proattivamente metterci le mani, in fondo è l’approccio giusto.
Legato anche al punto precedente, una wiki non dovrebbe essere una perdita di tempo. Se passate più tempo a gestirla significa che qualcosa non è corretto. Più cose non salienti scriverete, più cose potenzialmente cambieranno e quindi dovranno essere verificate e modificate. Va dosato il rapporto costi/benefici.
Infine, una volta entrati nel mood, valutare anche di usare non solo le wiki per documentare processi, ma anche quelle di codice, per sfruttare i repository al meglio, come vale per i repo GitHub. Con Azure DevOps questo è praticamente naturale.

Insomma, le wiki possono essere viste come un potentissimo strumento a supporto dell’organizzazione aziendale, anche per dare un’immagine della propria realtà in totale trasparenza e in accordo con il lavoro di tutti i membri dei team e dei dipartimenti. Una vera alleata.

Agile@School 2022 – Final Boss!

di Pier-Paolo Mammi.

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

La sfida

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

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

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

Ready? Fight!

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

Tutti Unity – Ein

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

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

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

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

AppeninTech – The IRA Tale

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

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

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

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

Anonymous – Skyrish Adventure

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

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

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

What-A-Kingdom

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

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

Conclusioni

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

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

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

In definitiva, complimenti davvero a tutta la classe!

Agile@School 2022 – Episodio 1

Testo di Pier-Paolo.

Benvenuti al settimo appuntamento col nostro amato progetto Agile@School, questa volta con una grossa “novità”: le lezioni in presenza! 😁 Ebbene sì, nonostante ricadute e limitazioni, quest’anno ci è stata data la facoltà di effettuare le nostre lezioni di persona. Nonostante la precedente esperienza in full remote sia stata positiva e avessimo possibilità di scegliere in che modo condurre l’attuale, abbiamo deciso di essere presenti in aula su consiglio del professor Memoli, che ci seguirà nel progetto. E in retrospettiva devo dire che abbiamo fatto proprio bene, ma di questo parleremo in seguito.

Il progetto

Visto il successo dell’anno scorso, abbiamo voluto riproporre il progetto di un videogioco che riproduca la logica di un libro-game, quindi una storia con un protagonista che, a seconda delle azioni eseguite dal giocatore, “vivrà” diverse esperienze fino ad arrivare (si spera) ad un lieto fine. Di nuovo, abbiamo proposto alcune linee guida, come avere una “barra di salute” del personaggio, per dare un po’ di confini alla fantasia sfrenata dei team. Tuttavia, non è servito a molto, poiché i giochi proposti presentano molte particolarità degne di titoli di grosso calibro!

I ragazzi non dovranno però soltanto creare un videogioco, ma, come fosse un “vero” progetto aziendale, dovranno utilizzare gli stessi strumenti che noi stessi adoperiamo sul lavoro, come Microsoft Azure DevOps e Git. Dovranno creare la documentazione tecnica e funzionale del progetto e anche una presentazione in stile marketing, come se dovessero proporre il progetto ad un vero e proprio cliente. Ah, naturalmente il gioco dovrà essere funzionante!

Ma bando alle ciance e presentiamo i team e i rispettivi progetti.

I team e i loro giochi

Una premessa é d’obbligo: abbiamo chiesto ai team di individuare al loro interno alcune figure ritrovabili anche in un tipico contesto aziendale:

  • un tech lead, che seguirà l’andamento dello sviluppo dal punto di vista tecnico
  • un coordinatore, che gestirà il team e le attività
  • un creativo, che si occuperà della presentazione e della parte artistica
  • ovviamente, gli sviluppatori!

Anonymous: la storia ideata dal team è ambientata in Irlanda, in un’epoca medioevale. Il giocatore dovrà impersonare un cavaliere la cui missione è salvare la principessa: lungo la strada il protagonista incontrerà molti personaggi che gli saranno di aiuto o di ostacolo, e potrà trovare ed equipaggiare una serie di oggetti più o meno magici per facilitare la sua missione. Il gioco verrà creato sotto forma di applicazione web e grafica in pixel art a partire da disegni a mano.

AppenninTech: torniamo in Irlanda, ma stavolta il gioco segue le vicissitudini di un giornalista irlandese ai tempi dell’IRA. Il protagonista dovrà infiltrarsi nel loro gruppo per scrivere l’articolo che gli frutterà il Nobel, ma dovrà stare attento a non farsi scoprire e a gestire le sue risorse per sopravvivere nella vita di tutti i giorni. La trama sarà inoltre costellata di eventi generati casualmente che potranno volgere a favore (oppure no!) del giocatore. Il videogioco utilizzerà Unity per la parte grafica e audio.

Tutti Unity: il gioco presenta un’ambientazione distopica e interessante. La Germania nazista crea dieci cloni di Hitler per vincere la guerra ma, dopo la loro disfatta, decide di eliminarli tutti: ne sopravvivrà uno solo (di nome Ein, “uno” in tedesco) che dovrà cercare di sfuggire ai suoi inseguitori e, contemporaneamente, decidere se seguire l’esempio del dittatore o se dare ascolto al suo lato buono. Interessante la funzionalità dell’allineamento morale vista in giochi tripla-A. Bellissimi anche i personaggi in pixel art!

What-A-Kingdom: l’idea del libro-game qui si è evoluta molto in fretta, diventando nella pratica un vero e proprio gestionale in cui il giocatore, impersonando il re di un regno medioevale, dovrà prendere decisioni in merito ad alleanze, risorse e conflitti, per assicurare ai suoi sudditi sicurezza e prosperità. Da evidenziare la cura nella caratterizzazione e nell’alberatura delle scelte dei molti personaggi che troveremo nel gioco. La grafica sarà realizzata interamente con l’ultima versione di Unreal Engine.

L’organizzazione

Come dicevamo in precedenza, abbiamo voluto dare un’impronta “aziendale” al progetto, il cui delivery plan è stato suddiviso in tre sprint. Abbiamo chiesto ai ragazzi di portare avanti il lavoro proprio come se stessero lavorando in un’azienda in cui si portano avanti i paradigmi di Agile Development e DevOps. Rispetto ad altre volte il nostro compito è stato facilitato, in quanto il professore aveva già improntato le attività dei ragazzi secondo la metodologia Scrum e aveva già insegnato loro l’utilizzo di Git per il versionamento del codice. Nel primo sprint abbiamo quindi potuto soprassedere sulle basi e andare dritto al sodo, mostrando alla classe quali sono le parti più “insidiose” del lavoro (che per noi è pane di tutti i giorni), come la suddivisione delle attività in features, il concetto di deliverable e l’organizzazione del lavoro di gruppo.

Fine dello Sprint 1

Il primo sprint si è concluso in maniera soddisfacente e tutti i gruppi hanno consegnato qualcosa di tangibile. Alcuni hanno lasciato più indietro la parte tecnica favorendo invece la presentazione del gioco e la parte grafica e di contenuti. Altri sono invece riusciti a mostrare parti funzionanti del software, come i menu di gioco e le funzioni di caricamento e salvataggio partita o i controlli del personaggio.

In generale, sono rimasto molto colpito dai team: non mi aspettavo una tale capacità di organizzarsi a livello di squadra e di attività, vista la relativa inesperienza nell’utilizzo degli strumenti aziendali, e una tale intraprendenza (e fantasia) nel presentare e portare avanti i loro progetti. Alla seconda lezione uno dei gruppi ha addirittura realizzato un piccolo slideshow con tanto di infografica in cui si presentava il progetto, le sue particolarità e la composizione del team, davvero di buon livello!

Chiaramente questa potrebbe essere un’arma a doppio taglio, perché ora ci aspettiamo davvero tanto dai ragazzi nei prossimi sprint!

Restate in linea per sapere come proseguirà il progetto.

Agile@School 2021 – La serie completa

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

Agile@School – Giornata conclusiva

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

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

Presentazione dei progetti

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

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

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

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

Fine della corsa

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

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

Agile@School – Anno sesto

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

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

Il cosa

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

Il come

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

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

Gli strumenti

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

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

I team

I ragazzi hanno già scelto i nomi dei team:

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

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

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

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

Stay Tuned!

Agile@School – Anno quinto, ep. 8

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

Esaminare il file README e le grafiche delle applicazioni

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

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

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

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

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

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

Tirando le somme

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

Conclusioni

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

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

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

Stay tuned per il prossimo anno…

Agile@School – Anno quinto, ep. 7

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

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

Uso scorretto degli strumenti e disorganizzazione

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

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

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

Torniamo alla teoria: la documentazione

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

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

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

Conclusioni

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

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

Agile@School – anno quinto, ep. 6

Siamo arrivati al sesto incontro con i ragazzi. La quarantena non ci lascia tregua ma noi siamo più tenaci e non molliamo di certo! Ormai l’incontro su Microsoft Teams è consolidato e sarà il fatto che è ora di colazione o che ci troviamo tutti “insieme” ma a casa, insomma, ci si sente quasi in famiglia.

Ma bando alle ciance, perché oggi tocca al branching su Git, pratica molto utile e consigliata nell’utilizzo quotidiano, ma allo stesso tempo complessa e insidiosa.

[…] il branching risulta essenziale per poter testare l’efficienza di implementazioni differenti o per realizzare dei proof-of-concept in corso d’opera.

Chi sviluppa conosce bene il tema, essendo vita di tutti i giorni. Tuttavia, in certi frangenti, è necessario chiedere aiuto alla documentazione o a chi può esserci di aiuto. Per questo motivo Pier-Paolo, con tanta pazienza, ha preferito mantenere un livello di applicazione piuttosto semplice, portando esempi pratici tratti dalla nostra esperienza lavorativa aziendale, per meglio dimostrare ai ragazzi la reale utilità di questo strumento.

Il branching, il nostro miglior alleato

I vantaggi del branching non si limitano al fatto di poter sviluppare funzionalità differenti in parallelo o da sviluppatori differenti. Infatti, risulta essenziale per poter testare l’efficienza di implementazioni differenti o per realizzare dei proof-of-concept in corso d’opera. Pier-Paolo ha inoltre evidenziato l’eventualità, in realtà fin troppo frequente, del verificarsi di conflitti nel codice al momento del merge dei vari branch su quello principale di sviluppo. E cosa ha deciso di far provare ai ragazzi?

The “git flow” branching model
gitflow, esempio di branching su git

Reazioni dei ragazzi ai primi conflitti

Il caso più semplice che abbiamo sottoposto ai ragazzi si verifica quando due o più sviluppatori modificano il medesimo file in punti differenti. Ma siamo arrivati al caso più critico, quello di un file modificato nello stesso punto. Abbiamo seguito insieme i passi necessari per risolvere i conflitti tramite SmartGit e la condivisione dello schermo (vedi smart learning).

La lezione è stata davvero impegnativa, ma i ragazzi sembrano aver seguito con attenzione e compreso bene, reagendo con prontezza grazie anche alle indicazioni degli strumenti ai quali sono abituati.

Durante la prossima lezione vedremo molto probabilmente qualche risultato tangibile in termini di prodotto. Di certo parleremo di documentazione funzionale destinata all’utente finale, aspetto spesso tralasciato in favore della realizzazione tecnica del software.

Continuate a seguirci, l’esperimento delle lezioni online sta procedendo a gonfie vele e ormai manca poco a vederne i risultati finali.

Stay Tuned!

DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 02 – build

In a previous post, we’ve described the “from scratch” approach on the development side. When everything works well there, a push (or check-in) triggers the build engine. We must deal with two SQL Server instances (SSIS Servers hereafter), with an environment for each of them:

The build pipeline

The SSIS Servers keep Vertica‘s test and production mappings as well as test and production connection strings for the SQL Server databases. So we need the right variable mapping for all the scenarios, but this is not in the scope of the post, we will speak about it in the next posts. Anyways, here is how the build pipeline works:

Our build process

You may notice that the task “Copy vertica deploy scripts” is disabled. Well, to be honest, right now we’re waiting for the target integration environment.

Build process explained

In the beginning, the build server gets the source files from the repository and creates the target artifacts folder with a Powershell script. This will be the path from which we will push the artifacts to the release pipeline.

The build server generates the .ispac file for the SQL Server Integration Services packages using the dedicated task. The copy tasks will be executed:

As you can see, we’ve got a set of utilities and transformation tools, that will be executed in the release pipeline as well as the environment script. This one contains the SSISDB variables mapping and the SSIS Project configurations statements. Misc files, .sql files for environments and the .ispac file will be copied to the target artifacts folder.

The tasks above copy our template of the .nuspec file to generate the NuGet file (NuGet pack step). This is what we get using NuGet:

Then, we’re ready to publish the files to the release pipeline. We will see how the release pipeline works in the next posts.

Ehm… you miss Vertica

Yes, you’re right. But, it’ll be just a copy of .sql files to the artifacts folder. We will see how the release manager will execute them, so…

Stay tuned!