Avvio
Partiamo dalle attività dell'Avvio, che consiste in una serie di analisi preliminari alla pianificazione del progetto, che supportano la decisione circa l'approvazione formale di un progetto o di una singola fase.
Attività in Avvio obbligatorie:
Analisi del contesto organizzativo
Fare un'analisi del contesto organizzativo in cui il progetto va a collocarsi e delle sue modalità di gestione.
Vedi anche Approfondimento attività "Analisi del contesto organizzativo"
Benefici
L’analisi è necessaria per:
Capire quali risorse interne (umane, materiali, strumentali) possono essere disponibili per il progetto
Adattare lo sforzo di gestione alla maturità e alle disponibilità del contesto
Condurre analisi “make or buy”, in base ai rischi di contesto
Strumenti / Modelli:
Cruscotto di assessment del contesto con correlati modelli / template utilizzabili in base agli esiti della valutazione (cfr. Strumenti, materiali e modelli).
Scelta dell’approccio di gestione
Vedi anche Approfondimento attività "Scelta dell'approccio di gestione".
Benefici
L’analisi – da intendersi come sotto-step della più ampia ricognizione del contesto – è necessaria per:
Scegliere l’approccio di gestione più adatto al progetto: predittivo / adattivo / ibrido
Definire le strategie di azione o di mitigazione dei rischi in caso di adozione dell’ibridazione o dell’adattività del ciclo di vita progettuale.
Strumenti / Modelli:
Applicazione del Flusso di analisi per scelta approccio; ove richiesto da flusso, utilizzo Checklist pre-requisiti per ciclo adattivo.
Analisi degli stakeholder
Chi è impattato, chi va coinvolto, con quale ruolo e responsabilità. Follow up di analisi per l’individuazione degli stakeholder di tipo utente, da coinvolgere e ingaggiare.
Benefici
La mappatura degli stakeholder è centrale per:
Ottenere i diversi livelli di requisitazione (progetto, soluzione, compliance)
Strutturare le responsabilità di direzione, gestione e operatività sul progetto
Definire modalità, canali e frequenza di comunicazione intra-progetto
Analizzare l’impatto sul contesto del cambiamento generato dal progetto e individuare le azioni di coinvolgimento.
Strumenti / Modelli:
Template_Reg Stakeholder_Categ-Utenti.xls
Definizione dei ruoli e delle responsabilità del progetto e della sua gestione
Benefici
La strutturazione dell’organigramma progettuale è centrale per:
individuare i soggetti responsabili delle diverse attività gestionali, tecniche e amministrative previste per la direzione, gestione del progetto e realizzazione della relativa soluzione;
definire quali soggetti sono deputati ad assumere quali tipi di decisioni sul progetto;
perimetrare le responsabilità, i livelli di delega di autonomia organizzativa sul progetto e i gradi escalation, in caso di criticità lungo la realizzazione del progetto, attraverso il modello RACI.
Strumenti / Modelli:
Formalizzazione della concezione e del design del progetto per il suo avvio ufficiale in Kick off Meeting
Benefici
L’allestimento di un documento di sintesi relativo all’ideazione del progetto, all’analisi del contesto, agli obiettivi, benefici attesi e ai vincoli è fondamentale per:
consolidare in un unico documento gli step di avvio definiti come obbligatori;
condividere gli elementi chiave dell’avvio progettuale con gli stakeholder individuati e – soprattutto – con coloro che hanno ruoli formali nel progetto (Sponsor, Responsabile di progetto, Rappresentante degli utenti/Product Owner) durante la riunione di Kick off Meeting.
Strumenti / Modelli:
Template_PM2_Scheda Inizio.docx
Template_Prj_Charter Canvas.pptx, da utilizzare per formalizzare la concezione del progetto in modo visivo e sinottico, allegato al presente documento
Template_Prj_Charter Agile.xls, per formalizzare la concezione del progetto di tipo adattivo/ibrido
Approfondimento attività "Analisi del contesto organizzativo"
Descriviamo ora in maggior dettaglio l’attività “Analisi del contesto organizzativo”. Come anticipato, ovvero esistono molteplici standard, frameworks e metodi di gestione progetti atti a sviluppare la governance, quindi a proteggere il valore delle iniziative progettuali. Vanno dunque identificate, nel corso dei processi di Avvio del progetto, non soltanto le tipologie di frameworks e metodi più opportuni per il contesto, la maturità organizzativa e la struttura organizzativa non solo del progetto, ma tout court dell'organizzazione committente l'iniziativa di cambiamento. Inoltre, tra l’avvio e la pianificazione – anche a prescindere dalla natura dei frameworks che si vorranno utilizzare e adottare – è comunque necessaria quell'attività che definiamo “tailoring” ovvero di adattamento al contesto di progetto di qualsivoglia tipo di standard metodologico che si intende applicare.
Vale quindi esplorare gli indicatori di riferimento da tenere in considerazione per identificare non soltanto il tipo di framework o metodo di gestione adottare, ma anche in che modo plasmarne alcuni aspetti, in modo da renderlo coerente, sostenibile e utile per la gestione del progetto stesso.
Tra gli indicatori chiave, per il setting dell'approccio metodologico e il suo più dettagliato adattamento al contesto di progetto, ne menzioniamo alcuni tra i più significativi e impattanti:
la cosiddetta struttura e il più ampio contesto organizzativo riferito alla committenza di progetto;
la scala dimensionale del progetto;
l'approccio di gestione delle variabili chiave di progetto;
i tipi di supporto di cui può avvalersi il progetto.
Esploriamo il significato di ciascuno di questi item di analisi del contesto:
per struttura e contesto organizzativi, intendiamo una serie di livelli di indagine (sotto-indicatori) quali:
il modello gerarchico-funzionale organizzativo, le sue interfacce di comunicazione prevalenti, i livelli di intersezione trans dipartimentale/trans unità organizzativa
i meccanismi standard di reporting ed escalation, i livelli di delega perimetrati e delineati, i processi decisionali definiti in termini di modalità, criteri e livelli di distribuzione di responsabilità
il dimensionamento delle risorse umane, la loro allocabilità sul progetto, in riferimento alle competenze, esperienze e disponibilità temporali, collocazione logistica delle stesse, ovvero co-locazione o distribuzione territoriale differenziata. Questi aspetti influenzano e determinano sia le scelte cosiddette “make or buy”, ovvero di approvvigionamento di know how esterno o diretto appalto della realizzazione della soluzione a terzi – con correlata diluizione temporale e influenza sulla tempistica di progetto – sia le scelte relativi agli approcci, canali e strumenti di comunicazione (più interattivi orali e visivi o più formali scritti, monodirezionali e monologici).
Maggiore sarà la maturità organizzativa, data dal verificarsi delle numerose condizioni qui menzionate, non solo maggiore sarà l'autonomia gestionale delle figure tattiche del progetto (RUP, project manager, program manager, business manager, rappresentante lato committente), ma più efficiente sarà anche il tempo e l'impegno di gestione nella formalizzazione di prassi di comunicazione e scambio riferiti al progetto che mutuano dalle consuetudini organizzative in essere.
per scala dimensionale di progetto, si intendono almeno due aspetti da considerare:
la durata, l'estensione temporale dell'iniziativa che influenza le modalità di impostazione delle fasi di gestione, la frequenza del controllo e il cosiddetto orizzonte di pianificazione; maggiore è l'arco di progetto, minore è la capacità di fornire stime di durate, disponibilità di risorse (umane, materiali) e effort correlati puntuali sul medio-lungo periodo in quanto cresce l'incertezza circa la predicibilità degli eventi;
l'appartenenza del progetto a un più ampio disegno strategico, quale quello programmatico o di portfolio o l'istanziazione del progetto come iniziativa irrelata e indipendente; questa dimensione influenza le modalità di pianificazione del lavoro, se presenti dipendenze tra output di vari progetti, vincoli temporali, organizzativi e/o economici legati all'appartenenza ad un programma (vedi il concetto di missione del PNRR), ancora determina la prioritizzazione delle risorse e delle loro allocabilità e disponibilità se il progetto afferisce a un portfolio o se considerato chiave per un cambiamento strategico organizzativo (riorganizzazione di processi, introduzione di nuovi sistemi informativi, creazione di nuovi servizi per i beneficiari target dell'organizzazione;
per approccio di gestione delle variabili chiave di progetto (cosiddetti: ambito, tempistiche e costi) intendiamo la scelta di un modello di pianificazione prevalentemente predittivo o prevalentemente adattivo: nel primo caso, il disegno delle fasi del piano di progetto potrà seguire il proprio tipico andamento sequenziale (cosiddetto "waterfall") a partire dall'ambito, dai requisiti della soluzione definiti e chiari fin dalla convezione del progetto; nel secondo caso, il disegno delle fasi di realizzazione della soluzione avverrà per iterazioni (blocchi temporali inamovibili a risorse fisse) a rilasci progressivi e incrementali con prioritizzazione continuativa delle esigenze, requisiti e caratteristiche della soluzione progettuale, in un termine, l'approccio sarà orientato alla velocizzazione della delivery, ovvero "agile".
infine, per tipi di supporto, si intendono una serie di strumenti organizzativi e informativi atti a snellire il tempo di gestione dei responsabili di progetto: ci si riferisce, in particolare:
disponibilità di flussi di pianificazione-gestione e controllo codificati e standardizzati per l'intera organizzazione che consentano una loro rapida applicazione al contesto specifico anche attraverso l'utilizzo di modelli documentali/template per la formalizzazione degli item di progetto, il ricorso a ruoli con responsabilità predefiniti. Una sorta dunque di sistema gestione progetti che - al pari di un più ampio sistema di gestione della qualità ISO9001 - facili il team di progetto nella focalizzazione sull'output di progetto, piuttosto che sul modus operandi per gestirlo incrementando così efficacia di risultato - anche comparabile come performance tra iniziative diverse, sottintendendo gli stessi processi gestionali e aumentando l'efficienza;
disponibilità di strumenti informativi centralizzati e gestionali di pianificazione e controllo che consentano di garantire trasparenza dei dati, loro costante accesso e disponibilità e monitoraggio anche multi-progetto lato direzionale per consentire ai livelli apicali di progetto non solo di acquisire in tempo reale avanzamenti ed eventuali informazioni circa criticità, rischi e impedimenti, ma anche di assumere decisioni rispetto alla prioritizzazione delle risorse comparando in modo continuativo e omogeneo le prestazioni dei diversi progetti in portfolio.
Sulla base dell'analisi di questi indicatori, può essere impostato il modello opportuno e coerente con il contesto di governance, stabilendo una "baseline" di riferimento, ovvero un set minimo di processi, tecniche e strumenti di gestione per gli ambienti di progetto maggiormente deficitari sui diversi indicatori, fino a un sistema più organico, complesso e sofisticato di approcci utile per i contesti maggiormente strutturati e con gli indicatori menzionati prossimi al loro massimo setting di valore.
Vale quindi la pena riassumere questo passaggio chiave di "analisi del contesto di progetto", passaggio preliminare e propedeutico all’impostazione stessa di progetto (cosiddetto processo/fase di avvio), in forma di rapido cruscotto di assessment, caratterizzato dai quattro indicatori con relativi cursori di valutazione da muovere lungo una scala di valutazione qualitativa a cinque gradienti, secondo l’immagine di seguito riportata:
Si descrive quindi, a seguire, tale approccio di analisi del contesto che supporti – in maniera snella ed efficace – le indicazioni chiave per l'impostazione gestionale di progetto, esaminando esattamente le quattro dimensioni sopracitate, considerate quali macro indicatori di valutazione dell'ambiente di progetto.
Nello specifico, si suggerisce di condurre una valutazione qualitativa – da svolgersi in modo condiviso almeno tra il ruolo del responsabile di progetto e lo sponsor/proponente dello stesso – relativa alla presenza/soddisfacimento degli elementi di dettaglio riferiti ad ogni singolo macro indicatore. Quindi, in base alla presenza di detti elementi di dettaglio per ciascuno dei quattro indicatori, impostare il cursore, presente su ogni indicatore, su un valore medio di riferimento considerando che la scala Likert qualitativa potrà vedere il posizionamento del valore medio tra l'1 e il 5; di conseguenza, maggiore è la presenza degli elementi descritti in ciascuno dei quattro indicatori, maggiore sarà il valore medio da riportare sul cursore. Il posizionamento del cursore supporta la successiva modellizzazione gestionale, prendendo spunto dalle azioni suggerite per ciascun indicatore organizzate in base a due macro fasce di risultanza: inferiore al valore medio "3" e superiore al valore medio "3".
Le azioni indicate per ciascun indicatore e formulate in base alle due macro fasce di esito della valutazione sono le seguenti, riportate seguendo cromaticamente l’indicatore di riferimento:
Mediamente, ogni azione suggerita prevede l’utilizzo di un modello standard o template: ciascuno di essi è disponibile alla pagina "Strumenti, materiali e modelli".
Approfondimento attività "Scelta dell'approccio si gestione"
Ove – nell’ambito dell’applicazione del cruscotto di analisi di contesto – emergesse un valore che suggerisse una scelta prevalentemente adattiva, caratterizzata dalle accelerazioni delle prassi “Agile”, sarebbe opportuno approfondirne l’analisi, adottando il flusso decisionale di seguito rappresentato. Questo approccio supporterà la valutazione del gradiente di “agility” che il contesto di progetto e il più ampio contesto organizzativo potrà efficacemente supportare e sopportare.
Se, in base alla sequenza dei punti decisionali del flusso sopra rappresentato, emergesse la necessità di un follow up dei cosiddetti “Pre-requisiti” (Checklist_Prerequisiti_Agile) per l’adozione di prassi agili – come ivi indicato – sarà utile applicare la seguente checklist. Questo strumento è organizzato in categorie di prassi tipicamente legate al modo di lavorare adattivo/agile e serve a dimensionare quali-quantitativamente se queste modalità sono già in uso presso l’organizzazione, se lo sono solo in parte, o, alternativamente, non lo sono affatto.
Checklist verifica pre-requisiti per approccio di gestione adattivo
CATEGORIA
ELEMENTI/ITEM DA ESAMINARE
Mindset agile
Cultura e conoscenza diffusa rispetto agli approcci agili alla gestione progetti
Cultura organizzativa orientata alla delega di autonomia decisionale anche ai livelli tattici e operativi, con meccanismi di leadership diffusa e decentralizzata
Capacità di rappresentanza degli utenti/beneficiari del servizio (Product Owner/Customer representative/Business Manager/Senior User)
Team performance
Disponibilità temporale quotidiana del Product Owner/Customer representative/Business Manager/Senior User
Disponibilità elevate competenze tecniche e adeguata seniority dei membri specialistici del team (Project Core Team)
Dimensionamento stabile dei membri specialistici del team (Project Core Team) per almeno un mese in modalità FTE
Autonomia dei membri specialistici del team (Project Core Team) rispetto alla auto-organizzazione del lavoro, proattività nel problem analysis e problem solving, capacità di assunzione condivisa/concorde di decisioni
Comunicazione osmotica
Co-locazione dei membri specialistici del team (Project Core Team)
Disponibilità strumenti informativi e di comunicazione condivisi (es. Jira, Kanban board, Trello, sharepoint, MS Teams)
Prevalenza di approcci di comunicazione interattivi (es. interviste, workshop, brainstorming, riunioni) rispetto a forme di comunicazione scritta, formale e monodirezionale (email, reportistiche, protocolli)
Value driven delivery
Utilizzo della requisitazione in forma di Epiche e User Story, manutenute lungo il ciclo di vista del progetto
Utilizzo della prioritizzazione progressiva e continuativa delle User Stories raccolte e dei criteri di accettazione
Adozione delle cerimonie: planning, daily e retrospective meeting
Pianificazione adattiva
Adozione della pianificazione di dettaglio della singola iterazione con definizione dell'incremento dell'iterazione e definizione delle size delle attività dell'iterazione
Adozione modelli di Product Backlog, Iteration backlog, Burn chart
Assunto: ogni aspetto/item ha lo stesso peso come rilevanza di osservazione. Indicatori: ogni "Sì" equivale a 1 punto; ogni "No" equivale a 0 punti; ogni "Si parziale" equivale a 0,5 punti. Esito A: se punti totali equivalenti a <7,5 (<50%), checklist ko, pianificare implementare azioni di mitigazione su registro rischi; Esito B: se punti totali equivalenti a <7,5 e 12 (tra 50% e 80%), checklist ok parziale, pianificare azioni di miglioramento in un piano ad hoc e setting piano release in iterazioni incrementali; Esito C: se punti totali equivalenti a >12 (> 80%), checklist ok, setting piano release in iterazioni incrementali.
I risultati emergenti dalla checklist suggeriscono – in base al punteggio automaticamente calcolato sulla base della occorrenza/presenza delle prassi investigate – che tipo di ibridazione sia sostenibile adottare nel contesto di progetto; l’agile way o ciclo adattivo, rappresentando specifiche modalità di pianificazione, coordinamento e controllo per singola iterazione di progetto (blocco temporale di breve termine, ripetuto ciclicamente), richiede infatti una readiness (prontezza/preparazione) degli attori e una loro precipua competenza, in assenza o carenza della quale, questo ciclo accelerato può introdurre fattori di rischio impattanti sia la qualità della delivery sia la soddisfazione degli stakeholder di tipo utente.
Pertanto, se l’occorrenza di readiness agile, risultante dalla checklist, fosse compresa tra il 50 e l’80% di adozione delle modalità di lavoro adattive, il responsabile di progetto individuerà azioni di mitigazione dei fattori di rischio, da porre nel relativo registro rischi, valutandone a frequenza regolare lo stato di probabilità, severità e impatto. Diversamente, se l’occorrenza di readiness agile, risultante dalla checklist, fosse inferiore al 50% di adozione delle modalità di lavoro adattive, il responsabile di progetto individuerà azioni non più di mitigazione dei fattori di rischio dell’uso dell’agile, ma definirà attività da mettere operativamente in campo e da inserire, di conseguenza, nelle attività di gestione del piano di lavoro del progetto o nella sua roadmap.
La distinzione di trattamento tra azioni di mitigazione e azioni da implementare risiede nel fatto che:
nel primo caso (azioni di mitigazione), l’organizzazione, i ruoli e le competenze di contesto del progetto potrebbero non essere del tutto confidenti con alcune modalità di lavoro agile e, di conseguenza, ove si volessero applicare, si dovranno definire attività di miglioramento o riduzione delle potenziali criticità nel loro utilizzo; per questo motivo, tali azioni rappresentano dei “potenziali” impegni, dunque eventi non ancora accaduti (rischi appunto) da censire nel registro e da valutare in termini di loro implementazione, in base all’esigenza che emerge di adottare una nuova o diversa tecnica agile, rispetto a quelle in uso.
nel secondo caso (azioni da implementare), invece, l’organizzazione nel suo insieme, dunque anche i ruoli che richiede l’agile e sue rispettive prassi sono ignote o poco note: di conseguenza, per accelerare la delivery e adottare pratiche adattive, si dovranno con certezza definire e mettere direttamente in implementazione sistemi di sicurezza per evitare che il ricorso poco consapevole all’agile si possa trasformare in un boomerang frustrante per il team di progetto e pericoloso per la delivery stessa della soluzione.
Il tema di fondo è sempre quello del “tailoring” (adattamento): anche se il progetto è orientato alla trasformazione digitale dei processi, dunque impatta a 360° sul sistema organizzativo (persone, modus operandi, tecnologie, infrastrutture) e anche se il progetto richiede lo sviluppo di componenti tecnologiche a più o meno significativa complessità e innovatività, ciò non implica l’automatica scelta di adozione del ciclo adattivo (agile) a rilascio iterativo-incrementale.
Infatti, se è vero da un lato che l’agile riduce i rischi della complessità, innovatività, obsolescenza tecnologica – tipici del ciclo predittivo di progetto –, lavorando per brevi iterazioni (blocchi temporali inamovibili di breve termine di massimo 12 settimane se trattasi di release, di massimo 4 settimane se trattasi di interazione intra-release), è pur vero dall’altro lato che l’“agile way” stesso introduce dei rischi specifici che vanno riconosciuti (ie.: uso checklist pre-requisiti) e gestiti. Un elemento chiave per adattare (“tailor”) in modo consapevole ed efficace il ciclo di vita sia al contesto di progetto sia alla sua più ampia cultura di riferimento organizzativa può essere sintetizzato nel motto: “l’agile non è un fattore dicotomico sì/no, ma un gradiente di accelerazione, dunque più correttamente ci si dovrebbe domandare: “how much agile” adottare. Questo motto rappresenta una delle abilità del responsabile di progetto, l’arte del “tailoring”: cucire il repertorio di strumenti, metodi e tecniche sullo specifico progetto e non viceversa, forzando l’applicazione ad ogni costo di prassi sul progetto, solo perché sono frequentemente citate o perché sono “trend topics” tra gli esperti di dominio!
Azioni di mitigazione dei rischi a maggior impatto positivo sulla crescita della “agility” del team e dell’organizzazione
Coerentemente dunque al motto e alla centratura sull’adattamento al contesto, si propongono di seguito, in forma tabellare, le più significative azioni di mitigazione dei rischi e/o interventi da svolgere per gestire efficacemente le performance medio-basse sulla readiness risultanti dalla checklist dei pre-requisiti. Con azioni “più significative”, si intendono quelle che possono avere il maggior impatto positivo sulla crescita dell’“agility” del team e organizzativa, tenendo ovviamente sempre presente il bilanciamento tra i costi di tali proposte, l’effort che richiedono per essere implementate e i relativi benefici sul progetto:
Azioni su mindset agile/team performance
Criticità su prassi agile: mindset agile/team performance
AREA DI INTERVENTO
AZIONE SUGGERITA
Cultura e conoscenza diffusa rispetto agli approcci agili alla gestione progetti
Avviare cicli di disseminazione interna delle prassi e dei valori del modus operandi agile, guidati da soggetti dell’organizzazione esperti in materia (ad esempio, partecipanti al percorso TD Specialist).
Cultura organizzativa orientata alla delega di autonomia decisionale anche ai livelli tattici e operativi, con meccanismi di leadership diffusa e decentrali
Alla concezione, ideazione e avvio di progetti TD che prevedano – in base alla valutazione del contesto – l’adozione di un ciclo di gestione adattivo e/o ibrido, definire l’organigramma di progetto, condividendo e formalizzando nel Kick off Meeting, i ruoli, le responsabilità e i livelli di autonomia e delega decisionale per gli attori “agile”:
Product Owner (responsabile della raccolta delle esigenze degli utenti impattati dal cambiamento)
Facilitatore (Scrum Master/Agile coach) per guidare, supportare e sostenere le prassi agile e le relative cerimonie di comunicazione (esempio: Planning meeting, Daily meeting)
Team operativo (anche afferente a organizzazione fornitore) in grado di assumere decisioni collegiali, di essere proattivo nella condivisione di criticità della delivery, di auto-organizzarsi il lavoro.
Autonomia dei membri specialistici del team (Project Core Team) rispetto alla auto-organizzazione del lavoro, proattività nel problem analysis e problem solving, capacità di assunzione condivisa/concorde di decisioni
Stabilire, sempre in corso di Kick off Meeting, i criteri decisionali (maggioranza, pluralità, unanimità) rispetto ad alcune delle seguenti variabili (tempistiche delle iterazioni, modalità di prioritizzazione dei requisiti, distribuzione degli stessi nelle varie iterazioni, ecc.), formalizzando anche le tecniche per l’assunzione decisionale: ad esempio, dot voting, fist of five, metodo dei 100 punti.
Capacità di rappresentanza degli utenti/beneficiari del servizio (Product Owner/Customer representative/Business Manager/Senior User); Disponibilità temporale quotidiana del Product Owner/Customer representative/Business Manager/Senior User
Individuare nell’organizzazione i potenziali rappresentanti degli interessi dei diversi target di utenti impattati dal cambiamento (cosiddetti “Product Owners”), selezionandoli tra gli esperti di dominio/area interessata, in grado di assumere decisioni in nome del gruppo rappresentato, disponibili temporalmente lungo ogni iterazione per prioritizzare le esigenze, validarne i criteri di accettazione, condividere all’interno dell’area rappresentata gli avanzamenti della delivery rispetto alle esigenze concordate per la stessa.
Knowledge awareness e knowledge sharing sistematici sul modus operandi dell’“agile”
Definire e implementare sessioni di formazione per i Product Owners relativamente alle tecniche, modalità e strumenti di raccolta delle esigenze e loro prioritizzazione.
Definire e implementare sessioni di formazione per il team di sviluppo relativamente alle prassi dei meeting agile, alle modalità di avanzamento visual del lavoro (esempio mediante Kanban board degli stati della delivery), al protocollo di comunicazione con Responsabile di progetto, Sponsor e Product Owner, in caso di problemi e impedimenti sulla realizzazione della soluzione.
Individuare un soggetto interno o esterno all’organizzazione – quando non coincidente con le competenze del Responsabile di progetto –, in grado di guidare e supportare lungo tutto il ciclo progettuale l’applicazione e l’adozione delle prassi “agile” (Agile coach o Scrum Master).
Raccogliere, formalizzare e condividere a frequenza regolare le lezioni apprese (da precedenti analoghe iniziative e durante la realizzazione del progetto) mediante la cerimonia della retrospective
Adottare in modo sistematico la retrospective coinvolgendo, al minimo, Product Owner, team di sviluppo, Responsabile di progetto e Sponsor, per individuare successi, criticità, errori occorsi in ciascuna finestra temporale di riferimento (idealmente, al termine di ogni iterazione) e definire di conseguenza le azioni correttive e/o migliorative da applicare, nonché i soggetti e le modalità con cui verranno implementate.
Azioni su contrattualistica agile
Criticità su prassi agile: contrattualistica con soggetto referente per “design-build-test” della soluzione
AREA DI INTERVENTO
AZIONE SUGGERITA
Tipologia di contratto
Formulare – in caso di ricorso a società in house e/o fornitori esterni – contratti di tipo “Tempo e Materiali”, per la realizzazione della soluzione, che consentono flessibilità sulla delivery della stessa, evitando di ricorrere a contratti a corpo, incompatibili con la prioritizzazione delle funzionalità da rilasciare in modo iterativo-incrementale.
Elementi del contratto
Inserire nei contratti verso società in house e/o fornitori esterni i seguenti elementi, necessari a condividere le prassi agile:
Definire gli outcomes attesi (miglioramenti/ottimizzazioni) più che gli output specifici, che evolveranno nel tempo
Specificare le modalità di ingaggio, presenza e collaborazione delle rappresentanze degli utenti
Identificare i requisiti minimi di prodotto e ad alto livello di specifica, senza includere una requisitazione di dettaglio
Definire la scala per la prioritizzazione dei requisiti man mano che verranno raccolti e definiti
Definire le modalità di gestione delle richieste di cambiamento all’ambito (Change Request), stabilendo quali vanno accolte perché granulari, quali vanno approvate formalmente con relativo aggiornamento contrattuale, perché impattano sui «Must have» e Should have» (expected case di business case)
Valorizzare economicamente non il «cosa» si rilascerà, ma uno o più blocchi temporali inamovibili («timeboxes») con incentivazione basata su «valore in qualità» generato iterativamente.
Azioni su prassi agile
Criticità su prassi agile: Value-driven delivery/Pianificazione adattativa
AREA DI INTERVENTO
AZIONE SUGGERITA
Ideazione/design del prototipo minimo della soluzione a garanzia della definizione del valore/benefici attesi
Identificare in condivisione tra Product Owner e utenti target rappresentati da ciascun Product Owner, le esigenze che costituiscono il cosiddetto "Minimum Business Increment", da utilizzare quale criterio di successo della soluzione progettuale.
Condivisione della visione del progetto e commitment degli stakeholder coinvolti
Elaborare un artefatto, condiviso tra i diversi stakeholder chiave, di tipo "CANVAS" / "Charter" che contenga le informazioni chiave del progetto: obiettivi, vincoli, assunti, rischi principali, requisiti di alto livello della soluzione e condividerli in un Kick off Meeting.
Utilizzo della requisitazione in forma di Epiche e User Stories, manutenute lungo il ciclo di vista del progetto
Avviare sessioni di focus group tra Product Owner, utenti target e rappresentanti del fornitore – definite “discovery” – per accogliere, valutare, e formalizzare le diverse esigenze, progressivamente granularizzate, usando la grammatica delle User Stories (Who-What-Why).
Utilizzo della prioritizzazione progressiva e continuativa delle User Stories raccolte e dei rispettivi criteri di accettazione
Nel corso delle sessioni di discovery, raccolte le prime 20-30 esigenze chiave della soluzione, procedere alla loro comparazione per assegnarne la priorità/importanza, al fine di allestire un “Product backlog” scomponibile in blocchi di delivery da distribuire – in base alle priorità assegnate – alle iterazioni previste. Utilizzare, a tal fine, la scala «MoSCoW».
Adozione dei modelli di Product Backlog e Iteration backlog
Implementare la prassi del continuo affinamento/scomposizione/aggiustamento del product backlog («grooming») tra i diversi utenti e il Product Owner lungo il ciclo progettuale, mediante: scomposizione delle user stories n esigenze di dettaglio, loro prioritizzazione, formalizzazione dei rispettivi criteri di accettazione (cosiddette “Definition of Done” – DoD) e aggiornamento del Backlog per quelle user stories “done” (realizzate, testate e accettate dagli utenti/Product Owner).
Adozione delle cerimonie: planning, daily e retrospective meeting
Rispettare la cerimonia della riunione di review, al termine di ogni iterazione, quale dimostrazione agli utenti target degli «incrementi» prodotti dal team di sviluppo, per ottenerne formale (parziale o completa) accettazione e mantenere così gli utenti aggiornati sui progressi e ingaggiati sul piano motivazionale.
Ultimo aggiornamento