Ir al contenido

Instrucciones de uso

Una guía de usuario completa. Para los conceptos, consulta la Introducción.

Regístrate en eastagiletracker.com/register con un correo electrónico y una contraseña, o continúa con GitHub si prefieres OAuth. Verifica tu correo electrónico desde el enlace que te enviamos; hasta entonces puedes iniciar sesión, pero algunas funciones están limitadas.

Si te han invitado a un proyecto o a una organización, sigue el enlace del correo de invitación — se crea tu cuenta (o inicias sesión) y aterrizas directamente en el tablero correspondiente.

¿Olvidaste tu contraseña? Usa Forgot Password en la pantalla de inicio de sesión; te enviamos por correo un enlace para restablecerla.

Desde el avatar arriba a la derecha → Account Settings:

  • Profile — Nombre visible, iniciales (se usan en los avatares de owners), correo electrónico.
  • Bio — Una breve descripción de ti mismo (hasta 4 KiB). Aparece en /me y en los listados de miembros de la organización, para que un agente (o un compañero) pueda elegir a la persona adecuada a quien preguntar. Déjala en blanco para no participar.
  • Password — Cámbiala cuando quieras.
  • Avatar — Sube una imagen o quédate con tus iniciales.
  • API Keys — Crea tokens de API personales; consulta la Guía de la API.
  • Theme — Agile, Labs, Dark o Light (también se puede cambiar desde la barra lateral).
  • Delete Account — Una confirmación en dos pasos. Te elimina de todas las organizaciones y proyectos.

Desde el avatar arriba a la derecha → Security:

  • Doble factor (TOTP) — Configura un código desde cualquier aplicación de autenticación (1Password, Authy, Google Authenticator, …). Obtén 10 códigos de recuperación de un solo uso — se muestran una vez, así que guárdalos. Desactívalo más adelante con un código actual o un código de recuperación.
  • Passkeys — Añade una passkey WebAuthn vinculada al dispositivo (Touch ID, Windows Hello, llave de seguridad por hardware). Después inicia sesión sin contraseña. Añade, nombra y elimina llaves desde la misma página.

Un inicio de sesión correcto emite dos tokens: un JWT de acceso de corta duración y un refresh token de larga duración (30 días, rotado en cada uso). La SPA refresca el token de acceso automáticamente cuando expira; permaneces con la sesión iniciada hasta que el refresh token expire o cierres sesión. El cierre de sesión revoca el refresh token en el servidor, de modo que una copia robada no puede reproducirse.

La mayoría de las cuentas son Free Forever para uso personal. Si tu cuenta tiene un saldo de crédito medido, lo encuentras en Account → Billing — recarga vía el checkout de Paddle y consulta el historial de transacciones.

Cada cuenta pertenece a una o más organizaciones. Un registro nuevo recibe una organización personal (“Organización de <Nombre>”) creada automáticamente, al estilo de Linear/Vercel. Los proyectos viven dentro de las organizaciones, y la membresía en la organización condiciona la membresía en el proyecto.

Haz clic en el selector de organización de la barra superior para alternar entre las organizaciones a las que perteneces. La organización activa tiñe la barra lateral, acota la lista de “Projects” y queda preseleccionada cuando creas un proyecto nuevo.

Haz clic en el bloque de la organización en la barra lateral → Manage organization → aterrizas en /organization/{id}/projects. La barra lateral muestra tres pestañas de administración:

  • Projects — Todos los proyectos de esta organización.
  • Members — Miembros actuales, roles e invitaciones pendientes. Invita por correo electrónico; la invitación queda fijada a ese correo con un token con TTL y un techo de rol (los miembros no pueden invitar a administradores).
  • Settings (solo owners) — Nombre de la organización, slug, plan. Aquí transfieres la propiedad a otro miembro.

Eliminar a un miembro de una organización se propaga en cascada: sus membresías por proyecto en los proyectos de esa organización se revocan en la misma transacción. Las URLs de tablero guardadas como marcadores dejan de funcionar en el momento en que pierden el acceso a la organización — no queda ningún rastro huérfano.

Desde la página Projects, haz clic en New Project. El formulario de creación solo pide dos cosas:

  • Title — Obligatorio.
  • Description — Opcional; visible para todos los miembros.

Todo lo demás — duración de la iteración, día de inicio, velocidad inicial, escala de estimación, estado terminado, conmutador de tareas — se configura más adelante en Project Settings y se inicializa con valores por defecto razonables.

En el menú Settings del proyecto, cuatro pestañas:

  • Project — Edita título, descripción, duración y día de inicio de iteración, estrategia de velocidad (promedio de las últimas 3 / 5 / 10), estado terminado, escala de estimación, conmutador de tareas.
  • Member — Invita, promueve/degrada y elimina miembros humanos (ver Miembros e invitaciones, más abajo).
  • Agent — Emite y revoca claves de API de agente para este proyecto (ver Agentes, más abajo). Solo owners.
  • Import — Trae historias desde otro tracker (ver Importar desde otros trackers, más abajo).

En la pestaña Member de Project Settings, invita a personas por correo electrónico. Las invitaciones pendientes quedan en un cubo separado hasta que se aceptan; ves quién ha sido invitado y puedes reenviar o revocar. A los miembros activos puedes promoverlos o degradarlos entre viewer, member y owner. Los owners pueden cambiar la configuración del proyecto; los viewers pueden leer pero no escribir.

El historial del proyecto está en su propia página — cada cambio en la configuración del proyecto, cada cambio de membresía, con el actor (humano o agente).

Usa la opción + Add story en cualquier panel del tablero (Current, Backlog, Icebox o uno personalizado) — escribe un título y pulsa Enter.

Las historias nuevas creadas en Current quedan por defecto en current_state = 'unstarted'. Eso es paridad con PT: una iteración Current es un plan de trabajo, no una partición por estado. El owner inicia la historia explícitamente cuando empieza el trabajo — el reloj del tiempo de ciclo no se pone en marcha hasta entonces.

Obligatorio: título. Elige un tipo (por defecto feature). Añade descripción, estimación (solo features), etiquetas, owners, followers, bloqueadores — cualquiera de estos campos se puede rellenar después desde el panel de detalle.

¿Pulsaste Enter dos veces seguidas rápido? Sin problema — el botón está protegido; obtienes exactamente una historia.

Las features son el único tipo que recibe puntos. Haz clic en el círculo de puntos de la tarjeta (o en el panel de detalle) y elige un valor de la escala. Las features sin estimar muestran un círculo en blanco.

  • Escala Fibonacci0, 1, 2, 3, 5, 8, 13. Estándar de XP. Cualquier cosa mayor que 13 debería partirse en historias más pequeñas.
  • Escala East Agile0, 1, 2, 3. Más ajustada. Un 3 significa una iteración completa del tiempo de una persona. Nada cabe por encima de 3.
  • Escala de 3 puntos1, 2, 3 (Pequeña / Mediana / Grande). Dimensionamiento estricto por tallas — sin opción de cero, sin medios puntos.

Elige la escala una sola vez en Project Settings; puedes cambiarla más adelante (las estimaciones existentes se mapean automáticamente).

Tres maneras de mover una historia a lo largo del ciclo de vida:

  1. Haz clic en el botón de acción en línea de la tarjeta — Start, Finish, Deliver, Accept, Reject. El texto del botón refleja el siguiente estado válido para el tipo de la historia.
  2. Arrastra la tarjeta a otra columna. El sistema aplica la transición que implica cruzar esa columna. Los movimientos hacia atrás piden confirmación.
  3. Transición masiva — Selecciona varias historias, Transition all — cada historia transiciona de forma independiente. Si una es ilegal, las demás siguen adelante.

Haz clic en cualquier punto de la fila de una historia para expandirla en línea. El panel de detalle muestra:

  • Título (editable), descripción (Markdown), tipo, estimación, solicitante.
  • Owners (añade/quita miembros o agentes), followers, etiquetas.
  • Tareas (si están habilitadas), comentarios, adjuntos, bloqueadores, enlaces, revisiones.
  • Un menú de 3 puntos para duplicar, eliminar y otras acciones menos comunes.

Pulsa Escape para cerrar la historia abierta más recientemente (recuerda la pila — colapsa una a una).

Hasta 10.000 caracteres, renderizado en Markdown. Puedes editar y eliminar tus propios comentarios; el registro de auditoría guarda el historial. Menciona miembros con @ y el autocompletado los recoge.

Arrastra un archivo al panel de detalle o usa el botón de subida. Hasta 2 GB por archivo — sí, lo bastante grande para vídeos walkthrough de grabación de pantalla. Usa el reproductor de vídeo en línea.

Desde la página Labels en la barra lateral: crea etiquetas con nombre y color, archívalas cuando dejen de usarse (las etiquetas archivadas desaparecen del tablero pero siguen siendo buscables). Añade etiquetas por historia en el panel de detalle.

  • Bloqueadores — Una nota libre del tipo “esto está bloqueado por X”. Márcala como resuelta/no resuelta. Filtra el tablero por has:blocker.
  • Enlaces — Seis tipos de relación: relates to, duplicates, blocks, is blocked by, pull request, branch. Pega una URL de GitHub y el tipo se detecta automáticamente.
  • Revisiones — Asigna un revisor (humano o agente) con un estado (pending, approved, rejected) y un comentario opcional.

Si están habilitadas en Project Settings, las historias incorporan subtareas — una lista de verificación dentro de la historia. Márcalas a medida que avanzas; el recuento aparece en la tarjeta.

Cada variable de elección en la superficie de detalle de la historia lleva un pequeño icono [?] junto a su etiqueta. Haz clic en él dentro de la aplicación para ver la misma orientación que se resume a continuación. Los traductores entregan el texto de la aplicación junto con el resto de la interfaz; esta sección es la referencia canónica en formato largo.

Los campos se enumeran en el orden en que aparecen en la pestaña Overview.

El lugar de la historia en el ciclo de vida: Unstarted → Started → Finished → Delivered → Accepted (o Rejected de vuelta a Started).

El estado crítico es Delivered: el ingeniero la marca como entregada, pero no está terminada hasta que el product owner la acepta explícitamente frente a los criterios de aceptación — o la rechaza, devolviéndola. 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.

Si las historias se acumulan en Delivered, eso es una señal de que el bucle de aceptar/rechazar se ha estancado. Mira el recuento de Delivered al final de cada iteración — si está creciendo, esa es tu señal de que el product owner está infradotado de recursos o los criterios de aceptación no son lo bastante claros de antemano.

En qué iteración está planificada la historia. Déjalo en None para mantener la historia en el Backlog, donde el sistema la agrupará automáticamente bajo una próxima iteración en función de la velocidad.

La anulación manual aquí es útil cuando quieres fijar una historia a una iteración concreta sin importar el orden — p. ej., atar una historia de release a una fecha fija. Por lo demás, deja que el orden en el Backlog dirija la asignación de iteraciones; eso es lo que mantiene honesta la proyección de velocidad.

Quién está haciendo el trabajo. Los owners pueden ser humanos o agentes — ambos se representan como participantes con nombre propio en el registro de auditoría, la autoría de comentarios y la analítica. No hay forma de disfrazar a un owner que es agente como humano.

Tener varios owners es la expresión visible de la programación en parejas (o emparejamiento con agente). Añade el agente que tomó la historia y el humano que la revisa — ambos nombres aparecen en la tarjeta. Esto mantiene bajo el trabajo en curso; terminar antes de empezar la siguiente historia es la mayor palanca sobre el tiempo de ciclo.

Los owners no son lo mismo que los Followers (un campo aparte en la tarjeta). Los followers son personas a las que les importa la historia pero no están haciendo el trabajo — normalmente suscriptores de notificaciones.

Los cuatro tipos no son intercambiables — la distinción es justo de lo que se trata todo el modelo de datos.

  • Feature — Nuevo valor observable por el usuario. El único tipo que lleva puntos y cuenta para la velocidad. Esto te obliga a trocear el trabajo en valor que el usuario pueda ver.
  • Bug — Un defecto. Sin puntos. Los defectos no ganan crédito de velocidad, lo que mantiene visible el coste del retrabajo en lugar de premiarlo.
  • Chore — Trabajo necesario sin valor directo para el usuario (refactorizaciones, infraestructura, configuración). Sin puntos. Se presiona al equipo para que agrupe los chores dentro de features siempre que sea posible, de modo que el marco de valor siga siendo honesto.
  • Release — Un marcador de cero puntos para un hito. Va directo de Unstarted a Accepted, anclando una fecha para la proyección.

Si te ves con ganas de puntuar un bug o un chore: no lo hagas. Eso rompe la proyección que mantiene honesto a todo el sistema. La velocidad es un instrumento de medición; no manipulas tu propio instrumento.

No uses esto si puedes evitarlo. El Backlog es la prioridad — de arriba abajo, de prioridad única, sin empates. El product owner es dueño del orden.

Un campo de “prioridad” es el clásico antipatrón que convierte calladamente un backlog empírico y ordenado de nuevo en planificación ilusoria. Si te encuentras con tres P1, no tienes una prioridad — tienes un Backlog con el orden equivocado. Arregla el orden; elimina la señal de prioridad.

El campo existe por compatibilidad con las importaciones de trackers que usan uno (Jira, Asana, …), para que las historias importadas no pierdan información al entrar. Déjalo en “None” en el trabajo nuevo.

Tamaño relativo de la historia. Las features llevan puntos; los bugs, los chores y las releases se quedan en cero.

La estimación es una conversación de dimensionamiento, no una promesa. No traduzcas los puntos a horas; no infles los puntos para parecer rápido. La velocidad es un instrumento de medición — no manipulas tu propio instrumento.

Vienen tres escalas:

  • Fibonacci0, 1, 2, 3, 5, 8, 13. La escala clásica de XP. Cualquier cosa mayor que 13 debería dividirse.
  • East Agile0, 1, 2, 3. Una escala más ajustada. Un 3 significa una iteración completa del tiempo de una persona.
  • 3 puntos1, 2, 3 (Pequeña / Mediana / Grande). Dimensionamiento estricto por tallas.

Si estimas a menudo en 5, 8 o 13, tus historias son demasiado grandes. Divídelas hasta que cada una sea entregable de forma independiente (la S y la I de INVEST).

Quién pidió la historia. Normalmente una persona — el product owner, una parte interesada o un agente actuando en nombre de alguien.

El solicitante no es el owner. El owner es quien hace el trabajo; el solicitante es quien se preocupa por el resultado y lo aceptará (o no). Pueden ser la misma persona, pero son roles separados. Registrar al solicitante es lo que te da la respuesta de auditoría a “¿quién pidió esto?” seis meses después.

Rótulos de colores. Las historias pueden llevar varios. Se usan para categorización transversal — mvp, tech-debt, security, el nombre de una release concreta — y para filtrar el tablero (label:mvp en el cuadro de búsqueda, o guárdalo como panel de filtro personalizado).

Las etiquetas tienen alcance de proyecto. Gestiónalas en la página Labels de la barra lateral. Archiva las etiquetas obsoletas en lugar de eliminarlas; el archivo mantiene el historial buscable a la vez que despeja el tablero.

Notas libres que describen qué impide que esta historia avance. Marca como resuelto cuando el impedimento desaparezca.

Los bloqueadores son una señal de flujo, no una cola. Usa la reunión diaria para sacarlos a la luz; resuélvelos por otra vía. Si tienes más de uno o dos bloqueadores abiertos por historia durante más de un día, la planificación está mal — divide la historia o cambia la dependencia. El objetivo es que el panel Blocked esté vacío la mayor parte del tiempo.

Qué es la historia y cómo reconocer que está terminada. Markdown.

Los criterios de aceptación van aquí — idealmente en forma Given / When / Then para que se correspondan directamente con las pruebas de aceptación:

Given I am signed in as a member
When I click "Add a story" in Current
Then the story is created in state "unstarted"

INVEST es la comprobación de cordura sobre si una historia está bien formada:

  • Independent — se puede entregar sin otras historias.
  • Negotiable — capta la intención, no una especificación congelada.
  • Valuable — para un usuario o una parte interesada.
  • Estimable — el equipo puede dimensionarla.
  • Small — cabe cómodamente en una iteración.
  • Testable — tiene criterios de aceptación que se pueden ejercitar.

Una historia en la parte superior del backlog con criterios de aceptación vagos es un fallo de planificación — no un problema futuro que ignorar. Arréglalo antes de dejar que avance.

Selecciona varias historias en el tablero (shift-click para un rango, o Select all in panel). Después:

  • Transición masiva
  • Borrado masivo
  • Duplicado masivo

El tablero es la pantalla principal de cada proyecto. Tres columnas por defecto:

  • Current — Historias de la iteración activa. Agrupadas por cabecera de iteración (la actual, luego las próximas, luego las cerradas). Las tarjetas aparecen en orden de secuencia temporal de la iteración, con su estado visible en cada tarjeta; la columna no se trocea por estado — eso rompe la secuencia temporal de la iteración en la que planifica el equipo.
  • Backlog — Cola estrictamente ordenada. El sistema agrupa automáticamente las próximas iteraciones según la velocidad. El product owner es dueño del orden de arriba abajo; la claridad puede degradarse a medida que te desplazas hacia abajo, pero nunca en la parte superior.
  • Icebox — Ideas sin fecha. Sin orden, sin estimar. El Icebox tiene permiso para ser un cementerio.

Paneles configurables — casillas de la barra lateral

Sección titulada «Paneles configurables — casillas de la barra lateral»

La sección Board de la barra lateral enumera cada columna preconfigurada con una casilla: marca una casilla para mostrar esa columna, desmárcala para ocultarla. Los conmutadores persisten por proyecto y por usuario (se sincronizan mediante GET/PUT /preferences). Las preconfiguraciones son:

  • Current Iteration (activada por defecto)
  • Backlog (activada por defecto)
  • Icebox (activada por defecto)
  • Done — Historias aceptadas.
  • My Work — Historias en las que eres owner.
  • Blocked — Historias con bloqueadores sin resolver.
  • Epics — Agregaciones a nivel de épica.
  • Chat — Columna de chat con alcance de proyecto.

Fija una búsqueda como panel: pega una consulta como type:feature label:mvp owner:claire y guárdala. Redimensiona las columnas a tu gusto; los anchos persisten entre sesiones.

La barra de búsqueda acepta la sintaxis de filtros descrita en la Introducción. Los resultados de búsqueda viven en un panel de resultados; haz clic en cualquiera para saltar a esa historia en el tablero.

La barra superior muestra el número de la iteración actual, su rango de fechas y los puntos aceptados frente a los planificados. Haz clic para saltar a la columna Current.

El sistema crea iteraciones automáticamente según tu duración y día de inicio. No necesitas “abrir” ni “cerrar” iteraciones.

Para planificar a futuro, arrastra historias desde el Backlog a los grupos de las próximas iteraciones. El sistema marca en rojo los grupos que superan tu velocidad. Para planificar más lejos, desplázate por el backlog — muestra tres o cuatro iteraciones por delante.

Para rebobinar: haz clic en la cabecera de cualquier iteración pasada en la columna Current para entrar en el informe de esa iteración.

Las releases son un tipo de historia, no un objeto separado. Crea una release igual que cualquier otra historia: elige Release como tipo, ponle un nombre (por ejemplo, v2.4) y arrástrala a la iteración en la que pienses entregar.

Las releases se saltan los estados Started/Finished/Delivered/Rejected — van de Unstarted a Accepted en un solo paso. Acepta una release cuando entregues; las vistas analíticas muestran el marcador de release.

La pestaña Analytics (arriba del proyecto) te da seis informes:

  • Project Overview — Tendencia de velocidad, KPIs de iteraciones recientes, burnup, burndown, flujo acumulado.
  • Iteration — Profundiza en una iteración concreta: KPIs, burndown, flujo de estados.
  • Releases & Burndowns — Línea temporal de releases, burndown por release.
  • Story Activity — Quién hizo qué, filtrable por actor, tipo y rango de fechas.
  • Cycle Time — Media y distribución del tiempo desde Started hasta tu estado terminado.
  • Projections — Pronóstico de cuándo terminará el backlog a la velocidad actual.

Esta es la parte del producto que lo distingue. Un agente es un compañero de equipo con nombre — pero es una IA.

Tienes que ser owner del proyecto (o administrador). Abre Project Settings → Agents:

  1. Create new agent key.
  2. Dale un nombre al agente (aparecerá con ese nombre en los registros de auditoría, en la autoría de los comentarios y en los avatares de owners).
  3. Elige un rol — viewer (solo lectura) o member (puede escribir). El rol owner está reservado a personas.
  4. La clave se muestra una sola vez — cópiala; no la almacenamos de forma recuperable. El prefijo es ea_agent_….

Un agente con rol member puede hacer lo mismo que un miembro humano:

  • Crear, editar, transicionar y eliminar historias
  • Comentar, adjuntar archivos, añadir etiquetas, asignar owners
  • Asignarse a sí mismo como owner de una historia
  • Leer actividad, seguir eventos

El registro de auditoría guarda cada escritura con la identidad del agente. No hay forma de hacer que una acción de agente parezca una acción humana.

En Project Settings → Agents ves todas las claves activas, sus nombres, roles y marca de tiempo del último uso. Revoca una clave cuando quieras; el agente pierde el acceso de inmediato. La actividad pasada del agente permanece en el registro de auditoría para siempre.

Consulta Guía de la API → Agent keys para ver ejemplos de código.

Si vienes de otra herramienta, tenemos importadores para ocho orígenes:

  • Pivotal Tracker
  • Jira
  • Asana
  • GitLab
  • Shortcut
  • Trello
  • Linear
  • Plane

Desde Project Settings → Import, sube una exportación (CSV en la mayoría, JSON en Plane). Historias, owners, comentarios, etiquetas y estados se mapean automáticamente; algunos orígenes también traen iteraciones.

Una vista previa muestra lo que se va a importar. Las discrepancias (por ejemplo, una etiqueta que no existe en tu proyecto) preguntan — crear-o-saltar, tú decides.

Vienen cuatro temas. Cambia desde el pie de la barra lateral (o en Account Settings → Theme):

  • Agile — La paleta de la landing de marketing. Blancos cálidos, acento de marca azul intenso (#1f6f9f), iconos de tipo de historia saturados. Opción principal del selector.
  • Labs — La paleta de Pivotal Tracker, conservada con cariño. Cromo oscuro, barra superior azul, separaciones pastel entre columnas. La original.
  • Dark — Oscuro neutro puro.
  • Light — Claro neutro puro. Tinta sobre papel.

Tu tema persiste entre sesiones.

La interfaz está traducida a 15 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. Cambia desde el pie de la barra lateral — la interfaz, las páginas de autenticación, el área de cuenta/seguridad, la lista de proyectos y la landing de marketing se localizan de inmediato. La localización del detalle de historia / la analítica / la configuración llega a continuación.

Algunos que se ganan su sitio:

  • Escape — Colapsa la historia abierta más recientemente.
  • Enter en un input en línea — Envía (no colapsa la fila).
  • Shift-click — Selecciona un rango de historias.

Se van añadiendo más con el tiempo; consulta Help en la barra lateral para ver la lista actual.

East Agile Tracker es código abierto. El código fuente completo está en github.com/EastAgile/agile-tracker — clónalo, compílalo y ejecútalo en tu propia infraestructura. Las mismas funciones que la versión alojada.

Para la configuración inicial, consulta el README del proyecto.