Introduction

East Agile Tracker est un outil de planification agile aux convictions affirmées sur la manière dont les équipes livrent du logiciel — et avec une idée inhabituelle sur la composition de l’équipe.

Les stories circulent dans une véritable machine à états XP. Les itérations se planifient toutes seules à partir de la vélocité. Un tableau vous montre exactement où en est le travail. Et aux côtés de vos coéquipiers humains, vous pouvez compter sur des agents — des participants IA nommés, dont le rôle est délimité, qui prennent en charge des stories, commentent, font transitionner les états, et laissent une piste d’audit lisible.

Cette page présente les concepts. Pour passer à l’action, voyez le Mode d’emploi.

Stories

Les stories sont l’unité fondamentale de travail. Il en existe quatre types, et la distinction est tout l’intérêt :

Feature — Nouvelle valeur pour les utilisateurs. Le seul type qui porte des points, le seul type qui contribue à la vélocité. C’est ce qui vous force à découper le travail en valeur observable par l’utilisateur.
Bug — Un défaut. Non estimé ; il suffit de le corriger. Les bugs ne rapportent aucun crédit, ce qui rend le coût des reprises visible plutôt que récompensé.
Chore — Travail de maintenance — refactorisations, montées de version de dépendances, infrastructure. Non estimé ; pas d’étape d’acceptation. L’équipe est incitée à regrouper les chores dans des features partout où c’est possible, pour que le cadrage par la valeur reste honnête.
Release — Un jalon à zéro point. Marque un déploiement ou un changement de version. Ancre une date pour la projection.

L’effet comportemental est ce qui compte : quand les bugs et les chores ne marquent pas de points, une équipe pousse naturellement à exprimer le travail sous forme de fonctionnalités orientées utilisateur, et elle devient pleinement consciente du coût des défauts. C’est une discipline de planification encodée dans le modèle de données — pas une règle dont vous devez vous souvenir.

Chaque story possède un titre, une description (en Markdown), des propriétaires, des suiveurs, des étiquettes, des tâches facultatives, des commentaires, des pièces jointes, des bloqueurs, des liens et des relectures. Le panneau de détail s’ouvre en ligne sur le tableau — pas de modal, pas de changement de contexte.

La machine à états et la boucle d’acceptation

Chaque story passe par des états. Le chemin exact dépend du type :

Type	Chemin
Feature	Unstarted → Started → Finished → Delivered → Accepted (ou Rejected)
Bug	Unstarted → Started → Finished → Delivered → Accepted (ou Rejected)
Chore	Unstarted → Started → Accepted
Release	Unstarted → Accepted

L’état critique est Delivered : un ingénieur marque une story comme livrée, mais elle n’est pas terminée tant que le product owner ne l’a pas explicitement acceptée au regard de ses critères d’acceptation — ou rejetée, ce qui la renvoie à Started. Cela inscrit une boucle de retour client dans chaque story plutôt que de reporter l’acceptation à une démo de fin de sprint. Les critères d’acceptation ont leur place sur la story avant qu’elle ne soit démarrée, idéalement sous forme Given/When/Then pour qu’ils se traduisent directement en tests d’acceptation. INVEST est le contrôle de bon sens pour savoir si une story est bien formée.

Vous pouvez avancer l’état depuis le bouton d’action en ligne de la carte, glisser la story dans un autre groupe d’itération, ou appeler l’API. Les transitions en arrière demandent confirmation pour éviter de perdre votre repère par accident.

Itérations

Le travail est organisé en itérations délimitées dans le temps (nous ne disons pas « sprints »). Chaque itération a une date de début, une durée (1 à 4 semaines selon le projet) et une capacité cible en points.

Vous ne remplissez pas les itérations à la main. Le système le fait pour vous, en s’appuyant sur votre vélocité — la moyenne des points achevés sur les itérations récentes — et la définition d’« état terminé » de votre projet (voir Vélocité, plus bas). Glissez les stories pour les réordonner ; les itérations se remplissent automatiquement.

Vélocité

La vélocité, c’est les points de features acceptées par itération. East Agile Tracker la calcule à partir de votre historique et l’utilise pour planifier la capacité de l’itération suivante.

Quelques éléments sont configurables par projet :

État terminé — quel état compte comme « terminé » pour la vélocité. La plupart des équipes choisissent Accepted ; certaines préfèrent Finished si leur cycle de livraison est découplé.
Stratégie — comment la vélocité est moyennée : les 3 dernières itérations, les 5 dernières, etc.
Vélocité initiale — une valeur de départ pour les nouveaux projets sans historique.

Le tableau : trois zones, une règle

Le tableau, c’est là où vit le travail. Trois zones, une règle :

Icebox — Le réservoir d’idées non priorisées. L’Icebox a le droit d’être un cimetière.
Backlog — Une liste strictement ordonnée, à priorité unique. Pas d’ex æquo. Pas de « P1/P1/P1 ». Le product owner est responsable de l’ordre de haut en bas. L’invariant : le haut du backlog est toujours le plus important et le mieux spécifié, la clarté décroissant légitimement à mesure que vous descendez. Une story proche du haut avec des critères d’acceptation flous est un bug de planification — pas un problème futur à ignorer.
Current — L’itération active. Les stories se rangent dans l’ordre de la séquence temporelle de l’itération, avec leur état (Unstarted / Started / Finished / Delivered / Accepted) visible sur chaque carte. L’ordre vous indique ce qui sera traité ensuite ; l’état vous indique où elle en est dans le cycle.

La colonne Current regroupe par en-tête d’itération (courante, puis à venir, puis closes) — et non par état. C’est délibéré : une itération Current est un plan de travail, pas une partition par état. Beaucoup de stories de l’itération sont Unstarted (certaines démarreront, d’autres seront reportées à l’itération suivante, d’autres seront abandonnées). Découper la colonne par état casse la séquence temporelle de l’itération dans laquelle l’équipe planifie réellement.

Depuis la section Board de la barre latérale, vous pouvez activer ou désactiver des colonnes supplémentaires (une case à cocher par préréglage) : Done, My Work, Blocked, Epics, Chat. Vous pouvez aussi enregistrer des panneaux de filtres personnalisés et redimensionner les colonnes comme vous voulez — votre disposition est mémorisée par projet et par navigateur.

Estimer

Vous estimez uniquement les features, avec des points relatifs — pas des heures. L’estimation est une conversation de dimensionnement, pas une promesse. Les bugs et les chores restent à zéro ; les pointer gonfle la vélocité en quelque chose qui ne veut plus rien dire, et la projection qui rend tout le système honnête s’écroule. La vélocité est un instrument de mesure ; on ne trafique pas son propre instrument.

East Agile Tracker propose trois échelles d’origine :

Fibonacci — 0, 1, 2, 3, 5, 8, 13. L’échelle XP classique. Tout ce qui dépasse 13 doit être découpé en stories plus petites.
East Agile — 0, 1, 2, 3. Une échelle plus resserrée que nous utilisons nous-mêmes. Décourage la sur-réflexion ; rien au-dessus de 3 n’a sa place dans une seule itération.
3 points — 1, 2, 3 (Small / Medium / Large). Un dimensionnement strict en tailles de t-shirt pour les équipes qui veulent une granularité minimale.

Choisissez l’échelle par projet. Vous pouvez en changer plus tard — les estimations existantes sont reportées par mappage.

Le bénéfice d’une estimation disciplinée : la projection de date de livraison devient un calcul, pas une négociation. La conversation avec les parties prenantes passe de « pouvez-vous vous engager sur X pour vendredi » à « à la vélocité actuelle, cette release atterrit autour de la date Y — voici l’arbitrage portée/date ».

Étiquettes

Les étiquettes sont des tags colorés. Une story peut en porter plusieurs. Vous les gérez sur la page Labels — couleurs, noms, archivage lorsqu’elles sont obsolètes.

Recherche et filtres

La recherche utilise une syntaxe de filtres simple qui se compose naturellement :

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

Filtres courants : type:, state:, label:"avec espaces", owner:, requester:, has:blocker, is:unestimated, plus du texte libre sur le titre et la description. Enregistrez des filtres comme panneaux nommés sur le tableau.

Propriétaires, suiveurs, demandeur

Propriétaires — Qui fait le travail. Plusieurs possibles.
Suiveurs — Les personnes intéressées par les mises à jour. Plusieurs possibles.
Demandeur — Qui a demandé la story. En général une seule personne.

Chacun de ces emplacements peut être rempli par un membre humain ou par un agent. La carte de la story affiche les avatars des propriétaires ; les propriétaires-agents reçoivent un traitement visuel distinct, pour qu’il soit toujours clair qui a réellement fait quoi.

Les agents — coéquipiers de plein droit

C’est la partie que la plupart des trackers n’ont pas, et celle que nous avons construite délibérément.

Un agent est un participant nommé d’un projet — comme un membre, mais c’est une IA. Il possède sa propre identité, son propre rôle (viewer / member / owner — le rôle owner est réservé aux humains), et sa propre piste d’audit. Quand un agent fait transitionner une story, le journal d’activité indique que c’est l’agent qui l’a fait. Quand un agent commente, le commentaire est signé par l’agent. Pas d’humains fantômes sur les écritures d’agents.

Les agents s’authentifient avec des clés d’API d’agent (ea_agent_*), créées par projet. Révoquez un agent et l’accès meurt avec la clé ; l’historique de l’agent reste à jamais dans le journal d’audit, pour que vous sachiez toujours ce qui s’est passé.

Pour aller plus loin, voir Mode d’emploi → Agents et le Guide de l’API.

Commentaires, pièces jointes, bloqueurs, liens, relectures

Commentaires — Markdown, jusqu’à 10 000 caractères. Filés sous la story.
Pièces jointes — Fichiers, vidéos comprises, jusqu’à 2 Go chacun.
Bloqueurs — Notes en texte libre « ce qui bloque ça », marquées résolues/non résolues.
Liens — Connectez les stories entre elles (blocks, is blocked by, duplicates, relates to) ou à des URL externes (les PR et branches GitHub sont détectées automatiquement).
Relectures — Assignez un relecteur (humain ou agent), obtenez une approbation ou un rejet.

Analyses

Au-delà du tableau, l’onglet Analytics propose :

Project Overview — Vélocité, taux d’acceptation, temps de cycle, KPI des itérations récentes.
Iteration Report — Détail par itération.
Releases & Burndowns — Jalons de releases et burndown par itération.
Story Activity — Qui a fait quoi, quand (filtrable).
Cycle Time — Temps entre Started et l’état terminé de votre projet.
Projections — Prévision de la date à laquelle votre backlog sera terminé à la vélocité actuelle.

Thèmes

Quatre thèmes sont fournis d’origine :

Agile — La palette de la page d’accueil marketing. Blancs chauds, accent de marque bleu profond (#1f6f9f), icônes de type de story saturées or/rouge/ardoise/violet. Le thème par défaut pour les nouveaux visiteurs et l’option principale du sélecteur.
Labs — La palette originale de Pivotal Tracker — chrome sombre, barre supérieure bleu PT, pastels entre colonnes. Amoureusement préservée.
Dark — Sombre neutre pur, sans teinte.
Light — Lumineux neutre pur, sans teinte. De l’encre sur le papier.

Basculez depuis le pied de la barre latérale ou dans Account Settings → Theme. Votre choix est mémorisé d’une session à l’autre.

Langues

L’interface est traduite en 15 langues : anglais, français, allemand, espagnol, japonais, chinois, coréen, portugais, italien, néerlandais, suédois, danois, tchèque, finnois, polonais. Basculez depuis le pied de la barre latérale ; le choix est mémorisé. L’interface, les pages d’authentification, l’espace compte/sécurité et la page d’accueil marketing sont câblés aujourd’hui ; la localisation du détail des stories / des analyses / des paramètres suit dans les mises à jour ultérieures.

La suite

Prendre l’outil en main : Mode d’emploi.
Lecture de fond : Qu’est-ce que le développement agile ? et eXtreme Programming.
Construire par-dessus : Guide de l’API et Spécification de l’API.