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:

• Feature — Nuovo valore per gli utenti. Per default l’unico tipo che porta punti e l’unico tipo che contribuisce alla velocity.
• Bug — Un difetto. Non stimato per default; 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 per default; nessun cancello di accettazione.
• 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. Un progetto che vuole comunque far contare bug e chore può attivare Punti per bug e chore nelle Impostazioni progetto; da quel momento accettano stime e alimentano la velocity come le feature.

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, e il product owner la accetta rispetto ai suoi criteri di accettazione oppure la rifiuta. Rejected è terminale nella macchina a stati; la via del ritorno è un’azione separata, Restart, che riporta la storia a Started. Rifiutare una storia che si trova in un’iterazione passata crea invece una copia in cima al Backlog, così la rilavorazione viene pianificata anziché sepolta. Questo incorpora un ciclo di feedback dal cliente in ogni singola storia, invece di rinviare l’accettazione a una demo di fine sprint. Non esiste un campo separato per i criteri di accettazione — i criteri appartengono alla descrizione prima che la storia 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 oppure chiamare l’API. Trascinare una card la sposta tra i pannelli — da Icebox a Backlog, da Backlog a Current. Rilasciarla in Current ne lascia invariato lo stato; rilasciarla in Backlog o in Icebox la riporta a Unstarted.

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; l’iterazione corrente si riempie di nuovo automaticamente.

Velocity

La velocity è il numero di punti completati per iterazione; una storia conta non appena raggiunge lo stato di completamento del progetto. 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. Le opzioni sono Finished, Delivered e Accepted.
• Strategia — come viene mediata la velocity: le ultime 3, 5 o 10 iterazioni, oppure un valore manuale che scavalca del tutto il calcolo.
• 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.
• 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.
• 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 è una singola iterazione sotto una singola intestazione — non un insieme di contenitori 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. Le iterazioni chiuse vivono nella colonna Done, e le iterazioni successive proiettate dal Backlog compaiono sotto Current solo quando attivi il suo interruttore Show Backlog stories.

Dalla sezione Board della sidebar puoi attivare o disattivare colonne aggiuntive (checkbox per preset): Done, My Work, Blocked, Epics, Archived. È elencata anche una colonna Chat; è un’anteprima statica con messaggi segnaposto, non una chat funzionante. Una ricerca si apre in una colonna propria, e il tuo insieme di colonne è memorizzato lato server per membro e per progetto, quindi ti segue tra un browser e l’altro.

Stimare

Per default stimi le feature, usando punti relativi — non ore. La stima è una conversazione sul dimensionamento, non una promessa. I bug e i chore restano senza stima a meno che il progetto non attivi Punti per bug e chore; allora ricevono stime e contano nella velocity come le feature.

East Agile Tracker offre tre scale pronte all’uso:

• Fibonacci — 0, 1, 2, 3, 5, 8, 13. La classica scala XP.
• East Agile — 0, 1, 2, 3. Una scala più stretta che usiamo noi stessi.
• 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, ma le stime esistenti non vengono rimappate: ogni storia conserva il suo vecchio valore, e un valore che la nuova scala non ha resta sulla storia finché non la ristimi.

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 sintassi di filtri in stile GitHub che si compone in modo naturale:

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

Qualificatori: type:, state:, label:"with spaces", epic:, priority:, points: (un valore o un intervallo come 1..5), iteration:, i qualificatori sulle persone owner:, requester:, follower:, reviewer:, commenter:, mention: (membri e agenti; @me sei tu), i qualificatori sulle date created:, updated:, started:, completed:, release: (un giorno o un intervallo) e i flag has:blocker, is:unestimated, is:icebox, is:backlog, is:blocked — più testo libero su titolo, riferimento e descrizione. Separa le alternative con una virgola in una faccetta (type:bug,chore), nega qualsiasi cosa con un - iniziale e ordina per rilevanza, creazione o aggiornamento. Eseguire una ricerca apre una colonna di risultati che resta sulla tua board. La grammatica completa è nella Guida API → Ricerca.

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 / manager — il ruolo di un agente non può mai superare quello di chi lo ha creato, quindi solo un manager umano genera un agente con ruolo manager) 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 20.000 caratteri. Un elenco piatto sotto la storia, ciascuno con reazioni emoji e un permalink.
• Allegati — File, video inclusi. I limiti dipendono dal tipo: video 200 MB, PDF / Word / Excel 25 MB, immagini / CSV / testo 10 MB.
• 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 (pull request, branch o other; gli URL di PR e branch GitHub vengono rilevati automaticamente).
• Review — Assegna un revisore (umano o agente), ottieni approvato/rifiutato.

Metriche

Oltre alla board, la pagina Metrics del progetto ha tre schede:

• General — Andamento della velocity, il burndown dell’iterazione corrente, il mix dei tipi di storia per iterazione, le card Committed / Completed / Carried-over e le storie riportate dalle iterazioni precedenti.
• Contributors — Punti e storie per membro o agente in un periodo, con i conteggi delivered / accepted / rejected.
• Epics — Burnup e throughput per epic, un segnale di salute on-track / at-risk / stalled e una previsione dell’iterazione in cui l’epic si completa.

Chi ha fatto cosa, e quando, è la pagina separata Project History.

Temi

Quattro temi sono inclusi nella confezione:

• Labs — La palette originale di Pivotal Tracker — chrome scura, topbar PT blu, spaziature pastello tra le colonne. Conservata con affetto. Il default.
• 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. L’opzione principale nel selettore.
• 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 27 lingue: inglese, francese, tedesco, spagnolo, giapponese, cinese, coreano, portoghese, italiano, olandese, svedese, danese, ceco, finlandese, polacco, ucraino, russo, hindi, vietnamita, arabo, ebraico, singalese, tamil, indonesiano, malese, filippino, thai. Cambia dal piè di pagina della sidebar; la scelta persiste. La localizzazione copre l’intera app — ogni schermata è disponibile in ogni lingua, e la build fallisce se manca una traduzione.

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.