DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 01 – development (part 2)

Intro

In the previous post we’ve described the idea behind the automation we’re trying to implement on a scenario based on MicroFocus Vertica database.

How it works

This “sandbox” is not a real isolated development workstation. Let’s separate it into two parts, the first one for the development on everything but Vertica (Windows local workstation) and the other one for a Vertica instance (probably Unix/Linux VM) shared between developers.

In this shared instance we will get a schema for each developer is working on the solution, in order to let everyone to get his own “environment”.

The source control folder tree (which will be TFVC source control on-premises) will be designed on the desired branch as the following:

/Project
    /Instance
        /Process1
            /_Master
                schema.ps1 
                tables.ps1
                views.ps1
            /Tables
                Table1.sql
                Table2.sql
            /Views
                View1.sql
                View2.sql
            Schema.sql
        /Process2
            /Tables ...
            /Views ...

As you ca see, under the Project folder there is the Vertica database folder, which contains, schema by schema, all the .sql files for Tables and Views DDLs (CREATE TABLE and CREATE VIEW). You can notice also .ps1 files, which contains the list of executions based on a certain order (business driven).

The file for a, let’s say, “Table1”, can be like this one:

CREATE TABLE :SCHEMA.Table1
(
    RowId int NOT NULL,
    RowStringValue varchar(30) NULL,
    CONSTRAINT PK_<schema>Table1 PRIMARY KEY (RowId)
);

We’ve added a :SCHEMA parameter, which allows each developer to create its own schema as described before. This is the only way we’ve found for isolating developers in a Vertica shared instance, avoiding an instance for each developer, which could be resource intensive for available PCs. Running the application locally, before committing any change set to the Source Control, a simple tool will execute .sql files with the new schema name and in the sort order given by the .ps1 file.

The Tables.ps1 file can be as the following:

param(
[parameter(Mandatory=$true)]$hostname,
[parameter(Mandatory=$true)]$port,
[parameter(Mandatory=$true)]$user,
[parameter(Mandatory=$true)]$psw,
[parameter(Mandatory=$true)]$schemaName,  
[parameter(Mandatory=$true)]$scriptsFolder
)

$schemaCommand = "vsql -h $hostname -p $port -U $user -w $psw -v SCHEMA=$schemaName -f $(Join-Path $scriptsFolder "Table1.sql")"
Invoke-Expression -command '$schemaCommand'

$schemaCommand = "vsql -h $hostname -p $port -U $user -w $psw -v SCHEMA=$schemaName -f $(Join-Path $scriptsFolder "Table2.sql")"
Invoke-Expression -command '$schemaCommand'

You may notice the term “vsql”, which is the command line provided by Vertica for executing queries. Further information here.

Also, usernames and passwords will be stored in an external config file (or a secured API), like the following one:

{
"host": "MyHost.Hos.Ext",
"port": 1234,
"user": "user",
"psw": "password",
"schemaName": "MYSCHEMA"
}

We’ve got the DDLs, the PoSh files for executing them and the Vertica command line. Good, in a development environment, however, a set of tools should be prepared for helping us to keep these artifacts on a single pipeline, too. This is the reason why we’ve created a “builder” script, like  this one:

$config = Get-Content (Join-Path $currentFolder "Build-Config.json") | Out-String | ConvertFrom-Json

$schemaCommand = $(Join-Path $scriptsFolder "Tables.ps1") 
$schemaCommand += " -hostname $($config.host)" 
$schemaCommand += " -user $($config.user)"
$schemaCommand += " -port $($config.port)"
$schemaCommand += " -psw '$($config.psw)'"
$schemaCommand += " -schemaName $($config.schemaName)"
$schemaCommand += " -scriptsFolder $scriptsFolder"

Invoke-Expression -command $schemaCommand

This is another layer of management, which allows us to organize every part of the DDLs to be executed against Vertica.

Note: Our scripts will destroy and rebuild any given SCHEMA. But this is the way we like.

Now, let’s see the possible scenarios.

Start from scratch or get started

When someone wants to start from scratch, this is the pipeline to follow:

  1. get latest version of the branch;
  2. check and change the configuration file (JSON);
  3. execute the create-vertica-database-from-scratch.bat file (it contains our powershell “build” script);
  4. that’s it, we’ve got a new schema in Vertica, empty and ready to be consumed.

If you want to preserve your data, this is not the right path for you. Executing the “builder” tool is optional.

New development

When a developer would make and try its changeset:

  1. change Visual Studio application (SSIS or SSRS here) when needed;
  2. change the Vertica schema (adding tables, columns and so on);
  3. get the .sql file of a new object or change the .sql file of an object which has been updated;
  4. replace them into the TFVC file structure;
  5. change the .ps1/.txt files if any DDL has been added (or if something that impacts on the order occurs);
  6. build the Visual Studio application and try it;
  7. When everything works good, check-in.

Now, everyone can get the latest changes in a CI way.

Get delta changes

When a developer is going to get the latest changes that contains an updated version of the Vertica objects, but wants to preserve its data, this is a little bit more tricky. The person who has made the change could share in a collaborative chat tool the ALTER script. This is not so reliable and comfortable, but without any comparison tool, there isn’t any best way to make this happen.

That being said, we’ve implemented our diff-script generator, based on the analysis of Vertica metadata (the catalog, browsing v_internal objects). So, after our friend gets the latest version, he executes a generate-diff-script.bat tool and lets this script to execute the generated ALTER script. Tricky, but it works like a charm (we will speak about this comparison tool in next posts, maybe) . Anyway, we’re looking forward hearing updates from MicroFocus. Hopefully, we’ll get an official diff tool from them soon!

Conclusions

I’ve just shown the way we’re managing tables DDLs and how we’ve created PowerShell scripts, but the real scenario is more complex. We have to drop Vertica schema (CASCADE DROP) before, then re-creating the new parametrized schema, then tables, then views and so on. Sometimes, we’ve got Vertica schemas which are referenced each other, so we have to create for everyone of them tables before, then views. The business logic is managed by how we write the “build” PowerShell script as well as the automated build process will.

Also the build process is not always “straight”. Some of the business processes need to be managed in a dedicated way. Cross reference will occur but this is the job that the “builder” will do. Both for the manual and the automated one. Moving responsibility to the build process allows us to feel more comfortable about our development solution.

Last, but not least, the manual-development-build process allows the developer to choose between re-create the database or not. They should not waste time in managing the things that a script can do repeatedly and efficiently. This is the reason why we kept somehow static the PowerShell instead of writing complicated business logic. Just adding rows of vsql invocation in the right order, that’s it.

DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 01 – development (part 1)

Intro

As a consultant, life could be difficult when it comes to manage platform like Vertica, a columnar RDBMS by MicroFocus. Speaking about DevOps, database management systems like this one neither is well supported by built-in tools nor by any third party suites.

In my experience, which is focused on the Microsoft SQL Server world, tools like the ones made by Redgate or ApexSQL, plays a crucial role when it comes to DevOps. Unfortunately, this time I cannot find any real help. I think that it’s an exciting task, but I’ve to be careful. It’s like “reinventig the wheel” for a car (Vertica) that didn’t realize that it needs wheels. Strong and reliable wheels.

Scenario

In the scenario I’m working on, the data warehouse is managed by a layer of business logic implemented within this platform. Starting from SQL Server database populated by the application layer, the data rows pass through SQL Server Integration Services ETL packages, which transform them onto Vertica repository, and they end into a Business Objects layer (the presentation layer). Just to get the big picture, see the following diagram:

bi-scenario-scenario

Our mission is to share DevOps knowledge, culture and tools in order to automate a set of processes which are managed manually, right now. Not a simple task, even if the guys I’m cooperating with are well-trained and powerful in tech skills. Additionally, they are enthusiast and ready to change (and we know how this is usually a trouble). We will get obstacles only from a technology perspective, actually.

After days of documentation and questions to our MicroFocus contacts, it looks like that Vertica gives us no built-in way or tool for getting an automated process during the phase of the schema comparison. Also third-party tools aren’t that good. We’re trying to dig more and more in order to find out something on the internet. However, everything it’s a “little bit” tricky. To be honest it seems that no one tried to do DevOps with Vertica, even though this is a very good platform for speeding up heavy queries on huge amount of data. Yes, we downloaded a couple of officially suggested tools, whose documentation says that we can compare from and to Vertica itself, but no one fits our scenario. No command lines, no direct integration, no script generation. If you think about automated pipelines, this can be a big problem to deal with. I think that this should be the foundation of a DevOps approach. In the end, it looks like we’re the the first team that is trying to invest efforts into that. It’s funny, though. Hopefully, someone with experience in Vertica DevOps who reads this post could help us!

(After digging more, I’ve found this article that describes almost the same scenario. I hope to reach out the author out).

Prerequisites

As a kick-off, we’ve moved into the prerequisites, starting from the most important thing: make a process that will facilitate the team’s workday, instead of wasting time due to bad choices. This process should be simple and automated.

Then, we’ve argued about the IDE used by developers, evaluating differences between before and after solutions, getting pro and cons of them all. In the end, we agreed on the following solution, development side:

  • Visual Studio 2017 will be the editor for SQL Server Integration services solutions. This team, “BI team” hereafter, is working on SSIS and is separated from the application development team, at least at the moment;
  • TFVC (Azure DevOps on-premises) will be the Version Control System since the BI team is already using it. We will think about a migration path to git then, but for now we’d like to avoid any distraction out of the scope;
  • every get latest from the source control must synchronize all the DDL scripts for Vertica as well as the SQL Server and SSIS solutions, in order to get a sandbox with source code and the local database provisioning scripts (most likely we’ll get a virtual machine with Unix and a Vertica instance, too);
  • each SSIS project must be deployed to the local SQL Server instance when running solutions into the sandbox;
  • when all the SQL Server Integration Services packages are deployed, the list of Vertica DDL must be executed in order to create the database from scratch;
  • Optionally, mock inserts (also from file) could be added to the database in order to get data to work on.

Our idea

As you can see, in this pipeline, we will get everything we need in our sandbox. Just a note, we can choose how to provision the instance of Vertica, in order to scale out resources from local workstations and also use another O.S. It’s up to the team.

A big picture of this process can be summarized as follows:

001

Conclusions

As we’ve seen, the big picture is ready to be implemented and also the team knows perfectly what are the goals. We already know what technologies will be involved and how to keep them all together in order to make our pipeline.

Unfortunately, we cannot find any tool that helps us, so we’re preparing to jot some lines of code down.

DevOpsHeroes 2018 – Another brick in the wall

Event details

DevOpsHeroes has been a great event, again! We didn’t expect so many people and we could not imagine that the feedback would be so good. Quick facts:

  • Subscription: 244 (150 the past year)
  • Attendees: 122 (94 the past year)
  • drop: 50% (38% the past year)

Attendee’s satisfaction

The following radar chart is about the event date, location, quality of the sessions, quality of the speakers, food, hospitality, event design, and kits:

As we can see, the overall satisfaction is really high (4/5)! The blue line is related to the audience which already has attended our event (40%) and the orange one represents the first-timers (60%).

Indeed, we’ve got a good feedback also for the following questions:

  • will you attend again?
    • Sure, 45%
    • Most likely, 33%
    • Likely, 22%
  • will you suggest the event to other people?
    • Sure, 76%
    • Most likely, 21%
    • Likely, 3%

Conclusions

We’re really proud of the third edition of DevOpsHeroes. Engage IT Services and Xebir did a great job together, and, hopefully, both companies will cooperate in the future in order to provide new formats and events like this one. A special thanks goes to Scott Ambler, and also to Italian Agile Moviment for sponsoring and supporting the organisation.

Download sessions here.

Last but not least, thanks to GetLatestVersion.it and also WindowServer.it which allowed us to get DevOpsHeroes in the best shape possible.

See you next year!

Agile @ School – Anno Terzo – Presentazione dei Progetti e Conclusioni

Anche quest’anno Agile@School è giunto al termine. Il percorso è stato come sempre ricco di nuove esperienze, imprevisti e soddisfazioni; un modo per osservare come le classi di studenti siano in grado di applicare gli insegnamenti portando a termine progetti fatti, finiti e funzionanti.

Sarà proprio questo il tema centrale del post: la presentazione dei progetti. Non ci soffermeremo sui singoli team perchè ognuno di essi, con i propri pregi e difetti, è stato in grado di mostrarci quanto di meglio potesse creare e di esporlo a tutta la classe.

Presentazione dei progetti

Ciascun team è stato chiamato ad esporre sotto forma di *pitch* il proprio lavoro, immaginando di avere di fronte i propri investitori (Gabriele, i professori e il sottoscritto) da convincere, sia dal punto di vista del valore tecnico che da quello commerciale. In 20 minuti, tutti hanno avuto il compito di mostrare le funzionalità del prodotto in termini hardware e software, con l’aggiunta di un possibile piano di vendita a sostenere il tutto. Grazie a quest’ultimo punto, anche i team non tecnicamente eccelsi avrebbero potuto “tenere il passo” puntando di più sul lato vendita e di design.

Per rafforzare quanto detto poco fa, il codice non è nemmeno stato preso in considerazione al momento della presentazione: Gabriele, tuttavia, se n’è occupato in prima persona confrontandosi faccia a faccia con i ragazzi consigliando loro eventuali migliorie, solo per determinare i punti deboli lato sicurezza, ottimizzazione e qualità dei listati.

Per ogni squadra, abbiamo deciso di valutare con il seguente questionario:

quest01

quest02

Giudizi, non voti. Focalizzazione su attitudini, non su skill. Tutto quanto di ottimistico (o critico costruttivo) che possa aiutare i docenti nella valutazione finale.

Guardate qui alcuni estratti di quanto visto durante la giornata:

 

Conclusioni di fine percorso

Vi è da dire che più l’edizione di Agile@School si ripropone e più diventa evidente l’importanza di focalizzarsi sugli aspetti della gestione del team. Ricordo ancora il primo anno, quando tutto era in fase embrionale, momento in cui ci siamo prestati ad aiutare i ragazzi sul codice vero e proprio, dimenticando il motivo per cui questo progetto è nato: fornire ai ragazzi gli strumenti e le attitudini per affrontare un qualsiasi progetto, personale o di team, che può prendere vita in un contesto lavorativo come nella sfera privata (time management).

Ecco, fare una retrospettiva su questo, sempre in puro stile agile, ci rende orgogliosi dei passi fatti fino ad oggi e di quanto ne potremmo ancora fare, affinando tecniche ed organizzazione al fine di lasciare ai ragazzi un’impronta il quanto più possibile ispiratrice per il loro futuro.

Per quest’anno è tutto, grazie per averci letto fino a questo punto.

E stay tuned! 🙂

Agile@School – Anno Terzo – Stato Avanzamento lavori e Retrospettiva

Ciao a tutti,

Siamo quasi giunti alla fine di questa edizione di Agile@School presso l’I.I.S.S. Gadda di Fornovo, Parma. Nella puntata precedente abbiamo visto i diversi team presentare i loro progetti, venendo a conoscenza degli strumenti utili alla collaborazione e alla gestione efficiente delle attività tra cui Slack, Trello ed il concetto di retrospettiva mediante l’utilizzo di una starfish. A tal proposito è stato chiesto di presentarne una fatta da loro contenente tutti i punti, suddivisi nelle varie aree, che hanno raccolto nel corso dell’ultima settimana. Siete pronti? Cominciamo!

 

Retrospettive

Nel presentare le retrospettive, i ragazzi hanno mostrato ancora una volta una vasta creatività nella presentazione, andando ben oltre a quanto richiesto dal punto di vista visivo, giocando anche con il termine stesso di starfish per creare un risultato di impatto agli occhi della classe.

rpt

A presentazioni concluse, è emerso un ottimo spirito critico dei ragazzi nei confronti delle attività che hanno svolto questa settimana in cui hanno mostrato di aver utilizzato gli strumenti da loro consigliati in precedenza e, ancora più importante, di aver gestito positivamente le differenze e le diversità all’interno del team andando in generale d’accordo l’uno con l’altro risolvendo problemi di natura tecnica mediante una stretta collaborazione. L’unica nota “negativa” è data dal fatto che tutti i gruppi si sono concentrati troppo sullo storytelling e sull’aspetto grafico rispetto ai contenuti e alla loro suddivisione, portando a non soddisfare a pieno le nostre richieste. In ogni caso però si trattava della loro prima retrospettiva, pertanto ci è sembrato giusto chiudere un occhio su quest’ultimo aspetto apprezzando il loro impegno.

 

Stato avanzamento lavori

Finita la retrospettiva, abbiamo chiesto ai ragazzi come stesse procedendo il loro lavoro e, con nostra sorpresa, è emerso che tutti i gruppi hanno già cominciato a sviluppare il software e a cablare i loro circuiti, arrivando a completare in alcuni casi più della metà delle attività da loro stimate in precedenza. Non è stato necessario fornirgli consulenza tecnica in quanto la scuola si è prestata ad aiutarli e sostenerli in questo percorso sia dal punto di vista elettronico, acquistando il materiale necessario e spiegando il corretto processo di cablaggio, sia dal punto di vista informatico, risolvendo eventuali dubbi di programmazion ed interfacciamento con i dispositivi.

 

Conclusione

Non possiamo che essere contenti quindi del lavoro che hanno svolto, avendo l’ennesima conferma del fatto che agire sull’organizzazione e sulle metodologie che stanno dietro al lavoro pratico porta ad ottenere risultati tangibili e duraturi, anche nei confronti di chi come loro non ha mai avuto modo di sperimentare la cosa.

Come compito per l’ultimo incontro, che avverrà venerdì prossimo, abbiamo chiesto ai ragazzi di portare una presentazione del loro prodotto con tanto di codice e circuiti funzionanti. Nessuna direttiva sugli strumenti da seguire, nessuno schema di esposizione: gli è stato permesso di sbizzarirsi con la creatività, alimentando un pò di sana competizione. Come finirà? Per scoprirlo, rimanete sintonizzati in attesa del prossimo post!

Per oggi quindi è tutto, ci vediamo alla prossima puntata!

Agile@School – Anno Terzo – Presentazioni ed Introduzione agli Strumenti

Eccoci alla seconda puntata del progetto Agile@School arrivato al suo terzo anno consecutivo presso l’ormai consolidato I.I.S.S. Gadda di Fornovo, Parma. Nel post di oggi parleremo della presentazione dei progetti assegnati a loro nel precedente incontro e dell’introduzione di alcuni strumenti utili ad aumentare la collaboratività e la produttività come Slack e Trello, concludendo con alcuni compiti lasciati a loro per la prossima settimana.

 

Presentazione dei progetti

Veniamo quindi alla presentazione dei progetti assegnati ai diversi gruppi, facendo riferimento ad uno schema fornito loro nello scorso incontro su come doveva essere svolta. Ciascun gruppo, in un quarto d’ora, ha avuto la possibilità di esporre il proprio progetto mostrando a noi e al resto della classe i loro obiettivi, il materiale utilizzato e le attività in cantiere per le prossime settimane. Fin da subito sono emerse le diverse attitudini e qualità dei gruppi: tecnicità, valutazione dei rischi e abilità nell’esporre sono solo alcune delle caratteristiche che li contraddistinguono, lasciando anche spazio ad incertezze ed errori di calcolo sui tempi e sui costi che rientrano nella quotidianità anche del mondo del lavoro. É stato soddisfacente vedere inoltre come sia stata data una particolare attenzione all’immagine sia della presentazione che del proprio prodotto, confermando quanto scritto in precedenza in merito all’attitudine verso l’attività.

IMG_20180511_123740.jpg

Introduzione agli strumenti collaborativi

É arrivato quindi il nostro turno: mostrare ai ragazzi gli strumenti con cui potranno affrontare lo sviluppo in modo organizzato ed indolore. Abbiamo introdotto per prima cosa Slack, facendo un paragone con i relativi Telegram e Whatsapp mostrandogli come avere una gestione di specifici canali per le attività e un sistema di menzioni più avanzato possa garantire una miglior reperibilità delle conversazioni lavorative. A seguire, abbiamo mostrato l’utilizzo di Trello con il quale, tramite l’utilizzo di schede, colonne, scadenze ed assegnamenti, potranno definire tutte le attività che andranno a prendere in carico nello sviluppo. Questo inoltre è stato propedeutico ai fini di quanto gli è stato spiegato successivamente in merito al concetto di retrospettiva, per la quale gli è stato chiesto di crearne una mediante la tipica starfish o mediante l’utilizzo di Trello.

dav

Conclusione

Al termine di questa giornata siamo stati contenti del lavoro che hanno svolto, mostrando un coinvolgimento da parte loro per quanto riguarda il progetto. Nel prossimo incontro, oltre a visionare il compito sulla loro retrospettiva, ci accerteremo dello stato sull’avanzamento dei loro lavori e chiariremo eventuali dubbi di natura organizzativa, qualora ne abbiano.

 

Per oggi è tutto, alla prossima puntata!

 

Agile@School – Anno terzo – Apertura del progetto

Siamo già al terzo anno consecutivo. Il tempo vola, ma devo dire che i progetti che sono nati in Engage IT Services sono anche solidi, graditi e duraturi. È successo con gli eventi (quest’anno ben tre per coprire i trend topic IoT, DevOps e il nostro SQL Saturday) e accade anche con Agile@School. Pensate che nel 2017 abbiamo “aperto” anche una nuova realtà in quel di Rovigo, grazie a Michele Ferracin (qui i suoi post in reblog e le statistiche finali). Insomma, il motore gira, forte e non dà cenni di arresto. Quindi siamo qui, 2018 nuovo vestito per il progetto e la scelta di scrivere i post ad esso relativi in italiano, anche per rispettare quanto fatto nel nostro Paese.

La nostra azienda è finalmente entrata a far parte di un progetto più ampio di Alternanza Scuola Lavoro per la nostra scuola di riferimento (I.I.S.S. Gadda di Fornovo, Parma) per cui, a differenza delle edizioni precedenti, quest’anno potremo sfruttare un intero mese. Gli studenti non avranno più incontri isolati ma una serie di giornate consecutive di lavoro “sul pezzo”, senza dispersioni e senza includere ore extra scolastiche, sulle quali è piuttosto difficile investire per gli adolescenti. Ma non solo, quest’anno abbiamo anche un “corpo docenti”: non mancherà chi ci ha supportato fin dall’inizio (la prof. Pinella Pedullà, informatica e tecnologia) ma avremo anche importanti aggiunte, come il prof. Stefano Saccani (informatica), la prof. Enrica Groppi, il prof. Graziano Maniello e tutti quanti hanno supportato il progetto “donando” le ore del normale programma di studi.

Edizione 2018

Partiamo con la descrizione di Agile@School 2018. Due anni fa, l’edizione pilota, spiegammo ad una decina di ragazzi di quinta superiore come affrontare un singolo progetto in agile (Scrum), mentre l’anno scorso abbiamo optato per un’idea multi-progetto e multi-team con supporto di kanban board. In entrambi i casi, la base è stata Visual Studio Team Services utilizzato con template differenti.

L’approccio

Quest’anno Gabriele Etta (lo ringrazio per essermi sempre di aiuto) ed io abbiamo optato per lasciare libertà agli studenti, concentrando l’iter sulla self-organziation e sul principio di responsabilità. L’obbiettivo è in definitiva quello di raggiungere un approccio “dal basso verso l’alto” (bottom-up) in cui scelte e proattività vincono su comando e controllo. Come? Ponendo gli studenti di fronte ai problemi, lasciandoli fare, sempre nell’ottica della realizzazione di un prodotto/servizio. Ovviamente la nostra presenza è quella che consente loro di ottenere consigli pragmatici su comportamenti e strumenti disponibili.

img_20180517_083248.jpg

Le novità

Questa edizione porta con sé differenze anche per la classe ed il numero di persone. Una ventina di ragazzi di terza, che molto probabilmente incontreremo ancora nel 2019 e, perché no, anche nel 2020. Ed è questa la vera novità. Agile@School sarà un progetto a lungo termine, non dedicato ad un solo anno scolastico. Approfondiremo la conoscenza con gli studenti e potremo valutarli anche su più aspetti, nel tempo. A mio modo di vedere ciò corrisponde ad un grande valore aggiunto per gli studenti, per la scuola e per noi. Un percorso da seguire tutti insieme.

Il primo incontro

Nella prima “puntata” abbiamo affrontato un punto delicato della comunicazione. Il farsi conoscere, capire le proprie attitudini ed esporre i propri interessi. Ma non solo, uno dei primi passi per responsabilizzare i ragazzi è stato quello di selezionarsi a vicenda, di lasciar costruire i team naturalmente, senza imporre nulla. Certo, abbiamo cercato di far capire che un team può essere costituito da ruoli diversi e che non è una cattiva idea far crescere anche persone che non sono “forti” in particolari ambiti, ma quello è stata l’unico consiglio. Abbiamo in poco tempo ottenuto cinque team, due dei quali da cinque elementi e tre da quattro.

I progetti

I professori prima dell’incontro hanno creato un elenco di cinque idee, tutte orientate al mondo dell’IoT e, per essere più precisi, al rapporto tra l’informatica e l’elettronica ai giorni nostri. Tutti i progetti sono basati su Arduino e sul kit di sviluppo con esso fornito. Ogni idea è vista come una “partenza”, che corrisponde al requisito minimo e necessario ma che, allo stesso tempo, può essere estesa e resa “personalizzata” a scelta del team, con analisi, implementazioni, studi e rischi annessi. Nel prossimo post descriveremo meglio i contenuti, ma possiamo affermare che la base è tendenzialmente la gestione di sensori di vario genere e la presentazione su web con utilizzo di storage per il salvataggio degli eventi che si verificano. Il prof. Saccani, dopo la presentazione dei progetti, ha osservato con noi i ragazzi procedere alla creazione autonoma dei team e all’assegnazione di progetti. Dopo un primo conflitto di preferenza (ogni idea poteva essere assegnata ad un solo team) e dopo aver capito la possibilità infinita di estensioni applicabili in ogni ambito, le squadre hanno concordato le assegnazioni finali.

img_20180517_101351.jpg

Le cerimonie

Il primo meeting che è stato suggerito ai ragazzi è il daily meeting. Con un’occasione del genere (tutti i giorni a lavoro per un mese, ricordo) non potevamo fare altrimenti. Abbiamo spiegato le tre fatidiche domande, illustrando i modelli di risposta accettabile e non, ponendo l’attenzione sui tempi e sul livello di dettaglio. Fare il daily meeting è stato uno dei compiti assegnati a tutti.

La gestione delle attività

Come strumento per il task management abbiamo suggerito Trello e come chat collaborativa Slack, cercando di non consigliare altro. Come compito, alla fine della settimana, ogni team dovrà aver ideato un nome per il proprio “prodotto”, un’analisi iniziale, soprattutto funzionale, e una relazione per descrivere i casi d’uso. E chiaramente dovrà presentarlo, simulando una sorta di “ricerca fondi” da investire nella produzione concreta del prodotto stesso. Proprio come una piccola startup.

Per chiudere

Tutti ci aspettiamo soddisfazioni da Agile@School 2018 e confidiamo nel fatto che sia una buona base per i prossimi anni. Le premesse sono più che soddisfacenti, ma dovremo valutare passo dopo passo, cercando di adattarci al cambiamento. Al prossimo appuntamento…

Stay tuned! 🙂