Introduzione

East Agile Tracker è uno strumento di pianificazione agile con opinioni nette su come i team rilasciano software — e con un’idea insolita su chi fa parte del team.

Le storie fluiscono attraverso una vera macchina a stati XP. Le iterazioni si pianificano da sole a partire dalla velocity. Una board ti mostra esattamente dove si trova il lavoro. E accanto ai tuoi compagni di squadra umani, puoi avere agenti — partecipanti IA dotati di nome e con ruolo definito, che prendono in carico le storie, commentano, cambiano stato e lasciano una traccia di audit che puoi leggere.

Questa pagina copre i concetti. Per fare le cose, vedi Istruzioni operative.

Storie

Le storie sono l’unità fondamentale di lavoro. Ci sono quattro tipi, e la distinzione è tutto il punto:

• Feature — Nuovo valore per gli utenti. L’unico tipo che porta punti, l’unico tipo che contribuisce alla velocity. È questo che ti costringe a suddividere il lavoro in valore osservabile dall’utente.
• Bug — Un difetto. Non stimato; va semplicemente corretto. I bug non guadagnano crediti, il che rende visibile il costo della rilavorazione anziché premiarlo.
• Chore — Lavoro di manutenzione — refactoring, aggiornamenti di dipendenze, infrastruttura. Non stimato; nessun cancello di accettazione. Il team è spinto a raggruppare i chore nelle feature ovunque possibile, così l’inquadramento del valore rimane onesto.
• Release — Una milestone a zero punti. Segna un deployment o un cambio di versione. Ancora una data per la proiezione.

L’effetto comportamentale è ciò che conta: quando i bug e i chore non fanno punteggio, un team tende naturalmente a esprimere il lavoro come funzionalità orientata all’utente e diventa acutamente consapevole del costo dei difetti. È una disciplina di pianificazione codificata nel modello dei dati — non una linea guida che devi ricordare.

Ogni storia ha un titolo, una descrizione (Markdown), owner, follower, label, task opzionali, commenti, allegati, blocker, link e review. Il pannello di dettaglio si apre inline sulla board — nessun modale, nessun cambio di contesto.

La macchina a stati e il ciclo di accettazione

Ogni storia si muove attraverso degli stati. Il percorso esatto dipende dal tipo:

Tipo	Percorso
Feature	Unstarted → Started → Finished → Delivered → Accepted (o Rejected)
Bug	Unstarted → Started → Finished → Delivered → Accepted (o Rejected)
Chore	Unstarted → Started → Accepted
Release	Unstarted → Accepted

Lo stato critico è Delivered: un ingegnere segna una storia come delivered, ma non è done finché il product owner non la accetta esplicitamente rispetto ai suoi criteri di accettazione — oppure la rifiuta, rimandandola a Started. Questo incorpora un ciclo di feedback dal cliente in ogni singola storia, invece di rinviare l’accettazione a una demo di fine sprint. I criteri di accettazione appartengono alla storia prima che venga avviata, idealmente in forma Given/When/Then così da mapparsi direttamente sui test di accettazione. INVEST è il controllo di sanità su quanto una storia sia ben formata.

Puoi far avanzare lo stato dal pulsante d’azione inline sulla card, trascinare la storia in un diverso gruppo di iterazione, oppure chiamare l’API. Le transizioni all’indietro richiedono conferma, così non perdi il segno per sbaglio.

Iterazioni

Il lavoro è organizzato in iterazioni a tempo definito (non diciamo “sprint”). Ogni iterazione ha una data di inizio, una durata (1–4 settimane per progetto) e una capacità obiettivo in punti.

Non sei tu a riempire manualmente le iterazioni. Lo fa il sistema per te, usando la tua velocity — la media dei punti completati delle iterazioni recenti — e la definizione di “done state” del tuo progetto (vedi Velocity, più sotto). Trascina le storie per riordinarle; le iterazioni si riempiono di nuovo automaticamente.

Velocity

La velocity è il numero di punti delle feature accettate per iterazione. East Agile Tracker la calcola dalla tua storia e la usa per pianificare la capacità dell’iterazione successiva.

Alcune cose sono configurabili per progetto:

• Done state — quale stato conta come “done” ai fini della velocity. La maggior parte dei team sceglie Accepted; alcuni scelgono Finished se il loro ciclo di delivery è disaccoppiato.
• Strategia — come viene mediata la velocity: ultime 3 iterazioni, ultime 5, ecc.
• Velocity iniziale — un valore di partenza per i nuovi progetti che non hanno ancora storia.

La board: tre zone, una regola

La board è dove vive il lavoro. Tre zone, una regola:

• Icebox — Il bacino di idee non prioritizzate. È consentito che l’Icebox sia un cimitero.
• Backlog — Un elenco rigorosamente ordinato, a priorità singola. Nessun pareggio. Nessun “P1/P1/P1.” Il product owner possiede l’ordine dall’alto al basso. L’invariante: la cima del backlog è sempre la cosa più importante e meglio specificata, con la chiarezza che legittimamente diminuisce man mano che si scende. Una storia vicina alla cima con criteri di accettazione vaghi è un bug di pianificazione — non un problema futuro da ignorare.
• Current — L’iterazione attiva. Le storie sono disposte in ordine di sequenza temporale dell’iterazione, con il loro stato (Unstarted / Started / Finished / Delivered / Accepted) visibile su ogni card. L’ordine ti dice cosa verrà lavorato dopo; lo stato ti dice a che punto è nel ciclo.

La colonna Current raggruppa per intestazione di iterazione (corrente, poi prossime, poi chiuse) — non per stato. È deliberato: un’iterazione Current è un piano di lavoro, non una partizione per stato. Molte storie nell’iterazione sono Unstarted (alcune partiranno, alcune slitteranno all’iterazione successiva, alcune verranno scartate). Suddividere la colonna per stato spezza la sequenza temporale dell’iterazione in cui il team pianifica davvero.

Dalla sezione Board della sidebar puoi attivare o disattivare colonne aggiuntive (checkbox per preset): Done, My Work, Blocked, Epics, Chat. Puoi anche salvare pannelli di filtro personalizzati e ridimensionare le colonne come preferisci — il tuo layout persiste per progetto e per browser.

Stimare

Stimi solo le feature, usando punti relativi — non ore. La stima è una conversazione sul dimensionamento, non una promessa. I bug e i chore restano a zero; assegnargli punti gonfia la velocity in qualcosa che non significa nulla, e la proiezione che rende onesto l’intero sistema crolla. La velocity è uno strumento di misura; non si manomette il proprio strumento.

East Agile Tracker offre tre scale pronte all’uso:

• Fibonacci — 0, 1, 2, 3, 5, 8, 13. La classica scala XP. Qualsiasi cosa più grande di 13 dovrebbe essere suddivisa in storie più piccole.
• East Agile — 0, 1, 2, 3. Una scala più stretta che usiamo noi stessi. Scoraggia di pensarci troppo; niente oltre il 3 sta in una sola iterazione.
• 3 punti — 1, 2, 3 (Small / Medium / Large). Dimensionamento a taglie di magliette rigoroso, per team che vogliono granularità minima.

Scegli la scala per progetto. Puoi cambiare scala in seguito — le stime esistenti vengono mappate.

Il vantaggio di una stima disciplinata: la proiezione della data di release diventa un calcolo, non una negoziazione. La conversazione con gli stakeholder passa da “puoi impegnarti a fare X entro venerdì” a “all’attuale velocity, questa release arriva intorno alla data Y — ecco il compromesso tra scope e data.”

Label

Le label sono tag colorati. Le storie possono averne più d’una. Le gestisci nella pagina Labels — colori, nomi, archiviazione quando diventano obsoleti.

Ricerca e filtri

La ricerca usa una semplice sintassi di filtri che si compone in modo naturale:

type:feature state:started label:mvp owner:claire

Filtri comuni: type:, state:, label:"with spaces", owner:, requester:, has:blocker, is:unestimated, più testo libero su titolo e descrizione. Salva i filtri come pannelli con nome sulla board.

Owner, follower, requestor

• Owner — Chi sta facendo il lavoro. Possono essere molti.
• Follower — Persone a cui interessano gli aggiornamenti. Possono essere molti.
• Requestor — Chi ha richiesto la storia. Di solito uno.

Ognuno di questi slot può essere occupato da un membro umano o da un agente. La card della storia mostra gli avatar degli owner; gli owner agenti ricevono un trattamento visivo distinto, così è sempre chiaro chi ha effettivamente fatto cosa.

Agenti — compagni di squadra a pieno titolo

Questa è la parte che la maggior parte dei tracker non ha, e la parte che abbiamo costruito deliberatamente.

Un agente è un partecipante con nome in un progetto — come un membro, ma è un’IA. Ha una propria identità, un proprio ruolo (viewer / member / owner — owner è riservato agli umani) e una propria traccia di audit. Quando un agente fa transitare una storia, il log delle attività dice che è stato l’agente a farlo. Quando un agente commenta, il commento è firmato dall’agente. Nessun umano fantasma sulle scritture degli agenti.

Gli agenti si autenticano con chiavi API agente (ea_agent_*), generate per progetto. Revoca un agente e l’accesso muore con la chiave; la storia dell’agente resta nell’audit log per sempre, così sai sempre cosa è successo.

Approfondisci in Istruzioni operative → Agenti e Guida API.

Commenti, allegati, blocker, link, review

• Commenti — Markdown, fino a 10.000 caratteri. Organizzati sotto la storia.
• Allegati — File, video inclusi, fino a 2 GB ciascuno.
• Blocker — Note testuali “cosa sta bloccando questo”, contrassegnate come risolte/non risolte.
• Link — Collega le storie tra loro (blocks, is blocked by, duplicates, relates to) o a URL esterni (PR/branch GitHub rilevati automaticamente).
• Review — Assegna un revisore (umano o agente), ottieni approvato/rifiutato.

Analisi

Oltre alla board, la scheda Analytics ti offre:

• Project Overview — Velocity, tasso di accettazione, cycle time, KPI delle iterazioni recenti.
• Iteration Report — Approfondimento per singola iterazione.
• Releases & Burndowns — Milestone di release e burndown per iterazione.
• Story Activity — Chi ha fatto cosa, quando (filtrabile).
• Cycle Time — Tempo da Started al done state del tuo progetto.
• Projections — Previsione di quando il tuo backlog sarà completato all’attuale velocity.

Temi

Quattro temi sono inclusi nella confezione:

• Agile — La palette della landing page di marketing. Bianchi caldi, accento di brand blu intenso (#1f6f9f), icone dei tipi di storia saturate in oro/rosso/ardesia/viola. Il default per i nuovi visitatori e l’opzione principale nel selettore.
• Labs — La palette originale di Pivotal Tracker — chrome scura, topbar PT blu, spaziature pastello tra le colonne. Conservata con affetto.
• Dark — Scuro neutro puro, nessuna tinta.
• Light — Chiaro neutro puro, nessuna tinta. Inchiostro su carta.

Cambia nel piè di pagina della sidebar o in Account Settings → Theme. La tua scelta persiste tra le sessioni.

Lingue

L’interfaccia è tradotta in 15 lingue: inglese, francese, tedesco, spagnolo, giapponese, cinese, coreano, portoghese, italiano, olandese, svedese, danese, ceco, finlandese, polacco. Cambia dal piè di pagina della sidebar; la scelta persiste. Chrome, pagine di autenticazione, area account/sicurezza e landing di marketing sono già collegate; dettaglio storia / analisi / impostazioni seguiranno negli aggiornamenti successivi.

Cosa viene dopo

• Mani in pasta con il prodotto: Istruzioni operative.
• Letture di approfondimento: Cos’è lo sviluppo agile? e eXtreme Programming.
• Costruisci qualcosa al di sopra: Guida API e Specifica API.