Discussione Orale - Versione Discorsiva

Scopo del documento

Questo documento affianca 11. Studio Orale - PM e CTAF. La guida 11 resta la versione strutturata e schematica; questo file invece raccoglie spiegazioni più discorsive, da leggere come preparazione all’orale.

Stato

Documento pubblicato su GitHub Pages e versionato nel repository obsidian_notes.

Indice

1. Scrum - spiegazione discorsiva
2. Scoping Process Group - spiegazione discorsiva
3. Planning Process Group - spiegazione discorsiva
4. Execution / Launching Process Group - spiegazione discorsiva
5. Monitoring & Controlling Process Group - spiegazione discorsiva
6. Closing Process Group - spiegazione discorsiva
Prossime sezioni da aggiungere

1. Scrum - Spiegazione Discorsiva

Fonti principali

Teoria Scrum negli appunti: The Scrum Team

Story point e planning poker: Stima di Durata, Effort e Risorse

Applicazione CTAF: Execution nel progetto CTAF

Elaborato: Execution, Sprint Plan

Cos’è Scrum

Scrum è un framework agile per gestire lo sviluppo software in modo iterativo e incrementale.

Negli appunti è definito come un framework di project management per lo sviluppo iterativo e incrementale di prodotti software. Questo significa che Scrum non è un processo rigido che dice esattamente ogni dettaglio da seguire, ma una struttura di lavoro fatta di ruoli, eventi, artefatti e regole leggere.

L’idea di fondo è semplice: nei progetti software non sempre è possibile conoscere tutto all’inizio. Per questo non si cerca di definire subito l’intero prodotto in modo definitivo, ma si procede per cicli brevi chiamati sprint. Alla fine di ogni sprint il team produce un incremento, lo mostra, riceve feedback e corregge la direzione.

Scrum è quindi:

Caratteristica	Significato
Iterativo	Il lavoro avanza per cicli ripetuti.
Incrementale	Ogni sprint aggiunge un pezzo funzionante al prodotto.
Empirico	Le decisioni si basano su ciò che emerge durante il lavoro.
Collaborativo	Il team lavora con comunicazione continua.
Adattivo	Il backlog può essere rivisto dopo feedback, rischi o problemi.

Nel progetto CTAF questa logica è evidente: il lavoro è stato diviso in sprint dedicati a Runtime BDI, Pipeline LLM, Web App Review e Integrazione. Ogni sprint ha prodotto un risultato verificabile e ha permesso di scoprire problemi prima della consegna finale.

I ruoli di Scrum

Negli appunti lo Scrum Team è composto da tre ruoli: Product Owner, Scrum Master e Team di sviluppo.

Il Product Owner è responsabile del prodotto e del “cosa” deve essere realizzato. È la figura che rappresenta il valore, ordina il backlog e chiarisce le priorità.

Lo Scrum Master è un facilitatore. Non è un capo tecnico tradizionale: aiuta il team a seguire Scrum, rimuove impedimenti, migliora la comunicazione e protegge il processo.

Il Development Team è il gruppo che realizza concretamente la soluzione. È autonomo sul “come” implementare il lavoro selezionato.

Nel progetto CTAF questi ruoli sono stati adattati al contesto accademico:

Ruolo Scrum	Interpretazione CTAF
Product Owner	Committente / referente Cardiologia di Forlì.
Scrum Master	Project Manager.
Development Team	Dev Jason, Dev Python, Dev Frontend.

Questa non è una implementazione Scrum industriale perfetta, ma è coerente con la simulazione progettuale: il committente valida il valore, il PM facilita e coordina, il team tecnico realizza gli incrementi.

Gli sprint

Lo sprint è il ciclo base di Scrum. Ha durata fissa e produce un incremento potenzialmente dimostrabile.

Nel progetto CTAF gli sprint duravano due settimane. Il piano era:

Sprint	Obiettivo
Sprint 1	Runtime BDI.
Sprint 2	Pipeline LLM.
Sprint 3	Web App Review.
Sprint 4	Integrazione e validazione.
Sprint 5	Riserva per imprevisti.
Sprint 6	Chiusura e consegna.

Ogni sprint aveva uno Sprint Goal, cioè un obiettivo sintetico che orientava il lavoro. Per esempio, nello Sprint 1 l’obiettivo era implementare i quattro agenti BDI in Jason e verificarli sul golden case gc04. Nello Sprint 2 l’obiettivo era realizzare la pipeline LLM per estrazione claim e generazione bozze di regole.

Questa divisione è importante perché dimostra che Scrum è stato usato non solo come etichetta, ma come modo concreto per organizzare il lavoro in incrementi verificabili.

Le cerimonie Scrum

Nel progetto sono state usate quattro cerimonie principali: Sprint Planning, Daily Standup, Sprint Review e Sprint Retrospective.

Cerimonia	Quando	Scopo nel progetto CTAF
Sprint Planning	Inizio sprint	Definire Sprint Goal e selezionare storie dal Product Backlog.
Daily Standup	Ogni giorno	Allineare il team su lavoro svolto, lavoro successivo e blocchi.
Sprint Review	Fine sprint	Mostrare l’incremento al committente e raccogliere feedback.
Sprint Retrospective	Dopo la review	Analizzare il processo e decidere azioni di miglioramento.

Il Daily Standup seguiva le tre domande classiche: cosa ho fatto ieri, cosa farò oggi, quali blocchi ho. Nel progetto è servito a intercettare problemi come la configurazione di Jason su Windows, la dipendenza ciclica tra agenti, il formato inconsistente degli output LLM e il rate limit di Groq.

La Sprint Review era particolarmente importante perché trasformava ogni sprint in un momento di validazione. Il committente vedeva una demo e poteva dare feedback. Questo è coerente con la natura iterativa del progetto: non si aspettava la fine per scoprire se il lavoro era utile.

La Retrospective serviva invece a migliorare il modo di lavorare. Per esempio, dopo lo Sprint 1 è emerso che la stima del setup Jason era stata troppo ottimistica; questa lezione è stata usata negli sprint successivi per riservare più tempo ai setup tecnologici.

Gli artefatti Scrum

Gli artefatti più importanti sono Product Backlog, Sprint Backlog, Incremento, Definition of Done e Acceptance Criteria.

Il Product Backlog è la lista ordinata di ciò che potrebbe essere realizzato nel prodotto. Nel progetto CTAF era gestito su GitHub Projects con board Kanban.

Lo Sprint Backlog è la parte del Product Backlog selezionata per uno sprint specifico.

L’Incremento è il risultato prodotto alla fine dello sprint: per esempio, il runtime BDI funzionante, la pipeline LLM funzionante, la console web, oppure l’integrazione end-to-end.

La Definition of Done è una checklist generale per dire che una story è completata. Nel progetto CTAF una story era done quando:

Il codice soddisfaceva i criteri di accettazione.
La pull request era approvata.
I test unitari e di integrazione passavano.
La documentazione minima era aggiornata.
La funzionalità era dimostrabile in Sprint Review.
Non c’erano errori runtime o warning bloccanti.

Gli Acceptance Criteria, invece, sono specifici della singola user story. La differenza è importante: la DoD vale per tutto, gli Acceptance Criteria cambiano da story a story.

Product Backlog e MoSCoW

Nel progetto CTAF il Product Backlog è stato prioritizzato con MoSCoW.

MoSCoW significa:

Categoria	Significato
Must Have	Obbligatorio: senza questi elementi il progetto non è accettabile.
Should Have	Importante, ma non bloccante.
Could Have	Utile o desiderabile, ma sacrificabile.
Won’t Have	Esplicitamente fuori scope.

Nel progetto:

Categoria	Elementi CTAF
Must	Agenti BDI, pipeline LLM base, console review, golden case, CLI.
Should	Visualizzazione tracce, gestione ambiguità, test automatici.
Could	Export report, dashboard metriche, dark mode.
Won’t	Deployment production, autenticazione, multi-dominio clinico.

MoSCoW è stato fondamentale perché ha protetto la consegna. Gli 11 story point non completati erano tutti Should o Could, nessun Must è stato perso. Questo dimostra che la priorità non era decorativa: era un vero meccanismo di controllo dello scope.

Story point e velocity

Scrum spesso non stima direttamente in giorni/uomo, ma in story point. Gli story point misurano la complessità relativa di una story, considerando effort, incertezza e rischio.

Nel progetto CTAF erano stati pianificati 78 SP e ne sono stati completati 67, quindi circa l’86%.

Sprint	SP pianificati	SP completati
Sprint 1	20	18
Sprint 2	22	18
Sprint 3	18	16
Sprint 4	18	15
Totale	78	67

Questo risultato va interpretato nel contesto: in un progetto plan-driven potrebbe sembrare un ritardo; in un progetto Iterative Scrum con componente R&D è accettabile perché i Must sono stati completati e la data finale è stata rispettata.

Perché Scrum era adatto a CTAF

Scrum era adatto perché il progetto aveva un obiettivo chiaro ma una soluzione parzialmente incerta.

L’obiettivo era chiaro: costruire un framework BDI+LLM tracciabile per supporto decisionale clinico. Però la soluzione aveva incognite: integrazione Jason-Python, API LLM, qualità dei claim, formati dati e gestione delle ambiguità.

Scrum ha aiutato perché:

gli sprint brevi hanno ridotto il rischio di scoprire problemi troppo tardi;
le review hanno mantenuto coinvolto il committente;
le retrospective hanno migliorato il processo;
il backlog prioritizzato ha permesso tagli consapevoli;
la DoD ha impedito di considerare completato lavoro non verificabile.

Nel progetto, però, Scrum è stato adattato per R&D tramite management reserve, risk-based sprint planning, technical spike, MoSCoW rigido e validazione incrementale su golden case.

Frase pronta per l’orale

Scrum è un framework agile iterativo e incrementale. Lo abbiamo scelto perché il progetto CTAF aveva un obiettivo chiaro, ma una soluzione parzialmente incerta, soprattutto per l’integrazione tra Jason, Python e LLM. Abbiamo organizzato il lavoro in sprint di due settimane, con Sprint Planning, Daily Standup, Sprint Review e Retrospective. Il backlog era prioritizzato con MoSCoW e ogni story aveva Definition of Done e Acceptance Criteria. Nel nostro caso Scrum non è stato applicato in modo puro, ma adattato alla componente R&D con technical spike, risk-based planning, management reserve e validazione incrementale su golden case.

2. Scoping Process Group - Spiegazione Discorsiva

Fonti principali

Teoria scoping: 06. Scoping Process Group

Applicazione CTAF: Scoping nel progetto CTAF

Elaborato: Scoping & Initiating

Artefatti: POS, RBS, CoS, SWOT

Cos’è lo Scoping Process Group

Lo Scoping Process Group è la fase in cui si definisce il perimetro del progetto. Prima di pianificare tempi, costi, risorse, sprint e deliverable, bisogna chiarire cosa si vuole ottenere, perché, per chi, con quali condizioni di soddisfazione e con quale approccio gestionale.

Negli appunti lo scoping è definito come il processo che serve a chiarire cosa deve essere prodotto, quali condizioni devono essere rispettate e quale approccio di project management usare.

In pratica, lo scoping risponde a domande come:

Domanda	Perché conta
Qual è il problema o l’opportunità?	Evita di costruire una soluzione non necessaria.
Chi è il committente?	Serve a capire aspettative e vincoli.
Cosa significa successo?	Serve per definire CoS e criteri di accettazione.
Quali requisiti sono davvero necessari?	Serve a delimitare lo scope.
Quale PMLC model è adatto?	Serve a scegliere l’approccio gestionale.
Quali rischi emergono già all’inizio?	Serve a non scoprirli troppo tardi.

Nel progetto CTAF lo scoping è stato fondamentale perché il rischio era partire subito dalla soluzione tecnica, cioè Jason, LLM e web app, senza chiarire il bisogno reale: supportare decisioni cliniche in modo tracciabile, auditabile e con revisione umana.

La sequenza dello scoping

Negli appunti il processo di scoping segue una sequenza precisa:

Condurre le Conditions of Satisfaction.
Definire i requisiti.
Creare la Requirements Breakdown Structure.
Valutare la completezza della RBS.
Definire il PMLC model più adatto.
Scrivere il Project Overview Statement.
Sottomettere il POS per approvazione.

Questa sequenza è importante perché mostra che lo scoping non è solo raccolta requisiti. È il momento in cui il PM costruisce il collegamento tra bisogno del committente, valore atteso, requisiti, rischi e modello di gestione.

Client Wants vs Client Needs

Uno dei concetti più importanti dello scoping è la distinzione tra ciò che il cliente dice di volere e ciò di cui ha realmente bisogno.

Negli appunti è esplicitato che ciò che il committente vuole potrebbe non coincidere con ciò di cui ha bisogno.

Nel progetto CTAF questa distinzione è centrale. Il committente poteva sembrare interessato genericamente a usare AI o LLM nel supporto clinico. Ma il bisogno reale non era avere un LLM che decidesse. Il bisogno reale era avere un sistema di supporto che fosse:

tracciabile;
spiegabile;
auditabile;
sicuro;
con umano nel ciclo;
compatibile con un dominio sensibile come quello clinico.

Quindi lo scoping ha trasformato un possibile want generico, “usare AI per decisioni cliniche”, in un need più corretto: costruire un framework BDI+LLM dove l’LLM supporta la generazione di bozze, ma non prende decisioni autonome.

Questa è una delle frasi più forti da usare all’orale: il valore dello scoping è stato evitare di confondere il fascino tecnologico dell’LLM con il bisogno gestionale e clinico di tracciabilità.

Conditions of Satisfaction

Le Conditions of Satisfaction sono le condizioni che devono essere rispettate perché il committente consideri soddisfacente il risultato del progetto.

Non sono ancora il dettaglio completo delle user story o dei test. Sono condizioni alte, concordate con il committente, che guidano poi requisiti, POS, planning e closing.

Nel progetto CTAF le CoS principali erano:

CoS	Significato gestionale
Sistema BDI funzionante su golden case	Il core simbolico deve essere dimostrabile.
Pipeline LLM	L’LLM deve supportare estrazione claim e bozze di regole.
Web app di review	Deve esserci revisione umana.
Tracciabilità 100%	Ogni decisione deve produrre una traccia.
CLI	Il flusso deve essere eseguibile in modo riproducibile.
Open source	Codice e documentazione devono essere disponibili su GitHub.

La CoS più importante è la tracciabilità al 100%, perché influenza tutta l’architettura e tutta la gestione. Non è un dettaglio tecnico: è una condizione di soddisfazione del committente e un criterio di successo.

CoS vs Acceptance Criteria

Bisogna distinguere bene Conditions of Satisfaction e Acceptance Criteria.

Concetto	Significato
Conditions of Satisfaction	Definiscono cosa deve essere vero perché il progetto sia soddisfacente per il committente.
Acceptance Criteria	Definiscono come verificare una specifica funzionalità o user story.

Nel nostro caso:

Livello	Esempio CTAF
CoS	Ogni decisione deve essere tracciabile.
Acceptance Criterion	L’esecuzione del golden case `gc04` deve generare una trace completa e leggibile.

Questa distinzione è utile perché mostra maturità: le CoS guidano il progetto, gli Acceptance Criteria guidano la verifica operativa.

Project Scoping Meeting

Il Project Scoping Meeting è il momento in cui PM, committente e team si incontrano per chiarire visione, aspettative, requisiti, rischi e approccio.

Negli appunti i deliverable attesi sono CoS, Requirements Document o RBS, best-fit PMLC model e POS.

Nel progetto CTAF abbiamo simulato due meeting.

Il Project Scoping Meeting #1, svolto il 4 marzo 2026, aveva l’obiettivo di raccogliere la visione iniziale e le CoS preliminari. In questo incontro il committente ha spiegato l’esigenza di un framework multi-agente BDI per supporto decisionale clinico, sottolineando la tracciabilità. Il team ha chiarito che il dominio cardiaco sarebbe stato dimostrativo e ha discusso l’uso di Jason e dei servizi LLM.

Le decisioni principali del primo meeting sono state:

CoS approvate come bozza;
dominio cardiaco confermato come ambito dimostrativo;
vincolo human-in-the-loop obbligatorio;
Jason selezionato come piattaforma BDI;
PM incaricato di preparare RBS, registro rischi preliminare e SWOT.

Il Project Scoping Meeting #2, svolto l’11 marzo 2026, ha validato e consolidato il lavoro. In questo incontro sono state approvate le CoS definitive, discussa la RBS, presentata la SWOT, scelto il PMLC model e approvato il POS preliminare.

Le decisioni principali del secondo meeting sono state:

CoS approvate in versione definitiva;
RBS approvata;
registro rischi preliminare discusso;
PMLC selezionato: Iterative Scrum con adattamenti R&D;
POS approvato come base per il planning;
sprint duration fissata a due settimane.

Requirements Breakdown Structure

La Requirements Breakdown Structure organizza i requisiti in modo gerarchico, partendo dal goal del progetto fino a funzioni, sotto-funzioni e feature.

Nel progetto CTAF la RBS parte da un obiettivo L0:

Framework multi-agente BDI per supporto decisionale clinico tracciabile.

Da questo obiettivo derivano quattro rami principali:

Ramo L1	Significato
Runtime BDI	Agenti Jason, ciclo BDI, comunicazione inter-agente.
LLM Pipeline	Estrazione claim, generazione regole, bridge Jason-Python.
Web App Review	Backend, frontend e revisione umana.
Tracciabilità e Spiegazione	Justification Tree, report, audit log.

La RBS è diversa dalla WBS. La RBS dice cosa deve soddisfare il sistema; la WBS, che verrà dopo nel planning, dice quale lavoro bisogna fare per realizzarlo.

Nel progetto questa distinzione è importante perché la RBS ha guidato la WBS: i rami di lavoro del planning derivano dai rami di requisito emersi nello scoping.

Requisiti funzionali e non funzionali

La RBS include sia requisiti funzionali sia requisiti non funzionali.

I requisiti funzionali dicono cosa il sistema deve fare: eseguire ciclo BDI, generare bozze di regole, gestire review umana, produrre trace.

I requisiti non funzionali dicono quali proprietà deve avere il sistema. Nel progetto CTAF erano particolarmente importanti:

NFR	Significato
Human-in-the-loop	Nessuna regola eseguita senza approvazione umana.
Tracciabilità	100% delle decisioni tracciate.
Spiegazioni groundate	Tracce collegate a fonti approvate.
Modularità	Componenti sostituibili.
Portabilità	Esecuzione su Windows, macOS e Linux.
Performance	Ciclo completo sotto 30 secondi.
Affidabilità	Gestione errori LLM e input malformati.

All’orale conviene sottolineare soprattutto human-in-the-loop e tracciabilità, perché sono i requisiti che collegano la gestione del progetto al dominio clinico e alla necessità di auditabilità.

Verifica della RBS

Negli appunti la RBS deve essere verificata rispetto ad attributi come completezza, chiarezza, validità, misurabilità, testabilità, fattibilità, stabilità, performance e safety.

Nel progetto CTAF questo significa fare domande come:

Attributo	Domanda applicata a CTAF
Completezza	Abbiamo coperto BDI, LLM, web review e tracciabilità?
Chiarezza	”Tracciabilità” è definita in modo non ambiguo?
Misurabilità	Possiamo misurare il 100% delle decisioni tracciate?
Testabilità	I golden case permettono una verifica end-to-end?
Fattibilità	Jason, Python e LLM sono integrabili entro il semestre?

Questa verifica è importante perché una RBS vaga porta a una pianificazione debole. Se i requisiti non sono chiari e testabili nello scoping, la WBS e il piano sprint saranno costruiti su basi fragili.

SWOT e rischi preliminari

Durante lo scoping è stata fatta anche una SWOT Analysis.

La SWOT ha evidenziato:

Categoria	CTAF
Strengths	Competenza su Jason, chiarezza della visione, BDI tracciabile.
Weaknesses	Poca esperienza LLM in produzione, budget zero, dipendenza da API esterne.
Opportunities	Interesse accademico per AI trasparente, riuso in altri domini clinici.
Threats	Rate limit LLM, evoluzione normativa AI Act, impegni accademici.

La SWOT non è stata un esercizio decorativo: ha fatto emergere rischi concreti, poi ripresi nel registro rischi.

I rischi preliminari erano:

Codice	Rischio
R1	Indisponibilità o degrado del servizio LLM.
R2	Complessità integrazione Jason-Python.
R3	Ritardi per impegni accademici.
R4	Ambiguità/inconsistenza dei claim clinici generati dall’LLM.
R5	Incompatibilità tra versioni delle librerie.
R6	Timeline semestrale insufficiente.

Questo mostra che il risk management non nasce solo nel monitoring: i rischi vengono già identificati nello scoping e poi raffinati nel planning.

Scelta del PMLC model

Una delle decisioni più importanti dello scoping è stata la scelta del PMLC model.

Nel progetto CTAF la scelta è stata Iterative Scrum con adattamenti per R&D.

Il motivo è che il goal era chiaro, ma la soluzione era parzialmente nota. Sapevamo di voler costruire un framework BDI+LLM tracciabile, ma non conoscevamo perfettamente la soluzione tecnica per integrare Jason, Python, LLM e revisione umana.

Questa scelta è coerente con Wysocki: un progetto con obiettivo chiaro e soluzione parzialmente incerta si colloca nell’area iterativa. Scrum è stato usato come framework operativo, ma adattato alla componente R&D tramite technical spike, risk-based planning, management reserve e validazione incrementale.

Project Overview Statement

Il Project Overview Statement, o POS, è il documento sintetico che formalizza il progetto e ne permette l’approvazione.

Nel progetto CTAF il POS contiene:

Sezione	Contenuto
Problema / Opportunità	LLM black-box non tracciabili in ambito clinico.
Obiettivo del progetto	Framework multi-agente BDI+LLM con revisione umana.
Obiettivi specifici	O1-O7.
Criteri di successo	IRACIS.
Assunzioni, rischi, ostacoli	Jason noto, API LLM disponibili, timeline semestrale.

Il problema dichiarato nel POS è che i sistemi basati su LLM soffrono di mancanza di trasparenza e tracciabilità. Il progetto propone quindi un framework in cui la raccomandazione clinica non è una risposta black-box, ma un risultato tracciato attraverso agenti BDI, fonti, regole e revisione umana.

SMART e IRACIS

Nel POS gli obiettivi devono essere chiari, verificabili e collegati al valore.

Nel progetto avete usato IRACIS, che distingue:

Categoria	Interpretazione nel progetto
Increased Revenue	Valore generato come base per tesi o progetti futuri.
Avoided Cost	Architettura riusabile in altri domini clinici.
Improved Service	Maggiore trasparenza e tracciabilità delle decisioni.

Il criterio più importante è Improved Service: 100% delle decisioni tracciate e 0 raccomandazioni senza revisione umana.

Questo collega direttamente il problema iniziale, cioè l’opacità degli LLM, con un risultato misurabile.

Perché lo scoping è stato cruciale

Nel progetto CTAF lo scoping è stato cruciale per quattro ragioni.

Primo, ha chiarito il vero bisogno: non semplicemente usare un LLM, ma costruire supporto decisionale tracciabile e human-in-the-loop.

Secondo, ha fissato vincoli non negoziabili: tracciabilità, revisione umana, budget zero, dominio dimostrativo e timeline semestrale.

Terzo, ha fatto emergere i rischi tecnici e organizzativi: integrazione Jason-Python, affidabilità LLM, rate limit, claim ambigui e impegni accademici.

Quarto, ha guidato la scelta metodologica: Iterative Scrum secondo Wysocki, con adattamenti R&D.

Senza uno scoping solido, il progetto sarebbe potuto diventare una semplice dimostrazione tecnica. Invece lo scoping lo ha trasformato in un progetto gestito: con committente, condizioni di soddisfazione, requisiti, rischi, PMLC model e POS.

Collegamento con le fasi successive

Lo scoping produce input per tutto il resto del progetto.

Output dello scoping	Uso successivo
CoS	Acceptance criteria, DoD e closing.
RBS	WBS e pianificazione.
POS	PDS e approvazione del piano.
Rischi preliminari	Risk register e Risk Response Plan.
PMLC model	Scrum, sprint plan e monitoring.
SWOT	Giustificazione delle scelte e mitigazione rischi.

Quindi lo scoping non è una fase isolata: è la base logica dell’intero elaborato.

Frase pronta per l’orale

Lo Scoping Process Group è stata la fase in cui abbiamo definito il perimetro del progetto CTAF prima della pianificazione dettagliata. Secondo gli appunti, lo scoping serve a chiarire cosa deve essere prodotto, quali condizioni devono essere rispettate e quale approccio di project management usare. Nel nostro caso è stato fondamentale perché il rischio era partire subito dalla soluzione tecnica, cioè Jason, LLM e web app, senza chiarire il bisogno reale del committente.

Abbiamo quindi svolto due Project Scoping Meeting. Nel primo abbiamo raccolto la visione del committente, definito CoS preliminari e vincoli come human-in-the-loop e tracciabilità. Nel secondo abbiamo validato le CoS, discusso la RBS, fatto SWOT, identificato rischi preliminari, scelto il PMLC model e approvato il POS.

Il punto centrale è la distinzione tra client wants e client needs. Il committente poteva sembrare interessato all’uso di AI o LLM, ma il bisogno reale era avere un sistema auditabile e tracciabile, dove l’LLM non prende decisioni cliniche autonome. Per questo la CoS più importante è stata la tracciabilità al 100% con revisione umana obbligatoria.

La RBS ha tradotto questo bisogno in quattro rami: Runtime BDI, LLM Pipeline, Web App Review e Tracciabilità. Da lì sono emersi anche requisiti non funzionali come human-in-the-loop, performance, portabilità e affidabilità. Infine, i rischi emersi nello scoping hanno giustificato la scelta di Iterative Scrum con adattamenti per R&D.

3. Planning Process Group - Spiegazione Discorsiva

Fonti principali

Teoria planning: 07. Planning Process Group

Applicazione CTAF: Planning nel progetto CTAF

Elaborato: Planning

Artefatti: PDS, WBS, Project Network Diagram, Cost Estimate, Risk Analysis, Sprint Plan

Cos’è il Planning Process Group

Il Planning Process Group è la fase in cui lo scope approvato viene trasformato in un piano operativo. Dopo lo scoping sappiamo cosa vogliamo ottenere, quali condizioni soddisfare e quale PMLC model usare; nel planning decidiamo concretamente cosa fare, in che ordine, con quali risorse, con quali tempi, con quali rischi e con quali criteri di controllo.

Negli appunti la pianificazione è definita come l’insieme delle attività con cui il team definisce cosa fare, con quali risorse, in quali tempi e con quali costi prima di passare all’esecuzione.

La cosa importante è che pianificare non significa eliminare l’incertezza. Significa renderla visibile e gestibile. Negli appunti è richiamata la pain curve di Wysocki: una buona pianificazione richiede più sforzo all’inizio, ma riduce i problemi dopo; una pianificazione debole sembra più veloce all’inizio, ma fa crescere il dolore durante l’esecuzione.

Nel progetto CTAF il planning era particolarmente importante perché il progetto aveva vincoli forti: team piccolo, budget zero, timeline semestrale, tecnologie diverse da integrare e componente LLM incerta.

Perché la pianificazione conta

Secondo gli appunti, la pianificazione serve a tre cose principali:

Funzione	Significato
Ridurre l’incertezza	Chiarisce attività, vincoli, dipendenze e rischi.
Aumentare la comprensione	Allinea PM, team e committente.
Migliorare l’efficienza	Rende più chiaro l’uso di tempo, risorse e budget.

Nel progetto CTAF questo si traduce così: il planning ha permesso di capire che il runtime BDI e la pipeline LLM erano sul percorso critico, mentre la web app poteva procedere in parallelo; ha permesso di stimare l’effort con PERT; ha permesso di formalizzare i rischi; e ha portato a una management reserve del 10%.

Un punto da sottolineare all’orale è che, anche se il progetto è Iterative Scrum, la pianificazione non sparisce. Semplicemente non è un piano rigido e definitivo come nel Waterfall: è una baseline iniziale che viene poi controllata e adattata sprint dopo sprint.

JPPS - Joint Project Planning Sessions

Le Joint Project Planning Sessions, o JPPS, sono sessioni collaborative in cui le persone coinvolte nel progetto costruiscono il piano insieme.

Negli appunti la JPPS è definita come il momento in cui project manager, team e committente costruiscono una visione condivisa del piano. Non è una riunione informativa: produce deliverable concreti.

I deliverable tipici di una JPPS sono:

PDS;
WBS;
stime di durata ed effort;
risorse necessarie;
network schedule;
schedula;
project notebook;
proposta di progetto.

Nel progetto CTAF sono state fatte due JPPS consecutive.

La JPPS #1, il 18 marzo 2026, era interna al team tecnico. Il PM ha presentato il PDS come estensione del POS, poi il team ha trasformato la RBS in WBS, ha stimato le attività con la tecnica dei tre punti e ha iniziato a identificare le dipendenze.

Le decisioni principali della JPPS #1 sono state:

WBS strutturata in macro-pacchetti legati agli sprint;
tecnica dei tre punti adottata per le stime;
stime in giorni/uomo con correzione per disponibilità part-time del team, cioè 0.5 FTE.

La JPPS #2, il 19 marzo 2026, ha coinvolto anche il committente nella validazione. In questa sessione sono stati presentati network diagram, critical path, analisi rischi, stima economica, piano sprint e responsabilità.

Le decisioni principali della JPPS #2 sono state:

critical path formalizzato: Setup BDI → Agenti → Pipeline LLM → Validazione;
strategie di mitigazione approvate;
quattro sprint da due settimane;
management reserve fissata al 10%;
piano sprint approvato dal committente.

Questo è importante perché dimostra che il planning non è stato deciso dal PM da solo. È stato costruito con il team e validato con il committente.

PDS - Project Definition Statement

Il Project Definition Statement, o PDS, è la versione estesa del POS dalla prospettiva del planning team.

Negli appunti il PDS contiene le stesse cinque sezioni del POS:

problem/opportunity;
project goal;
project objectives;
success criteria;
assumptions, risks, obstacles.

La differenza è che il POS è sintetico e serve ad approvare il progetto, mentre il PDS è più dettagliato e serve al team per pianificare.

Nel progetto CTAF il PDS ha aggiunto elementi concreti che nel POS erano solo sintetizzati:

Area	Contenuto CTAF
Contesto clinico	Masse cardiache, imaging multimodale, linee guida ESC.
Soluzione proposta	Quattro agenti BDI, pipeline LLM, web app, Justification Tree.
Obiettivi O1-O7	Runtime BDI, LLM Pipeline, Web App, Traceability, Golden Cases, CLI, Open Source.
Stakeholder	Team, PM, Cardiologia Forlì, cardiologo referente, utente finale simulato.
Criteri di successo	Completezza funzionale, stabilità runtime, tracciabilità 100%, documentazione, timeline, test.
Vincoli	Budget zero, dati sintetici, free tier LLM, consegna entro giugno 2026.
Rischi	R1-R6 con strategia e Risk Response Plan.

Il PDS è quindi il documento che rende il progetto pianificabile: non dice solo “vogliamo fare CTAF”, ma chiarisce cosa significa farlo, quali obiettivi sono Must, quali rischi esistono e come saranno verificati i risultati.

WBS - Work Breakdown Structure

La WBS è una descrizione gerarchica di tutto il lavoro che deve essere svolto per soddisfare i bisogni del committente.

Fonte teorica: Work Breakdown Structure WBS.

La differenza con la RBS è essenziale:

Struttura	Domanda a cui risponde
RBS	Quali requisiti deve soddisfare il sistema?
WBS	Quale lavoro serve per produrre quei requisiti?

Negli appunti si dice che la WBS traduce i requisiti in lavoro da eseguire. Se deriva direttamente dalla RBS, mantiene un collegamento forte con i criteri di successo.

Nel progetto CTAF la WBS è stata costruita partendo dai rami della RBS e trasformandoli in work package. I rami principali erano:

Ramo WBS	Contenuto
1.1 Requisiti e Scoping	requisiti, casi d’uso clinici, MoSCoW, CoS.
1.2 Progettazione	architettura multi-agente, pipeline LLM, web app, tracciabilità.
1.3 Runtime BDI	agenti Jason, piani, comunicazione, test.
1.4 LLM Pipeline	bridge Jason-Python, estrazione regole, test pipeline.
1.5 Web App	backend, frontend, integrazione.
1.6 Integrazione e Test	E2E, golden case, CLI, Docker.
1.7 Documentazione	14 artefatti, README, setup guide, GitHub.
1.8 Gestione Progetto	sprint planning, riunioni, monitoraggio rischi.

La WBS ha anche una funzione di controllo: se un pacchetto è definito bene, posso stimarlo, assegnarlo, monitorarlo e collegarlo a un deliverable.

Criteri di completezza della WBS

Negli appunti la WBS deve essere verificata rispetto a criteri di completezza. In sintesi, un task dovrebbe avere:

stato e completamento misurabili;
inizio e fine chiari;
deliverable associato;
tempi e costi stimabili;
durata accettabile;
indipendenza sufficiente;
giudizio positivo del PM sulla chiarezza del lavoro.

Nel progetto CTAF questi criteri sono stati rispettati perché i work package erano collegati a deliverable concreti: agenti implementati, pipeline funzionante, web app, test end-to-end, documentazione finale.

Un esempio: “Runtime BDI” da solo è troppo alto livello, ma nella WBS viene scomposto in definizione agenti, implementazione piani e goal, comunicazione inter-agente, test su scenari. A quel punto il lavoro diventa stimabile e assegnabile.

Approccio della WBS: verb-type

Negli appunti sono citati diversi approcci per costruire una WBS: noun-type, verb-type e organizational.

Nel progetto CTAF abbiamo usato un approccio prevalentemente verb-type, cioè orientato ad attività come progettare, implementare, integrare, testare, documentare.

Questo è coerente con un progetto software e con Scrum: non ci limitiamo a elencare componenti statici, ma descriviamo il lavoro necessario per arrivare agli incrementi.

Stime: durata, effort e PERT

Negli appunti c’è una distinzione importante tra durata ed effort.

La durata è il tempo di calendario necessario a completare un task. L’effort è la quantità di lavoro richiesta.

Non sono la stessa cosa. Se un task richiede 4 giorni/uomo di effort, non significa automaticamente che duri 4 giorni di calendario: dipende da quante persone ci lavorano, dalla loro disponibilità, dalle dipendenze e dagli imprevisti.

Nel progetto CTAF questa distinzione era importante perché il team era part-time, con disponibilità stimata a 0.5 FTE per membro.

Per stimare le attività è stata usata la three-point technique, cioè la tecnica dei tre punti:

E = (O + 4M + P) / 6

Dove:

O = stima ottimistica;
M = stima più probabile;
P = stima pessimistica;
E = stima attesa.

Questa tecnica è adatta al progetto perché alcune attività avevano incertezza significativa. Per esempio, l’integrazione Jason-Python o la pipeline LLM potevano andare bene, ma potevano anche generare problemi imprevisti.

Esempi di stima dal progetto:

Attività	O	M	P	PERT
Setup ambiente Jason	0.5	1	2	1.1
Agenti BDI	4	6	10	6.3
Claim extraction	3	5	8	5.2
Rule drafting	3	5	8	5.2
Flusso end-to-end	2	3	6	3.3

L’effort totale stimato era 39,17 giorni-uomo, con deviazione standard di progetto circa 2,12.

All’orale conviene sottolineare che PERT è stato usato proprio perché il progetto aveva una componente R&D. Una singola stima secca sarebbe stata meno realistica.

Planning poker e story point

Negli appunti è indicato che negli approcci agili come Scrum si possono usare tecniche come planning poker e story point.

Nel progetto CTAF ci sono due livelli di stima:

stime PERT in giorni/uomo per costruire baseline, effort e network diagram;
story point per gestire il backlog Scrum e la velocity degli sprint.

Questa combinazione è coerente con l’approccio scelto: Scrum per l’esecuzione iterativa, ma con strumenti di planning più strutturati per gestire rischio, durata e dipendenze.

Network Diagram e Critical Path

Il Project Network Diagram rappresenta le dipendenze tra task e permette di derivare la schedula del progetto.

Fonte teorica: Project Network Diagram.

Nel network diagram compaiono concetti come:

ES, earliest start;
EF, earliest finish;
LS, latest start;
LF, latest finish;
slack, ritardo massimo tollerabile;
critical path, percorso che determina la durata del progetto.

Il critical path identifica i task che non possono ritardare senza ritardare l’intero progetto.

Nel progetto CTAF, a livello di task, il percorso critico era:

Setup Jason -> Agenti BDI -> Golden case / Setup DSPy -> Claim extraction -> Rule drafting -> E2E -> Validazione -> Documentazione

Nel documento di progetto è espresso anche come:

1.1 -> 1.2 -> 1.3/2.1 -> 2.2 -> 2.3 -> 4.1 -> 4.2 -> 4.3

La durata stimata del critical path era 29,4 giorni-uomo, circa 6 settimane a 0.5 FTE.

A livello macro-fasi, invece, il percorso critico attraversa progettazione, runtime BDI, integrazione e documentazione, per circa 9 settimane. Le due misure sono coerenti ma hanno granularità diversa.

Il punto importante è che la Web App era fuori dal critical path: poteva procedere in parallelo. Questo è stato utile perché ha permesso di assorbire ritardi senza bloccare l’intera consegna.

Slack e management reserve

Negli appunti si distingue tra slack e management reserve.

Lo slack è il ritardo che un task può subire senza impattare il progetto o il task successivo. Però negli appunti è presente un avvertimento forte: non bisogna pianificare contando di usare lo slack per salvare il progetto.

La management reserve, invece, è una riserva esplicita e visibile. Negli appunti si dice che può essere una percentuale della durata complessiva, ad esempio 5-10%, e che non bisogna gonfiare la durata dei singoli task.

Nel progetto CTAF la management reserve è stata fissata al 10%, tradotta in scope bank / buffer di circa 8 story point e in una settimana di riserva.

Questa scelta è coerente con l’incertezza R&D: invece di nascondere margini dentro ogni task, il margine è stato reso visibile e gestito formalmente.

Analisi dei rischi nel planning

Nel planning i rischi emersi nello scoping sono stati dettagliati con probabilità, impatto, prodotto PxI, strategia e mitigazione.

I rischi principali erano:

Rischio	PxI	Strategia
R1 - Indisponibilità LLM	6	Mitigazione con provider multiplo e fallback.
R2 - Integrazione Jason-Python	9	Mitigazione con prototipo bridge HTTP e fallback file-based.
R3 - Ritardi accademici	4	Accettazione con buffer e scope bank.
R4 - Claim LLM ambigui	4	Mitigazione con validazione strutturale e post-processore.
R5 - Incompatibilità librerie	3	Contingenza con Docker.
R6 - Timeline insufficiente	6	MoSCoW rigido e sprint di riserva.

Il rischio più alto era R2, integrazione Jason-Python, con PxI = 9. Per questo è stato gestito con un technical spike e un prototipo bridge HTTP.

Questa parte è molto importante perché dimostra che la pianificazione non riguarda solo tempi e task, ma anche rischio e strategie di risposta.

Stima economica e budget zero

Negli appunti la stima dei costi serve a prevedere le risorse economiche necessarie e a controllarle durante l’esecuzione.

Nel progetto CTAF il costo monetario era zero, perché:

studenti senza compenso;
API LLM in free tier;
GitHub Free;
Docker gratuito per uso accademico;
sviluppo locale;
strumenti open source.

Questo non significa che il progetto non avesse costo in senso gestionale. L’effort stimato era di circa 200 ore aggregate nel cost estimate, distribuite tra sviluppo Jason, Python, frontend, PM e revisione/test.

La distinzione importante da dire all’orale è:

Il budget monetario era zero, ma effort e risorse erano comunque pianificati e controllati.

Questo evita l’errore di dire “non abbiamo fatto cost management perché non c’erano soldi”. In realtà avete fatto stima di effort e gestione delle risorse, anche se il costo economico diretto era nullo.

Piano sprint

Il piano sprint traduce la pianificazione in cicli Scrum.

Nel progetto CTAF:

Sprint	Periodo	Obiettivo	Deliverable
Sprint 1	23 Mar - 5 Apr	Runtime BDI	4 agenti Jason su `gc04`.
Sprint 2	6 Apr - 19 Apr	Pipeline LLM	DSPy per claim e rule drafting.
Sprint 3	20 Apr - 3 May	Web App	Console React/Vite per review e trace.
Sprint 4	4 May - 17 May	Integrazione e documentazione	Flusso E2E, golden case, report finale.

Poi erano previste una settimana di riserva e una fase di chiusura.

Questo piano è coerente con il critical path: prima BDI, poi LLM, poi integrazione. La web app procede in parallelo perché non è sul percorso critico principale.

RACI Matrix

La RACI Matrix serve a chiarire le responsabilità.

La legenda è:

Lettera	Significato
R	Responsible: chi esegue il lavoro.
A	Accountable: chi risponde del risultato.
C	Consulted: chi viene consultato.
I	Informed: chi viene informato.

Nel progetto CTAF il PM è Accountable per molte attività, coerentemente con il contesto accademico e la simulazione. Però ogni area tecnica ha un responsible chiaro: Dev Jason per runtime BDI e tracciabilità, Dev Python per pipeline LLM, Dev Frontend per web app.

Il committente è Accountable soprattutto per Sprint Review e accettazione, perché è lui che valida il valore del deliverable.

La RACI è utile perché evita ambiguità: in un team piccolo si rischia di pensare che “tutti fanno tutto”, ma a livello gestionale serve sapere chi risponde di cosa.

Collegamento con execution e monitoring

Il planning produce la baseline per le fasi successive.

Output del planning	Uso successivo
PDS	Riferimento completo per obiettivi, vincoli e rischi.
WBS	Base per sprint, task e monitoraggio.
Stime PERT	Baseline di effort e durata.
Network diagram	Identificazione critical path e dipendenze.
Risk analysis	Input per risk monitoring.
Cost estimate	Controllo budget/effort.
Sprint plan	Guida per execution.
RACI	Chiarezza responsabilità.

Quindi il planning è il ponte tra scoping ed execution: prende requisiti e condizioni di soddisfazione e li trasforma in lavoro organizzato.

Perché il planning è stato cruciale per CTAF

Nel progetto CTAF il planning è stato cruciale per cinque ragioni.

Primo, ha trasformato la RBS in WBS, quindi i requisiti sono diventati attività concrete.

Secondo, ha reso visibili dipendenze e critical path: BDI e LLM erano critici, la web app era parallela.

Terzo, ha quantificato l’incertezza tramite PERT, invece di usare stime arbitrarie.

Quarto, ha formalizzato i rischi con strategie di mitigazione e contingenza.

Quinto, ha previsto management reserve e MoSCoW, due strumenti essenziali per proteggere la consegna in un progetto con componente R&D.

Frase pronta per l’orale

Il Planning Process Group è stata la fase in cui abbiamo trasformato lo scope approvato in un piano operativo. Dopo lo scoping avevamo CoS, RBS, POS, rischi preliminari e scelta del PMLC model; nel planning abbiamo costruito PDS, WBS, stime, network diagram, critical path, risk response plan, cost estimate, sprint plan e RACI.

La pianificazione è stata condotta in due JPPS. Nella prima, con il team tecnico, abbiamo validato il PDS, trasformato la RBS in WBS e stimato le attività con la tecnica dei tre punti. Nella seconda, con il committente, abbiamo validato network diagram, critical path, analisi rischi, piano sprint e management reserve.

Abbiamo usato PERT perché alcune attività avevano incertezza elevata, soprattutto integrazione Jason-Python e pipeline LLM. Il critical path passava da setup Jason, agenti BDI, pipeline LLM, integrazione end-to-end, validazione e documentazione. La web app era fuori dal critical path e poteva procedere in parallelo.

Il planning è stato fondamentale perché ha reso gestibile l’incertezza: invece di nascondere margini nei task, abbiamo previsto una management reserve del 10%; invece di trattare tutti i requisiti allo stesso modo, abbiamo usato MoSCoW; invece di ignorare i rischi tecnici, li abbiamo formalizzati con strategie di mitigazione. Questo ha reso coerente il passaggio da scoping a execution.

4. Execution / Launching Process Group - Spiegazione Discorsiva

Fonti principali

Teoria process groups: Executing Process Group

Teoria Scrum: The Scrum Team

Applicazione CTAF: Execution nel progetto CTAF

Elaborato: Execution

Artefatti: Sprint Plan, Meeting Minutes, Status Reports

Cos’è l’Execution / Launching Process Group

Il Launching/Executing Process Group è la fase in cui il piano diventa lavoro coordinato. Dopo lo scoping e il planning, non basta avere POS, PDS, WBS, stime e rischi: bisogna mettere il team nelle condizioni di eseguire il lavoro, comunicare, risolvere blocchi, produrre incrementi e ottenere feedback.

Negli appunti il Launching/Executing Process Group è definito come il gruppo di processi che seleziona il personale del team, stabilisce le regole operative e aiuta il team a lavorare insieme per completare il progetto.

I processi indicati negli appunti includono:

reclutare o confermare i membri del team;
completare la documentazione descrittiva del progetto;
stabilire le regole operative;
stabilire il processo di gestione dei cambiamenti di scope;
gestire le comunicazioni del team;
finalizzare la schedula;
finalizzare i work packages.

Nel progetto CTAF questa fase coincide soprattutto con l’esecuzione Scrum degli sprint. Quindi il lavoro pianificato nella WBS e nello Sprint Plan è stato trasformato in incrementi concreti: Runtime BDI, Pipeline LLM, Web App Review e integrazione finale.

Execution non significa solo implementazione tecnica

Un errore da evitare all’orale è dire che l’Execution è semplicemente “la fase in cui abbiamo programmato”.

Nel corso, l’Execution include anche la gestione del team, delle comunicazioni, delle cerimonie, delle review e delle retrospettive. Scrivere codice è solo una parte. Dal punto di vista del project management, la domanda è: come abbiamo fatto lavorare il team in modo coordinato e controllabile?

Nel progetto CTAF la risposta è:

sprint di due settimane;
Sprint Planning all’inizio di ogni sprint;
Daily Standup su Discord;
Sprint Review con demo al committente;
Sprint Retrospective con azioni di miglioramento;
Product Backlog gestito su GitHub Projects;
Definition of Done e Acceptance Criteria;
MoSCoW per proteggere i Must-have.

Quindi l’Execution è la fase in cui Scrum diventa operativo.

Framework Scrum adottato

Il progetto CTAF è stato eseguito secondo Scrum, con sprint di due settimane.

Le cerimonie usate sono state:

Cerimonia	Funzione nel progetto CTAF
Sprint Planning	Definire Sprint Goal e selezionare le story dal Product Backlog.
Daily Standup	Allineare il team su lavoro svolto, lavoro successivo e blocchi.
Sprint Review	Dimostrare l’incremento al committente e raccogliere feedback.
Sprint Retrospective	Analizzare processo, problemi e azioni di miglioramento.

Il Product Backlog era gestito su GitHub Projects con una board Kanban: To Do, In Progress, Review, Done. Questo è coerente con la filosofia docs-as-code e con l’uso di GitHub come single source of truth del progetto.

Il backlog era priorizzato con MoSCoW:

Priorità	Elementi nel progetto
Must Have	Agenti BDI, pipeline LLM base, console review, golden case funzionante.
Should Have	Visualizzazione tracce, gestione ambiguità, test automatici.
Could Have	Export report, dashboard metriche, dark mode.
Won’t Have	Deploy production, autenticazione utenti, multi-dominio clinico.

Questo ha permesso di eseguire il progetto senza perdere di vista le priorità. Quando sono emersi ritardi o problemi tecnici, i Must sono rimasti protetti.

Definition of Ready e Definition of Done

Nel progetto CTAF lo Sprint Plan distingue anche tra Definition of Ready e Definition of Done.

La Definition of Ready indica quando una user story può entrare in uno sprint. Una story era pronta se:

era scritta nel formato corretto;
aveva criteri di accettazione definiti e testabili;
aveva una stima in story point condivisa;
aveva dipendenze identificate e non bloccanti;
era abbastanza piccola da chiudersi nello sprint;
aveva una priorità MoSCoW assegnata.

La Definition of Done indica quando una story può essere considerata completata. Nel progetto CTAF una story era done quando:

Il codice soddisfaceva i criteri di accettazione.
La pull request era approvata da almeno un reviewer.
I test unitari e di integrazione passavano.
La documentazione minima era aggiornata.
La funzionalità era dimostrabile alla Sprint Review.
Non c’erano errori runtime o warning bloccanti.

La distinzione è importante:

Concetto	Domanda a cui risponde
Definition of Ready	La story è pronta per entrare nello sprint?
Definition of Done	La story è davvero completata?
Acceptance Criteria	Questa specifica story soddisfa le condizioni attese?

Questa struttura ha dato qualità all’Execution: non bastava “averci lavorato”, serviva produrre qualcosa di verificabile e dimostrabile.

Sprint 1 - Runtime BDI

Il primo sprint si è svolto dal 23 marzo al 5 aprile 2026.

Lo Sprint Goal era implementare quattro agenti BDI in Jason e verificare il funzionamento sul golden case gc04.

Le story principali erano:

setup ambiente Jason e toolchain;
implementazione runtime_coordinator;
implementazione case_reasoner;
implementazione trace_guardian;
implementazione care_planner;
esecuzione golden case gc04;
test unitari degli agenti.

Durante i Daily Standup sono emersi due blocchi principali: la configurazione di Jason su Windows, risolta con Docker, e una dipendenza ciclica tra piani case_reasoner e trace_guardian, risolta con redesign dell’interfaccia.

La Sprint Review ha dimostrato il golden case gc04 con i quattro agenti BDI interagenti. I risultati sono stati positivi: quattro agenti funzionanti, tracce BDI in JSON e 12 test unitari passati su 12.

La retrospettiva ha evidenziato una lezione importante: il setup tecnologico era stato sottostimato. Questo ha portato ad aumentare l’attenzione per il tempo extra nei setup successivi.

Velocità misurata: 18 SP su 20, cioè 90%.

Sprint 2 - Pipeline LLM

Il secondo sprint si è svolto dal 6 aprile al 19 aprile 2026.

Lo Sprint Goal era realizzare la pipeline DSPy per estrazione di claim clinici e generazione di bozze regole.

Le story principali erano:

setup DSPy;
configurazione provider Groq/OpenRouter;
claim extraction;
rule drafting;
validatore formato regole per AgentSpeak;
test su sample claim clinici;
integrazione con output dello Sprint 1.

I blocchi principali sono stati tecnici e tipici della componente R&D:

DSPy richiedeva Python 3.11+;
l’output LLM non era sempre consistente;
Groq ha prodotto rate limit, quindi è stato attivato il fallback OpenRouter.

La Sprint Review ha mostrato l’inserimento di testo clinico, l’estrazione di claim e la generazione di bozze regole compatibili con Jason. I risultati sono stati: pipeline funzionante, Groq come provider primario, OpenRouter come fallback, 10 claim testati di cui 8 corretti e 2 con ambiguità minori.

Il feedback del committente ha chiesto di migliorare la gestione delle ambiguità nei claim borderline. Questo è un buon esempio di feedback iterativo: lo sprint non chiude solo lavoro, ma produce apprendimento.

Velocità misurata: 18 SP su 22, cioè 82%.

Sprint 3 - Web App Review

Il terzo sprint si è svolto dal 20 aprile al 3 maggio 2026.

Lo Sprint Goal era sviluppare la console web per revisione delle regole e ispezione delle tracce BDI.

Le story principali erano:

setup React/Vite + TypeScript;
componente RuleList;
componente RuleReview;
componente TraceViewer;
integrazione con API backend;
test UI/UX su 5 scenari utente.

I blocchi principali sono stati la scelta della libreria per visualizzare diagrammi di traccia e il ritardo sul componente TraceViewer, dovuto alla complessità del parsing JSON.

La Sprint Review ha mostrato una console web funzionante con lista regole, dettaglio regola, cronologia, approvazione/rigetto e visualizzazione delle tracce BDI. Il feedback del committente è stato positivo: l’interfaccia era chiara e la visualizzazione delle tracce utile per la validazione.

La retrospettiva ha mostrato che i componenti di visualizzazione dati erano più complessi del previsto. Questo è stato trasformato in una lesson learned: prevedere margine maggiore per componenti visuali complessi.

Velocità misurata: 16 SP su 18, cioè 89%.

Sprint 4 - Integrazione e Testing

Il quarto sprint si è svolto dal 4 maggio al 17 maggio 2026.

Lo Sprint Goal era completare il flusso end-to-end, validare i golden case e finalizzare la documentazione.

Le story principali erano:

integrazione BDI + LLM + Web App;
validazione golden case gc04;
gestione ambiguità claim;
test di integrazione;
documentazione framework;
preparazione deliverable finali;
archiviazione Project Notebook.

In questo sprint si sono concentrati i rischi più importanti. I blocchi principali sono stati:

discrepanza nel formato dati tra pipeline LLM e console web;
ambiguità dei claim clinici;
ritardo nella documentazione per sovrapposizione con esami accademici.

Il problema più rilevante è stato l’attivazione del rischio R4, cioè ambiguità/inconsistenza dei claim clinici generati dall’LLM. Durante la validazione del golden case, due claim generavano regole ambigue. Il PM ha attivato la management reserve per sviluppare un post-processore di disambiguazione.

Questo è un esempio molto forte da citare all’orale: un rischio identificato nello scoping/planning si è materializzato durante l’execution, ed è stato gestito usando la riserva prevista. Il ritardo di due giorni è stato assorbito senza spostare la data di consegna.

La Sprint Review finale ha mostrato il flusso completo:

input testo clinico -> pipeline LLM -> bozze regole -> review umana -> runtime BDI -> esecuzione agenti -> visualizzazione tracce

I risultati sono stati:

flusso end-to-end funzionante;
golden case gc04 validato;
gestione ambiguità implementata;
10 test di integrazione, 9 passati e 1 con warning minore;
documentazione completa;
Project Notebook archiviato su GitHub.

Il feedback del committente è stato: “Il progetto raggiunge tutti gli obiettivi. Framework funzionante e ben documentato. Consegna accettata.”

Velocità misurata: 15 SP su 18, cioè 83%.

Velocità complessiva

La velocity complessiva del progetto è stata:

Sprint	SP pianificati	SP completati	Percentuale
Sprint 1	20	18	90%
Sprint 2	22	18	82%
Sprint 3	18	16	89%
Sprint 4	18	15	83%
Totale	78	67	86%

Questa percentuale va interpretata correttamente. Non significa che il progetto abbia fallito il 14% del lavoro: significa che in un contesto Iterative Scrum con componente R&D sono stati completati tutti i Must-have, mentre gli elementi non completati erano Should o Could.

Il fatto che nessun Must sia stato perso dimostra l’efficacia di MoSCoW e della gestione dello scope.

Gestione dei blocchi durante l’esecuzione

Un aspetto centrale dell’Execution è la gestione dei blocchi.

Nel progetto CTAF i blocchi non sono stati trattati come eccezioni casuali, ma come informazioni utili per adattare il lavoro:

Blocco	Sprint	Gestione
Jason difficile su Windows	Sprint 1	Docker.
Dipendenza ciclica tra agenti	Sprint 1	Redesign interfaccia.
DSPy richiede Python 3.11+	Sprint 2	Aggiornamento ambienti.
Output LLM inconsistente	Sprint 2	Post-processore.
Rate limit Groq	Sprint 2	Fallback OpenRouter.
TraceViewer più complesso del previsto	Sprint 3	Libreria dedicata e margine futuro.
Ambiguità claim	Sprint 4	Management reserve e post-processore.

Questa tabella mostra bene la natura iterativa: ogni problema diventa un’occasione per aggiornare processo, stime o mitigazioni.

Ruolo della Sprint Review

La Sprint Review è stata una cerimonia centrale perché ha mantenuto il committente coinvolto.

Nel progetto CTAF la review non era una formalità. Ogni review aveva una demo concreta:

Sprint 1: runtime BDI su gc04;
Sprint 2: pipeline LLM con claim e bozze regole;
Sprint 3: console web con Rule Review e Trace Viewer;
Sprint 4: flusso end-to-end completo.

Questo ha reso l’avanzamento visibile. In un progetto con rischio tecnico elevato, mostrare incrementi frequenti riduce il rischio di scoprire alla fine che il deliverable non corrisponde alle aspettative.

Ruolo della Retrospective

La Sprint Retrospective ha permesso di migliorare il processo.

Esempi di lesson emerse durante l’execution:

setup tecnologici da stimare con più margine;
API LLM e rate limiting da documentare meglio;
componenti di visualizzazione dati più complessi del previsto;
documentazione da iniziare prima;
test di integrazione da automatizzare meglio.

Quindi la retrospective non è solo “cosa è andato bene e male”, ma un meccanismo di apprendimento organizzativo. Questo si collega poi direttamente al Closing e alle Lessons Learned.

Collegamento con monitoring

Execution e Monitoring non sono fasi separate in modo rigido. Negli appunti sui process groups si sottolinea che i gruppi di processo possono coesistere e interagire.

Durante l’esecuzione del progetto CTAF, il monitoring avveniva continuamente tramite:

Daily Standup;
GitHub Projects;
Sprint Review;
velocity per sprint;
issue log;
controllo dei rischi attivati;
confronto tra SP pianificati e completati.

Questo significa che mentre il team eseguiva, il PM controllava avanzamento, blocchi e rischi. L’Execution produceva lavoro; il Monitoring dava visibilità e permetteva correzioni.

Perché l’Execution è stata cruciale per CTAF

L’Execution è stata cruciale perché ha dimostrato che il piano non era solo teorico.

Primo, gli sprint hanno trasformato la WBS in incrementi reali.

Secondo, le cerimonie Scrum hanno dato ritmo e visibilità al team.

Terzo, le review hanno coinvolto il committente e validato progressivamente il risultato.

Quarto, le retrospective hanno permesso di migliorare il processo durante il progetto, non solo alla fine.

Quinto, la gestione dei rischi durante l’esecuzione ha dimostrato coerenza con planning e monitoring: R1 e R4 non sono stati improvvisati, ma gestiti con strategie già previste.

Frase pronta per l’orale

L’Execution, nel nostro progetto, non è stata semplicemente la fase in cui abbiamo sviluppato il software. Secondo gli appunti, il Launching/Executing Process Group serve a rendere operativo il progetto: stabilire regole di lavoro, gestire comunicazioni, finalizzare work package e aiutare il team a lavorare insieme. Nel nostro caso questo è stato realizzato tramite Scrum.

Abbiamo organizzato l’esecuzione in quattro sprint di due settimane. Il primo sprint ha prodotto il runtime BDI con quattro agenti Jason; il secondo la pipeline LLM con Groq/OpenRouter; il terzo la web app di review; il quarto l’integrazione end-to-end e la validazione sui golden case. Ogni sprint aveva Sprint Planning, Daily Standup, Sprint Review e Retrospective.

La Sprint Review è stata il momento più importante per il committente, perché ogni incremento veniva dimostrato e validato. La Retrospective, invece, ci ha permesso di correggere il processo: per esempio, abbiamo capito che setup tecnologici, rate limiting LLM e componenti di visualizzazione richiedevano più margine.

Durante l’esecuzione si sono attivati rischi previsti nel planning, come il rate limit Groq e l’ambiguità dei claim LLM. Li abbiamo gestiti con fallback OpenRouter e management reserve per il post-processore di disambiguazione. Alla fine abbiamo completato 67 SP su 78, cioè l’86%, ma nessun Must-have è stato perso: questo dimostra che Scrum, MoSCoW e la gestione dei rischi hanno funzionato.

5. Monitoring & Controlling Process Group - Spiegazione Discorsiva

Fonti principali

Teoria monitoring: 09. Monitoring and Controlling Process Group

Applicazione CTAF: Monitoring nel progetto CTAF

Elaborato: Monitoring & Controlling

Artefatti: Status Reports, Risk Analysis, Sprint Plan

Cos’è il Monitoring & Controlling Process Group

Il Monitoring & Controlling Process Group è la fase in cui il project manager osserva l’avanzamento reale, lo confronta con il piano e decide se servono azioni correttive.

Negli appunti è definito come l’insieme di strumenti, template e processi usati per monitorare l’avanzamento del progetto, controllare gli scostamenti e intervenire quando il progetto si allontana da quanto pianificato.

Il punto centrale è questo: dopo aver pianificato, non basta aspettare la fine per vedere se il progetto è andato bene. Bisogna controllare periodicamente cosa sta succedendo, confrontarlo con la baseline e agire quando emergono ritardi, rischi o problemi.

Quindi il monitoring non è solo produrre report. Serve a generare early warning, cioè segnali precoci che permettono di intervenire quando il problema è ancora gestibile.

Nel progetto CTAF questa fase è stata fondamentale perché c’erano molte fonti di incertezza: LLM, integrazione Jason-Python, rate limit, ambiguità claim, impegni accademici e timeline semestrale.

Monitoring e controlling non sono separati dall’execution

Un punto importante degli appunti è che i process groups non sono fasi rigidamente sequenziali. Durante l’execution il PM monitora e controlla continuamente.

Nel progetto CTAF questo significa che mentre il team lavorava agli sprint, il PM controllava:

burndown chart;
story point completati;
status report;
issue log;
rischi attivati;
uso della scope bank;
feedback del committente;
avanzamento rispetto allo Sprint Goal.

Quindi Execution e Monitoring procedevano insieme: gli sprint producevano lavoro, il monitoring produceva visibilità e controllo.

Come rispettare la schedula

Negli appunti sono indicate alcune regole operative per mantenere il progetto entro i binari:

tenere daily team meetings;
completare i task il prima possibile;
riportare problemi appena emergono;
evitare scope creep;
non indovinare, ma fare domande;
applicare il principio “good enough is good enough”;
rispettare i requisiti senza over-design;
essere aperti e onesti con il team.

Nel progetto CTAF queste regole sono state applicate tramite Daily Standup, GitHub Projects, Sprint Review e MoSCoW. In particolare, MoSCoW ha impedito di inseguire funzionalità non essenziali quando emergevano problemi tecnici.

Progress Reporting System

Un Progress Reporting System è il sistema con cui il PM raccoglie, organizza e comunica le informazioni sullo stato del progetto.

Negli appunti un buon sistema di reporting deve:

Caratteristica	Significato
Tempestivo	Le informazioni devono arrivare quando servono.
Completo	Deve coprire schedule, costi, qualità, rischi e stakeholder.
Accurato	I dati devono riflettere lo stato reale.
Leggero	Non deve generare overhead eccessivo.
Early warning	Deve far emergere problemi prima che diventino critici.

Nel progetto CTAF il reporting era leggero e coerente con Scrum: ogni sprint produceva status report, burndown, aggiornamento issue e aggiornamento rischi. Questo è adatto a un team piccolo: non serviva un sistema pesante, ma serviva visibilità continua.

Tipi di status report

Negli appunti sono descritti diversi tipi di report:

Tipo	Significato
Current Period Report	Descrive il periodo più recente.
Cumulative Report	Mostra l’andamento dell’intero progetto.
Exception Report	Evidenzia solo gli scostamenti critici.
Stoplight Report	Usa verde, giallo e rosso per comunicare lo stato.
Variance Report	Confronta pianificato e reale.

Nel progetto CTAF sono stati usati soprattutto status report a stoplight, perché sono semplici da leggere e adatti a comunicare rapidamente lo stato del progetto.

Gli stati erano:

Stato	Significato
Verde	Tutto sotto controllo, nessuna azione correttiva critica.
Giallo	Scostamento contenuto, azione correttiva in atto.
Rosso	Scostamento grave, intervento immediato necessario.

Nel progetto:

Sprint	Stato	Motivazione
Sprint 1	Verde	Avanzamento in linea, 2 SP non critici rinviati.
Sprint 2	Verde	Ritardo di 4 SP, ma recuperabile.
Sprint 3	Verde	Esecuzione regolare.
Sprint 4	Giallo	R4 attivato, ma gestito con management reserve.

La scelta di tenere Sprint 2 verde nonostante il ritardo è importante: lo stato non dipende solo dallo scostamento numerico, ma anche dal fatto che esista o meno un piano di recupero credibile.

Burndown chart

Il burndown chart mostra quanti story point restano da completare nel tempo.

Nel progetto CTAF è stato usato sia un release burndown sull’intero progetto sia burndown per sprint.

Il release burndown partiva da 78 SP totali. Alla fine non è arrivato a zero perché 11 SP non critici sono stati rinviati, principalmente migliorie UI e documentazione non essenziale.

Per sprint:

Sprint	SP iniziali	SP rimanenti a fine sprint	Interpretazione
Sprint 1	20	2	Andamento quasi ideale, setup iniziale più lento.
Sprint 2	22	4	Ritardo da configurazione DSPy e LLM.
Sprint 3	18	2	Buon andamento, TraceViewer più complesso.
Sprint 4	18	3	R4 attivato, ritardo assorbito.

Il burndown è utile perché rende visibile il trend. Non dice solo quanti task sono completati, ma mostra se il team sta bruciando lavoro alla velocità prevista.

Earned Value Analysis: PV, EV, AC

L’Earned Value Analysis, o EVA/EVM, serve a confrontare lavoro pianificato, lavoro svolto e costo effettivo.

Negli appunti le tre grandezze principali sono:

Sigla	Significato
PV	Planned Value: valore pianificato del lavoro.
EV	Earned Value: valore del lavoro effettivamente completato.
AC	Actual Cost: costo effettivo del lavoro svolto.

Nel progetto CTAF, siccome il budget monetario era zero, EV, PV e AC sono stati misurati in story point. Questa è una scelta ragionevole perché gli story point rappresentano il valore/effort del backlog completato.

I dati erano:

Sprint	PV	EV	AC	SPI	CPI
Sprint 1	20	18	18	0.90	1.00
Sprint 2	22	18	18	0.82	1.00
Sprint 3	18	16	16	0.89	1.00
Sprint 4	18	15	15	0.83	1.00
Cumulativo	78	67	67	0.86	1.00

SPI e CPI

Gli indici principali sono SPI e CPI.

Lo Schedule Performance Index misura la performance rispetto alla schedula:

SPI = EV / PV

Il Cost Performance Index misura la performance rispetto ai costi:

CPI = EV / AC

Nel progetto CTAF:

SPI cumulativo = 0.86;
CPI = 1.00.

SPI 0.86 significa che è stato completato l’86% del lavoro pianificato. Non va letto automaticamente come fallimento, perché gli SP non completati erano Should o Could, mentre tutti i Must sono stati consegnati.

CPI 1.00 va interpretato con cautela. Non significa che il progetto sia stato economicamente perfetto in senso industriale; significa che, usando story point come unità di controllo e avendo budget monetario zero, non ci sono stati costi diretti fuori controllo.

La frase corretta da dire all’orale è:

Il vero indicatore critico era lo SPI, non il CPI, perché il budget monetario era nullo. Lo SPI 0.86 è accettabile nel contesto perché i Must-have sono stati completati e la consegna è stata rispettata.

Issues Log

L’Issues Log è il registro dinamico dei problemi emersi durante il progetto.

Negli appunti è importante perché permette di tracciare problema, impatto, owner, azione, stato ed esito. Inoltre diventa una fonte storica utile per progetti futuri.

Nel progetto CTAF erano presenti 9 issue:

ID	Problema	Risoluzione
ISS-001	Jason su Windows	Docker.
ISS-002	Dipendenza ciclica piani BDI	Redesign interfaccia agenti.
ISS-003	DSPy richiede Python 3.11+	Aggiornamento ambienti.
ISS-004	Formato output LLM inconsistente	Post-processore.
ISS-005	Rate limit Groq	Fallback OpenRouter.
ISS-006	Scelta libreria grafica tracce	react-mermaid.
ISS-007	Parsing JSON tracce complesso	Libreria JSON viewer.
ISS-008	Discrepanza formato dati BDI-LLM	Interfaccia di trasformazione.
ISS-009	Ambiguità claim clinici	Post-processore con management reserve.

L’Issues Log mostra una cosa importante: la maggior parte dei problemi era legata all’integrazione, non alla singola implementazione isolata. Questo conferma che il rischio tecnico principale era davvero la combinazione BDI + LLM + web review.

Risk Monitoring

Il monitoraggio dei rischi verifica se i rischi identificati in scoping/planning si stanno materializzando.

Nel progetto CTAF:

Rischio	Stato
R1 - LLM API	Attivato: rate limit Groq, mitigato con OpenRouter.
R2 - Integrazione BDI-LLM	Non attivato, prevenuto da prototipo preliminare.
R3 - Ritardi accademici	Attivato parzialmente, assorbito da buffer.
R4 - Ambiguità claim	Attivato, mitigato con management reserve.
R5 - Incompatibilità librerie	Non attivato, prevenuto da Docker.
R6 - Timeline insufficiente	Attivato parzialmente, assorbito da reserve.

Questa parte è molto forte all’orale perché dimostra coerenza tra fasi: i rischi non sono stati scritti solo per riempire un documento, ma sono stati monitorati e alcuni si sono effettivamente attivati.

Scope Bank e change management

La Scope Bank è una riserva di tempo/scope usata per gestire modifiche durante il progetto.

Negli appunti la Scope Bank è descritta come un deposito di tempo, spesso 5-10% del totale, da usare quando bisogna integrare cambiamenti o imprevisti.

Nel progetto CTAF la scope bank era del 10%, cioè 8 SP su 78. Durante lo Sprint 4 sono stati usati 2 SP per aggiungere il post-processore di disambiguazione dei claim.

Questo non è un dettaglio tecnico: è gestione controllata dello scope. Quando R4 si è attivato, non si è semplicemente “aggiunto lavoro” in modo informale; il PM ha valutato l’impatto, usato la riserva e mantenuto la consegna.

Il change management seguiva questi passaggi:

Identificazione del cambiamento.
Valutazione impatto su tempo, costi, qualità e rischi.
Registrazione nel Change Log.
Decisione: approvato, respinto o rinviato.
Implementazione secondo priorità MoSCoW.

Esempi di change:

Change	Decisione	Motivazione
Supporto OpenRouter	Approvato	Mitigazione R1.
Sostituzione libreria grafica tracce	Approvato	Migliore visualizzazione.
Post-processore disambiguazione	Approvato	R4 attivato, assorbito da scope bank.
Riduzione test integrazione 15 → 10	Approvato	Priorità su documentazione e consegna.

Gestione del ritardo Sprint 4

Il caso più importante di monitoring è lo Sprint 4.

Durante lo Sprint 4 si è materializzato R4: due claim generati dalla pipeline LLM erano ambigui e non traducibili direttamente in regole AgentSpeak valide.

L’impatto stimato era di 2 giorni di ritardo sul flusso end-to-end.

Le azioni correttive sono state:

attivare la management reserve;
usare 2 SP dalla scope bank;
implementare un post-processore;
classificare i claim in chiari, ambigui e non validi;
mandare i claim ambigui a revisione umana prioritaria;
rigettare i claim non validi con motivazione.

L’esito è stato positivo: il ritardo è stato assorbito senza impattare la data di consegna del 17 maggio.

Questo esempio collega benissimo teoria e progetto: reporting, risk monitoring, issue log, scope bank e change management convergono tutti nello stesso episodio.

SPOC - Single Point of Contact

Nel progetto il SPOC, cioè Single Point of Contact, era il Project Manager.

Questo significa che il PM era l’unico punto di contatto per il committente e per i report di progetto. In un team piccolo è utile perché evita comunicazioni disperse: il committente sa a chi rivolgersi, e il team non riceve richieste contraddittorie.

Questo si collega alla communication management: non basta produrre report, bisogna anche avere un canale chiaro di comunicazione.

Perché il Monitoring è stato cruciale per CTAF

Il Monitoring & Controlling è stato cruciale per cinque motivi.

Primo, ha reso visibile l’avanzamento reale tramite burndown e status report.

Secondo, ha permesso di interpretare gli scostamenti: non tutti i ritardi erano critici, perché alcuni erano su Should/Could.

Terzo, ha monitorato rischi già previsti, come R1 e R4.

Quarto, ha gestito lo scope in modo controllato tramite scope bank e change log.

Quinto, ha permesso di rispettare la data di consegna nonostante ritardi e problemi tecnici.

La cosa più importante da dire è che il controllo non è stato punitivo o burocratico: è stato uno strumento per decidere quando intervenire.

Collegamento con Closing

Il Monitoring prepara direttamente il Closing.

Se durante il progetto hai status report, issue log, burndown, risk log e change log, alla fine puoi dimostrare in modo documentato cosa è successo.

Nel progetto CTAF questo ha permesso di arrivare al closing con:

evidenze sugli sprint;
rischi attivati e mitigati;
issue risolte;
stato finale dei deliverable;
motivazione dei pochi SP non completati;
accettazione del committente.

Quindi il Monitoring non serve solo durante il progetto: produce anche la memoria storica usata nel Final Report e nelle Lessons Learned.

Frase pronta per l’orale

Il Monitoring & Controlling Process Group è stato il gruppo di processi con cui abbiamo confrontato l’avanzamento reale del progetto CTAF con la baseline definita nel planning. Secondo gli appunti, non basta pianificare e poi aspettare la fine: bisogna osservare periodicamente cosa succede, rilevare scostamenti e intervenire con azioni correttive.

Nel nostro progetto il monitoraggio è stato fatto con burndown chart, status report a stoplight, Earned Value in story point, issue log, risk monitoring, scope bank e change management. Gli status report erano verdi per i primi tre sprint e giallo per lo Sprint 4, quando si è attivato il rischio R4 sui claim ambigui.

Abbiamo calcolato SPI e CPI. Lo SPI cumulativo è stato 0.86, cioè 67 SP completati su 78 pianificati. Il CPI è rimasto 1.00 perché non c’erano costi monetari diretti e abbiamo misurato il costo in story point. Lo SPI 0.86 non è stato un problema critico perché gli SP non completati erano Should o Could, mentre tutti i Must sono stati consegnati.

Il caso più importante è stato lo Sprint 4: due claim LLM erano ambigui, quindi si è attivato R4. Abbiamo usato 2 SP della scope bank per sviluppare un post-processore di disambiguazione. Il ritardo di due giorni è stato assorbito senza spostare la consegna. Questo dimostra che risk management, scope bank e monitoring hanno funzionato in modo integrato.

6. Closing Process Group - Spiegazione Discorsiva

Fonti principali

Teoria closing: 10. Closing Process Group

Applicazione CTAF: Closing nel progetto CTAF

Elaborato: Closing

Artefatti: Final Report, Status Reports, Meeting Minutes

Cos’è il Closing Process Group

Il Closing Process Group è la fase in cui il progetto viene chiuso in modo formale, ordinato e documentato.

Negli appunti è definito come l’insieme delle attività necessarie per chiudere il progetto in modo definito, ordinato e formalmente accettato dal committente.

La cosa più importante da ricordare è che chiudere un progetto non significa semplicemente aver finito il lavoro tecnico. Un progetto può avere codice funzionante ma non essere ancora chiuso dal punto di vista gestionale. Per chiuderlo servono accettazione formale, verifica dei deliverable, documentazione, audit post-implementazione, final report e archiviazione.

Nel progetto CTAF questa distinzione è fondamentale: non bastava dire che il framework funzionava. Bisognava dimostrare che gli obiettivi O1-O7 erano stati raggiunti, che il committente aveva accettato il deliverable, che la documentazione era completa e che le lezioni apprese erano state raccolte.

Perché il closing dipende dal planning

Negli appunti c’è un punto chiave: una chiusura efficace dipende da procedure definite prima, soprattutto nel planning.

Questo significa che la chiusura non si improvvisa alla fine. Se in planning hai definito criteri di successo, acceptance criteria, Definition of Done, deliverable e modalità di verifica, allora in closing puoi controllare in modo ordinato se tutto è stato raggiunto.

Nel progetto CTAF il closing è stato possibile perché nelle fasi precedenti erano già stati definiti:

obiettivi O1-O7 nel POS e nel PDS;
criteri di successo misurabili;
golden case;
Definition of Done;
Acceptance Criteria per sprint;
status report;
risk log e issue log;
Project Notebook.

Quindi il closing non è una fase scollegata: è la conseguenza logica di scoping, planning, execution e monitoring.

I passi del closing

Negli appunti i passi principali per chiudere il progetto sono:

Ottenere l’accettazione formale del deliverable.
Assicurarsi che tutti i deliverable siano stati installati o consegnati.
Assicurarsi che tutta la documentazione sia disponibile.
Ottenere la firma o approvazione del committente sul report finale.
Condurre l’audit post-implementazione.
Celebrare la fine del progetto.

Nel progetto CTAF questi passi sono stati simulati e documentati attraverso Sprint Review #4, Final Report, Project Notebook e Post-Implementation Audit.

Verifica degli obiettivi

La prima parte del closing CTAF è stata la verifica degli obiettivi definiti in POS e PDS.

Gli obiettivi erano:

Obiettivo	Criterio	Stato
O1 - Runtime BDI	4 agenti Jason operativi su `gc04`	Raggiunto
O2 - Pipeline LLM	DSPy con Groq/OpenRouter	Raggiunto
O3 - Console Web	App React/Vite + FastAPI per review	Raggiunto
O4 - Tracciabilità	Structured trace per ogni decisione	Raggiunto
O5 - Golden case	`gc00`, `gc04`, `gc_gray_zone` validati	Raggiunto
O6 - CLI	`ctaf run scenario.json` completa il flusso	Raggiunto
O7 - Open source	Repository con README e licenza	Raggiunto

Questo è un punto forte: tutti gli obiettivi sono stati raggiunti, inclusi i Must-have e anche l’obiettivo Could-have O7.

La verifica degli obiettivi collega direttamente closing e scoping: ciò che era stato definito all’inizio viene controllato alla fine.

Accettazione formale

L’accettazione formale è il momento in cui il committente approva il deliverable.

Negli appunti una procedura di accettazione serve a stabilire come il committente verifica e approva formalmente il risultato del progetto. Se i criteri non sono chiari, il closing può diventare conflittuale: il team pensa di aver finito, ma il committente può non essere soddisfatto.

Nel progetto CTAF l’accettazione formale è avvenuta il 17 maggio 2026, alla fine della Sprint Review dello Sprint 4.

La dichiarazione verbalizzata è:

“Il progetto Cardiac Traceability Agent Framework raggiunge tutti gli obiettivi definiti in fase di pianificazione. Il framework è funzionante, ben documentato, e dimostra l’efficacia dell’integrazione tra motore BDI simbolico e LLM assistito con revisione umana. La consegna è accettata.”

Questa frase è importantissima all’orale perché dimostra che il closing non è solo autovalutazione del team, ma include l’approvazione del committente.

Consegna finale dei deliverable

Nel closing sono stati consegnati o archiviati diversi artefatti:

Artefatto	Significato
Report finale di progetto	Sintesi conclusiva di risultati, performance e lezioni apprese.
Repository codice sorgente	Codice, README, documentazione e setup.
Project Notebook	Verbali, decisioni, change log, issue log, risk log.
Golden case `gc04`	Caso dimostrativo completo.
Console web	Demo della revisione e delle tracce.
Backlog storico	Storia sprint su GitHub Projects.
Status report	Evidenze di monitoring sui quattro sprint.

Questa lista mostra che la consegna non riguarda solo il prodotto tecnico, ma anche la documentazione gestionale.

Installazione della soluzione

Negli appunti sono descritti diversi approcci di installazione:

Approccio	Significato
Phased	Consegna per fasi.
By Business Unit	Installazione per unità organizzativa.
Cut-Over	Passaggio netto alla nuova soluzione.
Parallel	Vecchia e nuova soluzione funzionano insieme.

Nel progetto CTAF non c’era una produzione clinica reale, quindi l’installazione va interpretata in modo accademico: la consegna coincide con repository, demo script, golden case e tag finale.

L’approccio più vicino è un Cut-Over accademico: il repository viene congelato con tag finale v1.0.0-final e quella diventa la versione consegnata.

È importante dire che non si tratta di deploy clinico reale. Il progetto è un prototipo accademico, quindi non viene installato in reparto né usato su dati reali.

Project Notebook

Il Project Notebook è la raccolta ordinata dei documenti principali prodotti durante il progetto.

Negli appunti può includere POS, RBS, schedule, verbali, status report, design, prototipi, change log, comunicazioni, final report, documenti di accettazione e audit.

Nel progetto CTAF il Project Notebook era organizzato nel repository GitHub, in particolare sotto docs/, con tre aree:

Cartella	Contenuto
`docs/verbali/`	Verbali di scoping, JPPS, sprint planning, sprint review, retrospective, audit.
`docs/decisioni/`	`change-log.md`, `issue-log.md`, `risk-log.md`.
`docs/deliverable/`	POS, CoS, PDS, RBS, SWOT, WBS, report finale.

Il Project Notebook è stato archiviato il 20 maggio 2026 con tag v1.0.0-final.

Il punto importante è che il Project Notebook non è stato ricostruito solo alla fine: la documentazione è stata tenuta durante il progetto. Questo riduce il carico finale e rende più affidabile la memoria del progetto.

Final Project Report

Il Final Project Report è il documento finale che sintetizza risultati, performance, gestione, tecniche utilizzate, valutazione dell’approccio e raccomandazioni.

Negli appunti il final report include executive summary, livello di successo, performance del progetto, organizzazione, tecniche impiegate, pregi e difetti dell’approccio e raccomandazioni.

Nel progetto CTAF il Final Report contiene:

risultati raggiunti;
confronto obiettivi vs risultati;
lezioni apprese;
raccomandazioni;
Post-Implementation Audit Summary.

I risultati principali dichiarati sono:

framework BDI con quattro agenti;
pipeline LLM con bridge Jason-Python;
web app React/FastAPI per revisione umana;
Justification Tree per tracciabilità;
repository open-source con documentazione completa.

Il Final Report è quindi il documento che trasforma l’esito del progetto in una chiusura formalizzata e comunicabile.

Post-Implementation Audit

Il Post-Implementation Audit è la valutazione successiva all’implementazione. Non guarda solo se il prodotto funziona, ma anche se il progetto ha prodotto valore, se il committente è soddisfatto, se tempo/budget/specifiche sono stati rispettati e cosa si può imparare per il futuro.

Negli appunti le domande guida sono, tra le altre:

Gli obiettivi del progetto sono stati raggiunti?
Il deliverable fa quello che il team aveva previsto?
Il deliverable fa quello che il committente si aspettava?
Il progetto è stato completato rispettando tempo, budget e specifiche?
Il committente è soddisfatto?
I criteri di successo sono stati rispettati?
Che lezione è stata imparata rispetto alla metodologia?

Nel progetto CTAF l’audit è stato condotto il 20 maggio 2026.

I risultati erano:

Dimensione	Valutazione	Nota
Soddisfazione committente	5/5	Tutti gli obiettivi raggiunti.
Qualità prodotto	4/5	Framework funzionante, un warning minore.
Rispetto tempistiche	4/5	Consegna rispettata, alcuni SP non critici rinviati.
Gestione budget	5/5	Costo zero confermato.
Copertura test	4/5	Copertura migliorabile.
Documentazione	5/5	Completa e archiviata.
Gestione rischi	4/5	R4 attivato ma mitigato.

Questo audit è importante perché dimostra maturità gestionale: il progetto non viene solo celebrato, ma valutato criticamente.

Lessons Learned

Le Lessons Learned sono una parte centrale del closing perché trasformano l’esperienza in conoscenza riutilizzabile.

Nel progetto CTAF le lezioni principali sono:

Area	Lezione appresa	Raccomandazione
Metodologia	Scrum adatto a R&D con incognite	Mantenere sprint brevi.
Architettura	Separazione moduli riduce rischi	Progettare interfacce chiare.
Scope	MoSCoW previene scope creep	Applicarlo rigorosamente.
Stima	LLM difficile da stimare	Aggiungere 25-30% su componenti AI.
Riserve	Buffer 10% al limite	Usare 15-20% per progetti AI.
Documentazione	Docs-as-code riduce carico finale	Documentare in tempo reale.

Due lezioni sono particolarmente importanti per l’orale.

La prima è che Scrum si è dimostrato adatto, ma solo perché adattato alla componente R&D. Gli sprint brevi hanno permesso di scoprire prima i problemi di integrazione.

La seconda è che la management reserve del 10% è stata sufficiente ma al limite. R4 ha consumato 2 SP della scope bank; per futuri progetti AI si raccomanda una riserva del 15-20%.

Raccomandazioni future

Nel closing sono state indicate raccomandazioni per sviluppi futuri:

estendere il framework a patologie cardiache reali;
integrare test automatici in CI/CD;
validare formalmente con personale medico;
valutare pubblicazione accademica;
mantenere fallback LLM locale per riproducibilità;
usare il formato Justification Tree come base per progetti di explainable AI agents.

Queste raccomandazioni mostrano che il progetto si chiude, ma lascia una base per progetti successivi. Questo è coerente con la funzione del closing: non solo terminare, ma lasciare traccia utile.

Celebrare la fine del progetto

Negli appunti la celebrazione è l’ultimo passaggio del closing. Non aggiunge un deliverable tecnico, ma riconosce formalmente la conclusione del lavoro e il contributo del team.

Nel contesto accademico CTAF, la celebrazione è simbolica: accettazione del committente, tag finale, final report, documentazione archiviata e conclusione dell’elaborato.

Non è la parte più importante da discutere all’orale, ma serve a mostrare che il closing è anche una transizione: il team smette di lavorare sul progetto e il deliverable viene consegnato.

Perché il Closing è stato cruciale per CTAF

Il Closing è stato cruciale per cinque motivi.

Primo, ha verificato formalmente che tutti gli obiettivi O1-O7 fossero stati raggiunti.

Secondo, ha ottenuto l’accettazione del committente nella Sprint Review #4.

Terzo, ha raccolto deliverable tecnici e gestionali in un Project Notebook.

Quarto, ha trasformato i dati di monitoring in valutazione finale tramite audit e final report.

Quinto, ha prodotto lessons learned utili per progetti futuri, soprattutto su Scrum R&D, stime LLM e management reserve.

La chiusura dimostra che il progetto non è solo “arrivato alla fine”, ma è stato concluso in modo ordinato, verificabile e documentato.

Collegamento con tutte le fasi precedenti

Il Closing raccoglie ciò che è stato prodotto nelle fasi precedenti:

Fase precedente	Cosa confluisce nel Closing
Scoping	CoS, RBS, POS, criteri iniziali.
Planning	PDS, WBS, stime, risk response plan, sprint plan.
Execution	Incrementi, sprint review, deliverable tecnici.
Monitoring	Status report, issue log, risk log, SPI/CPI, scope bank.

Per questo il closing è il punto di sintesi dell’intero progetto.

Frase pronta per l’orale

Il Closing Process Group è stata la fase in cui abbiamo chiuso formalmente il progetto CTAF. Secondo gli appunti, chiudere un progetto non significa semplicemente aver finito il lavoro tecnico: bisogna ottenere accettazione formale, verificare i deliverable, archiviare la documentazione, condurre un audit post-implementazione e produrre il final report.

Nel nostro caso abbiamo verificato tutti gli obiettivi O1-O7 definiti in POS e PDS. Tutti sono stati raggiunti: runtime BDI, pipeline LLM, console web, tracciabilità, golden case, CLI e repository open-source. L’accettazione formale è avvenuta il 17 maggio 2026 durante la Sprint Review #4, con dichiarazione del committente che il progetto raggiungeva gli obiettivi e veniva accettato.

Abbiamo poi consegnato e archiviato gli artefatti: report finale, repository, Project Notebook, golden case, console web, backlog storico e status report. Il Project Notebook è stato archiviato con tag finale v1.0.0-final, includendo verbali, decisioni, issue log, risk log e deliverable approvati.

Infine abbiamo svolto il Post-Implementation Audit il 20 maggio 2026. L’audit ha valutato soddisfazione committente, qualità prodotto, rispetto tempistiche, budget, test, documentazione e gestione rischi. Le lessons learned principali sono che Scrum funziona bene per R&D se adattato, che MoSCoW ha prevenuto scope creep, che le componenti LLM richiedono stime più prudenti e che per progetti AI una management reserve del 15-20% sarebbe più adeguata del 10%.

Prossime Sezioni Da Aggiungere

Tecniche trasversali: WBS, RBS, PERT, EVM, RACI, Scope Bank
Strumenti e giustificazione toolchain

Appunti Uni

Esplora

12. Discussione Orale - Versione Discorsiva

Discussione Orale - Versione Discorsiva

Indice

1. Scrum - Spiegazione Discorsiva

Cos’è Scrum

I ruoli di Scrum

Gli sprint

Le cerimonie Scrum

Gli artefatti Scrum

Product Backlog e MoSCoW

Story point e velocity

Perché Scrum era adatto a CTAF

Frase pronta per l’orale

2. Scoping Process Group - Spiegazione Discorsiva

Cos’è lo Scoping Process Group

La sequenza dello scoping

Client Wants vs Client Needs

Conditions of Satisfaction

CoS vs Acceptance Criteria

Project Scoping Meeting

Requirements Breakdown Structure

Requisiti funzionali e non funzionali

Verifica della RBS

SWOT e rischi preliminari

Scelta del PMLC model

Project Overview Statement

SMART e IRACIS

Perché lo scoping è stato cruciale

Collegamento con le fasi successive

Frase pronta per l’orale

3. Planning Process Group - Spiegazione Discorsiva

Cos’è il Planning Process Group

Perché la pianificazione conta

JPPS - Joint Project Planning Sessions

PDS - Project Definition Statement

WBS - Work Breakdown Structure

Criteri di completezza della WBS

Approccio della WBS: verb-type

Stime: durata, effort e PERT

Planning poker e story point

Network Diagram e Critical Path

Slack e management reserve

Analisi dei rischi nel planning

Stima economica e budget zero

Piano sprint

RACI Matrix

Collegamento con execution e monitoring

Perché il planning è stato cruciale per CTAF

Frase pronta per l’orale

4. Execution / Launching Process Group - Spiegazione Discorsiva

Cos’è l’Execution / Launching Process Group

Execution non significa solo implementazione tecnica

Framework Scrum adottato

Definition of Ready e Definition of Done

Sprint 1 - Runtime BDI

Sprint 2 - Pipeline LLM

Sprint 3 - Web App Review

Sprint 4 - Integrazione e Testing

Velocità complessiva

Gestione dei blocchi durante l’esecuzione

Ruolo della Sprint Review

Ruolo della Retrospective

Collegamento con monitoring

Perché l’Execution è stata cruciale per CTAF

Frase pronta per l’orale

5. Monitoring & Controlling Process Group - Spiegazione Discorsiva

Cos’è il Monitoring & Controlling Process Group

Monitoring e controlling non sono separati dall’execution

Come rispettare la schedula

Progress Reporting System

Tipi di status report

Burndown chart

Earned Value Analysis: PV, EV, AC

SPI e CPI

Issues Log

Risk Monitoring

Scope Bank e change management

Gestione del ritardo Sprint 4