Agile@School – Anno quinto, ep. 5

Featured

Ed eccoci alla seconda lezione completamente online! L’impatto è stato molto meno forte; la volta scorsa abbiamo avuto un po’ di tensione causata dalla mancanza di esperienza, mentre stavolta la lezione è filata via senza intoppi (tolto qualche problema tecnico iniziale, prontamente risolto dal gentilissimo personale della scuola). È un buon segno. Nonostante tutto, è possibile (addirittura auspicabile?) una forma di educazione online, che nulla ha da invidiare alle classiche lezioni frontali, eccetto il rapporto umano, ovviamente.

Comunque, venendo ai temi della lezione, anche questa volta lo scopo è stato quello di “far parlare” i ragazzi: è piuttosto evidente che la maggior parte di loro non è abituata a interagire più del necessario (per carità, alla loro età…), però una delle cose che vorremmo gli restasse da questa esperienza è proprio quella di imparare i comportamenti tipici del team. In un ambiente lavorativo, dove la comunicazione e il lavoro di squadra sono centrali, infatti, possono fare la differenza.

Pier-Paolo ha iniziato la lezione riprendendo le fila di quella precedente e ha cercato di far comprendere meglio agli studenti la differenza fra un approccio waterfall (a cascata) e uno ad iterazioni, tipico invece dello sviluppo agile, che in questo periodo è addirittura indicato nei decreti ministeriali. Quello che si è notato è la tendenza da parte dei ragazzi di procedere in un modo un po’ “tutto o niente”, poco organizzato nel tempo, per quanto riguarda le implementazioni; in ambito lavorativo ciò non consente di portare un reale valore tangibile al cliente. Infatti, non gli viene fornita una versione coerente del lavorato e non gli si da visibilità dei progressi nel software fino a fine sviluppo. I ragazzi dovrebbero cominciare a lavorare più a “storie”, realizzando parti del loro software, magari piccole, ma funzionanti e “visibili” findai primi momenti (agile e iterazioni).

Le impressioni positive che già avevamo rilevato sono poi state confermate: la modalità totalmente online con cui si svolge la lezione è vincente. Anche questa volta il professore ha chiesto di mostrare l’avanzamento dei progetti ed è evidente che i ragazzi si stiano abituando al backlog e alla creazione e presa in carico dei task. Manca ancora il poter vedere i progetti funzionanti, ma siamo confidenti nelle prossime lezioni.

La lezione è terminata con una breve dimostrazione dell’integrazione fra le push su GitHub e Azure DevOps (impostate la volta precedente). La prossima settimana vedremo se tutto questo avrà portato i voluti risultati. Speriamo anche di poter iniziare a parlare di branching style, ma questo è un argomento ostico anche per i lavoratori, quindi non sarà semplice.

Bene, continuiamo così nonostante le difficoltà che ci stanno mettendo a dura prova. Alla prossima lezione!

Agile@School – Anno quinto, ep. 3

Nella seconda lezione abbiamo deciso di iniziare ad affrontare l’integrazione fra Git e Azure DevOps, in particolare per quanto riguarda il collegamento automatico fra i commit/push e i Task. Questa volta, però, abbiamo incontrato non poche difficoltà. I ragazzi, infatti, hanno lavorato su GitHub fino ad oggi, per cui abbiamo ritenuto opportuno effettuare l’importazione dei loro repository sul nostro Azure DevOps, tramite l’apposita funzione integrata.

Agli studenti, comprensibilmente, non erano stati dati permessi sufficienti per effettuare l’importazione in autonomia, per cui un po’ di tempo è andato perso nel far immettere le loro credenziali, uno alla volta. Superato “facilmente” questo primo ostacolo, i repository sono risultati importati con successo e, dopo una prima revisione dei concetti base di source control e del funzionamento di Git, Pier-Paolo ha seguito i ragazzi nell’operazione di cloning con l’ausilio di SmartGit, a cui erano già da tempo abituati.

log-default-coloring-4f58b1c4.png (1596×792)

Si è partiti con i comandi base di Git (checkout, commit, push/pull) intervenendo direttamente sul codice già scritto dai ragazzi, su schermo condiviso, in modo da dimostrare loro le potenzialità dello strumento. Purtroppo, la condivisione su schermo è stata l’unica strada percorribile, anche in questo caso i permessi erano mancanti. Dobbiamo preparare gli ambienti un po’ meglio la prossima volta!

Altra cosa da notare questa volta è che, durante la lezione, abbiamo avuto modo di toccare, seppure superficialmente, questioni di metodologia di sviluppo. Ad esempio abbiamo affrontato le naming convention, modularità e pulizia del codice, leggibilità, e via discorrendo, tutti argomenti che usualmente non vengono trattati nei classici corso di programmazione.

A fronte di tutte queste problematiche introdotte dal tentativo di migrare i progetti su Azure DevOps, è parso evidente che i ragazzi trarranno più benefici continuando ad utilizzare i loro repository su GitHub. Pier-Paolo si è quindi prefissato di sfruttare la funzionalità “GitHub Connections” la prossima volta. La feature di Azure DevOps permette di collegare un repository GitHub ad un progetto interno, permettendo al tempo stesso di sfruttare il meccanismo di associazione fra commit e Task, come descritto qui.

Kanban board shows GitHub links

Stavolta la lezione è stata forse più importante per noi che per i ragazzi e in retrospettiva individuale abbiamo imparato una importante lezione:

L’utilizzo di strumenti già in essere (non ci stancheremo mai di ripeterlo) è fondamentale per non aggiungere ostacoli ad un già difficoltoso percorso di migrazione culturale. Da queste piccole cose, si denota come una consapevolezza dell’ambiente in cui si lavora e dei tool annessi, avvicini tutti al successo del progetto stesso. E questo vale sia nelle aziende, sia nelle scuole.

La prossima volta tocca al branching e a comandi Git più “avanzati”, come le pull request, e il livello di difficoltà aumenterà notevolmente… Vediamo come sapranno affrontarla!

Agile@School 2017 – let’s start over

As a recurring project, Agile@School is started again on February, with a new set of projects and ideas. Gabriele will help me again, but it will be a very difficult task. During the past year we followed a Scrum approach, in order to comply the team structure. As you can read here, there were one team with a small bunch of members. Now, we’re getting “bigger”. As a result, we’ll have micro-teams of two/three member each. Great chance for Kanban. Let’s give it a try.

01

How will we approach in the beginning?

  • defining a set of micro-team, that we call “task forces”
  • designing a Kanban board
  • describing personas
  • speaking of some ceremonies we’d like to get rid of
  • speaking of some ceremonies we’ll keep
  • describing the customer journey and the story map practices

The task forces

The term not fits very well, actually; indeed, a task force is something that could be considered as a “defcon 1” team. However, we would give the teams a label which is “strong”. To be honest, we have a little amount of time, so in the end we can say that we’re in hurry already 🙂

The Kanbard board

As we said above, we will have more task forces, most likely six. Therefore, the board will use columns (as usual) for the status management and rows (aka Swimlanes) for separating teams and projects.

02

The board will be created in Visual Studio Team Services, in order to use also the Source Control Manager which relies on it.

Personas

Each team member will populate a simple card, the Persona card, which is depicted in the picture below:

03

As you can see (in Italian), the first column is for Persona details, the second for interests and the third is the “role” which the member would like to have. I know that the last column is not included in any best practice, but I feel that some student could start to think about its job and its future. Could be interesting.

The customer journey

During the next meeting, we’ll ask the students to show us their customer journey. Each team will have to describe the journey of a typical user, with mood for each action it takes and the value which it gets by the action itself.

Conclusions

Kanban, task forces, boards, customer journey, personas, etc. This year is full of new things to get knowledge from. Also the source control manager will change. We will use git on VSTS so we will get different projects in the same place in a quicker way.

And now, let’s start over! 🙂

SQL Saturday Parma – English Slide decks available to download

My SQL Saturday Parma slide decks are available to download on SlideShare.

The main topic of those presentations is database lifecycle management (DLM) on SQL Server.
Concepts: ALM/DLM, team work, differences between code and databases.
We’ve demonstrated the usage of the following tools: Visual Studio with SQL Server Data ToolsRed-Gate ed ApexSQL.
Second session: “Unit testing su database“.
Concepts: unit testing, database testing vs code testing.
We’ve demonstrated testing tools like Red-Gate SQL Test and Visual Studio Unit test projects, and the TSQLUnit framework.
Additionally, I’ve created a set of sample scripts with T-SQL and TSQLUnit on MSDN Code Samples.
Stay Tuned! 🙂