PMI Disciplined Agile: l’evoluzione in corso – pt.3

Flex (Flow for Enterprise Transformation) è sicuramente una delle novità più corpose dell’evoluzione di Disciplined Agile.

Può essere visto come l’anima dinamica di DA, in quanto si concentra sullo sviluppo di un Value Streamricamato sulle necessità degli stakeholder, o cliente che sia, abbracciando un mindset chiaramente Lean che suggerisce di concentrati sulla gestione del flusso di lavoro e non su come gestire le persone o il lavoro.

da flex 2020

DA Flex

Flex parte dall’ovvia considerazione che una soluzione preconfezionata non può andar bene per tutti, e che la contestualizzazione è fondamentale per evitare brutte sorprese e resistenze continue: “Fit for purpose” is the greatest measure of “simple.” (la capacità di adattamento allo scopo è la più importante misura di semplicità).

Questo, però, non vuol dire partire ogni volta da zero perché, concettualmente, i passi essenziali per l’implementazione efficace di un Value Stream sono spesso molto simili tra loro, quello che cambia è come vengono implementati singolarmente.

Scopo di Flex è proprio quello di fornire un archetipo che consenta di procedere più speditamente, e sfruttare le forti doti di contestualizzazione di DA per consentire l’implementazione specifica dei vari passi contemplati.

Rispetto alla una prima fase di integrazione (o forse meglio dire annessione, che potete trovare descritta qui), oggi Flex è maggiormente integrato con i (nuovi) Blade di DA, il che lo rende uno strumento molto adatto a creare un’organizzazione “customer centric” che guarda al flusso complessivo di realizzazione di una o più iniziative di business.

Ogni “work center” del Value Stream è associato ad uno specifico Blade che, come abbiamo visto nei precedenti articoli, rappresenta un ecosistema coeso di azioni, relazioni, informazioni e process goal atti a supportare la guided continuous improvement.

Si parte dagli stakeholder per tornare agli stakeholder” è questa la vera anima di Flex.

Lungo il cammino troviamo:

  • Portfolio Management
  • Product Management
  • Program Management (se presenti più team da coordinare)
  • Disciplined Agile Delivery
  • Release Management
  • Business Operation

che non descriviamo di nuovo perché ne abbiamo già parlato, così come i Blade presenti al “centro dell’ellisse” che sono di supporto trasversale, a partire da quello, ovvio, di Continuous Improvement e di Governancepassato per Security, IT Operation e Support.

Una cosa interessante da osservare è l’attenzione posta sul concetto di MBI (Minimum Business Increment), ovvero la quantità minima di valore da costruiredistribuire ed utilizzare in modo che l’iniziativa abbia effettivamente senso dal punto di vista aziendale. 

In tale ottica, Flex spinge a guardare sempre la sostenibilità aziendale di un’iniziativa e non solo il valore intrinseco delle singole funzionalità da rilasciare, supportando un approccio strategico al rilascio continuo.

L’MBI è un concetto interessante e fondamentale per capire cosa mettere in sviluppo, e non va confuso con l’MVP (Minimum Viable Product) che viene inteso da Disciplined Agile nell’accezione originale (Lean Startup), ovvero come la quantità più piccola di lavoro da fare per validare una ipotesi e non l’insieme minimo di prodotto da distribuire.

Stay tuned J

PMI Disciplined Agile: l’evoluzione in corso – pt.3

Flex (Flow for Enterprise Transformation) è sicuramente una delle novità più corpose dell’evoluzione di Disciplined Agile.

Può essere visto come l’anima dinamica di DA, in quanto si concentra sullo sviluppo di un Value Streamricamato sulle necessità degli stakeholder, o cliente che sia, abbracciando un mindset chiaramente Lean che suggerisce di concentrati sulla gestione del flusso di lavoro e non su come gestire le persone o il lavoro.

da flex 2020

DA Flex

Flex parte dall’ovvia considerazione che una soluzione preconfezionata non può andar bene per tutti, e che la contestualizzazione è fondamentale per evitare brutte sorprese e resistenze continue: “Fit for purpose” is the greatest measure of “simple.” (la capacità di adattamento allo scopo è la più importante misura di semplicità).

Questo, però, non vuol dire partire ogni volta da zero perché, concettualmente, i passi essenziali per l’implementazione efficace di un Value Stream sono spesso molto simili tra loro, quello che cambia è come vengono implementati singolarmente.

Scopo di Flex è proprio quello di fornire un archetipo che consenta di procedere più speditamente, e sfruttare le forti doti di contestualizzazione di DA per consentire l’implementazione specifica dei vari passi contemplati.

Rispetto alla una prima fase di integrazione (o forse meglio dire annessione, che potete trovare descritta qui), oggi Flex è maggiormente integrato con i (nuovi) Blade di DA, il che lo rende uno strumento molto adatto a creare un’organizzazione “customer centric” che guarda al flusso complessivo di realizzazione di una o più iniziative di business.

Ogni “work center” del Value Stream è associato ad uno specifico Blade che, come abbiamo visto nei precedenti articoli, rappresenta un ecosistema coeso di azioni, relazioni, informazioni e process goal atti a supportare la guided continuous improvement.

Si parte dagli stakeholder per tornare agli stakeholder” è questa la vera anima di Flex.

Lungo il cammino troviamo:

  • Portfolio Management
  • Product Management
  • Program Management (se presenti più team da coordinare)
  • Disciplined Agile Delivery
  • Release Management
  • Business Operation

che non descriviamo di nuovo perché ne abbiamo già parlato, così come i Blade presenti al “centro dell’ellisse” che sono di supporto trasversale, a partire da quello, ovvio, di Continuous Improvement e di Governancepassato per Security, IT Operation e Support.

Una cosa interessante da osservare è l’attenzione posta sul concetto di MBI (Minimum Business Increment), ovvero la quantità minima di valore da costruiredistribuire ed utilizzare in modo che l’iniziativa abbia effettivamente senso dal punto di vista aziendale. 

In tale ottica, Flex spinge a guardare sempre la sostenibilità aziendale di un’iniziativa e non solo il valore intrinseco delle singole funzionalità da rilasciare, supportando un approccio strategico al rilascio continuo.

L’MBI è un concetto interessante e fondamentale per capire cosa mettere in sviluppo, e non va confuso con l’MVP (Minimum Viable Product) che viene inteso da Disciplined Agile nell’accezione originale (Lean Startup), ovvero come la quantità più piccola di lavoro da fare per validare una ipotesi e non l’insieme minimo di prodotto da distribuire.

Stay tuned J

PMI Disciplined Agile: l’evoluzione in corso – pt.2

Nel precedente post abbiamo cominciato a parlare di come Disciplined Agile si stia rapidamente evolvendo per rispondere sempre più adeguatamente alla sfida di sviluppare la Business Agility all’interno di contesti enterprise.

Dopo aver visto l’evoluzione del toolkit in termini di aree di riferimento, diamo uno sguardo a quelle che sono le novità rispetto ai Process Blade, ovvero i nuovi Blade introdotti e le modifiche apportate a quelli esistenti.

Ricordiamo che i “Blade” sono delle aree di operatività auto-consistenti che interessano azioni specifiche, come ad esempio IT ed HR. Il nome deriva dalla similitudine con i Blade Server (computer server) pensati per essere auto-contenuti e sostituibili all’occorrenza, in perfetta sintonia con il principio “Choice is Good”.

Partiamo dall’evoluzione dei Balde esistenti, sintetizzata dalla figura seguente:

da new blades1

Process Blades evolutions

Come avevamo già accennato nel precedente post, la modifica più evidente è rispetto a DAD che smette di essere un layer e diventa un Process Blade di Disciplined DevOps. La modifica è naturale e dovuta, in linea con l’evoluzione attuale dello sviluppo IT, chiarendo inoltre un punto ambiguo della rappresentazione precedente.

Le altre evoluzioni sono:

  • Governance, frutto della fusione tra IT Governane (leadership, strutture organizzative e semplificazione dei processi) e Control (collaborazione con le aziendali);
  • Information Technology, che raccoglie le specificità del precedente layer DAIT; 
  • Vendor Management, sostituisce e rende attuale le funzionalità di Procurement;
  • Program Management, non subisce modifiche di sostanza (per ora) ma viene spostato a livello di Value Stream, mentre prima era identificato come un lifecycle in DAD;
  • Asset Management, che estende le azioni di riuso a 360gradi, inglobando il precedente Reuse Engineering.

Per quando riguarda i nuovi Blade, abbiamo invece:

da new blades2

 New Process Baldes

  • Research & Development, dedicato alle attività di R&D e in gestazione da oltre un anno;
  • Strategy, basato su Brightlinee finalizzato a supportare gli executive nel colmare il divario tra pianificazione strategica e delivery;
  • Transformation, per il supporto al cambiamento organizzato e fusione dei relativi aspetti di DA, Flex e Brightline.

Come si può intuire molte cose sono in evoluzione e le chiariremo nelle settimane a venire, mentre nel prossimo post daremo uno sguardo all’evoluzione e combinazione di Flex con i diversi Process Blade.

 

Stay tuned J

PMI Disciplined Agile: l’evoluzione in corso

Come più volte ribadito, Il Disciplined Agile toolkit è in continua evoluzione e l’ingresso nella famiglia del PMI ha accelerato questo percorso.

Nel post precedente abbiamo raccontato il mindset con cui oggi esso viene presentato e che ne costituisce il cuore relazionale, grazie ai tre pillar di riferimento: PrincipiPromesse e Linee Guida.

Descriveremo ora come si sta trasformando il DA Poster che rappresenta, di pari passo, lo strumento per inquadrare le strategie di azione nelle diverse aree dell’organizzazione.

Fino ad ora il poster di riferimento è stato il seguente:

da poster

Previous DA Poster

Mentre da poco ne è stato resa pubblica la nuova versione che porta in dote profondi cambiamenti e migliorie:

da poster new

The Disciplined Agile Toolkit

Il perimetro dei diversi layer è stato ridisegnato per meglio descriverne l’animo enterprise di DA e la vocazione di “collante” che da sempre lo caratterizza rispetto all’ecosistema agile e lean in continua espansione.

I nuovi layer di riferimento (frutto di evoluzione, e non rivoluzione) si fondano tutti sul Foundation Layer, andando a mettere a fattore comune tutti quegli aspetti che sono il cuore pulsante del toolkit, allineandolo con il nuovo mindset di riferimento. Per meglio comprendere ciò, si pensi, ad esempio, ai Ruoli che precedentemente erano fortemente concentrati nel layer DAD e sparsi nei diversi Blade, mentre ora sono esplicitati in modo indipendente.

A sua volta DAD non è più un “layer”, ma diventa il Blade centrale del layer Disciplined DevOps, ottenendo due risultati rilevanti: si fa chiarezza sul fatto che i lifecycle non sono blade e si enfatizza che gli stessi non possono più essere considerati in modo separato rispetto all’azione complessiva di sviluppo e deploy.

Il precedente layer Disciplined Agile IT (DAIT) lascia il posto al Value Stream layer, frutto dell’integrazione profonda con FLEX.

da value stream

 DA Value Stream layer

L’obiettivo è quello di focalizzarsi in modo esplicito sul cliente, spostando l’attenzione ad una visione meno incentrata. 

Infine, implicitamente, anche il layer più esterno Disciplined Agile Enterprise evolve di conseguenza, arricchendosi comunque di alcuni nuovi blade e contando sull’evoluzione di alcuni già esistenti.

 

Nel prossimo appuntamento esploreremo proprio come si stanno evolvendo i blade preesistenti e i nuovi blade introdotti.

Stay tuned J

Serie completa: Agile@School 2020

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

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

Alla prossima!

PMI Disciplined Agile: la promessa, la svolta e il prestigio

Non siamo neanche riusciti a terminato il percorso di descrizione di Disciplined Agile, che Ambler e Lines hanno dato vita ad un aggiornamento del toolkit. Come più volte detto, la cosa deve però solo stimolarci, non certo disturbarci, perché significa che il toolkit è vivo e vegeto e si evolve continuamene in chiave kaizen, a piccoli, ma significativi passi.

L’evoluzione è principalmente concentrata nella struttura del toolkit stesso, a partire dalla descrizione del mindset e dal poster. In questo post ci concentreremo sul mindset, dedicando il successivo al poster.

Devo dire che quando ho letto la parte del nuovo libro (libro) che descrive il mindset, mi è subito venuto in mente il film The Prestige, in cui, all’inizio, uno scenografo esperto di illusionismo pronuncia questa frase illuminante a proposito dei giochi di magia:

“Ogni numero di magia è composto da tre parti o atti. La prima parte è chiamata “la promessa”. L’illusionista vi mostra qualcosa di ordinario: un mazzo di carte, un uccellino o un uomo. Vi mostra questo oggetto. Magari vi chiede di ispezionarlo, di controllare che sia davvero reale… sì, inalterato, normale. Ma ovviamente… è probabile che non lo sia. […] Il secondo atto è chiamato “la svolta”. L’illusionista prende quel qualcosa di ordinario e lo trasforma in qualcosa di straordinario. Ora voi state cercando il segreto… ma non lo troverete, perché in realtà non state davvero guardando. Voi non volete saperlo. Voi volete essere ingannati. Ma ancora non applaudite. Perché far sparire qualcosa non è sufficiente; bisogna anche farla riapparire. Ecco perché ogni numero di magia ha un terzo atto, la parte più ardua, la parte che chiamiamo “il prestigio”

Questo, in particolare, per la presenza del pillar “Promises”, ovvero l’impegno concreto che prende un “Agilista Disciplinato” nei riguardi del proprio team e dell’intera organizzazione. Ma è interessane come il toolkit abbia un ruolo proprio come quello dello scenografo di cui sopra: rendere espliciti i “trucchi”, e sfatare il mito che un framework o una metodologia, o una pietra filosofale che si voglia, possa essere la soluzione per ogni problema. Lo ribadisco da sempre: “Persone ed Iterazioni, più che processi e tool”, le organizzazioni sono fatte di Persone e queste sono la vera ricchezza delle stesse.

Ma torniamo al Disciplined Agile Mindset:

da mindset

The Disciplined Agile Mindset

Il DA Mindset è strutturato in 3 pillar: PrincipiPromesse e Linee Guida:

“Ci piace dire che crediamo in questi otto principi, quindi promettiamo l’un l’altro che lavoreremo in modo disciplinato e che seguiremo un insieme di linee guida che ci consentiranno di essere efficaci”

Vediamoli nel dettaglio:

  • I Principi, che guidano le azioni di un Disciplined Agile: Delight customers, Be awesome, Context counts, Be pragmatic, Choice is good, Optimize flow, Organize around products/services, Enterprise awareness. Sui principi non ci soffermiamo, visto che ne abbiamo già parlato abbondantemente qui, tranne se non per evidenziare che sono diventati 8, avendo aggiunto Organize around products/services, che pone il focus sullo stream di lavoro annesso ad un prodotto/servizio e frutto dell’integrazione con FLEX.
  • Le Promesse, ovvero l’impego che i “Disciplined Agilist” si assumono nell’adottare comportamenti che consentono loro di lavorare in modo più efficace:
    • Create psychological safety and embrace diversity, avere la possibilità di esprimersi, non solo in senso lavorativo, senza la paura delle conseguenze negative sullo status, sulla carriera o sulla propria autostima: bisognerebbe sempre sentirsi a proprio agio nell’ambiente lavorativo.
    • Accelerate value realization, migliorarsi costantemente per accelerare la creazione di valore.
    • Collaborate proactively, l’impegno di un “Agilista Disciplinato” è quello di sforzarsi a creare valore aggiunto in ogni sua azione, non solo rispetto alle attività individuali o quelle del team di cui fa parte.
    • Make all work and workflow visible, tutto il lavoro è costamene e trasparentemente visibili a tutti, così come il way of workingdel team.
    • Improve predictability, i team si sforzano di migliorare la predicibilità delle proprie attività, per consentire la collaborazione e l’auto-organizzazione in modo più efficace. In tal modo si aumentano le possibilità di assumersi impegni sostenibili nei confronti degli stakeholder.
    • Keep workloads within capacity, le attività su cui il team si ingaggia sono sempre bilanciate in relazione alla sua reale capacità contestuale.
    • Improve continuously, un team DA si impegna costantemente a individuare e sperimentare nuovi modi per migliorare i processi e il proprio way of working.
  • Le Linee Guida, che suggeriscono azioni concrete da mettere in campo:
    • Validate our learnings, l’unico modo per diventare “fantastici” è sperimentare ed adottare, se la sperimentazione ha dato esiti interessati, nuovi modi di lavorare in sinergia.
    • Apply design thinking, entrare in empatia con il cliente, ovvero provare a capire il suo ambiente e le sue esigenze prima di sviluppare la soluzione. 
    • Attend to relationships through the value stream, le interazioni tra le persone coinvolte in tutta la filiera produttiva (e non solo) sono fondamentali, indipendentemente dal fatto che facciano parte o meno del team specifico.
    • Create effective environments that foster joy, una strategia chiave, per raggiungere un ambiente sereno e piacevole, è quella di consentire ai team di auto-organizzarsi, scegliendo il proprio WoW (e come farlo evolvere), la struttura organizzativa e gli ambienti di lavoro stessi.
    • Change culture by improving the system, per migliorare costantemente un sistema, è fondamentale far evolvere sia le sue componenti, sia in senso assoluto che nelle interazioni relative tra esse.
    • Create semi-autonomous, self-organizing teams, anche se i team autonomi sarebbero l’ideale, bisogna sempre ricordarsi che ci saranno sempre dipendenze da altri team, sia a monteche a valle.
    • Adopt measures to improve outcomes, per sapere se si sta migliorando è fondamentale che i team scelgano ed utilizzino metriche che consentano di fornire approfondimenti su come stanno andando le cose, fornendo visibilità del tutto.
    • Leverage and enhance organizational assets, i team devono essere liberi non solo di adottare risorse pre-scelte (tipo tools), ma anche di scoprire come migliorarle, per se stessi e per gli altri, e sperimentare di nuove.

Come si può intuire, il mindset Disciplined Agile fornisce un ecosistema di base da cui iniziare, evidenziando come sia fondamentale non solo “essere agili”, ma anche “fare agile”, ovvero avere gli strumenti che permettono di concretizzare quanto promesso già dal Manifesto Agile: 

è meraviglioso avere persone che vogliono lavorare in modo collaborativo e rispettoso, ma se poi non sanno come farlo, non faranno molta strada! 

Ricordo, per chi è interessato ad approfondire DA ed avviare anche un percorso di certificazione, che è ancora possibile iscriversi al prossimo virtual workshop del 6 e 7 maggio.

 

Stay tuned J

Agile@School – Anno quinto, ep. 8

Siamo infine giunti al termine della nostra avventura “agile” coi ragazzi del I.I.S.S. Gadda; è stato un viaggio pieno di concetti nuovi, di abitudini per lo più sconosciute e difficili da fare proprie, soprattutto in un percorso così breve. Cosa avranno imparato i ragazzi e cosa sarà rimasto loro per il futuro? Intanto, scopriamo com’è andata la presentazione dei progetti.

Esaminare il file README e le grafiche delle applicazioni

Nella precedente lezione Pier-Paolo ha dato un paio di esercizi: compilare il README.md dei progetti GitHub, visualizzato in automatico all’apertura del repository da browser e realizzare alcuni mock-up dell’interfaccia grafica per le applicazioni che hanno sviluppato finora. Eravamo curiosi di capire come i ragazzi si sarebbero immaginati la propria applicazione, così come quale sarebbe stata la loro “sensibilità” verso la user experience.

Già dalle diverse modalità con cui i progetti sono stati presentati abbiamo notato con piacere il buon livello di organizzazione e affiatamento dei team. In particolar modo ci ha colpito il team TEP, che non solo ha realizzato un file readme corposo, con una descrizione estesa delle funzionalità dell’applicazione e istruzioni piuttosto dettagliate per l’apertura in locale del loro progetto, ma anche ricco di linee guida da seguire per la creazione della parte grafica, con i colori dell’applicazione, gli stili, ecc.

Le diverse schermate sono poi state descritte dai rispettivi creatori, tuttavia risulta evidente la coerenza generale con cui queste sono state ideate. Nonostante la grafica fosse minimale (com’è giusto che sia in un mock-up), questa risultava di immediata comprensione e fruibilità da parte di un possibile utente finale, per cui sarebbe stata tranquillamente impiegabile in una app reale.

Durante la visione del codice è risaltato il corretto utilizzo del branching negli sviluppi (affrontato in prcedenza) portati avanti dai vari membri.

Il secondo gruppo a dare soddisfazione è stato quello che ha progettato il Casinò. File readme ben compilato, è vero, ma degno di nota è stato soprattutto il mock-up della loro applicazione: una sola schermata, ma molto vicina ad una vera pagina iniziale di un sito di gaming, poiché costruita con molto colore e con tanta grafica. Non solo, anche funzionante!

Gli altri due gruppi sono riusciti a realizzare dei mock-up significativi, ma con qualche “pecca”: quello presentato dal team CUP, impaginato bene ma troppo simile a un sito vero e proprio, tanto era ricco di contenuti. Non è stata sottolineata la modalità di utilizzo dell’applicazione. I ragazzi del team ClasseViva sono stati più “in tema”, ma le schermate presentavano qualche incertezza a livello di esperienza utente. Pier-Paolo ha quindi suggerito di scegliere i componenti dell’interfaccia in modo da renderla più intuitiva e immediata per l’utente finale (ad esempio, prediligere i pulsanti invece delle tendine di selezione e via discorrendo).

Tirando le somme

In queste otto lezioni abbiamo parlato di come ci si approccia allo sviluppo “agile”: cosa sono le user story e come queste diventano work item in un sistema di gestione dei progetti (in particolare Azure DevOps); cosa sono le boards, come si utilizza il backlog e la presa in carico dei task; infine, come sia importante abituarsi alle cosiddette cerimonie (stima dei work item, review quotidiana, etc.). Abbiamo poi complicato il tutto coinvolgendo Git e le sue caratteristiche più avanzate, come ad esempio il branching e la risoluzione dei conflitti, nonché la necessità di collegare la gestione del codice ai work item per tracciare contemporaneamente gli sviluppi e l’andamento del progetto. Infine abbiamo condito il tutto con qualche concetto normalmente tralasciato quando si parla di sviluppo, come la creazione della documentazione (tecnica e funzionale) e la realizzazione di mock-up per la UI.

Conclusioni

A ben guardare, anche se per me il tempo è quasi volato, abbiamo fatte vedere davvero tante cose a questi giovani. Confidiamo che per gli studenti il corso (seppure il nome è riduttivo vista l’esperienza) non sia stato semplicemente uno fra tanti, ma che sia visto come un punto di partenza, uno stimolo in più per approfondire e fare propri tutti i concetti, soprattutto per quando si troveranno ad affrontare un’esperienza lavorativa. In più, la difficoltà imprevista della quarantena (a nostro avviso, affrontata alla grande) ci ha “costretti” a condurre il corso in modalità online. Beh, possiamo ritenerci decisamente soddisfatti.

Chiudo (un po’ a malincuore) ringraziando in primis il professor Christian Memoli e i dirigenti dell’I.I.S.S. Gadda, che ci hanno nuovamente dato fiducia nel portare avanti il progetto Agile@School; naturalmente i ringraziamenti si estendono, al nostro docente ormai ufficiale, Pier-Paolo, che ha svolto un lavoro eccellente, di cui ero praticamente certo.

Last, but not least non posso che ringraziare anche i ragazzi stessi, sia per aver sopportato le nostre pressioni, sia per aver ascoltato e messo a frutto quanto imparato: senza di loro questo progetto non avrebbe neanche senso di esistere!

Stay tuned per il prossimo anno…

Agile@School – Anno quinto, ep. 7

Settima lezione. Questa volta non parleremo dell’essere “online” a lezione come precedentemente descritto, ormai è un dato di fatto. Notizia di oggi, invece, quella che oltre agli esami di maturità effettuati online, in caso di protrarsi della situazione di emergenza, a settembre tutte le lezioni verranno tenute in didattica a distanza. In tal caso direi che siamo già pronti.

In questa lezione, i ragazzi hanno potuto provare con mano cosa accade quando non si applica una metodologia agile; il professore si infuria! Ma quali sono stati i passi falsi? Proviamo a vederli più in dettaglio, al fine di analizzare meglio la problematica ed evitare che si ripeta in futuro.

Uso scorretto degli strumenti e disorganizzazione

In un caso, il codice scritto da ciascuno dei membri di un team non è stato portato sul repository GitHub, bensì unicamente memorizzato sul proprio computer. E non è nemmeno stato installato il software necessario per interfacciarsi al source control. Nell’altro, non siamo stati in grado di vedere nulla. Indovinate il motivo… nessuno dei membri del gruppo aveva a disposizione un computer dal quale poter condividere lo schermo, poiché erano tutti collegati solo tramite smartphone.

Entrambi i casi rappresentano punti critici nell’adozione dell’agile development:

  • nel primo, la mancata adozione degli strumenti e dei processi scelti, che in un ambito aziendale hanno una precisa ragione d’essere. Possibili conseguenze sono disallineamento nel codice e introduzione di anomalie, se non addirittura perdita di codice (“se si rompe il PC?”);
  • il secondo, la mancanza di organizzazione, che è un sottoinsieme della mancanza di comunicazione, punto chiave della mentalità agile: in questo caso, pensate alla “brutta figura” che si fa nel non presentare nulla ai committenti perché nessuno ha un computer. Quasi anacronistico. E pensare a un piano di riserva?

Torniamo alla teoria: la documentazione

Siamo certi che i ragazzi abbiano imparato tanto da questa serie di difficoltà. Tuttavia, nonostante il blocco, la lezione è andata avanti con un po’ di teoria. Oggi è stato il momento della documentazione, aspetto spesso trascurato, se non frainteso, dello sviluppo del software. Avete sentito bene, dello “sviluppo del software”. Nessuno si può salvare, nemmeno gli sviluppatori.

Pier-Paolo ha quindi evidenziato la differenza fra la documentazione tecnica e quella funzionale, entrambe necessarie, ma diverse sia nell’obiettivo/destinatario che nella stesura. Se nella prima è possibile adottare un linguaggio di settore e scendere nel dettaglio delle implementazioni (pratica consigliata per favorire la documentazione interna del team), nella documentazione funzionale troveremo una descrizione dell’operatività, corredata di schermate ed esempi concreti. Non dimentichiamo che quest’ultima è rivolta soprattutto all’utente finale del software.

Per far capire meglio questo aspetto abbiamo mostrato ai ragazzi alcuni esempi di quanto realmente realizzato sul lavoro e abbiamo dato loro due semplici esercizi: uno, provare a compilare il file README.md sul repository GitHub, con una descrizione del proprio progetto e le istruzioni per scaricarlo e aprirlo; due, disegnare alcune schermate di come immaginano l’interfaccia utente che il loro software deve avere, utilizzando gli strumenti di mocking che preferiscono.

Conclusioni

La lezione si è chiusa con la presentazione del codice degli altri gruppi, quelli che hanno commesso meno errori dei primi. Una cosa ci ha colpito in particolare, la realizzazione del progetto “Casinò online”, in quanto i ragazzi hanno già adottato una soluzione che facilita l’integrazione del codice in un’interfaccia grafica; un approccio quasi da architetti software, bravi!

Ci avviciniamo purtroppo alla fine del nostro percorso, alla sfida finale, quasi al boss di fine gioco. La prossima volta i ragazzi dovranno presentare tutto quanto fatto. Siamo proprio ansiosi di vedere come lo step finale verrà affrontato da ognuno di loro. Le scelte di chi presenterà, come, gli strumenti ed, ultimo ma non per importanza, come gestiranno i tempi.

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