Category Archives: Visual Studio

PMI Disciplined Agile: il Manifesto (pt.1)

da pmi logoCon l’acquisizione di Disciplined Agile (DA) da parte del PMI, il procress framework creato da Scott Ambler e Mark Lines entra in una nuova dimensione che lo proietta in un contesto dove l’Agilità è stata per molto tempo vista con diffidenza, ma che da alcuni anni ha ormai intrapreso in percorso di convergenza senza però tradire i propri fondamenti.

Non potrebbe essere altrimenti, visto che la “contaminazione” è una ricchezza e, come più volte ribadito, l’Agilità è un mindset che non deve contrapporsi ad altri metodi, ma che aiuta a trovare una dimensione unitaria, utile all’organizzazione per muoversi nell’ambito di problematiche complesse, trasformandole in opportunità.

Come molti sanno, sono da anni coinvolto attivamente nell’evoluzione di DA e con questo primo post, inizierò a creare una guida introduttiva relativa, in modo da aiutare a capirne l’essenza e guardarlo da una prospettiva pragmatica.

Disciplined Agile Manifesto

Disciplined Agile è fortemente radicato sul Manifesto Agile, proponendone una rivisitazione per ampliarne lo “scope” in relazione alla modernità delle sfide moderne:

Individui e interazioni più che i processi e gli strumenti
Soluzioni consumabili più che la documentazione esaustiva
Collaborazione con gli stakeholder più che negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano

Nonostante l’indiscusso valore degli elementi a destra (non in grassetto), i “disciplined agilist” danno un peso predominante a quelli di sinistra (in grassetto).”

Come si vede da quanto evidenziato in rosso, DA guarda in modo esplicito alle soluzioni consumabili e non solo al software funzionante. Può sembrare una cosa di poco conto, ma rendere una soluzione “consumabile” vuol dire essere pronti affinché i nostri stakeholder possano usufruire in pieno dei relativi vantaggi. Pensiamo, ad esempio, ad una soluzione cloud b2c: in questo caso avremmo sicuramente bisogno di un customer careche supporta gli utenti nel suo utilizzo. È una questione di “working software”? No, ma è vitale per rendere la soluzione utilizzabile.

I principi annessi al Disciplined Agile Manifesto

Insieme ai Valori, il DA Manifesto definisce anche 15 principi, 3 in più di quelli definiti dal Manifesto Agile, sui cui si basa, e che rivede nella stessa misura fatta per il Valori (in particolare da “clienti” a “stakeholder”) 

  1. La nostra massima priorità è soddisfare gli stakeholder rilasciando soluzioni di valore, fin da subito e in maniera continua.
  2. Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
  3. Consegniamo frequentemente soluzioni consumabili, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
  4. Stakeholder e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
  5. Fondiamo i team su individui motivati. Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
  6. Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.
  7. Le soluzioni consumabili sono il principale metro di misura di progresso.
  8. I processi agili promuovono un approccio al rilascio sostenibile. Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
  9. La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.
  10. La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.
  11. Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.
  12. A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
  13. Sfruttare e contribuire a far evolvere le risorse organizzative disponibili all’interno del proprio ecosistema aziendale, e collaborare con le persone responsabili di ciò.
  14. Avere sempre chiaro il flusso di lavoro in modo da riuscire a sviluppare un flusso costante di rilasci che aiuta a ridurre le attività in corso al minimo.
  15. L’ecosistema organizzativo deve evolvere per riflettere e migliorare le attività dei team agili, ma al contempo essere sufficientemente flessibile da supportare gli eventuali team non-agili o ibridi.

I 3 principi aggiuntivi, dal 13 al 15, guardano all’enterprise, ovvero a come supportare l’Agilità a livello complessivo dell’organizzazione, che è implicitamente contaminata in relazione al cambiamento dei team che, a loro volta, ne vengono condizionati.

Durante l’evoluzione stessa di DA (in particolare dall’estensione di Disciplined Agile Delivery a Disciplined Agile), i 15 principi del Manifesto sono stati condensanti focalizzandoli sulle Persone, ottenendo i seguenti 7 principi portanti:

da principles

  • Delight Customers: non siamo focalizzati solo sul soddisfare le esigenze e le aspettative dei nostri stakeholder, ma siamo concentrati sul superarle per stupirli (ottica Lean)
  • Be Awesome: team fantastici sono costruiti intorno a persone motivate che operano in un ambiente arricchito del supporto necessario per raggiungere gli obiettivi individuali e complessivi
  • Pragmatism: cerchiamo di essere il più efficaci possibile, superando la semplice applicazione dell’agilità
  • Context Counts: ogni persona, ogni team ed ogni organizzazione è unica. Individuiamo e facciamo evolvere una strategia efficace data la situazione specifica che stiamo affrontando
  • Choice is Good: contesti diversi richiedono strategie diverse. I team devono essere in grado padroneggiare i propri processi e sperimentarli in relazione alla situazione specifica che devono affrontare. Avere opzioni tra cui scegliere, e individuarne i compromessi, abilita alla generazione di opzioni plausibili
  • Optimize Flow: ogni organizzazione è un Sistema Adattivo Complesso (CAS) di team e gruppi che interagiscono ed evolvono, sia individualmente che influenzandosi a vicenda. Per avere successo è necessario assicurarne un allineamento costante ed ottimale
  • Enterprise Awareness: quando le persone sono consapevoli dell’organizzazione in cui operano, sono motivate a prendere in considerazione le esigenze generali, e non solo quelle locali, in modo da assicurarsi che siano in linea con gli obiettivi complessivi

L’evoluzione dei principi è stata fortemente influenzata da Modern Agile di Joshua Kerievsky e Heart of Agile di Alistair Cockburn, rispecchiando l’attuale wave evolutiva del mondo agile.

 

Per ora è tutto, l’appuntamento è al prossimo post con il DA Poster.

Stay tuned J

How to fix 8000000A error when building VDPROJ

The Microsoft Visual Studio Setup Project is an old technology to create installer developed by Microsoft. It is out of support from nearly a decade and not present in Visual Studio anymore but when I visit customer sites I find legacy technologies and I need to deal with it on the short-term. A couple of… Continue reading How to fix 8000000A error when building VDPROJ

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

Intro In the previous post we’ve described the idea behind the automation we’re trying to implement on a scenario based on MicroFocus Vertica database. How it works This “sandbox” is not a real isolated development workstation. Let’s separate it into two parts, the first one for the development on everything but Vertica (Windows local workstation) … Continue reading DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 01 – development (part 2)

Agile e Robotic Process Automation (RPA), parte 4 – Retrospettiva finale

Eccoci giunti al quarto ed ultimo post della serie dedicata all’Agile nel mondo della Robotic Process Automation (RPA).

Abbiamo visto insieme come si sono svolte le diverse Iterazioni, cosa è stato introdotto come miglioramento progressivo ed evidenziato le lesson learned che riportiamo per avere un quadro d’insieme del tutto:

  1. Essendo l’obiettivo dell’RPA l’automazione della mimica relativa ad un processo, non si ha nella sostanza un utente utilizzatore, ma solo un “committente” che si aspetta un lavoro finito
  2. La priorità delle Technical Story (TS) è implicitamente dettata dal flow del processo e deve essere possibile rivederla liberamente senza vincoli, in funzione delle esigenze di sviluppo. Quindi non è più utile che sia nelle more del PO!
  3. La review tradizionale non è particolarmente utile nell’accezione comunemente nota. Dimostrare il valore di una TS in modo isolato non ha un grande valore, inoltre il PO, Process Owner(come detto nel post precedente), accompagna il team giornalmente nell’analisi degli elementi di dettaglio del processo, per cui alla fine avrà già una visione completa di quanto realizzato
  4. L’uso di un Flow Chart Mapping (FCM) rende subito visibile il flusso dati e i gate di input/output di ogni storia, consentendo una facile valutazione dei risultati

I Valori ed i Principi Agili si sono dimostrati, ancora una volta, assolutamente adatti nell’ambito complesso, soprattutto per aiutare il team promiscuo a trovare armonia interna.

A questo punto facciamo una considerazione sul risultato finale in funzione degli obiettivi ipotizzati.

L’intera azione di sviluppo prevedeva inizialmente l’obiettivo di realizzare 6 Robot, ovvero di automatizzare 6 flow che precedentemente venivano eseguiti manualmente con il coinvolgimento di diverse risorse e Persone, aziendali e non.

Come abbiamo descritto nel primo post, all’inizio del percorso sono stati utilizzati una serie di strumenti (Product Canvas, Elevator Pitch, ecc) per allineare tutto il team intorno a quello che è risultato essere il cuore di tutto il discorso: “creare sistemi in grado di mimare il comportamento umano“.

Quello a cui non abbiamo minimamente accennato sono stati eventuali aspetti di pianificazione annessi. Ebbene, nessuna azione di stima o previsione è stata necessaria perché l’iniziativa era di per sé completamente allineata con il ben noto Iron Triangle rovesciato:

iron triangle planning

Nel dettaglio, si avevano a disposizione 8 mesi di tempo e un budget determinato dal costo delle Persone coinvolte e pochi elementi variabili di incidenza tollerabile. L’approccio è stato quindi quello di iniziare lo sviluppo, capire la velocity (non tanto in termini di una metrica specifica, ma di quanto il team realisticamente fosse in grado di realizzare) e tarare di volta in volta gli obiettivi.

Dopo le prime 3 iterazioni è parso subito chiaro che l’obiettivo dei 6 processi non era raggiungibile, per cui il PO ha cominciato ad esercitare le giuste leve verso gli stakeholder per riallineare le attese, mentre tutto il team (PO compreso, nel ruolo di Process Owner) ha fatto dei ragionamenti per capire come ottimizzare lo sviluppo.

E qui è nata una soluzione interessante: guardando i processi restanti nel loro insieme, è risultato evidente che una parte degli step costituenti relativi era praticamente comune per 4 dei 5 flow rimanenti.

Questo elemento è stato illuminante per rivedere tre elementi strategici:

  • Pianificazione, si è deciso di ri-pianificare il contenuto del portfolio backlog, non più in funzione della sola importanza (valore relativo) del processo, ma adottando un approccio value-reuse driven, in cui si è dato precedenza ai processi che avrebbero consentito di sviluppare per primi i componenti comuni, abbattendo di conseguenza anche i rischi dello sviluppo relativo
  • Metriche di Effort, per supportare una migliore stima dell’effort necessario per le Techincal Story, si sono stabilite una serie di TS campione (5 nello specifico) rispetto alle quali effettuare una stima massiva (Affinity Grouping) di quanto ipotizzato per le iterazioni a seguire. Le TS di riferimento erano caratterizzate da:
    • Numero di oggetti in ingresso
    • Numero di fonti dati sottese
    • Numero di sistemi terzi interrogati
    • Numero di oggetti in uscita 
  • Deep Analysis, il Process Owner ha modifica il suo approccio al refinement, non limitandosi alla sola rappresentazione tramite Flow Chart Mapping (FCM)del processo ma passando ad una vera e propria reingegnerizzazione. Infatti, il PO ha analizzato quali aspetti del processo consentissero allo stesso di superare la soglia del 90% degli impatti positivi, rimuovendo gli step relativi al resto.

Questi tre elementi hanno consentito di avere una visione più chiara di quanto stesse succedendo, rendendo inoltre possibile diminuire lo scope, del singolo processo e complessivamente, in modo da raggiungere un obiettivo finale realistico in chiave iterativa: ovvero, di quello che resta fuori ce ne occupiamo in seguito se serve!

Si chiude qui questa serie di post dedicati ad una esperienza pratica di adozione di un approccio Agile scrum-like nell’ambito della Robotic Process Automation.

Stay tuned J

Agile e Robotic Process Automation (RPA), parte 3 – Flow Chart Mapping

Ci eravamo aggiornati lasciando in sospeso la discussione sul risultato del primo Sprint. 

Ebbene vediamo com’è andata.

Il team ha lavorato molto bene, sviluppando una prima timida sinergia che, anche in relazione alla composizione dello stesso (che vi ricordo era fatta di Persone afferenti a 4 player diversi), di per sé è già un buon risultato che merita dei kudo.

Se veniamo invece alle Technical Story (TS), la situazione si è rilevata un po’ più difficile da comprendere: infatti, se è vero che la maggior parte delle TS sono state completate, è anche vero che è risultato abbastanza difficile rappresentare il valore reale di quanto realizzato. Questo perché le Storie sono subito apparse come “isolate” e, rappresentando tasselli di un flow di esecuzione automatizzato, non è stato possibile valutare nessuna esse in senso atomico e da un punto di vista esplicitamente funzionale.

[Terza Considerazione] Abbiamo quindi appreso una nuova lezione: la review tradizionale non è particolarmente utile nell’accezione comunemente nota. Dimostrare il valore di una TS in modo isolato non ha un grande valore, inoltre il PO, Process Owner (come detto nel post precedente), accompagna il team giornalmente nell’analisi degli elementi di dettaglio del processo, per cui alla fine avrà già una visione completa di quanto realizzato.

Quello invece che è risultato interessante è stata la visualizzazione del data-set ottenuto dall’esecuzione del primo flow parziale realizzato. In pratica si è costruita una semplice vista che, evidenziando di volta in volta il passaggio completato, metteva a confronto lo stato in ingresso con quello in uscita, consentendo al PO di valutare la correttezza del risultato e ponendo le basi per una successiva validazione automatizzata (un RPA dell’RPA J).

A questo punto si è tenuta la prima retrospettiva (classico Strafish) e la problematica primaria affrontata è stata quella di capire come rappresentare in modo più efficace la visione d’insieme e le diverse specializzazioni verticali. In pratica, come riuscire a sfruttare un tool tipo User Story mapping, che però risultava poco efficace rispetto alle più volte sottolineate caratteristiche delle Tecnical Story. La soluzione individuata è stata quella di ricorre ad una rappresentazione grafica del processo, attraverso uno dei più classici strumenti che si conosca: un flow chart.

flow chart mapping

Questo strumento è stato introdotto nel planning dello Sprint 2, consentendo al team di discutere visivamente del processo e andare a esplicitare i 5 elementi di riferimento di ogni Technical Story: Sottosistemi coinvolti, Dati in ingresso attesi (tipologia e set campione per il test), Dati in uscita attesi (tipologia e set campione per il test), Gate di ingresso e Gate di uscita.

 [Quarta Considerazione] Alcuni strumenti comunemente utilizzati per il mapping delle Storie, vanno opportunamente rivisti, considerando gli aspetti tecnici delle storie. In particolare, l’uso del Flow Chart Mapping (FCM) rende subito visibile il flusso dati e i gate di input/output di ogni storia, consentendo una facile valutazione dei risultati.

L’FCM ha permesso al nostro speciale PO, Process Owner, di descrivere il sotto-flow atteso per lo sprint, in funzione dei dati di input di start e quelli di output in end. A questo punto il team si è rituffato nello sviluppo!

Nel prossimo post, che chiuderà la serie, vedremo come sono andati gli sprint successivi e faremo una serie di considerazioni finali.

 

 

Stay tuned J

Agile e Robotic Process Automation (RPA), parte 2 – Il ruolo del PO

Ed eccoci arrivati allo start del primo Sprint!

Dopo aver dedicato alcuni incontri a parlare di Agilità, soffermandoci sui Valori e sui Principi, e aver illustrato il framework Scrum (come detto scelto a livello Corp), il team è pronto per iniziare a sperimentare sul campo e costruire il primo draft di Product Backlog.

Bisogna dire che l’obiettivo complessivo era quello di automatizzare tramite RPA 6 processi con diversi livelli di complessità e che, mediamente, essi interessavano almeno 3 sistemi di gestione differenti. Il grande vantaggio nella fase di Inception è stato quello di avere un neo-PO estremamente esperto di ogni singolo processo, in grado di descrivere in modo minuzioso ogni step relativo e il set di dati fondamentali.

[Prima Considerazione] Ecco quindi una prima considerazione rispetto al tradizionale ruolo di PO: essendo l’obiettivo dell’RPA l’automazione della mimica relativa ad un processo, non si ha nella sostanza un utente utilizzatore, ma solo un “committente” che si aspetta un lavoro finito.

po role reponsability

La validazione di quanto realizzato può essere fatta confrontando i risultati di ogni step con quelli analoghi fatti da un operatore umano (subFlow), o valutando l’intero flow.

Il PO, in questo scenario, non si occupa di formalizzare needs funzionali (sotto forma di Storie o altro), ma, più che altro, è un esperto di processo/dominio/data in grado di descrivere una sorta di flow chart (activity diagram) che consente di suddividere adeguatamente i passi costituente del processo.

Potremmo dire che è più un Process Owner che un Product Owner.

po rpa

Tornando al nostro Product Backlog, è stato deciso di identificare ogni processo da automatizzare come “prodotto” differente, dotato quindi di uno specifico Product Backlog. Per ogni prodotto sono state create una serie di Technical Story (lo so, qualcuno storcerà il naso, ma noi abbiamo ritenuto giusto così) in relazione agli step di avanzamento del processo, individuandone gli aspetti caratterizzanti primari:

  • Sottosistemi coinvolti
  • Dati in ingresso attesi (tipologia e set campione per il test)
  • Dati in uscita attesi (tipologia e set campione per il test)
  • Gate di ingresso 
  • Gate di uscita

Quando la prima versione del Product Backlog è stata completata, il team si è trovato difronte alla necessità di scegliere su quali Tech Story ingaggiarsi nel primo Sprint. In questo caso, non avendo una “storia passata”, si è optato per lasciare allo stesso la scelta di un numero di storie che ritenevano “aggredibili”, senza impiegare tempo in stime o pesi che non potevano avvalersi di alcuna esperienza pregressa e rimandando la “prima pesatura” a consuntivo.

Ogni Tech Story è stata suddivisa, durante il successivo Sprint Plannig, in Task di dettaglio, in cui sono state esplicitate le attività di implementazione e le differenti aree di sviluppo tecniche interessate. Quest’ultimo aspetto è stato fondamentale per gestire la pluralità del team (come descritto nel primo post della serie) e calibrare la loro permanenza in-house, non necessariamente di 5gg a settimana.

Completato il tutto, il team ha cominciato a lavorare sulle singole Technical Stories, adottando la strategia Serial-and-Parallel: il team avvia la prima Storia e lavora in parallelo sui Task di dettaglio e solo in caso qualcuno sia scarico si avvia la successiva Storia, altrimenti ci si concentra sul finirne una alla volta. In tal modo si riduce sensibilmente il rischio di avere troppe Storie avviate e finite solo parzialmente a fine Sprint.

Anche qui è stato riscontrato subito un punto dolente: il rispetto delle priorità indicate dal Product Owner (e implicitamente dal processo). I membri del team hanno ritenuto opportuno rivederle più volte per sbloccare situazioni di stallo dovuto a condizioni tecniche abilitati.

[Seconda Considerazione] Da qui una seconda considerazione operativa: la priorità delle Technical Story è implicitamente dettata dal flow del processo e deve essere possibile rivederla liberamente senza vincoli, in funzione delle esigenze di sviluppo. Quindi non è più utile che sia nelle more del PO!

Detto questo, il team ha utilizzato le canoniche due settimane, allineandosi giornalmente nel classico Daily, per completare quante più Technical Story possibili, con una presenza attiva del PO per rispondere a problematiche di processo/sistema/dati.

Volete sapere com’è andata? Beh.. non vi resta che attendere il prossimo post della serie.

Stay tuned J

Two tech events in Parma, the city of food

SQL Saturday Parma, six years in a row. DevOpsHeroes, four. Parma has been a great place to reach, also for technical events. I’ve started organizing the first SQL Saturday in my birthplace in November 2014. After two years I tried to create a brand-new event, when the DevOps culture started to grow and when the … Continue reading Two tech events in Parma, the city of food

Agile e Robotic Process Automation (RPA), parte 1

Nelle mie ultime esperienze ho avuto l’occasione di sperimentare l’applicazione dell’universo Agile all’interno di un contesto di sviluppo che guarda alla Robotic Process Automation (RPA).

Di cosa stiamo parlando nello specifico?

La Robotic Process Automation (RPA) raggruppa tutta una serie di tecnologie software che hanno lo scopo di automatizzare in modo profondo i processi di back office. Non stiamo quindi parlando di robot fisici o sistemi di alta intelligenza artificiale (almeno in quelli odierni), ma di agenti softwareche sono in grado di completare attività deterministiche e ripetitive che prima venivano effettuate da un operatore umano.

La cosa interessante è che, tipicamente, un robot“attraversa” diversi sistemi, mettendoli in correlazione attraverso lo scambio la gestione dei dati, per portare a casa un risultato unico, spesso la risposta ad un quesito (query) o un report aggregato.

Lo scopo principe di RPA è quindi quello di Mimare il comportamento umano, automatizzando un processo ben delineato che sia suddivisibile in attività e task atomici. Il tutto, ovviamente, con la capacità di ripeterlo all’infinito (fermo restando le condizioni abilitanti) e ottenere sempre un risultato in linea con le attese.

rpa process mimic

Tra i settori che stanno dimostrando maggiore interesse a questa tecnologia troviamo, ad esempio, quello finanziario dove il costo delle attività di back office rappresenta una parte importante delle proprie spese operative. Secondo una indagine condotta da Deloitte tramite il suo Global CPO Survey, la necessità di diminuire questa fetta di costi è la importante per il 30% dei Global Services Leaders.

Ma torniamo all’esperienza pratica.

La prima sfida da affrontare è stata quella di assemblare il team di lavoro (circa 10/11 persone): completamente in outsourcing, anche se co-localizzato per 4gg su 5, ad esclusione del PO (senza alcuna esperienza pregressa nel mondo Agile, ma grandissimo conoscitore dei processi specifici) e alcuni rappresentanti dell’IT interno, fondamentali per l’interconnessione coi sistemi interessati. Il resto del team era composto da 7 tecnici afferenti a tre diverse aziende fornitrici, con 4 esperti dell’ambito RPA e gli altri dei software e del dominio su cui attivare la mimica.

Si comprende quindi che mettere insieme fornitori diversi, con legittimi interessi diversi, e farli remare in una direzione unica non è proprio la cosa più semplice che si possa fare. Inoltre, il Team Lead apparteneva ad una degli outsourcer, per cui c’era un po’ di diffidenza iniziale da parte degli altri. Fortunatamente lo stesso si è rilevato molto competente e con spiccate dote di Leadership, in relazione al contesto e alla sfida che eravamo posti, così come tutti i componenti del neo-team si sono dimostrati ottimi professionisti e interessati all’approccio.

Essendo una sorta di progetto “pilota/sperimentale”, la prima attività che ho messo in campo è stata quella di chiedere ai presenti di lavorare con strumenti per creare un primo sharing dell’iniziativa da realizzare (Product Canvas, Elevator Pitch, ecc). Tali attività sono state fondamentali per inquadrare meglio i diversi aspetti del prodotto e creare una prima azione di Team Building.

rpa board1rpa board2

(le immagini sono volutamente a bassa qualità)

Fatto questa prima attività (che, come ben sappiamo è sempre on-going), tutto il team era allineato sugli obiettivi, sui constraintse sul perimetro d’azione. Il passo successivo è stato quello discutere degli aspetti cardini dell’Agile, utilizzando Scrum come framework ispiratore, anche per scelte calate dall’alto, ma con un’ampia libertà di adattamento.

La maggior parte delle tematiche erano nuove un po’ per tutti, ad esclusione del Team Lead che aveva avuto esperienze in merito e che, su proposta del committente, ha accettato di imbarcarsi nel ruolo di Scrum Master. Complice la volontà generale di provare a fare qualcosa di nuovo, le resistenze rispetto all’adozione di Scrum sono state veramente minime, probabilmente grazie anche al lasso di tempo prospettato per il progetto di 6 mesi, cosa che però non ha portato ad una reazione di indifferenza (vabbè, tanto sta roba passa!), ma a una positiva-curiosità verso il tutto.

Nel prossimo post vi parlerò del primo Sprint e di cosa abbiamo imparato da esso.

 

Stay tuned J

Agile Montessori, l’armonia della perfezione

Una delle caratteriste che spesso ci meraviglia dei bambini è la loro perseveranza nel compiere con estrema attenzione ed esattezza determinate azioni, curandone i particolari in modo quasi ossessivo. Quando sono attratti da un’attività, e finché non la sostituiscono con la successiva, la ripetono più e più volte, pretendendo, in qualche modo, di farla sempre in modo similare (standardizzazione) con l’aggiunta di qualche piccola variazione (sperimentazione).

agilemontessori bimbo puliza

La cosa veramente illuminante è la loro reazione se un adulto tenta di sostituirsi nella definizione della loro “idea di ordine” e di “corretto”, provando a spingere, e in alcuni casi imporre, verso una soluzione differente. Quello che si ottiene è che al primo momento utile (quando è solo, alla nostra prima distrazione, ecc.) il bambino si adopererà per riportare il tutto nell’ordine che aveva precedentemente eletto a quello “giusto”, basato su quanto pazientemente sperimentato ed appreso.
E’ per questo che la Montessori vede sempre i tempi e le soluzioni specifiche di ogni singolo bambino come gli unisci giusti per la sua crescita, riservando agli educatori il ruolo di angelo custode che osserva e non interviene quasi mai (4 principio).
E’ un aspetto incredibilmente similare a ciò che accade se si forza una organizzazione (ma anche un solo team) a seguire una strada che non ritiene idonea per la sua natura: non è possibile costringere le persone a fare qualcosa in cui non credono e di cui non avvertono la necessità, ancor peggio se sono convinte del contrario. Una delle migliori formulazioni di questo concetto è nel processo di cambiamento di Kotter, in cui come primo step del percorso viene identificato il Senso di Urgenza, ovvero il convincimento da parte dei destinatari che sia necessario farlo.

agilemontessori kotter

Ma la cosa che accomuna ancor più quanto avviene nel mondo Agile con quanto in oggetto (riferito al terzo principio del Metodo Montessori: Abituare un bambino a fare con precisione è un ottimo esercizio per sviluppare l’armonia del corpo) è che la ripetitività dell’azione specifica sviluppa un fare preciso e metodico, esattamente come accade quando si utilizza un Improvement Kata per migliorare, adattare e innovare costantemente all’interno di una organizzazione.
In tal modo si acquisisce consapevolezza e padronanza, consentendo di sviluppare un’armonia sociale, sia del singolo che della collettività, rafforzata dal padroneggiare metodi, tecniche e strumenti che consentono di soddisfare gli obiettivi aziendali ma anche quelli motivazionali propri della persona, così come rappresentanti anche in Management 3.0.

agilemontessori mngt30

La capacità di sentirsi realizzati e non essere assimilati a Macchine Banali, trova, inoltre, un naturale sbocco nell’affinamento dell’utilizzo delle pratiche di automation di DevOps (che, ricordiamo, sono diretta derivazione di Lean e di eXtreme Programming) con un robusto utilizzo dei moderni tool a supporto del Deploy e della Delivery. Le persone possono così dedicarsi a quanto le attrae professionalmente (così come i bambini fanno in modo naturale, senza costrizioni) e dare il meglio di se con la massima concentrazione e passione.
Insomma, lasciare le persone libere di sperimentare ed adattarsi è un principio fondamentale che però deve portare a risultati che standardizzano quanto è risultato proficuo per l’organizzazione, in perfetta chiave Lean.

Nei prossimi post parleremo dei 10 principi portanti del Metodo Montessori, provando a confrontarli con i Principi del Manifesto Agile.

Stay tuned :)

La dissipazione dei bug

Per quanto si possa eccellere nella scrittura di codice, esiste una triste verità: nessun programma sarà mai privo di bug! Questo porta a riflettere sul come gestire i bug durante una Iterazione, evitando che il team ecceda la normale capacity prevista e risponda in maniera strutturata ad essi.

Per affrontare la questione, è necessario definire cosa si intende per bug: 

un bug è un funzionamento anomalo che si verifica durante il normale utilizzo del software.

Ora questo porta ad alcune considerazioni fondamentali:

  • Se i test di unità e funzionali evidenziano un problema durate l’iterazione di sviluppo del Product Backlog Item, non si tratta di un bug, ma di un’azione di “correzione” intrinseca all’attività di sviluppo stessa
  • Se il nostro Product Backlog Item è stato validato da Product Owner (e dal key stakeholder), una successiva richiesta di modifica è una “change request” non un bug, e per accoglierla deve essere creato un regolare Product Backlog Item da prioritizzare nel backlog
  • I bug hanno sempre alta priorità di risoluzione, in modo da costruire e mantenere una main-line di sviluppo di qualità, ridurre il costo di risoluzione relativo, e poter ottenere una build affidabile in ogni istante (second way di DevOps)

bugs remove asap

Fatte queste precisazioni, è utile, in fase di Iteration Planning, tenere sempre presente dell’andamento medio dei bug (tre/quattro iterazioni possono essere sufficienti) in modo da riservare una parte della capacity del team proprio per la loro risoluzione. Chiaro che se non si ha un trend decrescente del numero di bug, è necessario individuare un’opportuna azione di riduzione del debito tecnico e approfondire la tematica della Built-In Quality in retrospettiva, decidendo con il Product Owner un opportuno bilanciamento tra nuove funzionalità aumento della qualità.

A tal proposito, Martin Fowler raccomanda il mantra del “Refactoring forever”, ovvero risolvere immediatamente i bug (critici) intervenendo in modo strutturato per pulire il codice (clean code), senza dimenticarsi di aggiungere gli opportuni test di unità funzionali (ma non solo) necessari a irrobustire il codice e supportare adeguatamente la pipeline di deploy a partire dalla Continuous Integration.

La cosa importante è quella di non ricadere nella trappola del Team di Supporto (Support Team): non bisogna istituire un team che si occupa esclusivamente di bug a cui si demandano le relative responsabilità di risoluzione. Ciò ha alcune implicazioni molto evidenti, soprattutto dal punto di vista della Cultura Agile:

  • Il Support Team si sentirà presto un team di serie-B, perché non coinvolto nelle nuove attività ed iniziative
  • Il costo di risoluzione è decisamente più alto visto che il problema non sarà risolto dal team che lo ha (involontariamente) generato
  • Il know-how relativo ai problemi scoperti e risolti dovrà essere condiviso con il team originale che ha sviluppato la funzionalità specifica, causando un ping-pong di informazioni e ulteriori perdite di tempo

Il consiglio è quello di prevedere sempre, per ogni team, una gestione in stile Kanban dei bug, riservando una opportuna capacity dello stesso (la regola 80-20 è un buon punto di partenza se non si hanno dati storici del team)) per gestire i bug e occuparsi del refactoring e irrobustimento del codice: Do it your self!

 

Stay tuned J