10 - Server Project Management: Scrum e Agile

Panoramica: Cinque Server MCP per il Project Management Agile

Il project management agile e uno dei domini più complessi nello sviluppo software: richiede il coordinamento di sprint, task, metriche di performance, tracciamento del tempo, budget e retrospettive. Nella suite Tech-MCP, questi aspetti sono gestiti da cinque server MCP specializzati che collaborano attraverso l'EventBus, formando un ecosistema integrato di project management.

In questo articolo analizzeremo nel dettaglio ciascun server, i suoi tool con gli schema Zod, gli eventi pubblicati e sottoscritti, e il flusso di collaborazione che li unisce in un sistema coeso.

1. Scrum Board Server: l'Hub Centrale

Il server scrum-board e il cuore operativo dell'intera MCP Suite per il project management. Gestisce sprint, user story e task secondo la metodologia Scrum, fungendo da hub attraverso il quale transitano la maggior parte dei flussi di lavoro collaborativi. Praticamente ogni altro server PM interagisce con scrum-board, direttamente o tramite gli eventi che pubblica.

                    +---------------------------+
                    |     SCRUM-BOARD SERVER    |
                    |       HUB CENTRALE        |
                    +---------------------------+
                   /     |       |        |      \
                  /      |       |        |       \
                 v       v       v        v        v
          +-------+ +-------+ +------+ +-------+ +-------+
          |agile  | |time   | |retro | |standup| |project|
          |metrics| |track. | |mgr   | |notes  | |econ.  |
          +-------+ +-------+ +------+ +-------+ +-------+
    

Tool del Server scrum-board

Lo scrum-board espone 7 tool che coprono l'intero ciclo di vita Scrum:

Schema Zod: create-sprint

Ogni tool definisce i propri parametri tramite schema Zod per la validazione automatica degli input:

// Tool: create-sprint
const CreateSprintSchema = z.object({
  name: z.string().describe("Nome dello sprint"),
  startDate: z.string().describe("Data inizio ISO (YYYY-MM-DD)"),
  endDate: z.string().describe("Data fine ISO (YYYY-MM-DD)"),
  goals: z.array(z.string()).describe("Obiettivi dello sprint")
});
    

Schema Zod: update-task-status

// Tool: update-task-status
const UpdateTaskStatusSchema = z.object({
  taskId: z.number().describe("ID del task da aggiornare"),
  status: z.enum(["todo", "in_progress", "in_review", "done", "blocked"])
    .describe("Nuovo stato del task nel flusso Kanban")
});
    

Flusso Kanban dei Task

Ogni cambio di stato di un task segue il flusso Kanban standard. Da qualsiasi stato e possibile transizionare verso blocked:

  +-------+     +-------------+     +-----------+     +------+
  | todo  | --> | in_progress | --> | in_review | --> | done |
  +-------+     +-------------+     +-----------+     +------+
      |               |                   |
      +-------+-------+-------------------+
              |
              v
          +--------+
          | blocked|
          +--------+
    

Database ScrumStore: tre tabelle SQLite

Lo ScrumStore gestisce tre tabelle interconnesse tramite foreign key:

+------------------+       +-------------------+       +------------------+
|     sprints      |       |      stories      |       |      tasks       |
+------------------+       +-------------------+       +------------------+
| id (PK)          |<------| sprintId (FK)     |       | id (PK)          |
| name             |       | id (PK)           |<------| storyId (FK, NN) |
| startDate        |       | title             |       | sprintId (FK)    |
| endDate          |       | description       |       | title            |
| goals (JSON)     |       | acceptanceCriteria|       | description      |
| status           |       | storyPoints       |       | status           |
| createdAt        |       | priority          |       | assignee         |
+------------------+       | status            |       | createdAt        |
                            | createdAt         |       | updatedAt        |
                            +-------------------+       +------------------+
    

Sprint Board: Vista Kanban

Il tool sprint-board genera una vista Kanban completa, organizzando i task in colonne. Se non viene specificato sprintId, recupera automaticamente lo sprint con stato active:

+--------------------------------------------------------------------+
|                   Sprint Board: Sprint 14                          |
+--------------------------------------------------------------------+
| TODO          | IN PROGRESS   | IN REVIEW     | DONE    | BLOCKED  |
|---------------|---------------|---------------|---------|----------|
| Task: Setup   | Task: Login   | Task: Test    | Task:   | Task:    |
|   OAuth       |   form UI     |   OAuth flow  |  DB     |  Deploy  |
|               |               |               | schema  |  (needs  |
| Task: 2FA     | Task: Token   |               |         |  infra)  |
|   research    |   refresh     |               |         |          |
+--------------------------------------------------------------------+
    

Eventi pubblicati da scrum-board

Lo scrum-board e il principale produttore di eventi della suite PM. Ogni operazione critica genera un evento che attiva reazioni a catena negli altri server:

Eventi sottoscritti da scrum-board

Lo scrum-board e anche uno dei pochi server che riceve eventi da altri server, creando un ciclo di feedback bidirezionale:

Esempio: Workflow completo di uno Sprint

// 1. Creare lo sprint
{ "tool": "create-sprint",
  "arguments": {
    "name": "Sprint 14 - Autenticazione",
    "startDate": "2025-02-03",
    "endDate": "2025-02-14",
    "goals": ["Implementare login OAuth", "Aggiungere 2FA"]
  } }

// 2. Creare una user story
{ "tool": "create-story",
  "arguments": {
    "title": "Login OAuth Google",
    "description": "Come utente voglio autenticarmi con Google",
    "acceptanceCriteria": ["Redirect a Google", "Token salvato", "Sessione attiva"],
    "storyPoints": 8,
    "priority": "high",
    "sprintId": 1
  } }

// 3. Creare task per la story
{ "tool": "create-task",
  "arguments": {
    "title": "Configurare OAuth credentials",
    "description": "Setup su Google Cloud Console",
    "storyId": 1,
    "assignee": "mario"
  } }

// 4. Aggiornare lo stato del task
{ "tool": "update-task-status",
  "arguments": { "taskId": 1, "status": "in_progress" } }

// 5. Visualizzare la board
{ "tool": "sprint-board", "arguments": { "sprintId": 1 } }
    

2. Agile Metrics Server: Analisi e Previsioni

Il server agile-metrics fornisce strumenti analitici per misurare e prevedere le prestazioni del team. Calcola velocity, genera dati di burndown, analizza cycle time e produce previsioni di completamento basate su simulazioni Monte Carlo.

Una caratteristica fondamentale e che il server e completamente stateless: non possiede database ne store interno. Riceve dati come input (tipicamente provenienti dallo scrum-board) e restituisce calcoli puri.

Schema Zod: calculate-velocity

const CalculateVelocitySchema = z.object({
  sprints: z.array(z.object({
    name: z.string(),
    completedPoints: z.number(),
    totalPoints: z.number()
  })).describe("Lista sprint con punti completati e totali")
});
    

Schema Zod: forecast-completion

const ForecastCompletionSchema = z.object({
  remainingPoints: z.number().describe("Punti rimanenti da completare"),
  velocityHistory: z.array(z.number())
    .describe("Storico velocity degli ultimi sprint"),
  sprintLengthDays: z.number()
    .describe("Durata di uno sprint in giorni")
});
    

Simulazione Monte Carlo

Il tool forecast-completion esegue 1000 simulazioni per prevedere quando il lavoro rimanente sarà completato, considerando la variabilità storica della velocity:

  Algoritmo Monte Carlo:
  +-------------------------------------------------------+
  | Per ogni simulazione (1..1000):                       |
  |   remainingWork = remainingPoints                     |
  |   sprints = 0                                         |
  |   while remainingWork > 0:                            |
  |     velocity = random(velocityHistory)                |
  |     remainingWork -= velocity                         |
  |     sprints++                                         |
  |   record(sprints * sprintLengthDays)                  |
  +-------------------------------------------------------+
  | Ordina risultati                                      |
  | p50 = risultato al 50-esimo percentile                |
  | p85 = risultato all'85-esimo percentile               |
  | p95 = risultato al 95-esimo percentile                |
  +-------------------------------------------------------+
    

L'output fornisce tre livelli di confidenza:

{
  "remainingPoints": 50,
  "simulations": 1000,
  "forecast": {
    "p50": { "sprints": 2, "days": 28, "date": "2025-03-14" },
    "p85": { "sprints": 3, "days": 42, "date": "2025-03-28" },
    "p95": { "sprints": 3, "days": 42, "date": "2025-03-28" }
  },
  "confidence": "Con l'85% di probabilità, completamento entro 42 giorni"
}
    

Burndown Chart: Ideale vs Attuale

Il tool generate-burndown confronta la linea ideale con l'avanzamento reale, indicando per ogni giorno se il progresso e on-track, behind o ahead:

  Punti
  40 |*
     | *  .
  30 |  *   .
     |   *     .    * <-- attuale (in ritardo)
  20 |    *       .
     |     *         .    *
  10 |      *           .     *
     |       *              .    *
   0 |--------*------------------.--*-----> Giorni
     1  2  3  4  5  6  7  8  9 10

     * = linea ideale     . = avanzamento reale
    

Cycle Time: Statistiche Dettagliate

Il tool calculate-cycle-time analizza i tempi di completamento dei task:

Eventi sottoscritti da agile-metrics

Agile-metrics e un puro consumatore di dati. Non pubblica eventi, ma sottoscrive quelli dello scrum-board per reagire ai cambiamenti nello sprint in corso:

• scrum:sprint-completed → trigger per ricalcolo velocity e report di fine sprint
• scrum:task-updated → aggiornamento dati burndown in tempo reale
• scrum:story-completed → aggiornamento punti completati per velocity tracking

3. Time Tracking Server: Tracciamento del Tempo

Il server time-tracking gestisce il tracciamento del tempo lavorato sui task, con supporto per timer live e registrazione manuale. Mantiene uno stato persistente tramite SQLite con due tabelle: una per i time entry e una per i timer attivi.

Il server implementa una protezione contro il doppio avvio: non e possibile avere più di un timer attivo contemporaneamente per lo stesso utente.

Schema Zod: start-timer e log-time

const StartTimerSchema = z.object({
  taskId: z.string().describe("ID del task da tracciare"),
  description: z.string().optional()
    .describe("Descrizione dell'attivita"),
  userId: z.string().optional()
    .describe("ID utente (default: 'default')")
});

const LogTimeSchema = z.object({
  taskId: z.string().describe("ID del task"),
  durationMinutes: z.number()
    .describe("Durata in minuti"),
  description: z.string().optional(),
  date: z.string().optional()
    .describe("Data ISO (YYYY-MM-DD)"),
  userId: z.string().optional()
});
    

Flusso del Timer

Il flusso di start-timer include la protezione contro il doppio avvio. Il stop-timer calcola automaticamente la durata e crea un time entry:

  start-timer(taskId: "TASK-42")
       |
       v
  Verifica: esiste timer attivo per userId?
       |
       +--[SI]--> Errore: "Timer attivo per TASK-15. Ferma prima quello."
       |
       +--[NO]--> Crea record in active_timers
                   startTime = new Date().toISOString()

  stop-timer()
       |
       v
  Cerca timer attivo per userId
       |
       +--[NON TROVATO]--> Errore: "No active timer found"
       |
       +--[TROVATO]
            |
            v
       endTime = now()
       durationMinutes = Math.round((endMs - startMs) / 60000)
            |
            v
       INSERT INTO time_entries --> DELETE FROM active_timers
            |
            v
       Pubblica time:entry-logged
    

Database TimeStore

Il TimeStore gestisce due tabelle SQLite:

• active_timers: timer attualmente in corso (id, taskId, userId, startTime, description)
• time_entries: registrazioni completate (id, taskId, userId, startTime, endTime, durationMinutes, description, date)

Eventi del time-tracking

{
  "taskId": "TASK-42",
  "userId": "mario",
  "durationMinutes": 45,
  "date": "2025-02-07"
}
      

4. Project Economics Server: Budget e Costi

Il server project-economics gestisce il budget e i costi di progetto, fornendo visibilità sulla spesa, breakdown per categoria e previsioni di esaurimento budget. Include un sistema di alert automatico che pubblica un evento quando il budget utilizzato raggiunge o supera l'80%.

Schema Zod: log-cost

const LogCostSchema = z.object({
  projectName: z.string().describe("Nome del progetto"),
  category: z.string().describe("Categoria di spesa (es. sviluppo, infra, testing)"),
  amount: z.number().describe("Importo in valuta del budget"),
  description: z.string().describe("Descrizione del costo"),
  date: z.string().optional().describe("Data ISO del costo"),
  taskId: z.string().optional().describe("ID task associato")
});
    

Algoritmo di Forecast del Budget

Il tool forecast-budget calcola il burn rate giornaliero e stima quando il budget si esaurira:

  Algoritmo di previsione:
  +---------------------------------------------------+
  | 1. Trova prima e ultima data di costo             |
  | 2. daysTracked = (lastDate - firstDate) + 1       |
  | 3. dailyBurnRate = totalSpent / daysTracked       |
  | 4. estimatedDaysRemaining = remaining / burnRate  |
  | 5. runOutDate = today + daysRemaining             |
  +---------------------------------------------------+
    

Budget Status con Breakdown

Il tool get-budget-status restituisce una vista completa del budget con breakdown per categoria di spesa:

{
  "projectName": "MCP Suite v2",
  "totalBudget": 50000,
  "currency": "EUR",
  "totalSpent": 38500,
  "remaining": 11500,
  "percentageUsed": 77.0,
  "breakdown": [
    { "category": "sviluppo", "total": 25000 },
    { "category": "infrastruttura", "total": 8500 },
    { "category": "testing", "total": 3000 },
    { "category": "design", "total": 2000 }
  ]
}
    

Eventi del project-economics

Flusso degli Alert di Budget

  log-cost("MCP Suite v2", "sviluppo", 5000, ...)
       |
       v
  Calcola percentageUsed = totalSpent / totalBudget * 100
       |
       v
  percentageUsed = 82%  --> >= 80%?
       |
       +--[SI]--> Pubblica economics:budget-alert
       |           { projectName: "MCP Suite v2",
       |             percentageUsed: 82,
       |             remaining: 9000,
       |             totalBudget: 50000 }
       |
       +--[NO]--> Solo economics:cost-updated
    

Eventi sottoscritti da project-economics

• time:entry-logged (da time-tracking) → converte tempo registrato in costo e lo aggiunge al progetto
• scrum:sprint-completed (da scrum-board) → trigger per report di fine sprint con analisi costi

5. Retrospective Manager Server: Retrospettive Agili

Il server retrospective-manager gestisce il ciclo completo delle retrospettive agili: dalla creazione della sessione con formato specifico, alla raccolta del feedback per categoria, al sistema di votazione, fino alla generazione automatica di action item dai temi più votati.

Supporta tre formati di retrospettiva standard:

Schema Zod: create-retro e add-retro-item

const CreateRetroSchema = z.object({
  format: z.enum(["mad-sad-glad", "4ls", "start-stop-continue"])
    .describe("Formato della retrospettiva"),
  sprintId: z.string().optional()
    .describe("ID dello sprint associato")
});

const AddRetroItemSchema = z.object({
  retroId: z.number().describe("ID della retrospettiva"),
  category: z.string()
    .describe("Categoria (validata dal formato della retro)"),
  content: z.string().describe("Contenuto del feedback"),
  authorId: z.string().optional()
    .describe("Autore del feedback")
});
    

Validazione delle Categorie

Il server valida la categoria verificando che sia coerente con il formato della retrospettiva. Se la categoria non e valida, restituisce un errore:

  add-retro-item(retroId: 1, category: "happy", content: "...")
       |
       v
  Verifica formato retro #1 = "mad-sad-glad"
  Categorie valide: ["mad", "sad", "glad"]
  "happy" NON e valida
       |
       v
  Errore: 'Invalid category "happy" for format "mad-sad-glad".
           Valid categories: mad, sad, glad'
    

Generazione Action Item

Il tool generate-action-items seleziona i top-N elementi più votati e genera un action item per ciascuno, pubblicando l'evento retro:action-item-created:

  Top 3 votati --> Action Items:
  1. [mad] Deploy troppo lento (8 voti)
  2. [sad] Manca documentazione (6 voti)
  3. [glad] Code review migliora qualità (5 voti)
       |
       v
  Per ogni action item:
    Pubblica retro:action-item-created
    { retroId, actionItemId, description, assignee }
       |
       v
  scrum-board riceve --> crea task nel backlog
    

Database RetroStore: tre tabelle SQLite

• retros: sessioni di retrospettiva (id, sprintId, format, status)
• retro_items: feedback del team (id, retroId, category, content, votes, authorId)
• action_items: azioni concrete (id, retroId, description, assignee, dueDate, status)

Flusso bidirezionale con scrum-board

Flusso di Collaborazione: Come i 5 Server PM Interagiscono

Il valore reale di questi cinque server emerge dalla loro collaborazione tramite EventBus. Nessun server opera in isolamento: ogni evento pubblicato attiva reazioni a catena che creano un flusso di project management integrato e automatizzato.

Diagramma di Collaborazione

  +------------------+
  |   SCRUM-BOARD    |  (HUB CENTRALE)
  |   7 tool         |
  +--------+---------+
           |
           | scrum:sprint-started
           | scrum:task-updated
           | scrum:sprint-completed
           | scrum:story-completed
           |
     +-----+-----+-----+------------------+
     |           |     |                  |
     v           v     v                  v
+----------+ +------+ +---------------+ +----+
|agile-    | |time- | |retrospective- | |... |
|metrics   | |track.| |manager        | |    |
|4 tool    | |4 tool| |5 tool         | |    |
|stateless | |      | |               | |    |
+----------+ +--+---+ +------+--------+ +----+
                |             |
                | time:       | retro:action-
                | entry-      | item-created
                | logged      |
                v             v
          +----------+  +------------------+
          |project-  |  |  SCRUM-BOARD     |
          |economics |  |  (riceve e crea  |
          |4 tool    |  |   task backlog)  |
          +----+-----+  +------------------+
               |
               | economics:budget-alert
               | economics:cost-updated
               v
          (alert e audit)
    

Scenario Integrato: Sprint Completo con tutti i Server

Ecco un esempio di come tutti e cinque i server collaborano durante il ciclo di vita di uno sprint:

1. Pianificazione: l'AI invoca create-sprint sullo scrum-board. L'evento scrum:sprint-started notifica agile-metrics (nuova velocity) e retrospective-manager (contest per futura retro).
2. Esecuzione: gli sviluppatori aggiornano lo stato dei task con update-task-status. L'evento scrum:task-updated attiva il ricalcolo del burndown in agile-metrics e il time-tracking può avviare/fermare timer automaticamente.
3. Tracciamento tempo: al stop-timer, time-tracking pubblica time:entry-logged. Project-economics riceve l'evento e converte il tempo in costo, aggiornando il budget.
4. Budget alert: se la spesa supera l'80% del budget, project-economics pubblica economics:budget-alert per notificare il team.
5. Chiusura sprint: al completamento dello sprint, agile-metrics ricalcola velocity e forecast, mentre retrospective-manager crea automaticamente una retrospettiva.
6. Retrospettiva: il team inserisce feedback, vota e genera action item. L'evento retro:action-item-created crea task nel backlog dello scrum-board, pronti per il prossimo sprint.

Architettura Interna dei Server PM

Tutti e cinque i server PM seguono la stessa struttura architetturale standardizzata, condividendo pattern e convenzioni dal pacchetto @mcp-suite/core:

server-name/
  src/
    index.ts          --> entry point
    server.ts         --> createXxxServer(), registra tool e collaboration
    services/
      xxx-store.ts    --> Store SQLite (gestione dati persistenti)
    tools/
      tool-name.ts    --> handler singolo tool con schema Zod
    collaboration.ts  --> setupCollaborationHandlers(eventBus, store)
    

Il pattern collaboration.ts e particolarmente importante: e il file che gestisce la sottoscrizione e la pubblicazione degli eventi sull'EventBus, rendendo esplicito il contratto di collaborazione di ogni server con il resto della suite.

Dipendenze dei Pacchetti Condivisi

I server PM utilizzano tre pacchetti condivisi della MCP Suite:

• @mcp-suite/core: base per la creazione del server MCP, registrazione tool, gestione lifecycle
• @mcp-suite/event-bus: sistema di eventi tipizzati per la comunicazione inter-server
• @mcp-suite/database: wrapper SQLite con migrazioni automatiche (usato da 4 dei 5 server; agile-metrics e stateless)

Conclusioni

I cinque server di project management della MCP Suite dimostrano come il protocollo MCP possa supportare workflow complessi e realmente collaborativi. Lo scrum-board come hub centrale, agile-metrics per l'analisi predittiva con Monte Carlo, time-tracking per la gestione del tempo, project-economics per il controllo dei costi e retrospective-manager per il miglioramento continuo formano un ecosistema completo di gestione agile.

Il pattern chiave e la collaborazione event-driven: ogni server pubblica eventi che attivano azioni negli altri, creando catene di automazione che riducono il lavoro manuale e mantengono sincronizzato l'intero sistema. Il ciclo retrospettiva-backlog e un esempio perfetto di come i server MCP possano chiudere loop di feedback in modo completamente automatizzato.

Nel prossimo articolo esploreremo i server avanzati della suite: incident-manager, decision-log, access-policy, quality-gate, workflow-orchestrator, insight-engine e altri, scoprendo come gestire scenari ancora più complessi con pattern architetturali evoluti.

Il codice completo di tutti i server di project management e disponibile nel repository Tech-MCP su GitHub.