Agile@School – Giornata conclusiva

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

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

Presentazione dei progetti

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

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

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

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

Fine della corsa

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

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

AgileEngineering, la fase di Engineering: l’organizzazione del lavoro

Nello scorso appuntamento abbiamo affrontato gli elementi caratterizzanti della fase di Inception, in cui il sistema da realizzare viene “inizializzato” con un approccio Lean like, avvalendosi di un approccio ispirato al metodo 3P (ProductionPreparation e Process) che consente al team di lavoro di sviluppare quanto necessario per creare la dorsale della specifica soluzione

In questo secondo appuntamento della serie, inizieremo a parlare della fase di Engineering in cui il prodotto viene implementato nei diversi aspetti funzionali customer side, seguendo una logica più tipicamente Agile.

agileengineering poster

Questa fase viene guidata da un “albero funzionale”, elemento di output/outcome della precedente fase di inception, in cui sono state definiti, a livello medio-alto, le diverse componenti caratterizzanti il sistema.

albero funzionale

Albero Funzionale

L’utilizzo dell’albero funzionale aiuta a focalizzarsi sulle funzionalità da realizzare in relazione alle necessità del cliente, favorendo l’organizzazione in team cross-funzionali. Si tratta di un aspetto molto delicato, soprattutto nell’ambito dell’ingegneria di sistema che, normalmente, si basa su una forte settorializzazione delle competenze e suddivisone delle attività in “working-package” affini (leggasi WBS).

L’albero funzionale è chiaramente accompagnato da una vista architetturale che aiuta a capire i componenti da utilizzare per l’implementazione delle funzionalità richieste, permettendo di fare una prima valutazione di fattibilità e sostenibilità, alla base anche delle attività di sviluppo della dorsale, già presentate nella discussione inerente la fase di Inception.

Tornando ai team, la loro composizione è un aspetto particolarmente delicato da curare: generalmente, si hanno più team concentrati su parti funzionali del sistema che però non hanno un contatto continuativo con il cliente finale, anche perché per quest’ultimo l’oggetto minimo da poter valutare è una Capability, che rappresenta un sotto-insieme funzionale (ma anche a livello di componenti) significativo. Tale Capability ha tipicamente un tempo di sviluppo ampio, che può superare anche l’anno, per cui bisogna trovare il modo di spostare il focus di review e allineamento quanto meno sulle Feature (che hanno ragionevolmente una declinazione temporale di qualche mese) .

Anche in questo caso, comunque, si hanno intervalli di tempo considerevolmente più ampi di quanto generalmente previsti nel mondo Agile (2, 3 settimane di media), cosa che porta a riconsiderare il ruolo di Product Owner di ogni team più in un ottica di Engineer Owner che aiuta il team nel dettaglio delle attività e nel coordinamento con gli altri team o aree di lavoro coinvolte. Viene quindi a configurarsi una “product ownership board” composta dagli Engineer Owner, generalmente uno per ogni team che, nell’insieme, si coordinano con il Product Owner (di prodotto) che li supporta nelle relazioni con il cliente e nella revisione dell’Agile Portfolio tramite il quale vengono definiti gli obiettivi nei diversi riferimenti temporali (Annuale, Quarter, Mensile, Iterazione, ecc), nonché i backlog operativi.

In particolare, la vista dei diversi backlog viene implementata tramite la cosiddetta Flight Level Architecture, in cui si passa dal livello Strategico a quello Operativo (e viceversa) per una completa visione di come sta progredendo lo sviluppo del prodotto.

flight levels

The Flight Levels Architecture

Si ottengono quindi una serie di Backlog a diversa granularità e con ownership affidate a gruppi di coordinamento che partono dal basso (buttom-up) ma che sono supportati e coordinati da figure progressivamente più business/holistic related.

agile portfolio

L’MBI, ovvero il Minimum Business Increment, riportato nel backlog centrale della figura precedente, rappresenta un elemento atomico che ha significato dal punto di vista del business, ovvero sia per il cliente ma anche per il business. Su di esso c’è il vero focus di sviluppo in chiave ross-disciplinare (software, elettronico, meccanico, chimico, ecc), grazie ad una sua progressiva scomposizione che da vita al backlog operativo (quello più a destra nella figura precedente) che va ad esplicitare gli interventi diretti da realizzare sul prodotto.

L’MBI viene scomposto in funcionality, a loro volta scomposte in work item (sempre cross-dominio), che vengono presi in carico da un team in grado di completarne tutti gli aspetti.

Un team che si ispira ad AgileEngineering è, quindi, un team composto da esperti dei vari settori afferenti che si coordinano tra loro per completare qualcosa di significativo funzionalmente parlando, abbattendo notevolmente la complessità di integrazione e di test che si riscontra quando lo sviluppo è invece centrato su componenti di dominio realizzati in modo indipendenti tra loro.

eng teams

Nel prossimo appuntamento continueremo a parlare della fase di Engineering affrontando gli aspetti di integrazione, testing e il relativo supporto dagli specialist extra-team.

 

 

Stay tuned :-J

AgileEngineering, la fase di Construction: l’organizzazione del lavoro

Nello scorso appuntamento abbiamo affrontato gli elementi caratterizzanti della fase di Inception, in cui il sistema da realizzare viene “inizializzato” con un approccio Lean like, avvalendosi di un approccio ispirato almetodo 3P (ProductionPreparation e Process) che consente al team di lavoro di sviluppare quanto necessario per creare la dorsale della specifica soluzione

In questo secondo appuntamento della serie, inizieremo a parlare della fase di Engineering in cui il prodotto viene implementato nei diversi aspetti funzionali customer side, seguendo una logica più tipicamente Agile.

agileengineering poster

Questa fase viene guidata da un “albero funzionale”, elemento di output/outcome della precedente fase di inception, in cui sono state definiti, a livello medio-alto, le diverse componenti caratterizzanti il sistema.

albero funzionale

Albero Funzionale

L’utilizzo dell’albero funzionale aiuta a focalizzarsi sulle funzionalità da realizzare in relazione alle necessità del cliente, favorendo l’organizzazione in team cross-funzionali. Si tratta di un aspetto molto delicato, soprattutto nell’ambito dell’ingegneria di sistema che, normalmente, si basa su una forte settorializzazione delle competenze e suddivisone delle attività in “working-package” affini (leggasi WBS).

L’albero funzionale è chiaramente accompagnato da una vista architetturale che aiuta a capire i componenti da utilizzare per l’implementazione delle funzionalità richieste, permettendo di fare una prima valutazione di fattibilità e sostenibilità, alla base anche delle attività di sviluppo della dorsale, già presentate nella discussione inerente la fase di Inception.

Tornando ai team, la loro composizione è un aspetto particolarmente delicato da curare: generalmente, si hanno più team concentrati su parti funzionali del sistema che però non hanno un contatto continuativo con il cliente finale, anche perché per quest’ultimo l’oggetto minimo da poter valutare è una Capability, che rappresenta un sotto-insieme funzionale (ma anche a livello di componenti) significativo. Tale Capability ha tipicamente un tempo di sviluppo ampio, che può superare anche l’anno, per cui bisogna trovare il modo di spostare il focus di review e allineamento quanto meno sulle Feature (che hanno ragionevolmente una declinazione temporale di qualche mese) .

Anche in questo caso, comunque, si hanno intervalli di tempo considerevolmente più ampi di quanto generalmente previsti nel mondo Agile (2, 3 settimane di media), cosa che porta a riconsiderare il ruolo di Product Owner di ogni team più in un ottica di Engineer Owner che aiuta il team nel dettaglio delle attività e nel coordinamento con gli altri team o aree di lavoro coinvolte. Viene quindi a configurarsi una “product ownership board” composta dagli Engineer Owner, generalmente uno per ogni team che, nell’insieme, si coordinano con il Product Owner (di prodotto) che li supporta nelle relazioni con il cliente e nella revisione dell’Agile Portfolio tramite il quale vengono definiti gli obiettivi nei diversi riferimenti temporali (Annuale, Quarter, Mensile, Iterazione, ecc), nonché i backlog operativi.

In particolare, la vista dei diversi backlog viene implementata tramite la cosiddetta Flight Level Architecture, in cui si passa dal livello Strategico a quello Operativo (e viceversa) per una completa visione di come sta progredendo lo sviluppo del prodotto.

flight levels

The Flight Levels Architecture

Si ottengono quindi una serie di Backlog a diversa granularità e con ownership affidate a gruppi di coordinamento che partono dal basso (buttom-up) ma che sono supportati e coordinati da figure progressivamente più business/holistic related.

agile portfolio

L’MBI, ovvero il Minimum Business Increment, riportato nel backlog centrale della figura precedente, rappresenta un elemento atomico che ha significato dal punto di vista del business, ovvero sia per il cliente ma anche per il business. Su di esso c’è il vero focus di sviluppo in chiave ross-disciplinare (software, elettronico, meccanico, chimico, ecc), grazie ad una sua progressiva scomposizione che da vita al backlog operativo (quello più a destra nella figura precedente) che va ad esplicitare gli interventi diretti da realizzare sul prodotto.

L’MBI viene scomposto in funcionality, a loro volta scomposte in work item (sempre cross-dominio), che vengono presi in carico da un team in grado di completarne tutti gli aspetti.

Un team che si ispira ad AgileEngineering è, quindi, un team composto da esperti dei vari settori afferenti che si coordinano tra loro per completare qualcosa di significativo funzionalmente parlando, abbattendo notevolmente la complessità di integrazione e di test che si riscontra quando lo sviluppo è invece centrato su componenti di dominio realizzati in modo indipendenti tra loro.

eng teams

Nel prossimo appuntamento continueremo a parlare della fase di Engineering affrontando gli aspetti di integrazione, testing e il relativo supporto dagli specialist extra-team.

 

 

Stay tuned :-J

Agile@School – Anno sesto, terzo incontro

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

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

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

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

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

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

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

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

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

See the source image

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

AgileEngineering, la fase di Inception

Uno dei dubbi che sorge immediatamente quando si parla di Agile applicato nell’ambito dell’Ingegneria di Sistema è come sia possibile sviluppare in modo iterativo un sistema complesso, spesso visto come un tutto o niente, e composto da elementi fisici la cui duttilità è tutt’altro che un elemento da sottovalutare.

Spesso, l’approccio seguito, è quello di concentrarsi sulla realizzazione di prototipi-successivi, in cui, di volta in volta, si raffinano aspetti specifici dei diversi componenti per poi arrivare al “Primo di Serie” e alla specifica definizione della Bill of Materials.

Per districarsi con questo aspetto, AgileEngineering individua una specifica fase di Inception, in cui vengono confutati gli aspetti primari della soluzione e realizzata la dorsale di sviluppo necessaria a dare lo start operativo di dettaglio.

agileengineering poster

In questa fase, un approccio Lean based risulta fondamentale, data la variabilità delle azioni da realizzare e la sperimentazione che generalmente caratterizza in questo frangente il prodotto in modo predominante.

Operativamente, ci si avvale di un approccio ispirato al metodo 3P (ProductionPreparation e Process), fondato su un processo rigoroso e strutturato che consente alle organizzazioni di concentrarsi sulla riduzione dei rischi e incrementare la capacità di validare rapidamente le ipotesi inerenti ai propri prodotti e i processi.

lean3p

Lean 3P

L’idea di fondo è quella di raffinare le assunzioni iniziali per poter raggiungere una condizione di progressiva confidenza “nel come” e “nel cosa” realizzare, con particolare riferimento ad un nuovo prodotto e alle attività di gestione annesse. Il tutto passa attraverso la creazione di una serie di “potenziali soluzioni” che permettono di diminuire le opzioni disponibili e concentrarsi, alla fine, solo su quella che, dati i vincoli, gli obiettivi, e l’organizzazione specifica, risulta più confacente. 

In tal modo i prodotti, dopo la fase di Inception, risultano meno complessi, più facili da produrre e, in ultimo, dovrebbero essere anche più facili anche da usare e manutenere.

A differenza dei metodi per il miglioramento continua a piccoli passi (Kaizen in primis), il 3P è orientato ad ottenere rapidamente miglioramenti su ampia scala, consentendo di migliorare le prestazioni ed eliminare gli sprechi a livello di sistema.

L’azione è affidata ad un gruppo eterogeneo di persone, un team (team 3P), che generalmente opera per più giorni con un focus su un compito specifico. L’obiettivo è proprio quello di sviluppare un design di prodotto che soddisfi al meglio le esigenze dei clienti in modo sostenibile.

In pratica è come se i principi Lean, generalmente pensati per l’ottimizzazione dell’as-is e la riduzione degli sprechi, subiscano un effetto di shift-left, agganciandosi allo sviluppo di nuovi prodotti e trovando applicazione nel momento in cui le decisioni possono avere la maggiore influenza sia sul prodotto che sul funzionamento.

Volendo guardare più nel dettaglio il metodo 3P, possiamo identificare una serie di passi caratterizzanti:

  • Definizione degli Obiettivi: il “team 3P” cerca di comprendere le principali esigenze del cliente da soddisfare. Il team procede a scomporre la visione di alto livello nelle componenti primarie, in termini funzionali/tecnologici/di processo, per valutarne il contributo individuale;
  • Definizione del Flusso Realizzativo: viene disegnato il flusso di realizzazione che porta dai requisiti di alto livello alla relativa implementazione. In questa fase si evidenziano anche le fasi di trasformazione dalle materie prime annesse. Il team 3P è quindi in grado di analizzare ogni diramazione del flusso e fare un brainstorming sui punti critici annessi;
  • Ricerca delle Similarità: il team 3P osserva soluzioni simili, artificiali o naturali, per “assorbire” le soluzioni note e concentrarsi sulle vere innovazioni da attuare;
  • Definizione e Valutazione del Processo: il flow realizzativo viene scomposto nei costituenti e vengono, eventualmente, creati nuovi team per approfondire i dettagli e identificare il set minimo di opzioni più plausibili;
  • Definire un Piano di Implementazione: il team individua un piano di sviluppo di massima in modo da valutare i tipici constraints di tempo/budget ed identificare le figure personali richieste;
  • Sviluppare gli Asset Portanti: il team può ora concentrarsi sullo sviluppo dei componenti portanti, sviluppando un set di varianti per assicurarsi di individuare quella che più soddisfa le aspettative.

Va sottolineato che tali passi non sono un “must”, ma vanno declinati in relazione al contesto e al progetto specifico.

L’insieme degli asset realizzati, unitamente al piano desiderato, costituiranno il passe-partout per passare alla fase di Construction, fase in cui il tutto verrà sviluppato nel dettaglio e rifinito in modo iterativo ed incrementale per ottenere il prodotto definitivo in grado di soddisfare l’utente e che sia, chiaramente, industrialmente sostenibile.

Il punto cardine del 3P è la capacità di generare know-how tra i membri del team e tra il team ed il cliente, spingendo all’innovazione sostenibile continua, così come ben riportato nel libro “The Lean 3P Advantage: A Practitioner’s Guide to the Production Preparation Process” di Allan Coletta che è tutt’ora di riferimento per la tematica.

 

Stay tuned :-)

DisciplinedAgile@University

da pmi logo

So, after different months of works, we are happy to announce DisciplinedAgile@University!

This is the first time that there is a real concrete opportunity for master’s degree students in Software Engineer to take an Agile Certification course (DASM) and become a PMI DA Certified Scrum Master. We will have onboard about 70students!

This designation will help them to have more opportunities to enter faster in the world of work, and improve their approach to problem solving in relation to complex situations.

This was made possible thanks to the collaboration with the Università degli Studi di Napoli Federico II (Naples, Italy), specially with prof. Anna Rita Fasolino, and the Project Management Institute (thanks Keren Moses Deront) that support us in this initiative and it’s actively part of it.

A great journey for new Agile passionate…. stay tuned for more information. We will start in the second half of may!

 

Scott W. Ambler, Mark Lines

 

#pmi #disciplinedagile Xebir Innovation

Agile@School – Anno sesto

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!

Engage Stories – digest 1

Come promesso, ecco la prima tranche di #EngageStories:

Altre interessanti storie, sempre in Engage, qui:

2cents on Business Agility

Riflettevo con alcuni colleghi di quanto ancora oggi si cerchi di inquadrare, sempre e comunque, la capacità di innovare in un “metodo” o in una “ricetta” da seguire pedissequamente.

business agility icon

La realtà dei fatti è che le organizzazioni, i team, le persone sono spesso molto diversi tra loro e l’idea di legarsi in modo dogmatico ad un unico strumento è, di per sé, la negazione stessa dell’Agile in quanto approccio adattativo che fa dell’empirismo la sua migliore arma.

Negli anni si sono diffusi molti bias a riguardo: “questo è meglio di quello”, approccio “tradizionale” o approccio “moderno”, “buoni” e “cattivi”, in realtà ogni evoluzione è spesso la sintesi di sperimentazioni trasversali, di tentativi di individuare possibili soluzioni allo stesso problema che partono da prospettive diverse e ne colgono sfumature che aiutano a comporre il quadro generale.

L’approccio di apertura e di contestualizzazione permette effettivamente di incamminarsi lungo il sentiero della Business Agility in modo efficace, riconoscendo che ci saranno sempre degli ostacoli lungo di esso e che bisognerà fermarsi, capire come superarli, e fare diversi tentativi, ricorrendo alle proprie esperienze e a quanto si è appresso.

Ogni ostacolo superato è un nuovo traguardo nel proprio viaggio che porta a sperimentare e rimettersi continuamente in gioco.

Ecco l’essenza della Business Agility, ovvero la capacità di non “imbrigliare” le persone, e di conseguenza le organizzazioni, in una rete, ma di sviluppare un Clima Organizzativo in grado di stimolare una innovazione continua e dare l’impulso alla strutturazione di una Cultura Organizzativa che renda il tutto “the new normal” da cui ripartire.

AgileEngineering, l’Agile nell’Ingegneria dei Sistemi

AgileEngineering logo

agileconstellation.infoagileengineering.info

Il mondo dell’Ingegneria dei Sistemi è continuamente alla ricerca di nuovi modelli operativi che consentano di innovare rapidamente i propri prodotti, efficientando al contempo la filiera produttiva.

Tipicamente, in essa, si adotta un lifecycle lineare che segue degli step sequenziali ben definiti e rappresentato nel cosiddetto modello a V caratterizzato da 2 flussi:

  • Flusso di Specifica, che si esplica nelle attività a sinistra
  • Flusso di Prova, che si sviluppa lungo la direttrice destra 

I due flussi sono collegati dall’implementazione, dove gli artefatti vengono realizzati.

v model

Questo modello è, però, scarsamente flessibile, con una netta divisione tra progettazione/pianificazione ed implementazione, rendendo costose le modifiche e l’adattamento alle esigenze emergenti.

Resta quindi intrinseca la fragilità dovuta al dettaglio dei requisiti, che si scontra con la realtà dove i clienti riescono a capire ciò che realmente vogliono solo nelle fasi più avanzate di realizzazione del prodotto, proprio dove i costi del cambiamento diventano spesso proibitivi. 

Inoltre, i progetti sono spesso di lunga durata (più anni) e impattano su molti domini differenti, il che enfatizza fortemente l’importanza e la complessità della governance generale e dell’integrazione dei vari elementi costituenti afferenti.

Questi elementi sono fortemente radicati nell’ambito dell’ingegneria dei sistemi e l’Agilità si concretizza nel metaforico azzeramento dell’angolo della V, azione grazie al quale il flusso di specifica e il flusso di testtendono a sovrapporsi completamente, sposando al loro interno le attività di sviluppo, senza inoltre ricorso a team esterni. Ciò permette di velocizzare il sistema dei feedback, in particolare quelli provenienti dai clienti, in modo da catturare gli immancabili cambiamenti da apportare quando ancora il prodotto è in una fase “grezza”, dove i costi annessi sono meno dirompenti.

AgileEngineering supporta operativamente questi aspetti, stimolando i team di ingegneria nell’adozione di una logica “fail fast” (o succeeding fast) su sviluppi coesi, orientati ad obiettivi specifici che si sviluppano su elementi validabili di breve, medio e lungo termine.

Essendo i prodotti dell’ingegneria di sistema dei “manufatti tangibili”, AgileEngineering suggerisce di dividere le fasi operative di sviluppo in tre momenti specifici: InceptionEngineering e Workout

agileengineering poster

In particolare, nella fase di Inception viene realizzato quanto necessario per validare il sistema che ci si appresta a realizzare, focalizzandosi sullo sviluppo di quei componenti abilitanti che ne costituiranno l’infrastruttura portante. In tal modo si ha una fase di “discovery”, spesso caratterizzata da un approccio Lean-based, che consente confronti rapidi con gli stakeholder.

Si adottano, quindi, metodi di rapid prototyping, sfruttando tecnologie emergenti (come, ad esempio, Stampa 3D e Realtà Mixata) in modo da ridurre i costi e consentire di sviluppare rapidamente nuovi prototipi tangibili con cui ingaggiare gli utenti e raccogliere feedback. In questo ambito il ricorso all’MVP (Minimum Viable Change), inteso nella sua corretta accezione di strumento per l’apprendimento, è fondamentale e supporta il tutto in modo concreto.

Quando si è raggiunta una condizione di relativa stabilità, si procede all’Engineering delle parti più malleabili (ovvero le componenti più facilmente evolvibili), apportando gli opportuni sviluppi di consolidamento su quelle meno duttili (ad esempio, la componentistica standard acquisito dal mercato).

Infine, la fase di Workout si occupa di gestire la produzione industriale (di serie) del tutto e di governare gli aspetti di delivery, nonché quelli di esercizio.

L’operatività nelle diverse fasi è affidata a team multidisciplinari, ovvero team composti da un mix di esperti nelle discipline coinvolte (elettronica, meccanica, chimica, software, ecc), che portano avanti le diverse attività necessarie per implementare le capability che caratterizzano il prodotto. 

La sfida di AgileEngineering è quella di utilizzare tutte le tecniche note del mondo Agile e Lean, per favorire la comunicazione nei team e tra i team, in cui, come detto, ci sono esperti di domini diversi spesso abituati a lavorare in relazione ai propri skill più che in funzione di un obiettivo di prodotto che guardi al cliente finale. A tal fine, per favorire la creazione di una “lingua comune”, è fondamentale il ricorso agli strumenti di Visual Management, come task board o, nei casi più evoluti, un vero e proprio approccio Kanban-like che consenta di massimizzare sia la trasparenza sullo stato delle attività, sia l’individuazione dei colli di bottiglia su cui intervenire il prima possibile.

Grazie ad AgileEngineering è possibile ridurre i rischi di diventare non competitivi, andando a stimolare un approccio adattativo in grado di ridurre il lead time e generare soluzioni innovative mantenendo fermi gli standard di qualità di riferimento. Infatti, non bisogna sottovalutare l’impatto che le normative di rifermento hanno sul processo generale, essendo spesso vincolanti e non derogabili per la commercializzazione e l’uso del prodotto stesso.

In conclusione, è possibile affermare che i principali vantaggi che si osservano nell’adozione di AgileEngineering sono:

  • Riduzione del Lead Time, del Time to Market e del Time to Value, grazie all’introduzione di strumenti di fast prototyping e l’utilizzo organico dell’MVP
  • Miglioramento dell’efficienza dei processi o workflow, sfruttando soluzioni ispirate all’Agile e a Lean, unitamente alla loro visualizzazione esplicita.
  • Riduzione del gap comunicativo tra i team di ingegneria e gli stakeholder, grazie allo sviluppo di feedback rapidi e momenti di allineamento costanti.
  • Miglioramento della qualità, sia “reale” che “percepita”.

Alcune declinazioni specifiche dell’ingegneria di sistema riguardano, ad esempio, l’Automotive, l’Aerospace, le aziende Missilistiche, le aziende dei Medical Device e così via.

Ognuno di questi domini può trarre vantaggi evidenti da quanto evidenziato fin ora, declinando ulteriormente le specificità nel proprio contesto e identificando gli strumenti espliciti che meglio supportano la visione complessiva e l’operatività corrente.