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 :

• Feature — Nouvelle valeur pour les utilisateurs. Par défaut, le seul type qui porte des points et le seul type qui contribue à la vélocité.
• Bug — Un défaut. Non estimé par défaut ; 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é par défaut ; pas d’étape d’acceptation.
• 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. Un projet qui veut malgré tout compter les bugs et les chores peut activer Points for bugs and chores dans Project Settings ; ils reçoivent alors des estimations et alimentent la vélocité comme des features.

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, puis le product owner l’accepte au regard de ses critères d’acceptation, ou la rejette. Rejected est un état terminal de la machine à états ; le chemin du retour est une action Restart distincte, qui remet la story à Started. Rejeter une story située dans une itération passée crée à la place une copie en haut du Backlog, pour que la reprise soit planifiée plutôt qu’enterrée. Cela inscrit une boucle de retour client dans chaque story plutôt que de reporter l’acceptation à une démo de fin de sprint. Il n’y a pas de champ distinct pour les critères d’acceptation — ils ont leur place dans la description avant que la story 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, ou appeler l’API. Glisser une carte la déplace d’un panneau à l’autre — de l’Icebox au Backlog, du Backlog à Current. Un dépôt dans Current laisse son état inchangé ; un dépôt dans le Backlog ou l’Icebox la remet à Unstarted.

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 ; l’itération courante se remplit automatiquement.

Vélocité

La vélocité est le nombre de points terminés par itération ; une story compte dès qu’elle atteint l’état terminé du projet. 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é. Les options sont Finished, Delivered et Accepted.
• Stratégie — comment la vélocité est moyennée : les 3, 5 ou 10 dernières itérations, ou une valeur manuelle qui remplace entièrement le calcul.
• 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.
• 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.
• 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 est une seule itération sous un seul en-tête — et non un ensemble de compartiments 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. Les itérations closes vivent dans la colonne Done, et les itérations à venir projetées à partir du Backlog n’apparaissent sous Current que lorsque vous activez son bouton Show Backlog stories.

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, Archived. Une colonne Chat est également listée ; c’est un aperçu statique avec des messages fictifs, pas un chat fonctionnel. Une recherche s’ouvre dans sa propre colonne, et votre ensemble de colonnes est stocké côté serveur par membre et par projet, il vous suit donc d’un navigateur à l’autre.

Estimer

Par défaut, vous estimez 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 non estimés, sauf si le projet active Points for bugs and chores ; ils prennent alors des estimations et comptent dans la vélocité comme les features.

East Agile Tracker propose trois échelles d’origine :

• Fibonacci — 0, 1, 2, 3, 5, 8, 13. L’échelle XP classique.
• East Agile — 0, 1, 2, 3. Une échelle plus resserrée que nous utilisons nous-mêmes.
• 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, mais les estimations existantes ne sont pas remappées : chaque story garde son ancienne valeur, et une valeur absente de la nouvelle échelle reste sur la story jusqu’à ce que vous la ré-estimiez.

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 à la GitHub qui se compose naturellement :

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

Qualificateurs : type:, state:, label:"avec espaces", epic:, priority:, points: (une valeur ou une plage comme 1..5), iteration:, les qualificateurs de personnes owner:, requester:, follower:, reviewer:, commenter:, mention: (membres et agents ; @me, c’est vous), les qualificateurs de dates created:, updated:, started:, completed:, release: (un jour ou une plage), et les drapeaux has:blocker, is:unestimated, is:icebox, is:backlog, is:blocked — plus du texte libre sur le titre, la référence et la description. Séparez les alternatives d’une facette par des virgules (type:bug,chore), niez n’importe quoi avec un - en tête, et triez par pertinence, date de création ou date de mise à jour. Lancer une recherche ouvre une colonne de résultats qui reste sur votre tableau. La grammaire complète est dans le Guide de l’API → Recherche.

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 / manager — le rôle d’un agent ne peut jamais dépasser celui de son créateur, seul un manager humain peut donc créer un agent de rôle manager), 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’à 20 000 caractères. Une liste à plat sous la story, chacun avec des réactions emoji et un permalien.
• Pièces jointes — Fichiers, vidéos comprises. Les plafonds dépendent du type : vidéo 200 Mo, PDF / Word / Excel 25 Mo, images / CSV / texte 10 Mo.
• 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 (pull request, branch ou other ; les URL de PR et de branches GitHub sont détectées automatiquement).
• Relectures — Assignez un relecteur (humain ou agent), obtenez une approbation ou un rejet.

Métriques

Au-delà du tableau, la page Metrics du projet propose trois onglets :

• General — Tendance de la vélocité, burndown de l’itération courante, répartition par type de story par itération, les cartes Committed / Completed / Carried-over, et les stories reportées depuis des itérations antérieures.
• Contributors — Points et stories par membre ou agent sur une période, avec les décomptes delivered / accepted / rejected.
• Epics — Burnup et débit par epic, un signal de santé on-track / at-risk / stalled, et une prévision de l’itération dans laquelle l’epic se termine.

Qui a fait quoi, quand, c’est la page Project History, distincte.

Thèmes

Quatre thèmes sont fournis d’origine :

• Labs — La palette originale de Pivotal Tracker — chrome sombre, barre supérieure bleu PT, pastels entre colonnes. Amoureusement préservée. Le thème par défaut.
• 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. L’option principale du sélecteur.
• 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 27 langues : anglais, français, allemand, espagnol, japonais, chinois, coréen, portugais, italien, néerlandais, suédois, danois, tchèque, finnois, polonais, ukrainien, russe, hindi, vietnamien, arabe, hébreu, cingalais, tamoul, indonésien, malais, filipino, thaï. Basculez depuis le pied de la barre latérale ; le choix est mémorisé. La localisation couvre toute l’application — chaque écran est livré dans chaque langue, et la compilation échoue sur une traduction manquante.

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.