Introducción

East Agile Tracker es una herramienta de planificación ágil con opiniones firmes sobre cómo los equipos entregan software — y una idea poco común sobre quién forma parte del equipo.

Las historias fluyen a través de una auténtica máquina de estados de XP. Las iteraciones se planifican solas a partir de la velocidad. Un tablero te muestra exactamente dónde está el trabajo. Y junto a tus compañeros humanos, puedes tener agentes — participantes de IA con nombre propio y acotados por rol, que toman historias, comentan, transicionan estados y dejan un registro de auditoría que puedes leer.

Esta página cubre los conceptos. Para hacer cosas, consulta las Instrucciones de uso.

Historias

Las historias son la unidad fundamental de trabajo. Hay cuatro tipos:

• Feature — Nuevo valor para los usuarios. De forma predeterminada, el único tipo que lleva puntos y el único tipo que contribuye a la velocidad.
• Bug — Un defecto. Sin estimar de forma predeterminada; simplemente hay que corregirlo. Los bugs no ganan crédito, lo que hace visible el coste del retrabajo en lugar de premiarlo.
• Chore — Trabajo de mantenimiento — refactorizaciones, actualizaciones de dependencias, infraestructura. Sin estimar de forma predeterminada; sin puerta de aceptación.
• Release — Un hito de cero puntos. Marca un despliegue o un cambio de versión. Ancla una fecha para la proyección.

El efecto en el comportamiento es lo que importa: cuando los bugs y los chores no puntúan, un equipo tiende de forma natural a expresar el trabajo como funcionalidad orientada al usuario, y se vuelve muy consciente del coste de los defectos. Eso es una disciplina de planificación codificada en el modelo de datos — no una directriz que tengas que recordar. Un proyecto que quiera que los bugs y los chores cuenten de todos modos puede activar Points for bugs and chores en Project Settings; a partir de entonces admiten estimaciones y alimentan la velocidad como las features.

Cada historia tiene un título, una descripción (Markdown), owners, followers, etiquetas, tareas opcionales, comentarios, adjuntos, bloqueadores, enlaces y revisiones. El panel de detalle se abre en línea en el tablero — sin modal, sin cambio de contexto.

La máquina de estados y el bucle de aceptación

Cada historia avanza por una serie de estados. La ruta exacta depende del tipo:

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

El estado crítico es Delivered: un ingeniero marca una historia como entregada y, a continuación, el product owner la acepta frente a sus criterios de aceptación o la rechaza. Rejected es terminal en la máquina de estados; el camino de vuelta es una acción Restart aparte, que vuelve a poner la historia en Started. Rechazar una historia que está en una iteración pasada crea en cambio una copia en la parte superior del Backlog, de modo que el retrabajo se planifica en lugar de quedar enterrado. Esto incorpora un bucle de retroalimentación del cliente en cada historia, en lugar de aplazar la aceptación a una demo de fin de sprint. No hay un campo aparte para los criterios de aceptación — los criterios deben estar en la descripción antes de que se inicie la historia, idealmente en forma Given/When/Then para que se correspondan directamente con las pruebas de aceptación. INVEST es la comprobación de cordura sobre si una historia está bien formada.

Puedes avanzar de estado desde el botón de acción en línea de la tarjeta o llamando a la API. Arrastrar una tarjeta la mueve entre paneles — de Icebox a Backlog, de Backlog a Current. Soltarla en Current deja su estado intacto; soltarla en Backlog o en Icebox la devuelve a Unstarted.

Iteraciones

El trabajo se organiza en iteraciones acotadas en el tiempo (no decimos “sprints”). Cada iteración tiene una fecha de inicio, una duración (1–4 semanas por proyecto) y una capacidad objetivo en puntos.

No empaquetas las iteraciones manualmente. El sistema lo hace por ti, usando tu velocidad — el promedio de los puntos completados en las iteraciones recientes — y la definición de “estado terminado” de tu proyecto (ver Velocidad, más abajo). Arrastra historias para reordenarlas; la iteración actual se rellena automáticamente.

Velocidad

La velocidad es la cantidad de puntos completados por iteración; una historia cuenta en cuanto alcanza el estado de finalización del proyecto. East Agile Tracker la calcula a partir de tu historial y la usa para planificar la capacidad de la siguiente iteración.

Algunas cosas se pueden configurar por proyecto:

• Estado terminado — qué estado cuenta como “terminado” para la velocidad. Las opciones son Finished, Delivered y Accepted.
• Estrategia — cómo se promedia la velocidad: las últimas 3, 5 o 10 iteraciones, o un valor manual que anula el cálculo por completo.
• Velocidad inicial — un valor de partida para proyectos nuevos que aún no tienen historial.

El tablero: tres zonas, una regla

El tablero es donde vive el trabajo. Tres zonas, una regla:

• Icebox — La reserva de ideas sin priorizar.
• Backlog — Una lista estrictamente ordenada, de prioridad única. Sin empates. Nada de “P1/P1/P1”. El product owner es dueño del orden de arriba abajo. La invariante: la parte superior del backlog siempre es lo más importante y mejor especificado, y la claridad disminuye legítimamente a medida que bajas.
• Current — La iteración activa. Las historias se sitúan en orden de secuencia temporal de la iteración, con su estado (Unstarted / Started / Finished / Delivered / Accepted) visible en cada tarjeta. El orden te dice qué se trabajará a continuación; el estado te dice en qué punto del ciclo está.

La columna Current es una única iteración bajo una única cabecera — no un conjunto de cubos por estado. Eso es deliberado: una iteración Current es un plan de trabajo, no una partición por estado. Muchas historias de la iteración están en Unstarted (algunas se empezarán, algunas pasarán a la siguiente iteración, algunas se descartarán). Trocear la columna por estado rompe la secuencia temporal de la iteración en la que el equipo planifica de verdad. Las iteraciones cerradas viven en la columna Done, y las próximas iteraciones proyectadas a partir del Backlog aparecen bajo Current solo cuando activas su interruptor Show Backlog stories.

Desde la sección Board de la barra lateral puedes activar o desactivar columnas adicionales (una casilla por preconfiguración): Done, My Work, Blocked, Epics, Archived. También aparece una columna Chat; es una vista previa estática con mensajes de relleno, no un chat operativo. Una búsqueda se abre en su propia columna, y tu conjunto de columnas se guarda en el servidor por miembro y por proyecto, de modo que te sigue entre navegadores.

Estimar

De forma predeterminada estimas las features, usando puntos relativos — no horas. La estimación es una conversación de dimensionamiento, no una promesa. Los bugs y los chores quedan sin estimar salvo que el proyecto active Points for bugs and chores; entonces admiten estimaciones y cuentan para la velocidad como las features.

East Agile Tracker incluye tres escalas de fábrica:

• Fibonacci — 0, 1, 2, 3, 5, 8, 13. La escala clásica de XP.
• East Agile — 0, 1, 2, 3. Una escala más ajustada que usamos nosotros mismos.
• 3 puntos — 1, 2, 3 (Pequeña / Mediana / Grande). Dimensionamiento estricto por tallas para equipos que quieren la granularidad mínima.

Elige la escala por proyecto. Puedes cambiar de escala más adelante, pero las estimaciones existentes no se reasignan: cada historia conserva su valor anterior, y un valor que la nueva escala no tiene permanece en la historia hasta que la vuelvas a estimar.

La recompensa de una estimación disciplinada: la proyección de la fecha de release se convierte en un cálculo, no en una negociación. La conversación con las partes interesadas pasa de “¿puedes comprometerte a X para el viernes?” a “a la velocidad actual, esta release aterriza alrededor de la fecha Y — este es el equilibrio entre alcance y fecha”.

Etiquetas

Las etiquetas son rótulos de colores. Las historias pueden tener varias. Las gestionas en la página Labels — colores, nombres, archivado cuando quedan obsoletas.

Búsqueda y filtros

La búsqueda usa una sintaxis de filtros al estilo de GitHub que se compone con naturalidad:

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

Calificadores: type:, state:, label:"con espacios", epic:, priority:, points: (un valor o un rango como 1..5), iteration:, los calificadores de personas owner:, requester:, follower:, reviewer:, commenter:, mention: (miembros y agentes; @me eres tú), los calificadores de fecha created:, updated:, started:, completed:, release: (un día o un rango) y los indicadores has:blocker, is:unestimated, is:icebox, is:backlog, is:blocked — además de texto libre sobre el título, la referencia y la descripción. Separa alternativas con comas dentro de una faceta (type:bug,chore), niega cualquier cosa con un - inicial y ordena por relevancia, creación o actualización. Al ejecutar una búsqueda se abre una columna de resultados que se queda en tu tablero. La gramática completa está en la Guía de la API → Búsqueda.

Owners, followers, solicitante

• Owners — Quién está haciendo el trabajo. Pueden ser muchos.
• Followers — Personas a las que les importan las actualizaciones. Pueden ser muchos.
• Solicitante (Requestor) — Quién pidió la historia. Normalmente uno.

Cada una de estas casillas puede ocuparla un miembro humano o un agente. La tarjeta de la historia muestra los avatares de los owners; los owners que son agentes reciben un tratamiento visual distinto, de modo que siempre queda claro quién hizo realmente qué.

Agentes — compañeros de equipo de primera clase

Esta es la parte que la mayoría de los trackers no tienen, y la parte que construimos a propósito.

Un agente es un participante con nombre propio en un proyecto — como un miembro, pero es una IA. Tiene su propia identidad, su propio rol (viewer / member / manager — el rol de un agente nunca puede superar el de su creador, así que solo un manager humano emite un agente con rol manager) y su propio registro de auditoría. Cuando un agente transiciona una historia, el registro de actividad dice que lo hizo el agente. Cuando un agente comenta, el comentario está firmado por el agente. No hay humanos fantasma en las escrituras de los agentes.

Los agentes se autentican con claves de API de agente (ea_agent_*), emitidas por proyecto. Revoca un agente y el acceso muere con la clave; el historial del agente permanece en el registro de auditoría para siempre, de modo que siempre sabes qué ocurrió.

Lee más en Instrucciones de uso → Agentes y en la Guía de la API.

Comentarios, adjuntos, bloqueadores, enlaces, revisiones

• Comentarios — Markdown, hasta 20.000 caracteres. Una lista plana bajo la historia, cada uno con reacciones emoji y un enlace permanente.
• Adjuntos — Archivos, incluido vídeo. Los límites dependen del tipo: vídeo 200 MB, PDF / Word / Excel 25 MB, imágenes / CSV / texto 10 MB.
• Bloqueadores — Notas libres del tipo “qué está bloqueando esto”, marcadas como resueltas/no resueltas.
• Enlaces — Conecta historias entre sí (blocks, is blocked by, duplicates, relates to) o con URLs externas (pull request, branch u other; las URLs de PRs y ramas de GitHub se detectan automáticamente).
• Revisiones — Asigna un revisor (humano o agente), obtén aprobación/rechazo.

Métricas

Más allá del tablero, la página Metrics del proyecto tiene tres pestañas:

• General — Tendencia de la velocidad, el burndown de la iteración actual, la mezcla de tipos de historia por iteración, las tarjetas Committed / Completed / Carried-over y las historias arrastradas desde iteraciones anteriores.
• Contributors — Puntos e historias por miembro o agente durante un periodo, con recuentos de entregadas / aceptadas / rechazadas.
• Epics — Burnup y rendimiento por epic, una señal de salud on-track / at-risk / stalled y un pronóstico de la iteración en la que el epic se completa.

Quién hizo qué y cuándo está en la página aparte Project History.

Temas

Cuatro temas vienen de fábrica:

• Labs — La paleta original de Pivotal Tracker — cromo oscuro, barra superior azul PT, separaciones de columna en pastel. Conservada con cariño. El predeterminado.
• Agile — La paleta de la landing de marketing. Blancos cálidos, acento de marca azul intenso (#1f6f9f), iconos de tipo de historia en dorado/rojo/pizarra/púrpura saturados. La opción principal del selector.
• Dark — Oscuro neutro puro, sin matiz.
• Light — Claro neutro puro, sin matiz. Tinta sobre papel.

Cambia en el pie de la barra lateral o en Account Settings → Theme. Tu elección persiste entre sesiones.

Idiomas

La interfaz está traducida a 27 idiomas: inglés, francés, alemán, español, japonés, chino, coreano, portugués, italiano, neerlandés, sueco, danés, checo, finés, polaco, ucraniano, ruso, hindi, vietnamita, árabe, hebreo, cingalés, tamil, indonesio, malayo, filipino, tailandés. Cambia desde el pie de la barra lateral; la elección persiste. La localización abarca toda la aplicación — cada pantalla se entrega en todos los idiomas, y la compilación falla si falta una traducción.

Qué sigue

• Manos a la obra con el producto: Instrucciones de uso.
• Lectura de fondo: ¿Qué es el desarrollo ágil? y eXtreme Programming.
• Construye algo encima: Guía de la API y Especificación de la API.