Studio Orale — Project Management & CTAF
Come usare questo documento: Ogni sezione parte dalla teoria, mostra l’applicazione nel progetto CTAF (Cardiac Traceability Agent Framework), e conclude con “Cosa dire all’esame” — una mini-script per rispondere oralmente.
Metodo di studio
Questo file è la traccia di discussione. Per ogni concetto trovi una definizione breve, l’applicazione nel progetto e il rimando agli appunti completi del corso. Se il docente approfondisce, apri il link Obsidian indicato nella sezione.
Indice
Mappa teoria → appunti completi
- Fondamenti di PM, business value e PMLC: 04. Definizione di Project Management
- Process groups e knowledge areas: 05. Definizione dei Processi
- Scoping, CoS, RBS, POS, SMART, IRACIS: 06. Scoping Process Group
- Planning, JPPS, PDS, WBS, stime, network, reserve: 07. Planning Process Group
- Monitoring, EVM, scope bank, issue log, status report: 09. Monitoring and Controlling Process Group
- Closing, accettazione, audit, lessons learned: 10. Closing Process Group
- Criteri e struttura dell’elaborato: Progetto - Linee Guida
1. Panoramica del Progetto
Riferimenti Obsidian
- Perché l’elaborato valuta la gestione e non il software: Obiettivo del Progetto
- Struttura richiesta dell’elaborato: Struttura dell’Elaborato
- Fasi da coprire nell’orale: Fasi da Coprire
CTAF - Cardiac Traceability Agent Framework
Framework multi-agente BDI (Jason/AgentSpeak) che integra ragionamento simbolico con LLM per supporto decisionale clinico cardiologico. Ogni inferenza è tracciabile (Justification Tree), le regole LLM sono bozze revisionate da umano.
| Elemento | Dettaglio |
|---|---|
| Corso | Project Management — UniBO, Prof. Boschetti |
| Studente | Lorenzo Leoni, Matricola 0001192033 |
| PMLC | Iterative (Scrum) con adattamenti per R&D |
| Durata | Febbraio — Giugno 2026 (semestre) |
| Budget | Zero (open-source, free-tier) |
| Team | PM + 3 sviluppatori + Committente (Cardiologia Forlì) |
| Repository | GitHub (docs-as-code, board kanban, issue tracking) |
Cosa dire all’esame (presentazione 30”)
“Il mio progetto si chiama CTAF, un framework multi-agente per supporto decisionale clinico tracciabile. L’obiettivo è coniugare la tracciabilità dei sistemi BDI simbolici — ogni inferenza è giustificata perché l’architettura BDI la genera con un piano e delle credenze — con la flessibilità degli LLM, però tenendo l’LLM solo in fase di authoring, non in produzione: genera bozze di regole cliniche che un revisore umano valida. Il dominio è la cardiologia, in particolare masse cardiache, basato sulle ESC Guidelines. L’architettura ha 4 agenti Jason:
runtime_coordinator,case_reasoner,trace_guardian,care_planner; una pipeline LLM con Groq/OpenRouter via DSPy; una console web React per la revisione umana.”“Dal punto di vista del PM, il progetto è stato gestito con un approccio Iterative Scrum con adattamenti per R&D, seguendo la tassonomia di Wysocki. Vi spiego perché questa scelta e come l’abbiamo applicata.”
Punto da sottolineare
Sottolinea subito la scelta PMLC perché è il punto centrale che il professore valuta.
2. PMLC Model — La scelta metodologica centrale
Punto critico
Il professore ha corretto “Adaptive” in “Iterative”. Devi saper distinguere e motivare.
Riferimenti Obsidian
- Definizione di project management secondo PMI e Wysocki: Definizione di Project Management
- Project Management Life Cycle: Project Management Life Cycle
- Modelli PMLC: Modelli PMLC
- Scelta del best-fit PMLC model: Scelta del Best-Fit PMLC Model
- Differenza tra process groups e PMLC: Process Groups e PMLC
Teoria (Wysocki)
PMLC Model
Un Project Management Life Cycle Model descrive come vengono organizzati e ripetuti i processi di gestione del progetto: scoping, planning, launching/execution, monitoring & controlling e closing. Non è solo una sequenza temporale: è il modo in cui il project manager decide quanto pianificare all’inizio, quanto iterare e come gestire l’incertezza.
Idea centrale
La scelta del PMLC dipende da quanto sono chiari goal e solution. Più la soluzione è incerta, più servono cicli brevi, apprendimento, risk management e coinvolgimento del cliente.
| Modello | Goal | Solution | Quando |
|---|---|---|---|
| Linear | Chiaro | Chiara | Requisiti stabili, nessuna modifica |
| Incremental | Chiaro | Chiara (a pezzi) | Business value frequente |
| Iterative | Chiaro | Parzialmente nota | Requisiti incompleti/instabili, si impara implementando |
| Adaptive | Chiaro | Non nota | Cambiamento atteso, pianificazione JIT |
| Extreme (xPM) | Non chiaro | Non nota | R&D pura, goal emerge durante |
Dibattito: Alcuni autori (Highsmith) classificano Scrum come Adaptive. Wysocki lo classifica come Iterativo. Il corso segue Wysocki.
Come dirlo all'orale
Non dire solo “abbiamo scelto Scrum”. Devi dire: “abbiamo scelto un PMLC Iterative Scrum secondo Wysocki, perché il goal era chiaro ma la soluzione era parzialmente incerta”.
Applicazione CTAF
| Parametro | Valutazione |
|---|---|
| Goal | Chiaro: framework multi-agente BDI+LLM per clinica tracciabile |
| Solution | Parzialmente nota: BDI noto, LLM noto, ma l’integrazione Jason↔Python aveva incognite (R2, PxI=9) |
| Requisiti | Stabili per il core BDI, instabili per la componente LLM (API esterne) |
| Rischio | Medio-alto (componente LLM, dipendenze esterne) |
Scelta: Iterative (Scrum) secondo Wysocki — goal chiaro, soluzione parzialmente nota, necessità di ispezione frequente.
Alternative scartate
| Modello | Perché NO |
|---|---|
| Linear (Waterfall) | Requisiti LLM non completamente prevedibili; non permette adattamento |
| Adaptive (ASD) | Eccessivamente flessibile: perde la struttura stabile del core BDI |
| Extreme (XP) | Troppo focalizzato su eccellenza tecnica, non su gestione del rischio |
| Incremental | Non basta: la componente R&D richiede iterazione, non solo incrementi |
5 Adattamenti Scrum per R&D
Riferimenti Obsidian
- Pianificazione iterativa e incertezza: Importanza della Pianificazione
- Management reserve nella schedulazione: Project Network Diagram
- Scope Bank nel controllo: Scope Bank
- Problem escalation e issues: Issues Log, Problem Escalation Strategy
- Prototipo/PoC/MVP nello scoping: PoC, Prototipo e MVP
Perché servono adattamenti R&D
Scrum fornisce sprint, ruoli, backlog e cerimonie, ma non risolve automaticamente l’incertezza tecnica tipica della ricerca e sviluppo. In CTAF l’incertezza era concentrata su LLM, bridge Jason-Python, formato dei claim e affidabilità delle API esterne. Gli adattamenti servono a trasformare l’incertezza in attività controllabili.
| Adattamento | Cosa significa | Perché serve in R&D |
|---|---|---|
| 1. Management Reserve (10%) | Sprint 5 di riserva + 8 SP buffer | Assorbire imprevisti tipici di R&D (API changes, bug inattesi) |
| 2. Risk-based sprint planning | Attività dedicate a ridurre rischi tecnici | Sprint 1: technical spike bridge Jason-Python |
| 3. Technical spike | Esplorazione tecnica prima di implementare | Bridge HTTP Jason↔Python, test LLM API, compatibilità librerie |
| 4. MoSCoW rigido | Must-have consegnati anche con tagli | Se LLM fallisce, il core BDI deve comunque funzionare |
| 5. Validazione incrementale | Ogni sprint validato su golden case | gc00 (semplice), gc04 (completo), gc_gray_zone (complesso) |
Spiegazione degli adattamenti
- Management Reserve / Scope Bank: è una riserva formale, non tempo libero. Nel progetto valeva 8 SP, circa il 10% del backlog. È stata usata per assorbire il rischio R4, cioè l’ambiguità dei claim LLM. Teoria completa: Scope Bank.
- Risk-based sprint planning: gli sprint non sono stati pianificati solo per produrre feature, ma anche per ridurre rischi. Esempio: anticipare la validazione LLM e il bridge Jason-Python invece di rimandarli alla fine. Collegamento teorico: Risk Management e JPPS.
- Technical spike: attività esplorativa breve per capire fattibilità e vincoli prima dell’implementazione definitiva. Nel nostro caso: prototipo bridge Jason-Python, test API LLM, formato output. Collegamento teorico: PoC, Prototipo e MVP.
- MoSCoW rigido: classificazione Must/Should/Could/Won’t usata per proteggere la consegna. Se il tempo finisce, si tagliano Should e Could, non i Must. Nel nostro progetto gli 11 SP non completati erano tutti Should/Could. Collegamento: WBS e Scope Bank.
- Validazione incrementale su golden case: ogni sprint produceva un risultato verificabile su casi clinici di riferimento. Questo evita di scoprire problemi solo alla fine e rende la Sprint Review un momento reale di accettazione progressiva. Collegamento: Procedure di Accettazione.
Cosa dire all’esame
“La scelta del PMLC model è la decisione metodologica più importante. Noi abbiamo classificato il progetto come Iterative Scrum secondo Wysocki: il goal era chiaro — un framework multi-agente BDI con LLM per tracciabilità clinica — ma la soluzione era parzialmente nota perché l’integrazione tra Jason e Python tramite bridge HTTP aveva incognite tecniche significative, tanto che l’abbiamo valutata con rischio PxI=9.”
“Abbiamo escluso Waterfall perché non avremmo potuto adattarci agli imprevisti della componente LLM. Abbiamo escluso Adaptive perché, pur avendo tratti agili, il core BDI era abbastanza noto da poter pianificare — quindi non c’era bisogno dell’estrema flessibilità dell’Adaptive secondo Highsmith.”
“Poi abbiamo aggiunto 5 adattamenti per R&D: management reserve al 10%, risk-based sprint planning, technical spike, MoSCoW rigido, e validazione incrementale su golden case. Questo perché Scrum puro non è progettato per R&D — mancano meccanismi per gestire l’incertezza tecnica. Gli adattamenti sono ispirati alla letteratura su Agile R&D e all’esperienza del corso.”
3. Scoping Process Group
Riferimenti Obsidian
- Panoramica scoping: Panoramica del Processo di Scoping
- Client wants vs needs: Client Wants vs Client Needs
- Conditions of Satisfaction: Conditions of Satisfaction
- RBS: Requirements Breakdown Structure
- POS, SMART, IRACIS: Project Overview Statement
Teoria
Scopo: definire il perimetro del progetto. Passi (Wysocki): (1) Conditions of Satisfaction → (2) Requisiti → (3) RBS → (4) Completezza → (5) PMLC model → (6) POS → (7) Approvazione.
Scoping
Lo Scoping Process Group chiarisce il problema, i bisogni del committente, le condizioni di soddisfazione, i requisiti principali e il modello PMLC più adatto. È la fase in cui si evita di partire a implementare una soluzione non allineata al vero bisogno.
CoS, RBS e POS
- Conditions of Satisfaction (CoS): condizioni che devono essere vere perché il committente consideri soddisfacente il risultato.
- Requirements Breakdown Structure (RBS): scomposizione gerarchica dei requisiti, dal bisogno generale ai requisiti più specifici.
- Project Overview Statement (POS): documento sintetico di approvazione con problema/opportunità, goal, obiettivi, criteri di successo, rischi e assunzioni.
Concetti chiave: CoS, RBS, Client Wants vs Needs, POS, Project Charter, SWOT, SMART, IRACIS, Definition of Done vs Acceptance Criteria.
Applicazione CTAF
| Step | Cosa abbiamo fatto |
|---|---|
| Project Scoping Meeting #1 (4/3) | Committente + PM + Team. Visione, CoS preliminari, selezione dominio cardiaco, human-in-the-loop obbligatorio |
| Project Scoping Meeting #2 (11/3) | Validazione CoS, presentazione RBS con 6 requisiti L0-L3, SWOT, PMLC model, POS bozza |
| CoS (C1-C6) | 6 condizioni: sistema BDI su gc04, pipeline LLM, web app, tracciabilità 100%, CLI, open-source |
| RBS | 4 rami L1: Runtime BDI, LLM Pipeline, Web App Review, Tracciabilità. 7 NFR |
| SWOT | S: architettura innovativa, tracciabilità by design; W: team studentesco, dipendenza API; O: pubblicazioni, AI Act; T: API changes, timeline |
| POS | Problema (LLM black-box), Goal, O1-O7, Criteri di Successo (IRACIS), Rischi preliminari |
Cosa dire all’esame
“Lo scoping è stato fatto in due Project Scoping Meeting. Nel primo abbiamo incontrato il committente — la Cardiologia di Forlì — per capire i bisogni reali. L’aspetto critico emerso subito è stato il requisito normativo: umano nel ciclo, perché in ambito clinico non puoi avere un LLM che decide. Questo ha portato alla CoS C4: tracciabilità 100% delle decisioni.”
“Abbiamo costruito la RBS con 4 rami principali — Runtime BDI, Pipeline LLM, Web App Review, Tracciabilità — coerente con l’architettura a 4 agenti del progetto. Per ogni ramo abbiamo specificato requisiti non funzionali, come human-in-the-loop obbligatorio e performance sotto i 30 secondi.”
“L’analisi SWOT ha evidenziato come punto di forza l’architettura innovativa BDI+LLM, e come debolezza principale la dipendenza da API LLM esterne. Questa debolezza l’abbiamo poi gestita in fase di risk management con un fallback locale.”
“Il POS è stato redatto con obiettivi SMART e criteri IRACIS. Per esempio, l’obiettivo di tracciabilità al 100% è misurabile tramite script di audit sulle tracce.”
4. Planning Process Group
Riferimenti Obsidian
- Panoramica planning: Importanza della Pianificazione
- JPPS e PDS: Joint Project Planning Session JPPS
- WBS: Work Breakdown Structure WBS
- Stime e PERT: Stima di Durata Effort e Risorse
- Network diagram e critical path: Project Network Diagram
Teoria
Scopo: identificare attività, stimare tempi/costi/risorse, approvare il piano.
Planning
Il Planning Process Group trasforma lo scope approvato in un piano operativo: attività, dipendenze, durata, effort, risorse, rischi, responsabilità e criteri di controllo. In un progetto iterativo non significa pianificare tutto rigidamente, ma definire una baseline e aggiornarla con consapevolezza.
JPPS, PDS, WBS, Critical Path
- JPPS: sessioni collaborative in cui PM, team e committente costruiscono il piano.
- PDS: versione estesa del POS, più utile al planning team.
- WBS: scomposizione del lavoro da svolgere, non dell’organigramma.
- Critical Path: sequenza di attività con slack nullo; un ritardo su questa catena ritarda il progetto.
Concetti chiave: JPPS, PDS, WBS, MoSCoW, Three-point (PERT), Network diagram, Critical Path, RACI, Management Reserve, Scope Bank, Risk register.
Applicazione CTAF
JPPS — Joint Project Planning Sessions
| Sessione | Data | Partecipanti | Cosa fatto |
|---|---|---|---|
| #1 | 18/3 | PM + 3 dev | Review POS, validazione PDS, RBS→WBS, stime tre punti, dipendenze |
| #2 | 19/3 | PM + 3 dev + Committente | Network diagram, critical path, rischi, budget, piano sprint |
Best practice
JPPS come “pianificazione partecipata” coinvolgendo tutto il team. Non è il PM che decide da solo.
PDS — Project Definition Statement
Versione estesa del POS. Include: contesto clinico, O1-O7 dettagliati, stakeholder (4 categorie), 6 criteri di successo, vincoli (budget zero, human-in-the-loop, semestre), matrice rischi R1-R6 con P/I/PxI/strategia, Risk Response Plan con trigger/owner/azione.
WBS — Work Breakdown Structure
| Ramo | Dettaglio |
|---|---|
| 1.1 Requisiti e Scoping | 4 attività |
| 1.2 Progettazione | Architettura, LLM pipeline, web app, tracciabilità |
| 1.3 Runtime BDI | 4 agenti, piani, comunicazione, test |
| 1.4 LLM Pipeline | Bridge, estrazione, valutazione, test |
| 1.5 Web App | Backend, frontend, integrazione |
| 1.6 Integrazione e Test | E2E, golden case, CLI |
| 1.7 Documentazione | 14 artefatti |
| 1.8 Gestione Progetto | Riunioni, risk, cambiamenti |
Metodo: Verb-type (design-build-test). Coerente con RBS e POS.
MoSCoW Prioritization
| Priorità | Cosa |
|---|---|
| Must | Agenti BDI (O1), pipeline LLM base (O2), console review (O3), golden case (O5), CLI (O6) |
| Should | Visualizzazione tracce, gestione ambiguità, test automatici |
| Could | Export report, dashboard metriche, dark mode |
| Won’t | Deployment production, autenticazione, multi-dominio clinico |
Punto critico
MoSCoW è il meccanismo che ha salvato la consegna. Gli 11 SP non completati erano tutti Should/Could.
Stime Three-Point (PERT)
| ID | Attività | O | M | P | PERT | σ |
|---|---|---|---|---|---|---|
| 1.1 | Setup Jason | 0.5 | 1 | 2 | 1.1 | 0.25 |
| 1.2 | 4 agenti BDI | 4 | 6 | 10 | 6.3 | 1.00 |
| 1.3 | Golden case gc04 | 1 | 2 | 4 | 2.2 | 0.50 |
| 1.4 | Setup DSPy | 1 | 2 | 3 | 2.0 | 0.33 |
| 1.5 | Claim extraction | 3 | 5 | 8 | 5.2 | 0.83 |
| 1.6 | Rule drafting | 3 | 5 | 8 | 5.2 | 0.83 |
| 1.7 | Setup React | 0.5 | 1 | 2 | 1.1 | 0.25 |
| 1.8 | Rule review componenti | 3 | 4 | 7 | 4.3 | 0.67 |
| 1.9 | Trace viewer | 2 | 3 | 5 | 3.2 | 0.50 |
| 1.10 | Flusso E2E | 2 | 3 | 6 | 3.3 | 0.67 |
| 1.11 | Validazione golden case | 2 | 3 | 5 | 3.2 | 0.50 |
| 1.12 | Documentazione finale | 1 | 2 | 4 | 2.2 | 0.50 |
Formula PERT: E = (O + 4M + P) / 6, σ = (P - O) / 6 Effort totale: 39.17 giorni-uomo, σ progetto ≈ 2.12
Network Diagram & Critical Path
Percorso critico: 1.1 Setup → 1.2 Agenti → 1.3/1.4 → 1.5 Claim → 1.6 Rule → 1.10 E2E → 1.11 Validazione → 1.12 Documentazione
Durata critical path: 29.4 giorni/uomo (~6 settimane a 0.5 FTE)
Attività in parallelo (non critiche): 1.7, 1.8, 1.9 (console web — può slittare senza impattare la data di fine)
RACI Matrix
| Attività | PM | Dev Jason | Dev Python | Dev Frontend | Committente |
|---|---|---|---|---|---|
| Requisiti e Scoping | A | C | C | C | C |
| Planning | A/R | C | C | C | I |
| Runtime BDI | A | R | C | I | I |
| LLM Pipeline | A | C | R | I | I |
| Web App | A | I | C | R | I |
| Tracciabilità | A | R | C | C | I |
| Integrazione e Test | A | R | R | R | I |
| Documentazione | A/R | C | C | C | I |
| Gestione Rischi | A/R | C | C | C | I |
| Sprint Review | R | C | C | C | A |
R = Responsible (esegue), A = Accountable (risponde del risultato), C = Consulted (dà input), I = Informed (informato).
Risk Register (R1-R6 + R7-R10 estesi)
| # | Rischio | Cat. | P | I | PxI | Strategia |
|---|---|---|---|---|---|---|
| R1 | Indisponibilità LLM | Tecnologico | M | A | 6 | Mitigazione: provider multiplo + fallback locale |
| R2 | Complessità integrazione Jason-Python | Tecnologico | A | A | 9 | Mitigazione: prototipo bridge HTTP, fallback file |
| R3 | Ritardi per impegni accademici | Risorse | M | M | 4 | Accettazione: buffer + scope bank |
| R4 | Ambiguità/inconsistenza claim LLM | Qualitativo | M | M | 4 | Mitigazione: validazione strutturale + post-processore |
| R5 | Incompatibilità librerie | Tecnologico | B | A | 3 | Contingenza: Docker versioni fissate |
| R6 | Timeline semestrale insufficiente | Pianificazione | M | A | 6 | Mitigazione: MoSCoW rigido, sprint riserva |
| R7 | Debugging ciclo BDI | Tecnologico | M | M | 4 | Accettazione: buffer sprint |
| R8 | Documentazione insufficiente | Qualitativo | M | B | 2 | Mitigazione: docs-as-code in tempo reale |
| R9 | Jason instabile/non mantenuto | Tecnologico | B | A | 3 | Contingenza: Docker, versione fissata |
| R10 | Scope creep | Gestionale | M | M | 4 | Prevenzione: MoSCoW + change control |
Strategie (5 tipi): Accept, Avoid, Contingency, Mitigate, Transfer.
Sprint Plan
| Sprint | Periodo | Goal | SP planned | SP done | % |
|---|---|---|---|---|---|
| Sprint 1 | 23/3 — 5/4 | Runtime BDI | 20 | 18 | 90% |
| Sprint 2 | 6/4 — 19/4 | Pipeline LLM | 22 | 18 | 82% |
| Sprint 3 | 20/4 — 3/5 | Web App Review | 18 | 16 | 89% |
| Sprint 4 | 4/5 — 17/5 | Integrazione & Validazione | 18 | 15 | 83% |
| Sprint 5 (Riserva) | 18/5 — 24/5 | Buffer imprevisti | — | — | — |
| Sprint 6 (Chiusura) | 25/5 — 31/5 | Collaudo e consegna | — | — | — |
| Totale | 78 | 67 | 86% |
Cosa dire all’esame
“La pianificazione è stata fatta in due JPPS — Joint Project Planning Sessions — seguendo Wysocki. Nella prima sessione, solo con il team tecnico, abbiamo fatto la scomposizione RBS→WBS e le stime tre punti. Nella seconda, con il committente, abbiamo validato il network diagram, il critical path, e il piano sprint.”
“Per stimare abbiamo usato la tecnica dei tre punti (PERT). Per esempio, l’integrazione Jason-Python l’abbiamo stimata con optimistico 4 giorni, più probabile 6, pessimistico 10 — la formula PERT dà 6.3 giorni con sigma di 1. Questa incertezza riflette il fatto che era la prima volta che integravamo Jason con Python.”
“Il critical path parte dal setup Jason, passa per i 4 agenti BDI, la pipeline LLM, e arriva all’integrazione E2E e validazione. La console web, invece, è fuori dal critical path perché può essere sviluppata in parallelo — questo è stato importante perché ci ha permesso di assorbire ritardi senza impattare la data di consegna.”
“Abbiamo usato MoSCoW per priorizzare: i Must erano agenti BDI, pipeline LLM base, console review e golden case. I Won’t includevano deployment production e autenticazione — cose che in un ambito clinico reale servono, ma nel prototipo accademico erano fuori scope.”
“Il risk register iniziale aveva 6 rischi, poi esteso a 10. Il rischio più alto era R2 (integrazione Jason-Python) con PxI=9. Per mitigarlo abbiamo fatto un technical spike nello Sprint 1 — un prototipo del bridge HTTP — prima di impegnare l’intera pipeline.”
“La matrice RACI è importante nel nostro caso perché il team è piccolo: PM accountabile per quasi tutto, ma ogni attività ha un solo Responsible. Il Committente è Accountable solo per la Sprint Review.”
5. Execution (Launching) Process Group
Riferimenti Obsidian
- Launching/Executing come process group: Executing Process Group
- Regole operative e team: Executing Process Group
- Collegamento con monitoring durante l’esecuzione: Process Groups e PMLC
Teoria
Scopo: selezionare personale, stabilire regole operative, aiutare il team a lavorare insieme.
Execution / Launching
Nel corso, il Launching/Executing non è solo “scrivere codice”. Include costruzione del team, regole operative, comunicazione, gestione del lavoro quotidiano e applicazione del piano. Nel progetto CTAF questa parte coincide con l’esecuzione degli sprint Scrum.
DoD e Acceptance Criteria
La Definition of Done vale per tutti gli item e dice quando un lavoro può essere considerato completato. Gli Acceptance Criteria sono specifici della singola user story e indicano quali condizioni deve soddisfare quella funzionalità.
Concetti chiave: Scrum Guide 2020, Sprint (2 settimane), Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective, Product Backlog, Sprint Backlog, Definition of Done, Acceptance Criteria.
L’Execution secondo Wysocki non coincide esattamente con l’omonimo Process Group PMBOK. Include: team building, regole operative, kick-off, e poi l’esecuzione vera e propria.
Applicazione CTAF
Framework Scrum
| Cerimonia | Quando | Durata | Come |
|---|---|---|---|
| Sprint Planning | Inizio sprint | 1h | Assegnazione story, stima planning poker |
| Daily Standup | Ogni giorno | 15min | Discord, 3 domande: ieri/oggi/blocchi |
| Sprint Review | Fine sprint (venerdì) | 1-2h | Demo al committente, validazione |
| Sprint Retrospective | Dopo Review | 30min | Cosa ha funzionato/migliorare |
Definition of Done (DoD)
- Codice soddisfa i criteri di accettazione della user story
- Pull review approvata da almeno un reviewer
- Test unitari e di integrazione superati
- Documentazione minima aggiornata
- Funzionalità dimostrabile in Sprint Review
- Nessun errore runtime o warning bloccante
Distinzione teoria: DoD ≠ Acceptance Criteria. DoD = condizioni generali per considerare “fatto” qualsiasi item. Acceptance Criteria = specifici per ogni user story.
Execution per Sprint
Sprint 1 — Runtime BDI (Goal: 4 agenti su gc04)
| Cosa | Dettaglio |
|---|---|
| Storie | Setup Jason, 4 agenti, gc04, test unitari |
| Blocchi | Giorno 3: Jason su Windows → Docker. Giorno 7: dipendenza ciclica → redesign |
| Risultati | 4 agenti funzionanti, gc04 ok, 12/12 test |
| Feedback committente | ”Positivo, procedere con pipeline LLM” |
| Retrospettiva | Docker utile; stima setup ottimistica (1 → 2.5 gg) |
Sprint 2 — Pipeline LLM (Goal: DSPy per claim/regole)
| Cosa | Dettaglio |
|---|---|
| Blocchi | Giorno 4: DSPy richiede Python 3.11+. Giorno 6: formato output inconsistente. Giorno 9: rate limit Groq |
| Risultati | Pipeline Groq/OpenRouter, 8/10 claim corretti |
| Feedback | Migliorare gestione ambiguità |
| Gestione R1 | Attivato (rate limit Groq) → fallback OpenRouter funzionante |
Sprint 3 — Web App Review (Goal: console web)
| Cosa | Dettaglio |
|---|---|
| Blocchi | Giorno 2: scelta libreria mermaid. Giorno 8: parsing JSON tracce |
| Risultati | Console completa, Rule Review, Trace Viewer, 5 scenari |
| Feedback | Visualizzazione tracce molto utile |
Sprint 4 — Integrazione e Test (Goal: E2E, golden case)
| Cosa | Dettaglio |
|---|---|
| Blocchi | Giorno 2: discrepanza formato dati. Giorno 5: R4 attivato (ambiguità). Giorno 8: esami |
| Risultati | E2E funzionante, gc04 validato, 9/10 test, doc completata |
| Gestione R4 | Management reserve attivata: post-processore disambiguazione |
| Feedback committente | ”Il progetto raggiunge tutti gli obiettivi. Consegna accettata.” |
Cosa dire all’esame
“L’esecuzione è stata organizzata in 4 sprint di 2 settimane ciascuno, più uno sprint di riserva. Ogni sprint cominciava con lo Sprint Planning, dove il Product Backlog veniva priorizzato col MoSCoW e stimato con planning poker.”
“Il Daily Standup era su Discord alle 9:30 — 15 minuti, tre domande: cosa ho fatto ieri, cosa faccio oggi, quali blocchi. Questo ci ha permesso di intercettare subito i problemi, come quando Jason non funzionava su Windows e abbiamo dovuto Dockerizzare tutto.”
“La Definition of Done è stata formalizzata con 6 criteri, dal codice funzionante alla demo in Sprint Review. Per ogni user story avevamo anche Acceptance Criteria specifici. Per esempio, per la user story ‘Esecuzione gc04’, il criterio era che il test di accettazione passasse senza errori.”
“La Sprint Review era il momento più importante: il committente vedeva la demo e dava feedback. Nella Review #1, per esempio, il trace_guardian è crashato alla prima chiamata bridge Python — lo abbiamo preso come segnale per rafforzare i test automatici del bridge.”
“Durante l’esecuzione si sono attivati due rischi: R1 (rate limit Groq) mitigato con fallback OpenRouter, e R4 (ambiguità claim) mitigato attingendo alla management reserve per sviluppare un post-processore di disambiguazione.”
“La velocità complessiva è stata 67 SP su 78 pianificati (86%). Gli 11 SP non completati erano tutti Should o Could — mai Must. Questo dimostra l’efficacia del MoSCoW come protezione.”
6. Monitoring & Controlling Process Group
Riferimenti Obsidian
- Obiettivo monitoring & controlling: Obiettivo del Monitoring and Controlling
- Reporting system: Sistema di Reporting
- Stoplight report ed EVM: Strumenti di Reporting Visuale
- Scope Bank: Scope Bank
- Issues Log e problem escalation: Issues Log, Problem Escalation Strategy
Teoria
Scopo: monitorare avanzamento, controllare scostamenti, intervenire.
Monitoring & Controlling
Questo process group confronta l’avanzamento reale con il piano, rende visibili scostamenti e rischi, e attiva azioni correttive. Non è solo reportistica: serve a evitare che piccoli problemi diventino fallimenti di progetto.
EVM, SPI, CPI
- PV: Planned Value, valore pianificato.
- EV: Earned Value, valore effettivamente realizzato.
- AC: Actual Cost, costo effettivo.
- SPI = EV/PV: misura il rispetto della schedula.
- CPI = EV/AC: misura l’efficienza rispetto ai costi.
Concetti chiave: EVA (PV/EV/AC/SPI/CPI), Burndown chart, Stoplight report, Scope Bank, Issues Log, Problem Escalation Strategy (3 livelli), Status reports (current/cumulative/exception/stoplight/variance).
Applicazione CTAF
EVM — Earned Value Management
| Sprint | PV | EV | AC | SPI | CPI | Stato |
|---|---|---|---|---|---|---|
| Sprint 1 | 20 | 18 | 18 | 0.90 | 1.00 | Verde |
| Sprint 2 | 22 | 18 | 18 | 0.82 | 1.00 | Verde (leggero ritardo assorbibile) |
| Sprint 3 | 18 | 16 | 16 | 0.89 | 1.00 | Verde |
| Sprint 4 | 18 | 15 | 15 | 0.83 | 1.00 | Giallo (R4 attivato) |
| Cumulativo | 78 | 67 | 67 | 0.86 | 1.00 |
- SPI < 1 = in ritardo sul piano. SPI = 0.86 significa 86% del lavoro pianificato completato.
- CPI = 1.00 = a budget (perché budget = 0, nessun costo diretto).
- Interpretazione: CPI = 1 non significa “bravi” ma “assenza di costi”. Il vero indicatore è SPI.
Burndown Chart
| Sprint | SP iniziali | SP rimasti | Trend |
|---|---|---|---|
| Sprint 1 | 20 | 2 | Allineato |
| Sprint 2 | 22 | 4 | Ritardo prima settimana (configurazione DSPy) |
| Sprint 3 | 18 | 2 | Buono, TraceViewer +1g |
| Sprint 4 | 18 | 3 | Giorno 5: R4 attivato, management reserve |
Scope Bank
- Dimensione: 10% (8 SP su 78)
- Utilizzo: 2 SP in Sprint 4 per post-processore disambiguazione (rischio R4)
- Regole: Prelievo solo per modifiche necessarie; Committente ridefinisce priorità
Issues Log (9 issues)
| ID | Data | Descrizione | Priorità | Stato |
|---|---|---|---|---|
| ISS-001 | 25/3 | Jason su Windows | Media | Docker |
| ISS-002 | 27/3 | Dipendenza ciclica BDI | Alta | Redesign |
| ISS-003 | 9/4 | Python 3.11+ | Media | Aggiornamento |
| ISS-004 | 11/4 | Formato LLM inconsistente | Alta | Post-processore |
| ISS-005 | 13/4 | Rate limit Groq | Alta | Fallback OpenRouter |
| ISS-006 | 21/4 | Scelta libreria grafica | Bassa | react-mermaid |
| ISS-007 | 28/4 | Parsing JSON tracce | Media | Fix |
| ISS-008 | 6/5 | Discrepanza formato dati | Alta | Interfaccia comune |
| ISS-009 | 10/5 | Ambiguità claim (R4) | Alta | Management reserve |
Problem Escalation Strategy — Esempio pratico
R4 attivato (10 maggio): claim ambigui su gc_gray_zone
- PM-Based (livello 1): Analisi impatto — 2 giorni ritardo, entro slack?
- Resource Manager-Based (livello 2): Non applicabile (team piccolo)
- Client-Based (livello 3): Informato committente, spiegato impatto, proposto post-processore → approvato
Gestione Ritardo Sprint 4
Rischio R4 materializzato (claim ambigui su gc_gray_zone)
- Impatto: 2 giorni ritardo
- Azione: Management reserve attivata, post-processore implementato
- Esito: Ritardo assorbito, consegna 17 maggio rispettata
Cosa dire all’esame
“Il monitoraggio è stato fatto su più livelli. Il principale era il burndown chart giornaliero, che ci dava la visibilità sull’avanzamento degli sprint. Poi c’erano gli status report a stoplight: verde se tutto ok, giallo se c’erano problemi con un Get Well plan.”
“I dati EVM sono stati calcolati per ogni sprint. SPI è sceso da 0.90 a 0.83 nell’ultimo sprint, quando si è attivato il rischio R4. CPI è rimasto 1.00 perché non abbiamo mai speso denaro — tutto open-source, budget zero.”
“La Scope Bank era di 8 SP (10%) e l’abbiamo usata per 2 SP in Sprint 4 per il post-processore di disambiguazione. È un esempio di come funziona la gestione delle riserve: non è un bonus, è un meccanismo formale con regole precise.”
“Abbiamo tenuto un Issues Log con 9 issue tracciate. Ogni issue aveva priorità, owner, azione, stato. Questo è importante perché la traccia storica permette di fare analisi a posteriori — per esempio, la maggior parte degli issue erano di integrazione (Jason-Python, formato dati).”
“La Problem Escalation Strategy a 3 livelli non è servita al massimo perché il team era piccolo: il PM ha risolto quasi tutto al primo livello. Però è un framework concettuale utile per sapere quando coinvolgere il committente.”
“Alla fine, il progetto ha rispettato la data di consegna nonostante 3 rischi attivati e un ritardo di 2 giorni, perché avevamo buffer e riserve — esattamente come previsto in fase di planning.”
7. Closing Process Group
Riferimenti Obsidian
- Obiettivo closing: Obiettivo del Closing Process Group
- Procedure di accettazione: Procedure di Accettazione
- Installazione della soluzione: Installare la Soluzione
- Project Notebook: Documentare il Progetto
- Post-Implementation Audit e Final Report: Post-Implementation Audit, Final Project Report
Teoria
Scopo: chiudere il progetto formalmente. Fasi: accettazione formale, installazione soluzione, documentazione, audit, celebrazione.
Closing
Il Closing Process Group formalizza la fine del progetto: verifica deliverable, accettazione del committente, documentazione finale, audit post-implementazione e lessons learned. Serve a trasformare la conclusione tecnica in chiusura gestionale documentata.
Concetti chiave: Acceptance Procedure, Phased/BU/Cut-Over/Parallel approach, Post-Implementation Audit, Final Report, Project Notebook, Lessons Learned.
Applicazione CTAF
Verifica Obiettivi (O1-O7)
| Obiettivo | Criterio | Risultato | Stato |
|---|---|---|---|
| O1 — Runtime BDI | 4 agenti su gc04 | 4 agenti implementati | Raggiunto |
| O2 — Pipeline LLM | DSPy con Groq/OpenRouter | Pipeline operativa | Raggiunto |
| O3 — Console Web | React/Vite + FastAPI | Console completa | Raggiunto |
| O4 — Tracciabilità | Structured trace per ogni decisione | Justification Tree, export MD/HTML | Raggiunto |
| O5 — Golden case | gc00, gc04, gc_gray_zone | 3/3 validati (9/10 test) | Raggiunto |
| O6 — CLI | Singolo comando | ctaf run scenario.json | Raggiunto |
| O7 — Open source | GitHub + MIT | Pubblicato | Raggiunto |
Accettazione Formale
Data: 17 maggio 2026, Sprint Review #4 Committente: Cardiologia di Forlì Verbo: “Il progetto raggiunge tutti gli obiettivi. Consegna accettata.”
Post-Implementation Audit (20/5/2026)
| Dimensione | Valutazione | Note |
|---|---|---|
| Soddisfazione committente | 5/5 | Obiettivi raggiunti |
| Qualità prodotto | 4/5 | Prototipo, room for improvement |
| Rispetto tempistiche | 4/5 | Leggero ritardo assorbito |
| Gestione budget | 5/5 | Budget zero |
| Copertura test | 4/5 | 9/10 test passati |
| Documentazione | 5/5 | Completa |
| Gestione rischi | 4/5 | R4 attivato ma gestito |
Lessons Learned
- Scrum adatto a R&D con incognite tecniche: sprint brevi, ispezione e adattamento
- Separazione componenti (BDI, LLM, Web) ha ridotto dipendenze critiche
- MoSCoW ha prevenuto scope creep: 11 SP non completati erano Should/Could
- Stima LLM più difficile del previsto: fattore correttivo 25-30% per componenti AI
- Management reserve al 10% al limite: 15-20% consigliato per progetti AI
- Documentare in tempo reale riduce carico finale: docs-as-code funziona
Cosa dire all’esame
“La chiusura è stata formale e documentata. Il 17 maggio, durante la Sprint Review #4, il committente ha verbalmente accettato il deliverable: ‘Il progetto raggiunge tutti gli obiettivi. Consegna accettata’. Questo è importante come evidenza.”
“Tutti e 7 gli obiettivi sono stati raggiunti. L’unico Could (O7, open-source) è stato comunque soddisfatto, arricchendo il risultato.”
“Il Post-Implementation Audit è stato fatto il 20 maggio. Le valutazioni vanno da 4/5 a 5/5. Le aree da migliorare sono la copertura test (9/10) e la gestione rischi (R4 si è attivato, ma è stato gestito).”
“Le Lessons Learned più importanti riguardano la stima: per componenti AI la tecnica tre punti funziona ma l’incertezza è maggiore del previsto — consigliamo un fattore correttivo del 25-30% sulle stime. La management reserve al 10% era al limite: per progetti AI, 15-20% sarebbe più prudente.”
“Il Project Notebook è stato organizzato come repository Git con cartelle
docs/verbali/,docs/decisioni/(change-log, issue-log, risk-log),docs/deliverable/. Questo è coerente con la filosofia docs-as-code: tutto nel repository, versionato, tracciabile.”“Abbiamo usato l’approccio Cut-Over per ‘installare’ la soluzione: il repository congelato con tag v1.0.0-final. Non c’erano ambienti di produzione, quindi la consegna coincide con il completamento del codice.”
8. Tecniche Trasversali
Ogni tecnica è legata alla teoria e alla sua applicazione nel progetto.
Riferimenti Obsidian
- Requisiti e valore: Requisiti e Business Value
- RBS, SMART, IRACIS, INVEST: 06. Scoping Process Group
- WBS, stime, network, reserve: 07. Planning Process Group
- EVM, scope bank, issues, reporting: 09. Monitoring and Controlling Process Group
- Audit e lessons learned: 10. Closing Process Group
Glossario teorico rapido
| Concetto | Definizione breve | Rimando completo |
|---|---|---|
| Business Value | Valore prodotto dal progetto per il committente: aumento ricavi, riduzione costi o miglioramento servizio | Requisiti e Business Value |
| Requirement | Stato finale desiderato che, se integrato nella soluzione, produce valore misurabile | Requisiti e Business Value |
| RBS | Struttura gerarchica dei requisiti, utile nello scoping per chiarire cosa deve soddisfare il progetto | Requirements Breakdown Structure |
| WBS | Struttura gerarchica del lavoro necessario per produrre i deliverable | Work Breakdown Structure WBS |
| JPPS | Sessione collaborativa di pianificazione con PM, team e stakeholder | Joint Project Planning Session JPPS |
| PERT / Three-point estimate | Tecnica di stima con scenario ottimistico, più probabile e pessimistico: E = (O + 4M + P) / 6 | Stima di Durata Effort e Risorse |
| Critical Path | Sequenza di attività senza slack: se ritarda, ritarda tutto il progetto | Project Network Diagram |
| Scope Bank | Riserva controllata di scope/tempo usata per modifiche approvate e imprevisti necessari | Scope Bank |
| EVM | Metodo di controllo basato su PV, EV, AC, SPI e CPI per misurare avanzamento e costi | Earned Value Analysis |
| Issues Log | Registro delle issue con descrizione, priorità, stato e azione correttiva | Issues Log |
| Acceptance Procedure | Processo con cui il committente verifica e approva formalmente il deliverable | Procedure di Accettazione |
| Post-Implementation Audit | Revisione finale per valutare risultato, metodo, performance e lezioni apprese | Post-Implementation Audit |
8.1 WBS — Work Breakdown Structure
Teoria: Descrizione gerarchica di tutto il lavoro. 4 impieghi: thought process tool, architectural design tool, planning tool, status reporting tool. Approcci: noun-type (componenti), verb-type (design-build-test), organizational. Criteri completezza (7 punti): stato misurabile, inizio/fine chiari, deliverable associato, stimabile, durata accettabile, indipendente, giudizio del PM.
CTAF: WBS verb-type in 8 rami (Requisiti → Progettazione → 4 sprint → Documentazione → Gestione). Coerente con RBS e POS.
8.2 RBS — Requirements Breakdown Structure
Teoria: Organizza requisiti gerarchicamente: goal → soluzione → requisiti → funzioni → feature. Elemento chiave dello Scoping.
CTAF: 4 rami L1 (Runtime BDI, LLM Pipeline, Web App, Tracciabilità) → L2 funzioni → feature. 7 NFR.
8.3 MoSCoW
Teoria: Must = obbligatorio per consegna; Should = importante ma non critico; Could = desiderabile; Won’t = esplicitamente escluso.
CTAF: Must: agenti, pipeline, web app, golden case, CLI. Should: trace viewer, gestione ambiguità. Could/Molto: export, dashboard, dark mode. Won’t: deploy cloud, autenticazione.
Da sottolineare
MoSCoW è stato il meccanismo di difesa. 11 SP non completati = 0 Must. Se avessimo usato solo priorità “alta/media/bassa”, sarebbe stato più difficile tagliare consapevolmente.
8.4 Three-Point (PERT)
Teoria: E = (O + 4M + P) / 6. σ = (P - O) / 6. Tecnica di stima che pesa il caso più probabile 4 volte.
CTAF: 12 attività stimate con tecnica dei tre punti. Esempio: integrazione Jason-Python O=4, M=6, P=10 → PERT=6.3, σ=1.0.
8.5 Network Diagram & Critical Path
Teoria: FS/FF/SS/SF dipendenze, forward pass (ES+Durata-1=EF), backward pass (LF-Durata+1=LS), Slack = LS-ES. Critical path = percorso con slack=0.
CTAF: Critical path = Setup → Agenti → LLM → E2E → Validazione → Doc (29.4 gg/uomo). Web App fuori dal critical path (parallelo).
8.6 EVM — Earned Value Management
Teoria: PV = valore pianificato, EV = valore realizzato, AC = costo effettivo. SPI = EV/PV, CPI = EV/AC.
- SPI < 1 = in ritardo, CPI < 1 = sopra budget
- Metodi misura EV%: 100-0, 0-100, 50-50, proporzione
CTAF: SPI cumulativo 0.86, CPI 1.00. Metodo proporzione per misura EV.
8.7 Risk Management
Teoria: Identificazione → Valutazione (P x I) → Mitigazione (Accept/Avoid/Contingency/Mitigate/Transfer) → Monitoraggio. Risk Log: ID, descrizione, categoria, P, I, PxI, strategia, owner, trigger, azione.
CTAF: 10 rischi, R2 (PxI=9) il più alto. 3 attivati (R1, R3, R4) e gestiti. Risk Response Plan con trigger, owner, azione preventiva/correttiva.
8.8 RACI
Teoria: Responsible (fa), Accountable (risponde), Consulted (consulta), Informed (informato). Mai più di 1 Accountable per attività.
CTAF: Matrice 10 attività × 5 ruoli. PM Accountable per quasi tutto, ogni attività ha 1 Responsible.
8.9 Scope Bank / Management Reserve
Teoria: 5-10% del tempo totale, visibile e gestita. Prelievo per modifiche approvate, non per cattiva pianificazione.
CTAF: 8 SP (10%), usati in Sprint 4 per post-processore (R4).
8.10 Definition of Done vs Acceptance Criteria
Teoria: DoD = condizioni generali per considerare “fatto” (vale per tutti gli item). Acceptance Criteria = specifici per user story (test di accettazione).
CTAF: 6 criteri DoD generali. Per ogni sprint, Acceptance Criteria specifici per ogni user story (es. Sprint 1: 3 criteri, Sprint 4: 7 criteri).
8.11 POS (Project Overview Statement) vs PDS (Project Definition Statement)
Teoria: POS = sintetico (5 sezioni), per approvazione senior management. PDS = versione estesa dal punto di vista del planning team, validato dal committente. Stesse 5 sezioni ma più dettaglio.
CTAF: POS (1 pagina) vs PDS (3 pagine con contesto clinico, stakeholder, budget, risk response plan).
9. Strumenti
Filosofia
Toolchain leggera, integrata col codice, versionata e riproducibile (“docs-as-code”). Open-source/free-tier per vincolo budget zero.
Mappa strumenti
| Strumento | Perché usato | Alternativa scartata |
|---|---|---|
| GitHub Projects | Board kanban integrata con issue, codice, PR — single source of truth | Jira (ridondante), Trello (non integrato col codice) |
| Mermaid | Diagrammi versionabili e diff-abili (Gantt, Network, WBS, RBS) | MS Project (plan-driven, a pagamento), GanttProject (non versionabile) |
| Markdown + Git | Docs-as-code, portabile, versionato | — |
| Obsidian | Knowledge management, Project Notebook a grafo | — |
| Fogli di calcolo | PERT, EVM, Budget con formule live | MS Project (troppo pesante) |
| Discord | Comunicazione asincrona, daily standup | — |
Cosa dire all’esame
“La scelta degli strumenti è una conseguenza diretta della natura del progetto: Agile, code-centric, budget zero. Non abbiamo scelto MS Project o Jira perché non avrebbero aggiunto valore rispetto a GitHub Projects, che è integrato con codice, issue e PR. Tutta la documentazione è in Markdown nel repository — docs-as-code — quindi versionata, diff-abile, esportabile.”
“Per i diagrammi (Gantt, Network, WBS, RBS) abbiamo usato Mermaid, che genera diagrammi da testo. Questo significa che i diagrammi sono versionati esattamente come il codice: se vedo un diff in un file
.mmd, so esattamente cosa è cambiato.”“I fogli di calcolo PERT, EVM e Budget sono file
.xlsxcon formule live — non numeri fissi, ma calcolati. Per esempio, il PERT calcola E = (O+4M+P)/6 automaticamente. Questi file sono nel repository come evidenza documentale.”
10. Domande-tipo per l’orale
Domanda 1: “Perché hai scelto Iterative e non Adaptive?”
“Perché secondo Wysocki l’Iterative si applica quando il goal è chiaro e la soluzione è parzialmente nota — il nostro caso. L’Adaptive, invece, si usa quando ne goal né solution sono noti. Noi sapevamo cosa volevamo fare (framework BDI+LLM) e avevamo esperienza con Jason; l’incognita era solo l’integrazione LLM. Quindi Iterativo, non adattivo. Per gestire l’incertezza R&D abbiamo aggiunto 5 adattamenti: management reserve, risk-based planning, technical spike, MoSCoW rigido, validazione incrementale.”
Domanda 2: “Perché Scrum e non un altro metodo iterativo?”
“Perché Scrum fornisce una struttura già pronta con cerimonie ruoli e artefatti. Alternative come l’Iterative puro di Wysocki sono più generiche e richiedono di definire tutto da zero. Scrum ci dava sprint planning, daily standup, review, retrospective — allineati con le nostre esigenze di ispezione e adattamento frequenti.”
Domanda 3: “Quali rischi si sono attualizzati e come li hai gestiti?”
“Tre rischi. R1 (rate limit Groq) in Sprint 2 → fallback su OpenRouter. R3 (ritardi accademici) parzialmente in Sprint 4 → assorbito dal buffer. R4 (ambiguità claim) in Sprint 4 → management reserve di 2 SP per sviluppare un post-processore. Nessuno ha impattato la data di consegna.”
Domanda 4: “SPI 0.86 è un buon risultato?”
“Dipende dal contesto. In un progetto plan-driven, 0.86 sarebbe un problema. Ma in un progetto Iterative Scrum con componente R&D, 0.86 significa che abbiamo completato l’86% del lavoro pianificato, con l’11% non completato che era tutto Should/Could — non Must. Considerando che si sono attivati 3 rischi su 10 e che la data è stata rispettata, è un risultato molto buono. Il CPI 1.00 è fisiologico: budget zero.”
Domanda 5: “Cosa avresti fatto diversamente?”
“Due cose. Primo: la management reserve al 10% era al limite — per progetti con componente AI, la letteratura suggerisce 15-20%. Secondo: la stima della componente LLM era troppo ottimistica: un fattore correttivo del 25-30% sulle stime tre punti sarebbe stato più realistico.”
Domanda 6: “Qual è la differenza tra DoD e Acceptance Criteria?”
“La Definition of Done è trasversale: definisce le condizioni che ogni item del backlog deve soddisfare per essere considerato completato (codice funzionante, test passati, code review, documentato). Gli Acceptance Criteria sono specifici per ogni user story e definiscono i test di accettazione che quella singola funzionalità deve superare. Per esempio: la DoD richiedeva test passati per tutte le storie; per la user story ‘Esecuzione gc04’, l’Acceptance Criterion era che lo scenario girasse end-to-end senza errori.”
Domanda 7: “Qual è il ruolo della Scope Bank?”
“La Scope Bank è una riserva di tempo (5-10%) gestita dal PM per assorbire modifiche necessarie non pianificate. Non è un bonus: si attiva solo quando un imprevisto richiede lavoro aggiuntivo. Nel nostro caso, l’abbiamo usata per 2 SP in Sprint 4 quando R4 (ambiguità claim) ha richiesto un post-processore. Il committente è stato informato e ha approvato.”
Domanda 8: “Giustifica la scelta di GitHub Projects rispetto a Jira o Trello.”
“GitHub Projects è integrato nativamente con issue, codice e PR. In un progetto che adotta docs-as-code e Git come strumento centrale, avere board, issue e codice nello stesso sistema è la scelta più coerente. Jira è più potente per grandi organizzazioni, ma introdurrebbe un ambiente separato, con costi di setup e manutenzione che in un team piccolo e a budget zero non sono giustificati. Trello è più semplice ma non ha integrazione col codice.”
Domanda 9: “Quale tecnica di stima hai usato e perché?”
“La tecnica dei tre punti (PERT). Perché è adatta a contesti con incertezza: lo stimatore fornisce optimistico, più probabile e pessimistico, e la formula PERT pesa il caso più probabile 4 volte. In un progetto R&D dove alcune attività (integrazione Jason-Python) avevano incertezza alta, questo dà una stima più robusta di una singola cifra. Abbiamo anche calcolato la deviazione standard per attività per capire quali avevano più incertezza.”
Domanda 10: “Parlami del Post-Implementation Audit.”
“L’audit è stato fatto il 20 maggio, dopo la consegna. Ha valutato 7 dimensioni su scala 1-5. I risultati migliori: soddisfazione committente e documentazione (5/5). Quelli con margine di miglioramento: copertura test (4/5) e gestione rischi (4/5). Le raccomandazioni sono confluite nelle Lessons Learned: fattore correttivo 25-30% per stime AI, management reserve 15-20%, documentazione in tempo reale.”
11. Fonti e collegamenti diretti
Appunti teorici
I link seguenti puntano agli appunti del corso pubblicati nello stesso sito Quartz e restano navigabili anche da Obsidian.
| Tema | Appunto |
|---|---|
| Linee guida elaborato | Progetto - Linee Guida |
| Introduzione al corso | 01. Introduzione al Corso |
| Brooks, Agile, Scrum | 02. Introduzione al PM |
| Progetto, scope, business value | 03. Definizione di Progetto |
| PMLC e modelli Wysocki | 04. Definizione di Project Management |
| Process group e knowledge areas | 05. Definizione dei Processi |
| CoS, RBS, POS, SMART, IRACIS | 06. Scoping Process Group |
| JPPS, PDS, WBS, PERT, Critical Path | 07. Planning Process Group |
| EVM, Scope Bank, status report | 09. Monitoring and Controlling Process Group |
| Chiusura, audit, final report | 10. Closing Process Group |
Artefatti dell’elaborato CTAF
Gli artefatti del progetto sono nel repository separato dell’elaborato. Questi link servono come riferimento pubblico, ma il materiale di studio resta nel repository obsidian_notes.
| Fase | Link diretto |
|---|---|
| Contesto e scelta PMLC | Parte 1.1 — Contesto |
| Scoping | Parte 1.2 — Scoping & Initiating, POS, CoS, RBS, SWOT |
| Planning | Parte 1.3 — Planning, PDS, WBS, Network Diagram, Gantt, Risk Analysis, Cost Estimate |
| Execution | Parte 1.4 — Execution, Sprint Plan, Meeting Minutes |
| Monitoring | Parte 1.5 — Monitoring & Controlling, Status Reports |
| Closing | Parte 1.6 — Closing, Final Report |
| Strumenti | Parte 1.7 — Strumenti di Supporto |
12. Quick Reference - Tabella riassuntiva
| Process Group | Teoria chiave | Cosa abbiamo fatto | Artefatto principale |
|---|---|---|---|
| Scoping | CoS, RBS, SWOT, POS, PMLC | 2 meeting scoping, CoS, RBS 4 rami, SWOT | POS, CoS, RBS, SWOT |
| Planning | JPPS, PDS, WBS, MoSCoW, PERT, Network, RACI, Risk | 2 JPPS, WBS verb-type, stime PERT, critical path, RACI | PDS, WBS, Network, Gantt, Risk, Cost, Sprint Plan |
| Execution | Scrum (Sprint Planning, Daily, Review, Retro), DoD | 4 sprint, cerimonie, MoSCoW backlog, DoD 6 criteri | Meeting Minutes, Status Reports |
| Monitoring | EVM (SPI/CPI), Burndown, Stoplight, Scope Bank, Issues Log | Burndown giornaliero, EVM per sprint, Scope Bank 8 SP | EVM data, Status Reports, Issues Log |
| Closing | Final Report, Post-Implementation Audit, Lessons Learned, Project Notebook | Review #4 accettazione, audit 7 dimensioni, lessons learned | Final Report, Meeting Minutes #8 |
Struttura per rispondere a qualsiasi domanda
Schema universale per l'orale
- Teoria: “Secondo Wysocki/PMBOK/Schwaber, il concetto di X…”
- Applicazione: “Nel nostro progetto CTAF, abbiamo applicato X facendo Y…”
- Motivazione: “Abbiamo scelto Y invece di Z perché…”
- Risultato: “Il risultato è stato W, che conferma/contraddice la teoria perché…”
Argomenti che il professore potrebbe approfondire
- PMLC classification (Iterative vs Adaptive) — PUNTO CRUCIALE
- Adattamenti Scrum per R&D — motivazione di ognuno
- Gestione rischi (R2 PxI=9, R1+R4 attivati)
- EVM interpretazione (SPI 0.86, CPI 1.00)
- MoSCoW come protezione (0 Must persi)
- Scope Bank (8 SP, 2 usati)
- WBS approccio (verb-type, coerenza RBS)
- PERT (perché usato, limite incertezza AI)
- Network diagram + critical path (cosa era critico e cosa no)
- RACI (struttura, perché PM Accountable)
- Project Charter vs POS (differenza - approfondire da appunti)
- SMART (verificare obiettivi O1-O7)
- INVEST (user stories)
- Metodi di misura EV% (noi: proporzione)
Nota
Gli ultimi 4 punti hanno meno materiale nel progetto ma potrebbero essere chiesti come teoria generale. Studiali dagli appunti 06. Scoping Process Group e 09. Monitoring and Controlling Process Group.
Documento creato il 22/06/2026 — Studio Orale PM + CTAF. Fonti: appunti Obsidian Project Management e artefatti versionati dell’elaborato CTAF.