13. Schema Progetto-Teoria

Schema Progetto ↔ Teoria

Scopo

Per ogni fase del progetto CTAF, questo schema mostra: (1) la teoria collegata, (2) la documentazione prodotta, (3) il perché della scelta, (4) le alternative possibili. Usalo per ripasso rapido prima dell’orale.

Come leggere

Ogni sezione ha una tabella principale + note critiche. La colonna “Perché” è la risposta alla domanda d’esame “perché avete fatto così?” — la colonna “Alternative” risponde a “perché non avete fatto diversamente?“

---

0. Contesto del Progetto

Teoria

• Definizione di PM
• PMLC Models
• Business Value
• Obiettivo dell’elaborato

Dimensione	Descrizione
Progetto	CTAF — Cardiac Traceability Agent Framework
Problema	LLM black-box in ambito clinico: assenza di tracciabilità, spiegabilità, auditabilità
Soluzione	Framework multi-agente BDI (Jason) + LLM assistito (bozze revisionate da umano)
Dominio	Masse cardiache, basato su ESC Guidelines, golden case dimostrativi
Vincoli	Budget zero, free-tier, semestre accademico, human-in-the-loop obbligatorio

Documentazione

Artefatto	Link	Contenuto
1-contesto.md	Contesto	Problema, stakeholder, architettura, scelta PMLC, vincoli
Architettura	img/architecture.mmd	Diagramma a 4 agenti + pipeline LLM + web console

Perché della scelta

Scelta	Motivazione
BDI + LLM ibrido	BDI dà tracciabilità per progettazione (justification tree); LLM dà flessibilità in authoring. Nessuno dei due da solo basta
Dominio cardiaco	Scelto dal committente (Cardiologia Forlì); abbastanza complesso per dimostrare il framework
Human-in-the-loop	Vincolo normativo (AI Act, MDR) e clinico: nessuna decisione automatica senza revisione umana

Alternative possibili

Alternativa	Perché scartata
LLM puro (zero-shot)	Black-box, non riproducibile, non auditabile — inaccettabile in clinica
Solo BDI simbolico	Regole scritte a mano: manutenzione costosa, non scalabile
Altro dominio	Avrebbe richiesto altro committente e knowledge del dominio

---

1. Scoping Process Group

Teoria

• Panoramica Scoping
• Client Wants vs Needs
• Conditions of Satisfaction
• RBS
• POS, SMART, IRACIS

Documentazione

Artefatto	Link	Contenuto
CoS	CoS	6 Conditions of Satisfaction (C1-C6)
RBS	RBS	4 rami L1: Runtime BDI, LLM Pipeline, Web App, Tracciabilità + 7 NFR
SWOT	SWOT	Strengths, Weaknesses, Opportunities, Threats
POS	POS	Problema, Goal, O1-O7, criteri IRACIS, rischi preliminari
2-scoping-initiating.md	Scoping	Verbali PSM #1 e #2, decisioni, azioni
Registro Rischi preliminare	in 2-scoping-initiating.md	R1-R6 con P/I/PxI

Perché della scelta

Scelta	Motivazione
CoS prima dei requisiti	Per allineare committente e team su “cosa significa successo” prima di dettagliare. La tracciabilità 100% è emersa come CoS, non come requisito tecnico
RBS anziché semplice lista requisiti	Gerarchia L0→L3 mostra legame tra goal, funzioni e feature. Collega visione (L0) a implementazione (L3)
SWOT in fase di scoping	Per far emergere rischi prima del planning: dipendenza API LLM, budget zero, competenze team
POS approvato in PSM #2	Formalizza l’accordo prima di passare a pianificare
Project Scoping Meeting strutturati	Due incontri separati (visione → validazione) evitano di mescolare esplorazione e decisione

Alternative possibili

Alternativa	Perché scartata
Raccolta requisiti informale (solo email/discord)	Nessuna tracciabilità delle decisioni; rischio di ambiguità e scope creep
Project Charter PMBOK invece di POS	Troppo formale per un progetto accademico; POS è più snello e sufficiente
Un solo scoping meeting	Troppo compresso: la visione iniziale va separata dalla validazione per dare tempo di preparare RBS, SWOT, rischi
Non fare SWOT	SWOT ha fatto emergere la debolezza “dipendenza API LLM”, poi gestita con fallback nel planning

---

2. Planning Process Group

Teoria

• Importanza della pianificazione
• JPPS
• WBS
• Stime three-point (PERT)
• Network Diagram, Critical Path
• Risk Management

Documentazione

Artefatto	Link	Contenuto
PDS	PDS	POS esteso: stakeholder, O1-O7 dettagliati, vincoli, risk response plan
WBS	WBS	8 rami verb-type, da requisiti a gestione progetto
Project Network Diagram	Network	Diagramma, critical path, slack
Risk Analysis	Risk	R1-R10 con P/I/PxI/strategia/trigger/owner
Cost Estimate	Cost	Budget zero: effort 200h
Sprint Plan	Sprint	4 sprint + riserva, SP, DoD, RACI
Gantt	Gantt	Timeline visiva
3-planning.md	Planning	Verbali JPPS #1 e #2, WBS, stime, network, rischi, budget, sprint, RACI

Perché della scelta

Scelta	Motivazione
JPPS in due sessioni	#1 tecnica (WBS, stime) → #2 con committente (validazione). Separa costruzione e validazione
WBS verb-type	Coerente con Scrum (attività per sprint). Noun-type sarebbe stato meno utile per schedulare
PERT (three-point)	Incertezza R&D: una stima secca sarebbe stata falsamente precisa. Tripla stima cattura variabilità
MoSCoW	Meccanico di protezione della consegna: 11 SP non fatti = 0 Must. Senza priorità esplicita sarebbero stati tagli casuali
Critical path = BDI → LLM → E2E	Ha guidato l’ordine degli sprint: prima il core stabile, poi l’incognita LLM, poi l’integrazione
Management reserve 10%	Visibile e formale, non “buffer nascosto”. Necessaria per R&D
RACI	Team piccolo: senza matrice, “tutti fanno tutto” crea ambiguità. PM Accountable coerentemente con lo scenario
Budget zero ma cost estimate	Anche senza soldi, l’effort va stimato e controllato. 200h aggregate

Alternative possibili

Alternativa	Perché scartata
Pianificazione Waterfall (tutto upfront)	Incompatibile con Scrum. L’incertezza LLM non permetteva un piano definitivo
Stime a giudizio esperto senza PERT	Meno accurate: PERT dà E = (O+4M+P)/6 e σ, catturando incertezza
WBS noun-type (per componenti)	Meno utile per Scrum: non dice “cosa fare” in ogni sprint
Nessun buffer / reserve	Irrealistico per R&D: senza reserve, R4 avrebbe spostato la consegna
MS Project per diagrammi	A pagamento, non versionabile. Mermaid dà diagrammi in testo, diff-abili
Jira per backlog	Ridondante con GitHub Projects, non integrato con codice

---

3. Execution / Launching Process Group

Teoria

• Executing Process Group
• Scrum: ruoli, cerimonie, artefatti
• Process groups e PMLC

Documentazione

Artefatto	Link	Contenuto
Sprint Plan	Sprint Plan	DoD, DoR, backlog per sprint
Meeting Minutes	Minutes	Verbali planning, review, retrospective per ogni sprint
4-execution.md	Execution	Sprint 1-4: goal, storie, blocchi, review, retrospettiva, velocity

Perché della scelta

Scelta	Motivazione
Sprint 2 settimane	Abbastanza brevi per ispezione frequente, abbastanza lunghi per produrre incrementi significativi
Sprint Planning + Daily + Review + Retro	Il ciclo completo Scrum dà ritmo, visibilità, feedback e miglioramento continuo
DoD a 6 criteri	Impedisce di dichiarare “fatto” lavoro non verificabile. Include review, test, demo
Sprint Review con demo	Non una riunione informativa: il committente vede il funzionamento e dà feedback
Technical spike in Sprint 1	Bridge Jason-Python prototipato prima dell’implementazione: ha prevenuto R2
R1 gestito con fallback	Rate limit Groq → OpenRouter. Mitigazione prevista nel risk response plan
R4 gestito con management reserve	Ambiguità claim → post-processore. Non improvvisato, ma previsto e budgettato

Esecuzione per sprint — schema rapido

Sprint	Goal	SP done	Blocchi principali	Risultato
Sprint 1 (23/3-5/4)	Runtime BDI	18/20 (90%)	Jason su Windows → Docker; dipendenza ciclica → redesign	4 agenti, gc04 ok, 12/12 test
Sprint 2 (6/4-19/4)	Pipeline LLM	18/22 (82%)	Python 3.11+, formato LLM inconsistente, rate limit Groq	DSPy + Groq/OpenRouter, 8/10 claim ok
Sprint 3 (20/4-3/5)	Web App Review	16/18 (89%)	Scelta libreria grafica, parsing JSON tracce	Console React/Vite completa
Sprint 4 (4/5-17/5)	Integrazione & test	15/18 (83%)	Discrepanza formato, R4 ambiguità claim, esami	E2E, gc04, 9/10 test, deliverable
Totale		67/78 (86%)	0 Must persi	Consegna accettata

Alternative possibili

Alternativa	Perché scartata
Sprint 1 settimana	Troppo corto per produrre incrementi significativi con setup e apprendimento
Sprint 4 settimane	Riduce frequenza ispezione: rischi scoperti tardi
Senza technical spike	R2 (PxI=9) si sarebbe attivato durante l’implementazione, con ritardo maggiore
Senza MoSCoW	Tagli sarebbero stati casuali; possibile perdita di Must-have
Sprint Review solo per PM	Il feedback del committente è essenziale per la direzione iterativa
Waterfall execution	Non avrebbe permesso di adattare il backlog dopo i blocchi

---

4. Monitoring & Controlling Process Group

Teoria

• Obiettivo M&C
• Reporting system
• Stoplight report, EVM
• Scope Bank
• Issues Log, Problem Escalation

Documentazione

Artefatto	Link	Contenuto
Status Reports	Status	Report a stoplight per ogni sprint
5-monitoring.md	Monitoring	Burndown per sprint, EVM, issue log, risk monitoring, scope bank, change management
EVM foglio	EVM_SPI_CPI.xlsx	Calcolo PV, EV, AC, SPI, CPI con formule live

Perché della scelta

Scelta	Motivazione
Burndown chart giornaliero	Visibilità immediata su avanzamento sprint. Mostra trend, non solo stato puntuale
Status report a stoplight	Comunicazione chiara a committente e team. Verde/giallo/rosso è immediato
EVM in story point	Budget zero → EVM monetario non significativo. Misurare in SP dà SPI = 0.86 reale
SPI come indicatore principale	CPI = 1.00 è poco informativo (budget zero). SPI mostra la vera performance
Scope bank 10% (8 SP)	Riserva formale per assorbire R4. 2 SP usati per post-processore
Issue log (9 issue)	Traccia storica per analisi a posteriori: la maggior parte sono problemi di integrazione
Risk monitoring continuo	3 rischi attivati (R1, R3, R4), tutti con mitigazione prevista e attuata
SPOC = PM	Singolo punto di contatto per committente: evita comunicazioni disperse

EVM in sintesi

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
Sprint 3	18	16	16	0.89	1.00	Verde
Sprint 4	18	15	15	0.83	1.00	Giallo
Cumulativo	78	67	67	0.86	1.00	—

Alternative possibili

Alternativa	Perché scartata
EVM monetario classico	Non applicabile: budget zero. Misurare in SP è la corretta trasposizione
Solo report testuali	Meno efficaci: stoplight + burndown danno impatto visivo immediato
Nessuno scope bank	R4 non avrebbe avuto budget per post-processore; ritardo non assorbibile
Issue log tenuto a mente	Perdita di tracciabilità. Il log ha permesso analisi post-progetto
Jira per monitoring	Sovraccarico per team di 4 persone. GitHub Projects è sufficiente

---

5. Closing Process Group

Teoria

• Obiettivo Closing
• Accettazione formale
• Installazione (Cut-Over)
• Project Notebook
• Post-Implementation Audit, Final Report

Documentazione

Artefatto	Link	Contenuto
Final Report	Final Report	Executive summary, risultati, lessons learned, raccomandazioni
6-closing.md	Closing	Verifica O1-O7, accettazione, deliverable, audit, lessons learned
Meeting Minutes	Minutes	Incluso verbale Sprint Review #4 con accettazione

Perché della scelta

Scelta	Motivazione
Verifica O1-O7 vs POS/PDS	Chiude il ciclo iniziato nello scoping: ciò che era stato promesso è stato controllato
Accettazione formale in Sprint Review	Non “auto-dichiarata”: il committente ha verbalizzato l’accettazione
Post-Implementation Audit	Valutazione critica, non solo celebrazione. 7 dimensioni, da 4/5 a 5/5
Lessons Learned strutturate	6 lezioni in 3 aree (metodologia, stime, documentazione). Trasformano esperienza in conoscenza
Project Notebook su GitHub	Docs-as-code: tutto versionato, tracciato, navigabile
Tag v1.0.0-final	Congela il deliverable: sapere esattamente cosa è stato consegnato
Cut-Over accademico	Coerente con prototipo: non c’è produzione da migrare, ma la consegna è netta e documentata

Verifica obiettivi

Obiettivo	Risultato	Stato
O1 — Runtime BDI	4 agenti Jason su gc04	Raggiunto
O2 — Pipeline LLM	DSPy + Groq/OpenRouter	Raggiunto
O3 — Console Web	React/Vite + FastAPI	Raggiunto
O4 — Tracciabilità	Justification Tree per ogni decisione	Raggiunto
O5 — Golden case	gc00, gc04, gc_gray_zone	Raggiunto
O6 — CLI	ctaf run scenario.json	Raggiunto
O7 — Open source	GitHub + MIT	Raggiunto

Alternative possibili

Alternativa	Perché scartata
Nessuna accettazione formale	Ambiguità su “il progetto è finito o no?“. L’accettazione chiude il ciclo
Solo Final Report senza audit	Auto-valutazione senza struttura. L’audit dà dimensioni oggettive
Project Notebook ricostruito alla fine	Meno accurato, perde dettagli. Docs-as-code è più affidabile
Phased approach per installazione	Non c’è produzione: Cut-Over è la scelta più semplice e chiara
Senza lessons learned	Le stesse esperienze sarebbero state perse per progetti futuri

---

6. Strumenti — Trasversale

Categoria	Strumento scelto	Perché	Alternativa scartata
Repository	GitHub	Docs-as-code, versionato, integrato con issue/PR	GitLab (stessa cosa, meno usato accademicamente)
Backlog	GitHub Projects	Board kanban integrata col codice	Jira (ridondante, non integrato), Trello (non versionabile)
Diagrammi	Mermaid (.mmd)	Testuali, diff-abili, versionati	MS Project (plan-driven, a pagamento), draw.io (binario)
Documentazione	Markdown + Quartz	Portabile, versionabile, pubblicabile	Word/PDF (binario, non diff-abile)
Stime	Excel (.xlsx)	Formule live, PERT/EVM calcolati	MS Project (troppo pesante)
Comunicazione	Discord	Asincrono, canali tematici, daily standup	Slack (pagamento per storico), Teams (pesante)
Knowledge	Obsidian	Project Notebook a grafo, wikilink	Notion (non versionato)

---

Tabella riassuntiva — Tutte le fasi

Fase	Teoria (appunti)	Documento (pm-project)	Perché chiave	Alternativa principale
Contesto	04. Definizione di Project Management	1-contesto	BDI+LLM ibrido per tracciabilità	LLM puro (black-box)
Scoping	06. Scoping Process Group	2-scoping	CoS ~ bisogno reale, non want	Raccolta requisiti informale
Planning	07. Planning Process Group	3-planning	PERT per incertezza, MoSCoW per protezione	Waterfall upfront, stima singola
Execution	05. Definizione dei Processi	4-execution	Sprint 2 settimane, DoD, technical spike	Sprint lunghi, nessuno spike
Monitoring	09. Monitoring and Controlling Process Group	5-monitoring	EVM in SP, scope bank 10%, stoplight	Solo report testuali
Closing	10. Closing Process Group	6-closing	Audit, lessons learned, Project Notebook	Nessuna accettazione formale
Strumenti	—	7-strumenti	Leggeri, open-source, versionati	Jira, MS Project, Word

---

Collegamenti rapidi

• Studio orale strutturato: 11. Studio Orale - PM e CTAF
• Versione discorsiva: 12. Discussione Orale - Versione Discorsiva
• Elaborato completo: https://lorybug.github.io/pm-project/
• Repo pm-project: https://github.com/LoryBug/pm-project