Agile@School – anno quinto, ep. 6

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

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

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

<

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

Il branching, il nostro miglior alleato

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

The “git flow” branching model

gitflow, esempio di branching su git

Reazioni dei ragazzi ai primi conflitti

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

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

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

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

Stay Tuned!

PMI Disciplined Agile: FLEX, Flow for Enterprise Transformation (pt.7)

Siamo giunti all’ultimo appuntamento di questa serie esplorativa di PMI Disciplined Agile, in cui abbiamo visto come il framework creato da Scott Ambler e Mark Lines può supportare pragmaticamente il percorso di Business Agility di una organizzazione.

La strategia del PMI in ambito Agile, oltre a contemplare l’acquisizione di Disciplined Agile, ha anche interessato il framework Flex e il Brightline Transformation Compass. Quest’ultimo va oltre il focus di questa serie, mentre Flex è attualmente in integrazione proprio con Disciplined Agile, per cui è importante capire cosa rappresenta nell’ecosistema DA.

In modo molto sintetico possiamo dire che se i process blade sono le fondamenta “statiche” di riferimento per la trasformazione Agile, Flex è il motore “dinamico” che permette di tracciare un flow, sia evolutivo che operativo, per sviluppare ed ottimizzare il Value Stream.

Abbiamo più volte citato il concetto di Value Stream, senza mai soffermarci su di esso: si tratta dell’insieme delle azioni necessarie per generare valore per il cliente, dalla richiesta iniziale fino alla sua concretizzazione. Il tutto inizia con il concept iniziale, attraversa varie fasi in cui sono coinvolti più team di lavoro (generalmente Agili/Lean) e prosegue fino alla consegna e al supporto finale.

Un Value Stream inizia e termina con un cliente.

da flex value stream

The Value Stream

DA FLEX ha proprio l’obiettivo di ottimizzare questo flusso, indipendentemente dalle dimensioni dell’organizzazione o se ad essere coinvolta è solo una parte di essa. Il framework, originariamente messo in bella copia da Al Shalloway, è sviluppato sulla base dei principi di Flow-ThinkingLean-Thinking, e la Theory of Constraints, trovando la sua essenza in gruppi di pattern che risolvono problemi ricorrenti nei diversi contesti. La filosofia di fondo si lega alle “leggi naturali dello sviluppo di un prodotto” (natural laws of product development), ovvero quegli aspetti capaci di influenzarci indipendentemente dal fatto che ci occupiamo o meno di loro. 

FLEX sviluppa il Value Stream sinergicamente con i process blades di DAD e Disciplined DevOps, in abbinamento ad alcuni di quelli specifici di DAIT e DAE, e si sviluppa come evidenziato dalla figura seguente:

da flex

FLEX

Visibilmente si individuano, quindi, esplicitamente le seguenti aree di impatto:

  • Strategic Planning e Lean Portfolio Management, ovvero l’area strategica in cui vengono convogliati i goal aziendali derivanti il più possibile dai clienti di riferimento. Qui vengono coinvolti i responsabili di alto livello (CxO) che si confrontano per dar vita alle Iniziativeda perseguire a medio/lungo termine, tipicamente quarter.
  • Lean Product Management, l’obiettivo è quello di declinare (decomporre) le Iniziative in una serie di obiettivi da poter rilasciare velocemente in modo incrementale. Vengono coinvolte le prime linee operative (PO, PM, BA, ecc..) al fine di ottenere, primariamente, un insieme di MBI(Minimum Business Increment) ed eventuali MVP(Minimum Viable Product).
  • Development Intake Process, viene individuato e selezionato un processo di gestione dello sviluppo ben definito, in modo che il lavoro si concentri sugli elementi a maggior valore.
  • Planning, Collaboration, and Dependency Management, orientata a definire lo sviluppo a breve termine e il relativo valore puntuale di riferimento, oltre ad individuare esplicitamente le dipendenze che possono metterne a rischio l’obiettivo.
  • Implementation and Integration, le attività sono in carico a team auto-organizzati, che lavorano secondo la cadenza più idonea e integrano costantemente il risultato delle attività.
  • Release and Realization, le attività tipiche di operationmarketingsupportsono essenziali per “trasferire” all’utente la qualità ed il valore di quanto realizzato.
  • Continuous Improvement, centrata sul ciclo PDSA (Plan, Do, Study, Act), spinge al miglioramento continuo basato sulle evidenze.

La parte di Implementation ed Integration può chiaramente scalare ed interessare più team paralleli, dedicati ad iniziative diverse (ma anche alla stessa), creando necessità di allineamento e gestione delle dipendenze.

da flex multiteam

FLEX multi-team

Interessante evidenziare che il flow mette implicitamente in evidenza la necessità di operare in chiave Disciplined DevOps, in modo da favorire una scorrevolezza nell’ultimo miglio una volta completati gli MBI su cui si è ingaggiati.

da flex devops

FLEX e DevOps

FLEX non ha, come tra l’altro l’intero toolkit DA, la pretesa di fornire una soluzione, ma piuttosto suggerisce un modo per esaminare i problemi e supportare la riduzione dei principali fattori di complessità:

  • Carico di lavoro relazionato all’effettiva capacità del team
  • Efficienza dei flussi
  • Batch Size
  • Livello di collaborazione
  • Ruolo del management
  • Gestione della pianificazione 
  • Qualità del prodotto

L’obiettivo è sviluppare la cosiddetta in’“Inherent simplicity”.

In particolare, uno degli elementi introdotti esplicitamente da FLEX è il già citato Minimum Business Increment(MBI), ovvero la quantità minima di valore, funzionale al business, che può essere costruitadistribuita e consumata in un intervallo di tempo ridotto. Lo scopo dell’MBI è quello di focalizzarsi sul valore “asciugato” del rilascio, in modo da poter consegnare prima ed efficientare la relazione con il cliente, raccogliendo feedback su quanto realizzato.

L’MBI si differenzia dall’MVP (Minimum Viable Product) perché quest’ultimo utilizza artefatti quick-and-dirty per validare rapidamente un’ipotesi, e generalmente, non è un prodotto ingegnerizzato, ma più una sorta di beta veloce per capire la direzione da prendere.

 

Concludiamo qui questa serie di articoli dedicati all’introduzione del nuovo ecosistema PMI DA. Restano, chiaramente, molti dettagli non esplorati a cui dedicheremo prossimamente articoli specifici, webinar e pillole di contesto.

Stay tuned J

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

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

The build pipeline

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

Our build process

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

Build process explained

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

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

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

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

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

Ehm… you miss Vertica

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

Stay tuned!

How to configure access policies to Work Items on Azure DevOps

One of the strengths of Azure DevOps is that it’s very scalable. It can be configured to work for company of all sizes: from small teams of a few people, to a large enterprise with thousands of users.

When we work in complex environment we should follow the best practices to choose how to organize people and projects on our Azure DevOps Organization. This is a great piece of documentation to get started when we work in an enterprise scenario and I recommend reading it.

A general (but please double check if it is suitable for your environment) guideline is to work inside a single project and create many teams.

With this kind of setup is common that customers ask me to provide a way to limit visibility of work-items. This way only some people could access some work items. This is to provide better focus to teams, for example. But your project could have other needs to do this.

While I was writing this blog post, my dear friend MVP Gian Maria Ricci also blogged about this. His blog post is excellent so I’ll stop here and redirect to his page.

How to share an Azure DevOps Artifact feed with the entire organization

Azure Feeds used to be scoped to an organization. However, to enable public feeds and to become more consistent with the rest of Azure DevOps, feeds created through the new create feed UI are now project-scoped.

The only way to create an org-scoped Azure Artifact Feed is through API calls and it’s not reccomended.

If we want to share a feed with an entire organization this is what we need to do.

Tutorial

  1. We open the Azure Artifact module on the left of the portal
  2. We select the feed that we want to share
  3. We click on the gear icon to open the settings related to the feed.
Azure DevOps Artifact feed section with numbered steps to achieve the result of the tutorial.

Azure DevOps Artifact Feed

From here we need to select a View of the feed that we want to share and select the appropriate visibility level. These are the necessary steps:

  1. We select the View tab from the settings page;
  2. Then we select the View that we want to share (Local in this example);
  3. We click the Edit button;
  4. We select the org name (miferrac in this example) to share the feed with the entire org.
Steps to share the Local view of an Azure Artifact Feed.

Edit view

And that’s it!

TL; DR

We learned how to share an Azure DevOps Artifact Feed with the entire org.

Reference

Secure and share packages – MS Doc

Agile@School – Anno quinto, ep. 5

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!

PMI Disciplined Agile: Disciplined Agile Enterprise (pt.6)

Riprendiamo il nostro viaggio attraverso Disciplined Agile, andando ad esplorare l’anello più olistico del toolkit, ovvero: Disciplined Agile Enterprise (DAE).

da f1

Con i process blade di livello DAE, DA supporta lo sviluppo di una organizzazione in grado di abbracciare una Cultura Agile a tutti i livelli, adottando strumenti che le permettono di rispondere rapidamente ai cambiamenti del mercato.  È utile sottolineare, ulteriormente, che le diverse aree di DA vanno intese in senso evolutivo: i benefici tangibili e continuativi si ottengono se esse si sviluppano partendo dal centro (DAD) verso l’esterno (DAE) e non scegliendo solo quello che ci è “comodo”.

Una DAE, in particolare, affronta le sfide di mercato grazie ad una cultura che favorisce il l’apprendimento e l’evoluzione continua, in modo da adattarsi costantemente alle mutevoli esigenze del mercato di riferimento, spesso di tipo VUCA (Volatilità, Incertezza, Complessità e Ambiguità). In questo contesto, DAE si fonda su tre considerazioni primarie:

  • Ogni azienda è un’azienda di software. Tutte le attività produttive moderne sono basate sul software: anche se non si è una software house, senza software non è possibile fare business! Il dipartimento IT non può essere visto come un “centro di costo” da tagliare, emarginare ed esternalizzare, ma deve essere al centro dell’azione aziendale perché tale è il suo compito. Bisogna eccellere nell’IT se si vuole avere un’opportunità di emergere (e sopravvivere) nel proprio settore di riferimento.
  • Nessuno può ritenersi al sicuro. Non esistono più condizioni di monopoli, in nessun settore: da quello bancario a quello delle macchine industriali pesanti. Basta un nuovo competitor innovativo, che rivoluziona l’approccio al mercato o al prodotto, per condannare l’organizzazione all’estinzione. La domanda non è “quando accadrà anche a me”, perché sta già accadendo ora, la questione è decidere se si vuole essere leader o tentare di sopravvivere finché la fine (certa) non arrivi.
  • Le aziende Agili saranno le uniche a sopravvivere. Per rispondere alle sfide moderne, in un mondo complesso, è indispensabile essere adattivi/reattivi/empirici, costruendo la propria visione di agilità. Non esiste un settore dove queste caratteristiche non facciano la differenza, nemmeno uno. 

Nello specifico, quando si arriva a concentrarsi sulle sfide inerenti una DAE, vengono introdotti (come focus) i seguenti process blade:

da dae processblades

DAE Process Blades

ovvero:

  • Business Operations: focalizzato sulle attività necessarie per fornire servizi ai clienti e supportare i prodotti. Tra esse troviamo: l’help desk, i servizi finanziari(bancari e non), le attività di supporto tecnico, ecc. Come è intuibile, nell’ottica di “deliziare” il cliente, è necessaria una stretta collaborazione con le tue attività di vendita e marketing.
  • Control: i team operativi devono collaborare strettamente con le aree finanziarie e legali, in modo da avere consapevolezza delle risorse disponibili e dei vincoli di azione esistenti, mitigando gli ostacoli che si potrebbero incontrare.
  • Finance: la Disciplined Agile Financesi concentra su obiettivi concreti ed essenziali come garantire il flusso di cassaassicurarsi che il budget sia speso adeguatamenterispetto degli obblighi di tassazionetracciamentoe registrazione delle 
  • Legal: lo scopo primario è quello di garantire che l’organizzazione lavori entro il rispetto delle normative vigenti nel territorio in cui opera. Il legal teamlavora, inoltre, alla definizione di “contratti agili” che consentono di estendere l’agilità oltre il perimetro aziendale, in collaborazione con il people management, il marketing, il procurement, ecc. 
  • Marketing: il suo obiettivo è lo sviluppo di interazioni di successo tra l’organizzazione e il mondo esterno. Il marketing si muove “a due vie”: per i clienti, rappresenta l’organizzazione stessa e le sue offerte, per il resto dell’organizzazione, i (potenziali) clienti. In collaborazione con la gestione dei prodotti, il marketing è attivamente coinvolto nella visione a lungo termine delle offerte.
  • Procurement: il suo principale scopo è quello di efficientare il processo di approvvigionamento, aiutando ad ottenere, nei tempi adeguati, prodotti e servizi da organizzazioni terze. A tale scopo, il team relativo collaborerà con altre parti dell’organizzazione per comprendere le esigenze di approvvigionamento, identificare potenziali fornitori in grado di soddisfarle e collaborare con legalper sviluppare contratti adeguati. Da punto di vista organizzativo, il team di approvvigionamento è spesso parte del team legale o comunque strettamente correlato.
  • Sales: il suo obiettivo è tanto ovvio quanto fondamentale, ovvero vendere i prodotti/servizi ai clienti. Gli addetti alle vendite, lavorano a stretto contatto con il team di marketing, per assicurarsi di essere concentrati sulle vendite che riflettono la strategia generale dell’organizzazione, oltre che con l’IT, per garantire che ciò che sta vendendo sia disponibile o possa essere sviluppato rapidamente. Sales, a livello organizzativo, è spesso combinato con il marketing o ad altre aree aziendali.

Come abbiamo visto per le altre aree, anche DAE è interessato da un workflow esplicativo che mette in relazione tra loro i diversi process blade, non solo quelli specifici appena tracciati.

dae workflow

DAE Workflow

DAE espande quindi una filosofia agile a tutte le aree organizzative, anche quelle storicamente più burocratizzate ed ingessate, promuovendo la cultura dell’innovazione continua in relazione alle sfide che il mercato di oggi (e di domani) presenta ad ogni tipo di organizzazione.

Si conclude così il nostro sesto appuntamento dedicato a PMI DA. Nel prossimo approfondimento introdurremo PMI FLEX, il framework “dinamico” che evidenzia come gestire un value stream sfruttando quanto messo a disposizione dal toolkit DA.

Stay tuned J

Agile@School – Anno quinto, ep. 4

Vista l’emergenza in corso, è passato un po’ di tempo dall’ultimo aggiornamento e di cose ne sono successe: poco dopo l’ultima lezione, infatti, il Coronavirus ha iniziato a diffondersi e sono state prese contromisure sempre più restrittive per arginare il fenomeno. Si è arrivati infine al divieto per tutti i cittadini di uscire di casa, a meno di emergenze e necessità lavorative.

[…] un’occasione per sperimentare una nuova condizione, per mettere alla prova gli strumenti che usiamo tutti i giorni sul lavoro.

Da parte nostra, si può dire che abbiamo avuto “fortuna”, sia perché la nostra attività quotidiana (la programmazione) può essere eseguita anche fuori dall’ufficio via telelavoro, sia perché avevamo già predisposto anche prima del virus gli strumenti per metterla in pratica, per cui siamo stati fra i primi ad adottare l’utilizzo dello smart working che ci permette di lavorare da casa. Engage IT Services nasce in telelavoro, da tre persone che non avevano soldi per un ufficio, e oggi, grazie alla filosofia descritta qui, possiamo dire “ragazzi, da lunedì si lavora da casa” senza nessun problema di sorta. Un problema a dire il vero c’è, il caffè insieme, quello ci manca davvero!

Ma cos’è successo nelle scuole? In quella seguita da noi, in particolare, il professore non si è voluto perdere d’animo e, dopo un paio di lezioni sospese per precauzione, ci ha chiesto disponibilità per tenere una delle nostre lezioni in modalità di meeting online con gli studenti: ovviamente abbiamo accettato con entusiasmo, sia perché ci sarebbe dispiaciuto lasciare indietro i ragazzi sugli argomenti che avevamo preparato, sia perché era un’occasione per sperimentare una nuova condizione, per mettere alla prova gli strumenti che usiamo tutti i giorni sul lavoro.

Ed eccoci qui, tutti pronti da casa con Microsoft Teams configurato e avviato in attesa di essere invitati alla “riunione” della classe. SPOILER: la lezione è andata alla grande e ha guadagnato molto dal fatto di essersi svolta online invece che di persona, e nel seguito vedremo il perché.

Partiamo dallo svolgimento della lezione: cominciamo col dire che questa ha avuto un tono molto da “review”; è stato chiesto ai ragazzi, uno per gruppo, di illustrare ciò che avevano fatto in queste settimane (non crediate che se ne siano stati con le mani in mano, anzi) evidenziando principalmente quale fosse stata l’organizzazione del team negli sviluppi. Dopo ogni presentazione, abbiamo quindi riesaminato le board per capire se i nuovi PBI fossero stati inseriti correttamente e abbiamo fornito consigli su come migliorarne la stesura.

intro-view.png (728×310)

Particolare attenzione è stata posta ancora una volta sulla disciplina necessaria ad adottare una serie di processi. Sebbene in un ambiente scolastico essi possano risultare “pesanti”, a lungo termine non possono che incrementare consapevolezza ed efficienza nel modo di lavorare.

Tutto questo è avvenutotramite schermo condiviso e ciò ha permesso una partecipazione forse più diretta rispetto ad una lezione frontale in cui i ragazzi spesso non riescono a condividere quanto implementato o a interagire direttamente su quanto mostra il professore.
Nonostante molti ragazzi non disponessero di un computer e si fossero collegati con smartphone o tablet, l’impressione è stata che la lezione si trasformasse in qualcosa di più personale. Le distanze “fisiche”, già inevitabili in classe e in questo frangente anche più estese, si sono praticamente annullate. E questo ha portato molta più partecipazione.

[…] essere reattivi al cambiamento sia un processo fondamentale di ognuno di noi, azienda o individuo.

<

p class=”has-text-align-justify”>La lezione è terminata con la richiesta di collegare i repository GitHub dei ragazzi alla nostra board Azure, per poter mostrare loro la prossima volta l’integrazione fra i due mondi: abbiamo quindi mostrato la procedura per la creazione dei Personal Access Token, toccando così anche l’argomento sicurezza nella gestione dei repository.

L’aspetto su cui Pier-Paolo insisterà nella prossima lezione è quello della creazione di valore aggiunto ad ogni iterazione: sembra infatti essere presente un po’ di “dispersione” negli sviluppi. Anche il professor Memoli ha richiesto, dal canto suo, che i ragazzi mostrassero qualcosa di funzionante e tangibile per evidenziare tale problematica.

Il primo esperimento si può quindi dire concluso con successo e non vediamo l’ora di proseguire con la prossima lezione per avere conferma delle nostre impressioni! Una cosa che vogliamo sottolineare è che in questo periodo di emergenza, non solo chi sfrutta i nostri servizi cambia. Cambiamo anche noi e questo non fa altro che incrementare la consapevolezza di come essere reattivi al cambiamento sia un processo fondamentale di ognuno di noi, azienda o individio. Questi ragazzi ci hanno dato un insegnamento non piccolo. Si può fare!

Agile@School – Anno quinto, il progetto in remoto

Si sente spesso dire che la scuola non ha tutti gli strumenti per poter fronteggiare formazione in remoto. In generale, il mondo della formazione scolastica è considerato talvolta un po’ arretrato. In realtà, l’istituto che stiamo seguendo, sia con progetti paralleli, sia come alternanza scuola-lavoro è ed è sempre stata all’avanguardia. Forse sono un po’ di parte, visto che si tratta della scuola in cui ho studiato, ma credo che meriti una degna menzione.

Ancor prima che io potessi contattare i professori per tentare il progetto in remoto, ho ricevuto una telefonata dal professor Christian Memoli che, riassumendo, chiedeva: “abbiamo tutto per fare da remoto, abbiamo Teams, abbiamo strumenti di video conferenza, è un problema per la tua azienda? Noi stiamo già facendo didattica a distanza.”. Che cosa posso dire? Prima di tutto, che l’IISS Gadda di Fornovo Taro è pronto, veramente. Poi, nel mondo del lavoro di cui noi informatici siamo parte, non spesso il telelavoro è ben visto, mentre una scuola dimostra un sentimento responsabile e proattivo.

Attenzione, non fraintendetemi, per la nostra azienda, TUTTI e sottolineo TUTTI i clienti e i fornitori hanno condiviso, chiesto e supportato il lavoro da remoto. Però conosco casi in cui, seppure possibile come strada da percorrere, il telelavoro non è ancora ben visto. Per fortuna la nostra realtà aziendale non ha questo tipo di conflitto, anzi! Consapevolezza e responsabilità vanno per la maggiore, unitamente al rispetto per la salute di tutti.

A partire da mercoledì, seguiremo una serie di incontri (purtroppo ancora fino a data da destinarsi) utilizzando Microsoft Teams (strumento già utilizzato dalla scuola regolarmente), connettendosi in Azure DevOps Services e sfruttando GitHub come già indicato nei post precedenti della serie. Il tutto da remoto! Sento che questo progetto, già interessante, non farà altro che diventarlo ancora di più. Dimostreremo le possibilità dell’informatica, terremo comunque i ragazzi interessati e chiuderemo il progetto, senza farci fermare dallo spazio fisico.

Non vedo l’ora, stay tuned!

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.

<

p class=”has-text-align-justify”>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!