Tag: Team working

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 – Episodio 2

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

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

I progressi

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

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

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

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

Le domande

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

Il cerchio che si chiude

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

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

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

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

Agile@School 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.

Passo dopo passo, quanto si impara

Sono passati tre mesi dall’inizio della crescita aziendale “di massa”, se così vogliamo chiamarla. Quante cose sono cambiate, e quante ancora subiranno variazioni. Avevo una paura folle, mentre ora vedo che é sempre più possibile riuscire nell’intento di crescere in maniera sana, controllata e, soprattutto, mantenendo una certa qualità su quanto é fondamentale per noi: le persone, il rapporto vita/lavoro, la qualità del lavoro, il rispetto reciproco, il team.

Definitele una serie di frasi fatte o stereotipi utili a descrivere “quanto siamo bravi”, ma vi assicuro che non é così. E non lo è per vari motivi:
– siamo una grande azienda? No, per niente, ed eravamo piccini come la maggior parte delle aziende italiane
– siamo leader di mercato? Affatto! Anzi, stiamo lottando per cercare di posizionarci
– abbiamo solo i migliori talenti? Suvvia, e cosa vorrebbe dire? No, abbiamo persone proattive, curiose, che hanno continui conflitti per crescere, anche nei miei confronti (per fortuna).

vogliamo che le persone parlino tra loro, che crescano insieme e che coltivino l’interesse per topic anche non necessariamente in uso o orientati al business

Siamo un’azienda come le altre ma, forse, una differenza c’è. L’investimento enorme (e lo sottolineo) nella selezione del personale, nella crescita professionale di ogni persona, nell’ascolto delle proposte e nell’incitamento all’aiuto, se così vogliamo definirlo “bottom-up”. Vi faccio però una serie di esempi pragmatici per dirvi cosa intendo, perché altrimenti sembra tutto “campato in aria”.

Scalabilità

Dopo la crescita cospicua, serve scalare. Avremo a breve team verticali, purtroppo un po’ isolati tra loro. Ebbene, la nostra prima preoccupazione é stata quella di creare incontri trasversali (workshop, sessioni, ecc.) al fine di non far perdere i contatti tra le persone. Ma non solo, i contenuti erogati saranno proposti da chiunque, su qualunque argomento, da “come fare le presentazioni” a “cos’è React”. L’obbiettivo poi sarà quello di incentivare tutti a parlare e, perché no, a premiare le proposte con un programma di premi interni come corsi, libri, ecc.

Credo che il messaggio sia forte: vogliamo che le persone parlino tra loro, che crescano insieme e che coltivino l’interesse per topic anche non necessariamente in uso o orientati al business, purché possano essere di interesse e spunto di chiacchierate comuni. Ore perse? Non direi. Sono di qualità inestimabile.

Escalation engineers

Dal momento in cui ogni problema cliente, via ticket, arrivava fino a poco tempo fa agli sviluppatori, già impegnati in altri progetti, é nato un team dedicato alla risoluzione di tali problematiche. Il team ha la possibilità di fare proposte quando la problematica é ricorrente, sul backlog di progetto, per poter evitare spreco di tempo, andando anche a definire come essa potrebbe apparire, ad esempio, su un client. Per noi gli item di “proposal” stanno diventando sempre più importanti, perché chi é in prima linea sa bene come il cliente usa il prodotto e sa quello che serve. Ma non solo, gli escalation engineers sono la rampa di lancio per i nuovi arrivi, che grazie a ruoli di triage, primo intervento e testing (sì, fanno anche QA, la parte manuale) conoscono sempre di più quanto facciamo in azienda. E l’onboarding diventa sempre più completo. Anche questo dimostra quanto la persona sia centrale, perché non é semplicemente buttato nella mischia, ma é accompagnato in un processo di crescita, tra l’altro seguito da senior, con l’obbiettivo di capire come proseguire il suo cammino professionale in azienda.

A ognuno ciò che più piace

Di recente abbiamo assunto un ragazzo come backend developer. É alle prime armi tutt’ora, ma, chiacchierando in uno dei miei ricorrenti 1 to 1, é emersa la sua voglia di guardare il frontend. Inutile dire che a breve intraprenderà la strada della formazione e onboarding per la parte client web. Certo, lo possiamo fare perché abbiamo le persone, non posso nascondere questo grande vantaggio, però anche chi è appena arrivato è stato ascoltato. L’azienda aveva le possibilità di ragionarci, ed eccoci qui, a far fare ad una persona quello che davvero, sotto sotto, preferisce. É un win-win, non c’è dubbio.

Annosi problemi ed esercitazioni

Proprio qualche giorno fa abbiamo avuto un serio problema: un nostro collega, al primo turno di reperibilità nel fine settimana, si è trovato malissimo con strumenti e documentazione. Inoltre, durante la gestione dell’urgenza, non è stato allineato a dovere, il che lo ha fatto sentire impotente e completamente a bocca asciutta per il futuro. Questo, per noi, è un enorme ostacolo. Il lunedì successivo si è parlato immediatamente di come mitigare e poi risolvere questo tipo di problemi, grazie soprattutto alla proattività di Roberto che, dall’alto della sua esperienza e umiltà, ha dato una serie di feedback tra i più importanti degli ultimi anni. La nostra reazione è stata quella di creare una card ad alta priorità (massima, per la verità) sulla quale abbiamo già descritto le possibili soluzioni, una delle quali è quella di effettuare ripetute esercitazioni per ridurre la frizione che le problematiche potrebbero dare a chi dovrà affrontare il supporto tecnico nel weekend. Ancora una volta, orientati a migliorare il futuro di tutti, non solo in ottica di qualità e di risposta pronta al cliente.

Conclusioni

Ripeto, siamo grandi? Siamo i migliori? Siamo alla ricerca solo di talenti? Siamo speciali? No. Siamo però persone che si impegnano a migliorare il lavoro di tutti i giorni e le condizioni di ognuno di noi. Da lì poi, tutto é in discesa.

Abbiamo problemi? Eccome! E ancora sono enormi, non vi faccio gli esempi o “facciamo notte”,  ma se l’atteggiamento é quello descritto sopra, credo che la maggior parte possano essere risolti con buona probabilità. Vedremo cosa ci riserverà il futuro, per ora proseguiamo così.

Questi ultimi tre mesi sono stati molto costruttivi per l’azienda, per noi tutti e per me, grazie anche al lavoro sinergico che sto seguendo con Michele. Stiamo raddrizzando molte cose e il suo lavoro è preziosissimo.

La nostra battaglia più dura

Sono passati mesi dall’inizio della missione ristrutturazione aziendale e ormai si vede bene la fine dell’anno. Negli ultimi tempi abbiamo affrontato una crescita aziendale non indifferente, non solo dal punto di vista delle persone, ma anche dei ruoli, dei dipartimenti e della cultura necessaria alla crescita stessa.

Nonostante la considerazione non possa essere definitiva, visto che continueremo a crescere ancora anche per tutto il 2022, posso già affermare che questa quest (glossario da gamer) è stata, e probabilmente sarà, una delle più complesse affrontate nella mia vita professionale. C’è tutto dentro: organizzazione, approccio filosofico/culturale/etico/economico, analisi dei dati, misurazione delle metriche di team, tecnologia, e via discorrendo. Ma alla base, sempre e solo una cosa, le persone.

Mi ricordo con nostalgia quando il mio lavoro era pensare “chissà se i miei test sulle performance rispetteranno i risultati che mi aspetto in produzione” o “come posso scalare con il tal SQL server” o ancora “voglio sistemare quella stored procedure per ridurre il tempo di risposta”. Era comunque molto impegnativo, vero, e senza studio e ricerca costante gli obbiettivi non si raggiungevano. Però era piuttosto deterministico. Diciamo che con un relazionale in certi casi hai quel dipende che i fan delle regole scolpite non digeriscono, ma era ancora macchina, software e tecnologia in generale. Oggi il mio lavoro è cambiato, un po’ per necessità, ma anche, in parte, per piacere e per sfruttare meglio la mia forma mentis, tutto sommato orientata all’organizzazione e all’ottimizzazione.

Scrivo questo post per condividere alcune riflessioni su quanto sia importante muoversi bene in contesti di migrazione come quello che stiamo vivendo, contesti in cui anche l’influsso di cambiamenti radicali a livello sociale (vedi pandemia) ci pone di fronte a scenari del tutto nuovi, con sfide non previste e difficoltà mai avute.

In passato molti di noi bramavano la possibilità di lavorare in remoto, di avere trattamento e approccio smart, di essere più indipendenti da tempo per ragionare ad obbiettivi. Oggi, alcune di queste condizioni sono fisiologicamente diventate uno standard, per la maggior parte accettate come nuovo modello. Altre hanno toccato l’esagerazione, come il non vedersi più di persona nemmeno quando possibile/importante, il numero delle call conference, il fatto di avere tutto e subito, sempre online. E ora, il metaverso (concetto che io ricordo dagli anni 90 da un romanzo intitolato Snow Crash) e tutte le innovazioni che, come la storia ci insegna, vengono idolatrate e demonizzate da chi, rispettivamente, vede solo vantaggi o tragedie apocalittiche. Oggi, comunque, abbiamo la gara a quello che va di moda e i social sono la monoposto con cui parteciparvi.

Ma crescere e cambiare vanno ben oltre questo. Quando abbiamo dovuto agire per predisporre un nostro percorso, non dormivo la notte, per paura (che ho tutt’ora) di una implosione aziendale e/o di non essere all’altezza. Il primo problema è stato avere una deadline stretta, che ci ha dato un ritmo atipico per fare selezione del personale. Per fortuna, la possibilità di lavorare da remoto con pochi requisiti di presenza ci ha dato il quid per venirne fuori egregiamente, visto che il resto è già people-first fin da quando abbiamo avviato l’attività. Le persone aggiunte seguono tutte i nostri principi, e non potremmo scegliere diversamente, pena “non remare tutti nella stessa direzione”.

Ma il vero problema, che é quello per cui ho fatto più fatica e che tuttora mi tiene sotto battuta, è stata la scalabilità dei nostri processi in essere. Ah, come funzionavano bene quindici persone fa! Da qualche tempo, invece, ogni cosa aveva iniziato a rallentare, si avevano stalli continui, la consapevolezza trasversale calava sempre di più e le prime reazioni precipitose rischiavano di portare a figure gatekeeper. Forse è naturale arrivare a ciò nella mente di tutti noi, a prima vista. Ma per chi crede nei principi della cultura DevOps e osserva più a lungo la situazione, questa non può essere la soluzione.

Ed è qui che abbiamo deciso di cambiare seriamente. Nessuna reorg, nessuna variazione all’organigramma. La gerarchia è rimasta piuttosto piatta, e non ci siamo fatti sopraffare dalla voglia di adattare il software sulla base della struttura aziendale (Team Topologies e la legge di Conway). Al contrario, abbiamo aggredito i problemi uno ad uno, cambiando a volte il processo, altre volte le abitudini. Abbiamo incluso persone nuove, con tanta esperienza sia con lo strumento (Azure DevOps) sia con le migrazioni culturali in realtà ben più grandi della nostra, abbiamo destabilizzato, di certo, ma stiamo già percependo i risultati. Per non dimenticare che l’appoggio del mio socio Michael Denny è stato indispensabile. I principi condivisi dall’azienda partono, in fondo, da noi due.

È importante avere una cultura aziendale condivisa in termini DevOps, ancor prima di pensare a qualunque strumento o prodotto. E non basta il coraggio, non serve il controllo gerarchico, ma un vero team di persone affiatate e pronte all’adattamento

La prossima retrospettiva verrò certamente rimproverato per l’impeto e la spinta rivoluzionaria, insieme a chi ha fatto sì che questo accadesse (il collega e amico Michele Ferracin, che mi ha consigliato anche il libro di cui sopra). Non potrò dare torto a chi lo farà; i cambiamenti fatti, forse, potevano essere affrontati con meno foga. Il fatto è che il processo antecedente alle modifiche non sarebbe più stato sostenibile e il rischio sarebbe stato quello di incappare in scelte da punto di non ritorno. Ho trattenuto il fiato e, credetemi, rispetto al quantitativo di variazioni, sono stato praticamente trasparente.

E ora? Beh, abbiamo una kanban board ben fatta, che rispecchia perfettamente un processo semplice, meno stati, meno informazioni inutili, meno dispersione e più consapevolezza trasversale. Certo, dobbiamo pulire gli arretrati, ma il peggio é passato. Siamo anche pronti a ridurre il numero di strumenti, perché essi sono stati semplicemente un supporto per la nostra cultura, sempre molto forte.

Con questo post, in conclusione, volevo sottolineare quanto sia importante avere una cultura aziendale condivisa in termini DevOps, ancor prima di pensare a qualunque strumento o prodotto. Senza questa radicata visione, la nostra azienda non sarebbe mai riuscita a reggere la crescita fino ad ora, né tantomeno a cambiare radicalmente pur mantenendo senza implodere. E non si tratta di hard skill, ma di un duro e prolungato lavoro di persone che remano dalla stessa parte, da oggi ancora più in maniera coerente e sincronizzata. Non basta il coraggio, non serve il controllo gerarchico, ma un vero team di persone affiatate e pronte all’adattamento.

Del salutarsi da adulti

Pochi giorni fa, in pausa caffè, uno dei ragazzi mi ha detto quanto segue: “mi sono stupito di quanto siano stati vissuti nel buon umore gli ultimi giorni in azienda di Peter”. Eh sì, seppure Peter sia un nome di fantasia, il suo lavoro con noi è terminato dopo pochi mesi. In passato, anche altri componenti del team hanno seguito strade differenti dalla nostra, persone forti e con noi da tanto tempo, e anche in quel caso mi sono chiesto “ha senso scrivere di questi episodi?”. Perché è piuttosto semplice ostentare sicurezza e fierezza quando si ha il vento in poppa, ma che implicazioni ha, invece, la fine di un rapporto di lavoro in cui tutto è fondato sul team building e sul team working?

Questo non è un post che sottolinea chi ha sbagliato cosa o che punta il dito su persone; non vuole esserlo nella maniera più assoluta. Tantomeno cercherò scuse o scappatoie, anzi, le condizioni che si vengono a creare in tali esperienze formative (e lo sottolineo) dimostrano il livello di maturità a cui si è arrivati come azienda, persona e figura responsabile del team che le vive. Attenzione, questo livello non è necessariamente buono, ma almeno si spera che il trend sia di crescita continua.

Quindi, perché scrivo? Semplice, perché dopo aver ricevuto la notizia da Peter ho pensato. Tanto. Ho fatto retrospettiva individuale, ho rivissuto i modi di pormi a lui, ho valutato come lui è stato collocato, seguito e vissuto dai suoi colleghi. Scrivo perché se da una parte ho avuto il dispiacere di veder partire nel tempo altri colleghi, dall’altra faccio un incredibile tesoro delle esperienze.

Per ovvi motivi non faccio alcuna menzione alle motivazioni che hanno spinto i ragazzi ad andarsene ma posso dire che ognuno ha avuto il proprio particolare trigger, ognuno dei quali ha fatto crescere l’azienda. Credo di poter dire che siamo una realtà totalmente orientata alle persone e al lavoro di squadra, che ci sono tanti stimoli tecnici, così come sono fermamente convinto che ognuno dei problemi che ovviamente abbiamo venga sempre affrontato, discusso e risolto nel tempo. L’ascolto per me è fondamentale ed è quello che fa crescere. Ed è proprio grazie a questo che, nonostante talvolta le persone cambino strada, l’azienda si comporta in maniera resiliente.

Ma torniamo alla frase di apertura; come mai è stato tutto normale fino al giorno della fine del rapporto? Come mai non c’è stata guerra e perché mai la persona che se ne sta andando da lì non è un “traditore”? Beh, mi stupirei del contrario, eppure, sembra che qualcuno sia stato etichettato in vari modi quando ha scelto di cambiare in molte realtà.

È stato come ogni giorno con Peter e con tutti gli altri perché, anche se ovviamente siamo feriti (a volte anche in difficoltà), prima di tutto siamo adulti e ognuno di noi è diverso, un piccolo grande universo di idee e di punti di vista. Per quale motivo una persona non deve poter cambiare senza subire un’etichetta? E anche se fosse per motivi che a noi appaiono futili o venali, chi ci giustifica ad essere giudici delle vite e delle scelte altrui? Per alcuni di voi saranno frasi fatte, per altri retorica, fa lo stesso. Posso dire che anche Peter ha fatto di tutto per essere di aiuto fino alla fine e la sua predisposizione e professionalità hanno fatto sì che il nostro rapporto non si interrompesse in malo modo. Noi investiamo in persone e rapporti umani,e se perdiamo nel cammino persone che scelgono di cambiare, beh, preferiamo augurare loro un grande in bocca al lupo!

Agile@School 2021 – La serie completa

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

Agile@School – Giornata conclusiva

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

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

Presentazione dei progetti

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

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

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

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

Fine della corsa

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

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

Agile@School – Anno sesto, terzo incontro

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

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

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

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

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

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

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

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

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

See the source image

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

Agile@School – Anno sesto, i progetti

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

  • Fisher
  • Cromosomi#
  • GentsAndLady.py
  • MonkeTeck

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

Team Fisher

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

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

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

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

L’idea

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

Team Cromosomi#

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

See the source image
Cluedo, il gioco in scatola

L’idea

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

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

Team GentsAndLady.py

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

Napoleon: Total War, SEGA 2010

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

L’idea

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

Team MonkeTeck

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

ATLAS, Grapeshot Games

L’idea

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

Conlcusioni

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

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