Agile@School – Anno sesto, i progetti

Featured

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 🙂

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!

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.

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à.

Agile@School – Anno sesto

Featured

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!

Featured

Engage Stories – digest 1

Come promesso, ecco la prima tranche di #EngageStories:

Altre interessanti storie, sempre in Engage, qui:

Our 2021

Everyone was waiting for this 2021, 2020 has been one of the worst year ever due to the Coronavirus pandemic. We need to start from scratch, both for relationships and professional development.

Due to the COVID-19, I have lost relatives and also some of my relationships with my fellows. From a professional perspective, I’ve travelled less, worked mostly in remote-working and I’ve invested in making our daily work in our company smarter. Anyways, we’re speaking about two sides of the same coin: trouble Vs opportunity.

For tech companies, the crisis has been a great opportunity. The disease has triggered (forced to be honest) a set of unstoppable changes. This is true also for Countries’ governments, school, services in general. At the same time, many small businesses and craftsmen stopped working due to lack of consumers. The world is changed and is going to change more and more. The change is killing someone and is testing severely the resilience of the others.

Luckily, our company is still alive and we are growing. I’ve learned many lessons in terms of recruitment, team management, tech stuff, project management. I’ve started to change my mind about multi-tasking and I’ve switched from many things at “the same time” to “the right number of things well managed” (but not only one 😉 I’m not yet able to follow such pattern).

We have dealt with the second big step of scaling out. Our organization is becoming bigger and more structured. The model is still flat, but now each individual is in charge of a single role. As a result, the quality of the product is improved, people are more focused and committed, but on the other hand, the time to market has increased. We have added a new role, which orchestrates the projects into the roadmap, increased the number of POs, created an R&D department, and fully involved Operations guys into the lifecycle (thanks Wikis!). All this stuff has been the game-changer for us.

It’s been so difficult to learn and cover so many topics, but we’ve accomplished our mission. Now we’re ready for the next year with many ideas. We already know that our team will grow more, and we’ll require new approaches. We know that we will deal with teams in different timezones and languages, so what is “smart” now, must become “smarter” tomorrow. Exciting, for sure!

Why am I writing this post? Not just to wrap-up something that happened this year. I would share with you that, starting from February 2021, Engage Labs (this will be our new name) will publish our guys’ blog posts periodically (in Italian language). Our great team will cover many topics, like professional development, lessons learned in the company, technology, and so on. We are a DevOps oriented organization and we would like to let our guys describe themselves.

So, stay tuned😉

Engage stories

Come promesso, sta per partire una nuova serie, chiamata Engage stories, in cui il team di Engage tratterà tanti argomenti, come lo sviluppo professionale e la carriera, le lezioni imparate sul campo, le impressioni derivanti dal cambiamento che ognuno ha dovuto affrontare, e via discorrendo. Siamo un’azienda orientata alla cultura DevOps perciò daremo spazio ai nostri ragazzi affinché raccontino qualcosa che, sperabilmente, sarà interessante per chi lavora nel settore informatico.

Benvenuti in Engage stories!

Stay tuned 😉

PASSed away

As described in this article, PASS “is ceasing all regular operations, effective January 15, 2021”. The 2020 has been one of the worst year ever for many companies and that is true also for the one behind the Professional Association of SQL Server.

That being said, our beloved SQL Saturdays (Parma, Pordenone, Milan, Turin, Ancona, Verona, etc.) will not be held anymore. To be honest, SQLSaturdays have been great from many perspectives:

  • Community aggregation
  • Offline networking
  • Content sharing
  • People relationship

So what? Are we losing these opportunities forever?

Well, the #sqlfamily is great and I’m proud to be part of it. But, the question is, how can we keep the value of the SQLSaturdays? We’ll start from scratch with the spirit of one of the strongest tech community ever known.

How? Take a look at datasaturdays.com and if you want to be involved, please follow the discussions on GitHub.

We need everyone’s help to continue delivering events as we’re used to do. Come with us and bring your passion!

From Jira to Azure DevOps (work items)

Introduction

A migration, no matter what is the involved set of technologies, is one of the hardest tasks to deal with. Not just for IT. However, working with the culture of many companies, I’ve got confirmation that the tool should be considered at the end of the migration process. Indeed, after setting up the ceremonies, involving the patterns of the team working, switching the methodologies from legacy to lean/iterative, it comes finally to understand how to choose from the available tools (part of the “enterprise awareness”) and including a set of new tools, optionally. The goal is to get all the stuff which fit the real scenario.

This post is a quick step by step guide to migrate work items from Jira cloud to Azure DevOps Services. I’m going to describe the last step of one of my customers’ migration.

Getting started

Before going in-depth with technical details, I would like to share some tips. As we have already said, the migrations are complex tasks. Mandatory requirements should be a strong knowledge in terms of business and team management, enterprise awareness and years of experience on different real scenarios.

We must avoid any decision if our ideas and targets are not clear. Indeed, another important requirement is to understand in depth the workflows you will work on, both the legacy one and the new one you’re figuring out. Some of the question we should ask ourselves are:

  • Do we require these steps? And what about these work items?
  • Is this state workflow good for us? Should we change it? How?
  • Do we require to preserve relationships and items’ history?
  • Can we keep something which is working very well now? If so, what tools we’re thinking about?

The software selection

The software selection has ended up on a tool made by Solidify (Thanks to the experienced members of our getlatestversion.eu community). Anyways, you can find more of them. For example:

When exporting from Jira, the CLI implemented by Solidify connects to the Jira server (cloud by default and on-premises when configured), executes a JQL query for extracting the Jira so-called “Issues”, evaluates and applies the mapping between users, work items, relationships and states, and exports a JSON file for each item.

When importing to Azure DevOps, the CLI imports the output JSON files using the same mapping configured into the configuration file in the exporting phase.

Why this tool? Because it has a couple of simple command lines and it consumes a JSON configuration which is clear. Additionally, it has many default behaviors, like the built-in configuration for SCRUM, agile and basic process templates, which allows us to forget about the complexity of both the source and target software.

Executing the tool

The scenario I’ve dealt with, Jira side, has been configured with many states, also with the same meaning (due to the legacy setup and different team’s approach) and with custom workflows/links. On the other hand, Azure DevOps side, I’ve created a customized Scrum template, with just two new work item types, which should support some of the customized source behaviors, and a couple of new states.

So the tool has been configured as depicted in the following JSON (just a subset of maps):

Just that. Notice that we can configure project names, the JQL query for gathering issues, working folder names and the file for the user mappings.

First, download the latest release of the CLI from GitHub. Then follow these steps.

How to export Jira issues

  1. create a folder called C:/Temp/JiraExport (you can configure this editing the JSON config file)
  2. create a file called “users.txt” within that folder and put into it a list of jirauser@domain.ext=AzDOs@domain.ext records
    • please note that the Jira user can be represented without the domain, depending on its configuration
  3. copy the JSON configuration file (based on he template we’re going to apply when importing) into the JiraExport folder
    • modify the file in the maps section: link-map, type-map, field-map, and so on.
  4. get the credentials (as admin) and the Jira server URL
  5. make your command line, which should look like the following:
    jira-export -u username@domain.ext -p userPwd --url https://jiraurl.ext --config config-scrum.json --force
  6. run the command and look for the JSON files into the JiraExport folder
    • look for any warning/error like the following and correct them (this will help you to import without any breaking change)
The missing mapping between Wip status and Story item

How to import to Azure DevOps

It’s time to execute the second command line, wi-import. As we can see, we have to get a personal access token (PAT) from Azure DevOps, as described in the documentation, with the full access.

Coming back to the configuration, we should pay attention to base-area-path and base-iteration-path. With these, we can choose the target of our migration, in terms of area and iteration. This means that we can manage our items after the import has been completed. With a query, for example, we can remove everything and start over with the migration. Cool.

The command should like the following:

wi-import --token PAT --url https://dev.azure.com/org --config config-scrum.json --force

After ten minutes we’ve got new areas and iterations:

The Azure DevOps hierarchy of items (except for the Features, which I’ve not mapped) has been preserved and also the history of any item:

Conclusions

In a couple of days, we’ve migrated everything related to work items from Jira to Azure DevOps. Most of the time should be invested in configuring the JSON mappings and, for sure, to check for the errors caught during exporting items. Finally, after importing into AzDOs, you can start over and over, removing all the items under the pre-configured area/iteration, until everything looks good.

Serie completa: Agile@School 2020

Eccovi la lista degli episodi, per condividere con voi il progresso di quest’anno con l’IISS Gadda di Fornovo Taro (TAG# Agile@School):

Anche quest’anno grandissima esperienza. Un grazie a Christian Memoli (docente di Tecnologia) e al nostro istruttore Pier-Paolo Mammi, che ha fatto veramente un bel lavoro.

Strumenti utilizzati: Azure DevOps services, Microsoft Teams, GitHub.

Alla prossima!

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.