PMI Disciplined Agile: Disciplined Agile IT (pt. 5)

In questo nuovo appuntamento dedicato a Disciplined Agile ci focalizzeremo su Disciplined Agile IT (DAIT).

da f1

DAIT fornisce un quadro d’insieme dei processi e delle azioni da implementare per ottenere una efficace integrazione tra le iniziative di business e le derivate azioni intraprese dall’IT, siano esse relative a nuovi prodotti o alla trasformazione di servizi in essere.

da dait workflow

DAIT Workflow

L’obiettivo è quello di consentire una governance chiara e trasparente delle diverse iniziative di un’organizzazione IT, consentendo di misurarne il valore e i benefici ottenuti.

Per raggiungere questo obiettivo, il toolkit introduce i seguenti Process Blade:

  • Continuous Improvement: si occupa di facilitare la condivisione della conoscenza all’interno dell’organizzazione, in modo da supportare il miglioramento continuo in modo sistematico. 
  • Enterprise Architecture: si concentra sulle dinamiche che caratterizzano lo sviluppo e l’evoluzione di una Disciplined Agile Enterprise Architecture (DA EA), ovvero su come rendere le strutture ed i processi aziendali flessibilifacilmente ampliabilifacilmente evolvibili. Il cuore della DA EA è l’esplorazione collaborativa ed evolutiva, realizzata in modo sensibile al contesto grazie alla collaborazione continua tra gli enterprise architecte i team di delivery.

Come gli altri process blade, anche l’Enterprise Architecture ha una fitta rete di relazioni e dipendenze con il resto degli elementi e processi dell’organizzazione.

da ea workflow

Enterprise Architecture Workflow

  • People Management: nota anche come gestione delle risorse umane(HR), gestione dei talenti,gestione del personale, ecc. Ha l’obiettivo fondamentale di gestione il percorso di crescita delle persone, attraendo e trattenendo talenti in grado di creare team fantastici
  • Portfolio Management: affronta il modo in cui un’organizzazione IT identificaassegnaleprioritàorganizza e governa le diverse attività. Discipline Agile Portfolio Management cerca di farlo nel modo più flessibile possibile supportando la creazione di valore sostenibile nel lungo periodo. Le attività IT, in genere, includono:
    • attività di delivery
    • team di sviluppo stabili
    • esperimenti di business (sulla falsariga di Lean Startup)
    • mantenimento efficace delle soluzioni esistent

Il flusso di relazione con gli altri process blade e i diversi aspetti organizzativi è riassunto nella figura seguente, che evidenzia come l’attività di Portfolio Management “attinge” e condivide informazioni con le diverse funzioni al fine di riallinearsi costantemente con lo stato reale delle attività grazie a quella che viene definita Development Intelligence.

da portfolio workflow

 Portfolio Management Workflow

  • Product Management: include le azioni di identificazioneed evoluzionedella Visione Aziendale della propria organizzazione. In sintesi si occupa di: 
    • identificare e dare la priorità ai potenziali prodotti/soluzioni
    • stabilire le priorità e allocare le funzionalità relative ai prodotti in fase di sviluppo
    • gestire le dipendenze funzionali tra prodotti
    • commercializzare i prodotti ai potenziali clienti

DA Product Management si fonda sulla gestione del prodotto in modo collaborativo ed evolutivo, riflettendo costantemente sul contesto organizzativo in essere.

  • (Lean) IT Governance: si occupa di sviluppare l’opportuna leadership, le opportune strutture organizzativesemplificare iprocessi al fine di consentire all’IT di lavorare come partner strategico al fine di massimizzare la capacità dell’organizzazione di produrre continuo valore per i clienti. 
  • Reuse Engineering: si concentra sulla creazione, la gestione, il supportoe la governancedelle risorse riutilizzabili. Il Reuse Engineering è spesso guidato dal team di enterprise architecture, anche se l’approdo più efficace è quello di disporre di un team specifico.

da dait process blades

DAIT Process Blade

Come visibile dal DAIT Workflow, questi process blade sono strettamente legati tra loro da una fitta rete di dipendenze, mai gerarchiche, ma sempre cicliche e in chiaro allineamento con la logica di continuous and fast feedback del mondo Agile. Nello specifico, gli archi relazionali evidenziano gli elementi di congiunzione, i manufatti se si vuole, che i diversi process blade si scambiano per allinearsi sugli aspetti che li condizionano in modo congiunto.

Disciplined Agile IT si occupa, quindi, della sovrastruttura minima indispensabile per garantire una efficace collaborazione e coordinamento tra tutte le anime che supportano la creazione di soluzioni (oltre il prodotto, quindi), pensate per deliziare i propri clienti.

Si conclude così il nostro quinto appuntamento dedicato a PMI DA. Nel prossimo approfondimento guarderemo più da vicino Disciplined Agile Enterprise.

Stay tuned J

Agile@School – Anno Quinto (2020)

Anche per l’anno 2020 siamo stati coinvolti per continuare il progetto Agile@School, svolto in collaborazione con la scuola I.I.S.S. Gadda di Fornovo. Questa continuità negli anni è sicuramente un buon segno, perché significa che negli scorsi anni il progetto ha dato i suoi frutti e che l’esperienza sul campo acquisita dagli studenti è stata utile.

Ma, per chi ci segue da poco, descriviamo innanzitutto in cosa consiste il progetto Agile@School.
Questo progetto è nato nel 2016 con l’intento di far conoscere agli studenti il cosiddetto modo di lavorare agile, che consiste nell’adozione di tutta una serie di comportamenti e discipline orientate alla collaborazione, al team working e alla condivisione e rielaborazione di informazioni, che stanno trovando sempre più larga diffusione nel campo dello sviluppo software (ma facilmente applicabili anche in altre professioni). La nostra impressione è che negli ambienti educativi si dia ancora troppa importanza all’insegnamento della programmazione pura (indipendentemente dal linguaggio scelto) a scapito di quanto sta “a contorno”, mentre saper programmare e basta è sempre meno sufficiente affinché gli studenti siano più preparati all’ingresso nel mondo del lavoro.

Edizione 2020

Quest’anno abbiamo delle novità: la prima, l’insegnante! A parte infatti la prima lezione che è stata quasi unicamente “conoscitiva”, di presentazione (sia da parte dei ragazzi, sia da parte nostra), in cui siamo stati presenti in due, le prossime lezioni saranno tenute principalmente da Pier-Paolo Mammi, uno dei nostri nuovi colleghi di lavoro, con il quale seguiremo il progetto direttamente “sul campo”.
Altra novità: mentre nelle edizioni passate gli studenti sono stati guidati dall’inizio alla formazione dei team e alla scelta dei progetti, nell’edizione attuale le squadre sono già formate e ognuna ha già portato avanti lo sviluppo software del progetto assegnato (li vedremo nel seguito). Avremo quindi l’occasione di concentrarci maggiormente sulla parte organizzativa del lavoro “a regime” e di mostrare loro le applicazioni dell’agile development, nonché l’utilizzo di strumenti informatici a supporto, che noi stessi utilizziamo nel nostro lavoro.

Il piano d’attacco

I punti principali sui quali insisteremo saranno principalmente tre:
– Team working: strumenti di collaborazione e condivisione, boards;
– Gestione del progetto in modalità agile: cerimonie, utilizzo di AzureDevOps e gestione degli sprint;
– Controllo del codice sorgente: utilizzo di Git e integrazione con AzureDevOps.

Terremo sicuramente delle spiegazioni più teoriche, ma l’ottica sarà quella di far applicare il più possibile i metodi direttamente ai team di studenti, perché è con la pratica (e la perseveranza) che si fissano meglio i concetti. Proveremo inoltre anche ad “aumentare la posta in gioco”, utilizzando in alcuni casi durante le lezioni una terminologia più aziendale che, se da una parte potrà essere poco gradita dai ragazzi, dall’altra li renderà più preparati all’ambiente professionale.

L’impatto

I ragazzi erano inzialmente un po’ timidi, come è lecito aspettarsi quando incontrano qualcuno di nuovo, ma pian piano si sono un po’ sciolti. Abbiamo poi chiesto ai team di presentare brevemente i loro progetti, descrivendone le funzionalità e indagando in particolar modo sulle funzionalità specifiche che prevedono di implementare, a chi è rivolto il software, con quali modalità sviluppano e come si passano codice e documentazione. Questo per avere un’idea di come hanno impostato il loro lavoro, per esempio se avessero già previsto della documentazione condivisa, piuttosto che un sistema di versioning. Diciamo che qui dovremo lavorare con impegno!

I progetti

La classe è stata suddivisa in quattro team, ciascuno composto da 4/5 studenti, di cui uno di questi durante le presentazioni è stato “eletto all’unanimità” come Leader. E qui va un doveroso ringraziamento al professor Christian Memoli, incaricato di seguire la classe, che si fa costante premura di insegnare ai ragazzi i concetti dell’agile development, al di là della pura e semplice programmazione!

Questi sono i progetti scelti dagli studenti, per i quali è già presente una buona base di codice:

Progetto Casinò
Il progetto consiste nella realizzazione di una serie di tipici giochi da Casinò (Black Jack, Roulette, etc.).

Progetto ClasseViva
Gli studenti realizzeranno una versione alternativa e migliorata dell’attuale sistema di gestione delle presenze in aula, integrandolo con notifiche e messaggistica fra professori e genitori.

Progetto CUP
I ragazzi vogliono realizzare un software per la gestione online completa delle prenotazioni delle visite sanitarie.

Progetto TEP
Il software gestirà la prenotazione, l’emissione e la gestione di biglietti per le linee TEP da parte dei cittadini, comprensivo di parte amministrativa per i dipendenti.

Prossimamente

La prima lezione introduttiva al mondo dell’agile si è poi conclusa con l’assegnazione dei compiti a casa ai team. Dopo aver impostato su AzureDevOps un ambiente TFS dedicato al progetto, comprensivo di repository Git per i quattro progetti, abbiamo chiesto ai ragazzi di caricare il loro codice sorgente sul proprio repository e di cominciare a inserire i Product Backlog Items, compilati con le user stories e le attività.
Da qui partiremo nella prossima lezione per espandere i concetti oggi solo accennati, relativi all’utilizzo di AzureDevOps per la gestione delle attività e di Git come sistema di versioning del codice sorgente.

Stay Tuned.

PMI Disciplined Agile: Disciplined Agile DevOps (pt.4)

Continuiamo ad esplorare Disciplined Agile, concentrandoci sul livello immediatamente successivo a Disciplined Agile Delivery, ovvero Disciplined DevOps.

da f1

Disciplined DevOps è la concretizzazione disciplinata del principio della Continuous Delivery, ovvero un efficiente Value Stream in grado di portare continuamente nuovo valore nelle mani degli stakeholder. 

Ma cosa rende DevOps “disciplinato”?

La sintesi la si incontra nella specifica definizione data da DA:

“Disciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.”

da disciplined devops

Disciplined DevOps

Nella sostanza, non sono solo i Dev e gli Ops chiamati a collaborare per il successo di una iniziativa di business, ma lo è l’intero ecosistema a supporto di essa

Questo aspetto è fondamentale, anche in relazione alla crescente moltiplicazioni di acronimi come: DevSecOps, DevDataOps, DevXXXOps, ecc. Non ha alcun senso inventare nuovi acronimi… tutto deve essere oliato perfettamente, grazie a cultura/pratiche/automazioni adeguate, in modo da ridurre gli sprechi lungo il value stream ed avere un processo di delivery adeguato basato su un deploy efficiente.

Proprio l’efficienza è un aspetto fondamentale: ogni attività, progetto, elemento, deve essere sempre facilmente collegabile ad una specifica iniziativa di business! Se ciò non è possibile, allora bisogna fermarsi e riflettere se ciò che si sta realizzando non sia un “tecnoware”, ovvero un’attività fine a sé stessa.

Nella sostanza, DA suggerisce di estendere gradualmente l’approccio DevOps alle varie funzioni coinvolte, in modo da far maturare progressivamente nel proprio contesto la Cultura necessaria a tale cambiamento.

da disciplined devops evo

Estendere gradualmente DevOps

Sicuramente non sorprende come il primo passo sia quello di abbattere lo “storico” muro tra Dev e Ops, abbattendo i silos comunicativi ed operativi annessi, proprio come suggeriscono le “Three Ways” di DevOps: FlowFeedback & Experimentation and Learning.

Disciplined DevOps individua 5 process blade espliciti, oltre a “inglobare” Disciplined Agile Delivery descritto nel post precedente:

  • IT Operations, fornisce un ecosistema IT affidabile. Si tratta di garantire l’opportuno livello di Quality of Servicesai propri utenti, cosa che può risultare non banale nelle organizzazioni con molti sistemi legaci e alto debito tecnico annesso. 
  • Support, anche Help DeskEnd-User support, si concentra nell’aiutare gli utenti finali a lavorare con le soluzioni realizzate. Idealmente, le soluzioni dovrebbero essere utilizzate senza il bisogno di nessun supporto in merito, ma spesso ciò non accade e il “support” è “l’ultima linea di difesa” per Deliziare i Clienti con i propri sforzi.
  • Security, il relativo focus è quello di attivare le azioni necessarie a proteggere l’organizzazione da minacce informatiche, virtuali o fisiche che siano. Ciò include procedure come la governance della sicurezzae la gestione delle vulnerabilità. Il tutto impatta sulla capacità di ripristino di emergenza e continuità aziendale, e deve essere un aspetto fondamentale della cultura organizzativa.
  • Data Management, la gestione dei dati è “lo sviluppo, l’esecuzione e la supervisione di piani, politiche, programmi e pratiche che controllano, proteggono, forniscono e migliorano il valore dei dati e delle risorse informative” [Data Management Body of Knowledge]. Per raggiungere tale scopo, DA promuove un approccio pragmatico e semplificato alla gestione dei dati che si adatta al resto dei processi IT: ottimizzare l’intero flusso di lavoro, non sub-ottimizzando la strategia di gestione dei dati. Una gestione dei dati, agile e disciplinata, è una gestione evolutiva e collaborativa, grazie a strategie concrete che forniscono i dati giusti al momento giusto alle persone giuste.
  • Release Management, si occupa della gestione dei rilasci, grazie alla pianificazione, il coordinamentoe la verificadella distribuzione (deploy) delle soluzioni in produzione. Il versioning richiede la collaborazione tra Dev e Ops, cosa che l’approccio agile può portare ad essere anche un’unica entità grazie al concetto di “you build it, you run it

da disciplined devops process blade

DevOps Process Blades

Per concretizzare ed attuare i DevOps Process blade, raggiungendo la pienezza di Disciplined DevOps, DA suggerisce una serie di strategie che afferiscono ad essi:

  • General Strategies(Collaborative work, Automated dashboards, ecc)
  • Teaming Strategies(Production hand-off, Warranty period, ecc)
  • Development Strategies(Canary tests, Split tests, ecc)
  • Operations Strategies(Solution monitoring, Standard platforms, ecc)
  • Support (Help Desk) Strategies(Online information, Online discussion forums, ecc)
  • Release Management Strategies (Release windows, Release train, ecc)
  • Data Management Strategies(Data and information guidelines, Quality data sources, ecc)
  • Security Strategies(Build “rugged software, Automated separation of duties, ecc)
  • Enterprise Architecture Strategies(Reuse mindset, Technical-debt mindset, ecc)

Dovrebbe risultare a questo punto evidente come Disciplined DevOps sia un passo fondamentale nella creazione di una organizzazione agile, consentendo di portare efficacemente la soluzione a “casa” degli stakeholder, prediligendo rilasci brevi e feedback costanti.

Si conclude così il nostro quarto appuntamento dedicato a PMI DA. Nel prossimo approfondimento guarderemo più da vicino Disciplined Agile IT.

 

Stay tuned J

Show Reporting Services usage statistics with Grafana

Introduction

In this post, we will describe an efficient way of showing the usage statistics of our SQL Server Reporting Services hosted reports. Most of the queries below have been addressed in another article published by Steve Stedman. Even though they are really useful, the article shows their results through SQL Server Management Studio.

The problem

One of the problems that often occur in our organization as well as some of our customers, is to get immediate feedback about usage statistics of reports. Usually, the request of creating reports is out of control and some of them are executed only “that time” and not anymore. In the worst-case scenario, many of them aren’t executed at all and some of them could become even overlapped or duplicated.

Therefore, it is important to know the usage statistics, user by user and report by report, to make the reader aware of them, let him interpreting the values of the same query in multiple ways and graphical layouts. While this is not possible with a tabular format (unless you export the values using any external tools such as Excel) it is simpler when it comes to a dashboard.

Our solution: Grafana

We considered two factors: simplicity and efficiency, in order to make this first-sight dashboard. Grafana enables us to get both of them, as well as being very powerful and immediate. Even though this is not the right definition for it, we can say that “it is a portal to create dashboards using connectors, which support the most famous tools that return data”. We can find them in its marketplace. For instance, tools such as PRTG and Prometheus (monitoring), NewRelic (APM), also SQL and NoSQL data sources are supported:

Obviously, we can find SQL Server. Also, we can contribute to create others, as well as to modify Grafana itself, since it is completely an Open Source project. Examples of possible graphical representations are listed below:

Creating a dashboard is really simple. Just add each panel with a button.

Then, write the query and modify settings to get the desired type of representation.

As mentioned before, the connectors are many. Once selected you can to configure them with parameters:

If you would like to install and configure Grafana you can read the official documentation which also includes a short guide that illustrates how to take your first steps.

That’s it!

Conclusions

With half a day of work (including the setup of the server), we have solved one of the most important problems of our customers, derived from the lack of awareness of reports deployed in production environments. We did it with very little effort and the result, as you can see, is pleasant and effective. Everything is now ready to be published every time we update the dashboards also through a delivery software (Octopus Deploy, Jenkins or Azure DevOps) so all these things fall into the second and third way of DevOps (according to The Phoenix Project): Immediate Feedback and Continuous Improvement.

Stay Tuned!

PMI Disciplined Agile: Disciplined Agile Delivery (pt.3)

Come visto nel precedente post della serie, Disciplined Agile ha al centro della propria azione Disciplined Agile Delivery (DAD) ovvero la capacità di realizzare soluzioni in modo disciplinato con team che fanno propri i Valori, i Principi e le Pratiche più consolidate del mondo Agile e Lean.

da f1

DAD è anche storicamente la prima area di Disciplined Agile ad essere stata formalizzata e, come già accennato nel post precedente, consiste in un approccio hybrid-agile allo sviluppo di soluzioni IT, in cui le Persone coinvolte fanno propria una cultura basata sull’apprendimento costante. 

DAD si basa su 8 principi portanti:

  • People-first, sono le persone a condizionare i processi e non viceversa
  • Goal-­driven, focus su goal chiari
  • Hybrid agile, scegliere le pratiche opportune da diversi framework/metodologie
  • Learning-­oriented, apprendimento continuo
  • Full delivery lifecycles, dall’idea alla consegna
  • Solution focused, soluzioni consumabili, non solo “finite”
  • Risk-­value lifecycle, gestione esplicita e profonda del rischio
  • Enterprise aware, consapevolezza aziendale

e affronta in modo esplicito tutti gli aspetti della realizzazione di un nuovo prodotto, attraverso tre fasi esplicite:

  • Inception, la fase di inizializzazione del progetto, in cui gli elementi fondamentali per la sua riuscita prendono corpo e si valutano aspetti come il Rischioe la Sostenibilità;
  • Construction, la fase di realizzazione, ovvero dove la soluzione viene concretamente implementata;
  • Transition, la fase che si occupa degli aspetti di Deployment.

dad phases

Fasi di DAD

Se l’utilizzo di fasi può sembrare qualcosa di “strano” all’interno di un framework Agile, bisogna evidenziare come esse non siano da intendersi alla waterfall, bensì come “contenitori di scopo” che non limitano alcuna review delle decisioni prese. Il loro obiettivo è quello di focalizzarsi, nei diversi momenti, su ciò che è tipicamente richiesto dalla lavorazione di un prodotto, così come esplicitato dagli specifici process goal annessi ad ogni singola fase.

dad goals

 The process goals of Disciplined Agile Delivery (DAD)

Nella figura precedente sono anche visibili dei goal raggruppati in una “virtual phase” chiamata Ongoing: si tratta di obiettivi trasversali che accompagnano il team nell’intera realizzazione del prodotto.

Nel rispetto del principio portate “choice is good” (si veda il primo articolo della serie), e della continua evoluzione organizzativa, le fasi prendono forma e si specializzano in 4 lifecycle specifici: Agile/Basic, Lean/Advanced, Continuous Delivery (Agile/Basic) e Continuous Delivery (Lean/Advanced).

dad lifecycles

DAD Lifecycles

Ad essi se ne aggiunge un quinto, Exploratory (Lean Startup) in cui le fasi precedenti non sono presenti, avendo uno scopo diverso e specifico: supportare le organizzazioni nella fase di customer delivery. Esempio tipico sono le “vere” startup.

Diamo ora uno sguardo più di dettaglio ai diversi lifecycle.

Agile/Basic Lifecycle (Extending Scrum): si tratta del lifecycle pensato per i team nuovi al mondo Agile o a quelli che già lavorano con Scrum e hanno la necessità di scalare le proprie attività. 

dad lifecycles basic

Agile/Basic Lifecycle

È indicato quando è possibile identificareprioritizzare e stimare le diverse funzionalità da realizzare, caratterizzandosi per:

  • Iteration Based, esattamente come Scrum la soluzione è sviluppata con un approccio time-boxed e ogni intervallo di sviluppo è definito Iteration
  • Non-Scrum Terminology, di base la terminologia Scrum è sostituita con una duale più generica (es: Iterationvs Sprint), anche se ciò non è un must
  • Inputs from outside the delivery lifecycle, vengono evidenziati gli elementi esterni primari in grado di condizionare la soluzione e generare cambiamenti durate la sua realizzazione
  • Work item list, not Product Backlog, DAD preferisce il concetto di Work Item a quello di Product Backlog. Questo per evidenziare che nello stack non sono presenti solo User StoryFeatureda realizzare, ma anche requisiti, difetti, aspetti non funzionali, ecc…. In pratica il Product Backlog contiene tutto quanto necessario al successo della soluzione (e non allo sviluppo del prodotto/progetto), comunque ordinato secondo diversi criteri
  • Explicit milestones, sono previste milestone esplicite che consentono una governance efficace delle attività, e rappresentano spesso il momento di Deployment concordato con il cliente.

Advanced/Lean DAD Lifecycle: si tratta del lifecycle pensato per team che lavorano in chiave di Value Stream, rilasciando gli Incrementi quando sono pronti, senza avere una finestra specifica di riferimento, e sforzandosi di ridurre al minimo il tempo che intercorre tra due rilasci. 

dad lifecycles advanced

Lean/Advanced Lifecycle

È indicato quando è possibile suddividere le attività in unità minimali di lavoro ed è difficile fare previsioni su di esse, caratterizzandosi per:

  • Continuous flow of delivery, la delivery avviene ogni volta che è disponibile un nuovo Incrementsignificativo, senza vincolarsi ad alcuna Iterazione. Le nuove attività sono “tirate” dal team nel flusso di lavoro appena si ha la capacità per farle e non “spinte” in funzione di una pianificazione time-boxed (pull vs push)
  • Practices are on their own cadences, i vari eventi (retrospettive, refinement, ecc…) vengono eseguiti quando ha senso farle e non secondo una cadenza pre-stabilita
  • Work item pool, non tutti i work-item sono uguali. Alcuni sono risk-value driven, altri value-drivene altri ancora data-driven(si pensi ai vincoli normative). Per questo motivo un Work Item pool ha molto più senso che uno stack ordinato per priorità generica.

Continuous Delivery Lifecycle (Agile/Basic): si tratta della naturale evoluzione del lifecycle Agile/Basic, con iterazioni di una settimana o meno. 

dad lifecycles cd basic

Continuous Delivery (Agile/Basic)

La differenza primaria è che la fase di Inception viene completamente assorbita da quella di Construction e anche la fase di Transition si riduce al minimo. Inoltre, rispetto all’Agile/Basic il rilascio avviene concretamente al massimo alla fine di ogni iterazione, e quindi almeno ogni settimana. Le sue caratteristiche sono:

  • Iteration Based(al massimo di 1 settimana)
  • Non-Scrum Terminology
  • Inputs from outside the delivery lifecycle
  • Work item list, not Product Backlog
  • Explicit milestones

Continuous Delivery Lifecycle (Lean/Advanced): si tratta della naturale evoluzione del lifecycle Lean/Avanced in cui il tempo di delivery è ridotto al minimo necessario, anche con frequenza di più volte al giorno, sfruttando strumenti di automazione (deploy) e processi standardizzati nel tempo. 

dad lifecycles cd advanced

Continuous Delivery (Lean/Advanced)

Per la fase di Inception e Transition vale quanto già detto per il Continuous Delivery Lifecycle Agile/Basic, mentre le caratteristiche rilevanti sono:

  • Continuous flow of delivery
  • Practices are on their own cadences
  • Work item pool

Exploratory (Lean Startup) Lifecycle: è il lifecycle ispirato a Lean Startup, pensato per le startup o le nuove iniziative, che devono prima di tutto validare la sostenibilità della propria idea, andando a scoprire il mercato con una serie di Minimum Viable Product (MVP) e una specifica implementazione del ciclo Build-Measure-Learn. 

dad lifecycles exploratory

Exploratory (Lean Startup) Lifecycle

L’obiettivo è quello di ridurre al minimo gli investimenti iniziali, favorendo, attraverso piccoli esperimenti, azioni testate sul mercato e misurate con metriche significative. Si caratterizza per:

  • Envision, si tratta di esplorare la nuova idea e formulare le ipotesi in relazione alla possibile idea che potrebbe attrare i potenziali clienti
  • Build a Little, sviluppare velocemente quanto necessario per validare le proprie ipotesi: Minimum Viable Product (MVP).Non è importante concentrarsi sulla qualità tecnica, bensì essere estremamente veloci e capaci di evidenziare le caratteristiche peculiari
  • Deploy, l’MVP deve essere reso velocemente fruibile agli early-adopter in modo da poterne testare l’interesse
  • Observe & mesure, una volta in erogazione, è necessario monitorare il comportamento degli early-adopter “instrumentando” l’MVP. In tal modo è possibile rendersi conto se quanto realizzato è sulla direzione giusta o è necessario eseguire un pivot
  • Cancel, dopo aver testato le idee portanti e sfruttato i pivot, potrebbe essere necessario decidere di abortire lo sviluppo della soluzione perché non è di interesse per i potenziali clienti. Se ciò deve avvenire, meglio che avvenga in un tempo ristretto limitando le risorse impiegate e massimizzando il know-how acquisito
  • Productize, se il prodotto trova il proprio spazio, la fase di Customer Deliverypuò ritenersi conclusa ed è opportuno passare alla fase di ingegnerizzazione, preferibilmente, tramite uno degli altri modelli di sviluppo presentati

Una caratteristica che abbiamo osservato è quella che prevede la graduale scomparsa (o assottigliamento delle fasi), pian piano che si evolve nell’adozione dei diversi lifecycle.

dad phases disappear

Phases Disappearing

Non bisogna però pensare che, in generale, una fase sia migliore dell’altra, ma lavorare su quella più adatta al contesto temporale e valutare possibili evoluzioni, anche come suggerito da DAD stesso nel tipico percorso di adozione relativo.

dad lifecycles adoptions

Typical Adoption Paths

Dal percorso resta ovviamente escluso l’Exploratory (Lean Startup) Lifecycle che ha un compito specifico e temporalmente limitato e che, una volta completato, viene sostituito con uno degli altri quattro.

 

Si conclude così il nostro terzo appuntamento dedicato a PMI DA. Nel prossimo approfondimento guarderemo più da vicino Disciplined DevOps.

Stay tuned J

PMI Disciplined Agile: Disciplined Agile Toolkit (pt.2)

Riprendiamo il nostro viaggio alla scoperta di PMI Disciplined Agile (qui il primo post), presentandone il poster o, come ufficialmente chiamato dal DA Consortium: il Disciplined Agile Toolkit.

da poster

Il toolkit fornisce una visualizzazione d’insieme delle 4 aree d’azione di DA, suddividendole in 25 process blade specifici. 

Ma cosa sono i process blade?

Si tratta, in sintesi, di una raccolta coerente di opzioni (in particolar modo pratiche e strategie) relative ad un processo che dovrebbero essere scelte ed applicate in relazione al contesto specifico. Ogni process blade affronta un ambito “atomico”, come, ad esempio: Data ManagementContinuous Delivery, o Portfolio Management. La scelta del termine “blade” è legata concettualmente all’omologo dei “server blade” per evidenziare la possibilità di aggiornarlo, cambiarlo, o addirittura sostituirlo, con estrema agilità, in relazione all’evoluzione del contesto in cui si sta operando.

La visione d’insieme delle diverse aree rappresenta la visione ad evoluzione progressiva di Disciplined Agile, in cui il livello N-esimo ingloba quello N-1, come viene sinteticamente descritto dalla metafora della Formula 1:

da f1

dove: Disciplined Agile Delivery è il motore, Disciplined DevOps la vettura, Disciplined Agile IT la squadra e Disciplined Agile Enterprise l’intero circus.

Proviamo ora ad andare maggiormente nel dettaglio delle diverse aree, abbinando gli specifici process blade:

  • Disciplined Agile Enterprise (DAE), è il livello complessivo, che guarda ad una organizzazione in grado di reagire rapidamente ai cambiamenti del mercato. Una DAE si basa su una Cultura e una Struttura Organizzativa che facilita il cambiamento nel contesto delle diverse situazioni che si trova ad affrontare.  A questo livello vengono aggiunti process blade che guardano all’intera organizzazione: BusinessOperationsMarketingSalesFinanceLegalProcurement e Control.
  • Disciplined Agile Information Technology (DAIT) estende Disciplined DevOps nell’ottica di ottenere un’area IT collaborativa e propositiva. I nuovi process blade introdotti sono: People Management (o Agile HR), Product ManagementPortfolio ManagementEnterprise ArchitectureReuse EngineeringIT Governance e Continuous Improvement.
  • Disciplined DevOpssupporta l’applicazione di strategie Agili a tutti gli aspetti dell’IT. Ciò include attività come quella della Security e del Data Management, utili a fornire soluzioni efficaci ed efficienti in relazione agli obiettivi e gli impegni aziendali.  I 5 process blade aggiunti da questo livelli sono: Release ManagementIT OperationsSupport,Security e Data Management.
  • Disciplined Agile Delivery (DAD) è l’approccio hybrid-agile alle soluzioni IT che si basa su persone (people-first) che fanno propria una cultura basata sull’apprendimento costante. DAD affronta tutti gli aspetti della delivery, includendo: modellizzazionepianificazione inizialeformazione del teamgaranzia dei finanziamentiarchitettura continuatest continuisviluppo iterativo/incrementalegovernance durante tutto il ciclo di vita. DAD supporta più lifecycle, esplicitando la gestione del rischio e focalizzandosi su obiettivi specifici nell’ambito aziendale, consentendo di scalare in funzione delle esigenze.  I process blade a questo livello sono i 5 diversi lifecycle suggeriti: AgileLeanContinuous Delivery: AgileContinuous Delivery: Lean ed Exploratory/Lean Startup, più, il blade Program Management per il coordinamento di team di delivery ampi o più team. 

Come abbiamo più volte accennato, l’approccio Goal-Based è fondante per DA. 

Si tratta, in pratica, di avere sempre visibilità del goal specifico su cui concentrarsi (ovviamente i goal viaggiano in parallelo e non in sequenza), andando a contestualizzare le azioni in relazione all’ambiente e al progetto specifico (valori: Context Count e Choice is good). Lo schema generale adottato per descrivere un goal è rappresentato nella figura seguente:

da gola generale

In pratica, per ogni Process Goal abbiamo dei Decision Point, ovvero delle “decisioni da prendere” obbligatoriamente e non demandabili, ed una serie di Opzioni, ordinate o meno. Queste opzioni sono quelle “suggerite” da DA e rispecchiano l’esperienza quasi decennale di applicazione del framework.

Un esempio concreto di Process Goal è quello riportato di seguito, nello specifico: “Explore Initial Scope”, appartenente alla fase di Inception di DAD (di cui parleremo in seguito).

da goal initial scope

Il nostro secondo appuntamento con la serie dedicata a PMI DA termina qui. Nel prossimo approfondimento guarderemo più da vicino DAD e i relativi process blade.

 

Stay tuned J

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 days ago I was working on an automated CI build on Azure DevOps and we hit an issue when trying to compile an old VDPROJ (migration to Wix in progress, btw ☺). We encountered an HRESULT 8000000A error.

How to fix

After some googling (with Bing) we discovered that it’s a known issue but as the technology is out of support the only that you can do is to apply a workaround.

You need to install the Microsoft Visual Studio Installer Projects extension for Visual Studio on your build machine.
This is because it includes a simple tool as you can read at the bottom of the page:

So what you need to do in your CI process (or Azure Pipeline) is to call this DisableOutOfProcBuild.exe from inside the folder of the exe itself and then build your VDPROJ.

Here you can find some very convenient batch scripts: Community edition, Professional edition, and Enterprise edition written by it3xl (thanks!). You can run this on your CI process.

Under the hood

What the simple executable does is changing a value on the registry to enable a deprecated feature of Visual Studio (out of proc build).

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) and the other one for a Vertica instance (probably Unix/Linux VM) shared between developers:

<sandbox workstations>

In this shared instance we will get a schema for each developer is working on the solution, in order to let everyone to get his own “environment”.

The source control folder tree (which will be TFVC source control on-premises) will be designed on the desired branch as the following:

/Project
    /Instance
        /Process1
            /_Master
                schema.ps1 
                tables.ps1
                views.ps1
            /Tables
                Table1.sql
                Table2.sql
            /Views
                View1.sql
                View2.sql
            Schema.sql
        /Process2
            /Tables ...
            /Views ...

As you ca see, under the Project folder there is the Vertica database folder, which contains, schema by schema, all the .sql files for Tables and Views DDLs (CREATE TABLE and CREATE VIEW). You can notice also .ps1 files, which contains the list of executions based on a certain order (business driven).

The file for a, let’s say, “Table1”, can be like this one:

CREATE TABLE :SCHEMA.Table1
(
    RowId int NOT NULL,
    RowStringValue varchar(30) NULL,
    CONSTRAINT PK_<schema>Table1 PRIMARY KEY (RowId)
);

We’ve added a :SCHEMA parameter, which allows each developer to create its own schema as described before. This is the only way we’ve found for isolating developers in a Vertica shared instance, avoiding an instance for each developer, which could be resource intensive for available PCs. Running the application locally, before committing any change set to the Source Control, a simple tool will execute .sql files with the new schema name and in the sort order given by the .ps1 file.

The Tables.ps1 file can be as the following:

param(
[parameter(Mandatory=$true)]$hostname,
[parameter(Mandatory=$true)]$port,
[parameter(Mandatory=$true)]$user,
[parameter(Mandatory=$true)]$psw,
[parameter(Mandatory=$true)]$schemaName,  
[parameter(Mandatory=$true)]$scriptsFolder
)

$schemaCommand = "vsql -h $hostname -p $port -U $user -w $psw -v SCHEMA=$schemaName -f $(Join-Path $scriptsFolder "Table1.sql")"
Invoke-Expression -command '$schemaCommand'

$schemaCommand = "vsql -h $hostname -p $port -U $user -w $psw -v SCHEMA=$schemaName -f $(Join-Path $scriptsFolder "Table2.sql")"
Invoke-Expression -command '$schemaCommand'

You may notice the term “vsql”, which is the command line provided by Vertica for executing queries. Further information here.

Also, usernames and passwords will be stored in an external config file (or a secured API), like the following one:

{
"host": "MyHost.Hos.Ext",
"port": 1234,
"user": "user",
"psw": "password",
"schemaName": "MYSCHEMA"
}

We’ve got the DDLs, the PoSh files for executing them and the Vertica command line. Good, in a development environment, however, a set of tools should be prepared for helping us to keep these artifacts on a single pipeline, too. This is the reason why we’ve created a “builder” script, like  this one:

$config = Get-Content (Join-Path $currentFolder "Build-Config.json") | Out-String | ConvertFrom-Json

$schemaCommand = $(Join-Path $scriptsFolder "Tables.ps1") 
$schemaCommand += " -hostname $($config.host)" 
$schemaCommand += " -user $($config.user)"
$schemaCommand += " -port $($config.port)"
$schemaCommand += " -psw '$($config.psw)'"
$schemaCommand += " -schemaName $($config.schemaName)"
$schemaCommand += " -scriptsFolder $scriptsFolder"

Invoke-Expression -command $schemaCommand

This is another layer of management, which allows us to organize every part of the DDLs to be executed against Vertica.

Note: Our scripts will destroy and rebuild any given SCHEMA. But this is the way we like.

Now, let’s see the possible scenarios.

Start from scratch or get started

When someone wants to start from scratch, this is the pipeline to follow:

  1. get latest version of the branch;
  2. check and change the configuration file (JSON);
  3. execute the create-vertica-database-from-scratch.bat file (it contains our powershell “build” script);
  4. that’s it, we’ve got a new schema in Vertica, empty and ready to be consumed.

If you want to preserve your data, this is not the right path for you. Executing the “builder” tool is optional.

New development

When a developer would make and try its changeset:

  1. change Visual Studio application (SSIS or SSRS here) when needed;
  2. change the Vertica schema (adding tables, columns and so on);
  3. get the .sql file of a new object or change the .sql file of an object which has been updated;
  4. replace them into the TFVC file structure;
  5. change the .ps1/.txt files if any DDL has been added (or if something that impacts on the order occurs);
  6. build the Visual Studio application and try it;
  7. When everything works good, check-in.

Now, everyone can get the latest changes in a CI way.

Get delta changes

When a developer is going to get the latest changes that contains an updated version of the Vertica objects, but wants to preserve its data, this is a little bit more tricky. The person who has made the change could share in a collaborative chat tool the ALTER script. This is not so reliable and comfortable, but without any comparison tool, there isn’t any best way to make this happen.

That being said, we’ve implemented our diff-script generator, based on the analysis of Vertica metadata (the catalog, browsing v_internal objects). So, after our friend gets the latest version, he executes a generate-diff-script.bat tool and lets this script to execute the generated ALTER script. Tricky, but it works like a charm (we will speak about this comparison tool in next posts, maybe) . Anyway, we’re looking forward hearing updates from MicroFocus. Hopefully, we’ll get an official diff tool from them soon!

Conclusions

I’ve just shown the way we’re managing tables DDLs and how we’ve created PowerShell scripts, but the real scenario is more complex. We have to drop Vertica schema (CASCADE DROP) before, then re-creating the new parametrized schema, then tables, then views and so on. Sometimes, we’ve got Vertica schemas which are referenced each other, so we have to create for everyone of them tables before, then views. The business logic is managed by how we write the “build” PowerShell script as well as the automated build process will.

Also the build process is not always “straight”. Some of the business processes need to be managed in a dedicated way. Cross reference will occur but this is the job that the “builder” will do. Both for the manual and the automated one. Moving responsibility to the build process allows us to feel more comfortable about our development solution.

Last, but not least, the manual-development-build process allows the developer to choose between re-create the database or not. They should not waste time in managing the things that a script can do repeatedly and efficiently. This is the reason why we kept somehow static the PowerShell instead of writing complicated business logic. Just adding rows of vsql invocation in the right order, that’s it.

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