Category Archives: ALM

Application Lifecycle Management

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. … Continue reading Agile@School – Anno Quinto (2020)

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 … Continue reading Show Reporting Services usage statistics with Grafana

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… 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