Tarea y ticket — qué son, sistemas de seguimiento y trabajo con tareas

¿Qué es una tarea y un ticket?

Tarea — una unidad de trabajo registrada en un sistema de seguimiento. Contiene descripción, prioridad (Critical, High, Medium, Low), responsable, fecha límite y estado. En el desarrollo móvil, una tarea puede ser “Agregar pantalla de perfil con avatar”, “Implementar paginación del feed” o “Actualizar targetSdk a 35”. Cada tarea está vinculada a un proyecto, sprint y a un desarrollador o equipo específico.

Ticket — una entidad más amplia. Un ticket puede ser un reporte de error (“La aplicación falla al rotar la pantalla en Android 14”), una solicitud de funcionalidad (“Agregar soporte para modo oscuro”), una consulta de soporte técnico (“No llega la notificación push”) o una tarea del gerente (“Preparar informe de crash rate del mes”). La línea entre tarea y ticket es difusa: en Jira, ambos conceptos se combinan en Issue. La diferencia clave: una tarea siempre tiene un responsable, mientras que un ticket puede ser una solicitud sin un responsable específico hasta el triaje.

En Scrum y Kanban, las tareas son el elemento principal del backlog. Cada tarea debe cumplir con los criterios INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Las tareas independientes se pueden implementar en cualquier orden. Las estimables — el equipo puede calcular el esfuerzo. Las pequeñas — caben en un sprint. Las comprobables — tienen criterios de aceptación claros. Las tareas grandes (épicas) se dividen en otras más pequeñas hasta que se cumplan todos los criterios.

Tipos de tareas en el desarrollo móvil

Feature — nueva funcionalidad de la aplicación. Ejemplo: “Pantalla de inicio de sesión biométrico (Face ID / Touch ID)”. Las tareas Feature siempre están vinculadas a una historia de usuario y tienen Criterios de Aceptación. La estimación es en story points (1, 2, 3, 5, 8, 13). Bug — un defecto encontrado durante el desarrollo o las pruebas. La prioridad del bug se determina por la severidad (crash → Critical, error de UI → Medium, error tipográfico → Low). En el desarrollo móvil, una tasa de crash superior al 0.1% es un error crítico que requiere corrección inmediata.

Tech Debt / Chore — tareas técnicas sin efecto visible para el usuario: actualización de librerías (Dependency Bump), refactorización (Migración de ViewPager a ViewPager2), configuración de CI/CD, escritura de pruebas. Las tareas de Tech Debt a menudo se subestiman, aunque según Stripe 2025, hasta el 30% del tiempo de un equipo móvil se destina al mantenimiento y pago de la deuda técnica. Ignorar la deuda técnica provoca un aumento de errores y una ralentización en el desarrollo de nuevas funciones.

Tipos adicionales: Spike (tarea de investigación — explorar una nueva tecnología, escribir un POC), Task (cualquier trabajo que no sea código — documentación, revisión de diseño), Improvement (mejora de la funcionalidad existente — optimización del tiempo de carga de pantalla). En Jira, los tipos de issues se personalizan por proyecto. El conjunto estándar para un equipo móvil: Story, Bug, Task, Improvement, Epic. Epic — un tema grande que une varias historias. Ejemplo: “E-commerce: carrito y finalización de compra”.

Ciclo de vida de una tarea: desde la creación hasta el cierre

Open (To Do) — tarea creada pero no iniciada. Contiene descripción, Criterios de Aceptación, prioridad. En este estado, la tarea debe pasar por el grooming (refinamiento y estimación) antes de entrar en un sprint. In Progress — el desarrollador comenzó a trabajar. En el desarrollo móvil, es importante vincular los commits y pull requests a la tarea: en Jira mediante Smart Commits (APP-123 #comment fix bug), en GitHub/GitLab mediante palabras clave en la descripción del PR (Closes APP-123).

In Review — código enviado para revisión. Verificaciones automáticas: CI (Gradle build, lint, unit tests), SonarQube (calidad de código), Danger (changelog, tests). El desarrollador no puede tomar la siguiente tarea mientras la actual esté en Review — esto evita la multitarea. QA / Testing — el tester verifica en dispositivos reales (Android — varias versiones del SO y tamaños de pantalla, iOS — diferentes modelos de iPhone). Si se encuentran errores, la tarea vuelve a In Progress con un comentario.

Done (Closed) — tarea completada: código fusionado en main/master, probado, listo para el lanzamiento. Algunos equipos agregan un estado Deployed — la tarea llega al usuario solo después de que el build se publique en las tiendas. Es importante cerrar las tareas con un comentario sobre el resultado: qué versión, qué PR, qué métricas cambiaron. Según Linear (2025), los equipos que cierran tareas con una descripción del resultado tienen un 40% menos de probabilidades de volver a las mismas tareas.

El ciclo de vida puede incluir un estado Blocked — la tarea no puede completarse debido a una dependencia externa (esperando diseño, respuesta del backend, aprobación del gerente). Las tareas bloqueadas deben tener un comentario con el motivo y la fecha de la próxima revisión. Una revisión semanal de las tareas bloqueadas ayuda a identificar retrasos sistémicos en el proceso de desarrollo. Los bloqueos que duran más de 2 semanas requieren escalación al nivel del gerente de producto.

Sistemas de seguimiento de tareas

Jira — el estándar de la industria para equipos de 10 o más personas. Admite tableros Scrum y Kanban, personalización avanzada del flujo de trabajo, campos personalizados, automatizaciones e integración con Bitbucket/GitHub. Desventajas: excesivo para equipos pequeños, UI lenta, configuración compleja. Para proyectos móviles, Jira se personaliza con: el plugin Mobile-specific fields (Platform, OS version, Device model), integración con TestFlight y Firebase Test Lab, y automatización de builds de lanzamiento. Jira es la opción para proyectos empresariales con procesos burocráticos.

Linear — un tracker moderno para equipos de producto. UI rápida, soporte de primera clase para atajos de teclado, Cycle integrado (análogo al sprint), integración con GitHub y Slack. Ventajas: creación rápida de tareas mediante CMD+K, distribución automática en fases (Triaged → Backlog → Upcoming → Current → Completed), documentación y roadmaps integrados. Linear es elegido por startups y equipos de producto que valoran la velocidad. En 2025, el 40% de los nuevos proyectos móviles usan Linear.

Trello — un tablero kanban simple para equipos pequeños (2–5 personas). Tarjetas con listas de verificación, etiquetas, fechas límite. Desventaja: no tiene sprints, analítica limitada, difícil de escalar. YouGile — un análogo ruso de Trello con tableros kanban, chat y videollamadas. Asana — un tracker enfocado en proyectos y cronogramas. La elección del tracker depende del tamaño del equipo, presupuesto y preferencias: Jira para empresas, Linear para equipos de producto, Trello/YouGile para startups. Importante: la herramienta debe ser unificada para todo el equipo — diseñadores, desarrolladores, QA, gerentes trabajan en un mismo sistema.

Mejores prácticas para la gestión de tareas

Escribir Criterios de Aceptación — los criterios de aceptación deben ser específicos y verificables. Malo: “La pantalla de inicio de sesión funciona”. Bueno: “El usuario ingresa email y contraseña, hace clic en Iniciar sesión. Si los datos son correctos — navega a la pantalla principal. Si son incorrectos — muestra el error “Email o contraseña inválidos””. Los Criterios de Aceptación (AC) son el contrato entre el desarrollador, el tester y el product manager. Sin AC, una tarea no cumple con la Definition of Ready (DoR) y no debe entrar en un sprint.

Vincula todo. Commits, PRs, casos de prueba, maquetas de diseño (Figma), discusiones en Slack — todo debe estar vinculado a la tarea. En Jira, esto se hace mediante enlaces en los comentarios; en Linear, mediante la vinculación automática de PR. La regla de un clic: desde la tarea hasta el diseño/código/pruebas — no más de un clic. El desarrollador abre la tarea y ve inmediatamente la maqueta en Figma, el enlace al PR y los casos de prueba. Esto acelera la incorporación de nuevos miembros al equipo en un 30% según Linear (2025).

No crees tareas fantasma. Una tarea sin descripción, sin AC y sin prioridad es basura. Si en la daily nadie recuerda por qué se creó una tarea, debe eliminarse o aclararse. La regla de las 48 horas: si una tarea ha estado en estado In Progress sin actividad durante 48 horas, el desarrollador debe dejar un comentario sobre los motivos del retraso. Según Jira (2025), el 60% de las tareas inactivas durante más de 3 días terminan cerrándose sin completarse.

Descomposición de tareas: épicas, historias de usuario y subtareas

Épica (Epic) — un área funcional grande que une muchas historias. Ejemplo: “Onboarding de usuario” incluye “Pantalla de bienvenida”, “Selección de intereses”, “Carga de avatar”, “Configuración de notificaciones”. Historia de usuario (User Story) — una tarea desde la perspectiva del usuario. Formato: “Como [rol], quiero [acción] para [valor]”. Ejemplo: “Como usuario, quiero iniciar sesión con biometría para no tener que ingresar mi contraseña cada vez”. Las Historias de Usuario las escribe el product manager o el product owner.

Subtarea (Sub-task) — descomposición del trabajo técnico dentro de una Story / Task. Ejemplo para la Story “Pantalla de perfil”: Subtarea 1: Crear UI (XML / SwiftUI), Subtarea 2: Conectar con ViewModel, Subtarea 3: Escribir Unit Tests, Subtarea 4: Snapshot Tests, Subtarea 5: UI Tests (Espresso / XCUITest). Regla de descomposición: cada subtarea se completa en 1–2 días. Si un desarrollador estima una subtarea más larga — divídela aún más. Las subtareas son una técnica interna del equipo, no son visibles en el backlog del producto. La suma de las estimaciones de las subtareas no es necesariamente igual a la estimación de la Story padre (parte del trabajo es comunicación, code review, testing).

Pirámide de descomposición: Epic (Trimestre / Semestre) → Feature / Story (Sprint) → Task (1–3 días) → Sub-task (Varias horas). La técnica INVEST ayuda a verificar la calidad de la descomposición. Si una tarea no es Independent (depende de otras) — esto señala una descomposición incorrecta. Si una tarea no es Small (más de 8 story points) — necesita más división. Patrón común: Epic → 5–15 Stories → cada Story → 3–8 Sub-tasks. La estimación final del épico = suma de estimaciones de las Stories, pero el primer sprint suele dar un margen de error del 20–30% en las estimaciones.

Errores comunes al trabajar con tareas

Error 1: tareas demasiado grandes. Una tarea de 2 semanas es un épico que necesita descomposición. Las tareas grandes no se pueden integrar en el seguimiento diario; permanecen en In Progress durante semanas. Regla: tamaño máximo de tarea — 2–3 días de trabajo. Todo lo más grande debe descomponerse. Efecto secundario: el desarrollador siente progreso al cerrar 2–3 tareas por semana en lugar de una gigantesca. Esto aumenta la motivación y la previsibilidad del cronograma.

Error 2: falta de Criterios de Aceptación. El desarrollador implementó la funcionalidad, el tester verificó — todo bien. El gerente: “¿Dónde está el botón de editar?” — “No estaba en la tarea”. Sin AC, cada parte entiende la tarea de manera diferente. Resultado: retrabajo, conflictos, plazos incumplidos. AC es un contrato: si la tarea no tiene criterios, no está lista para el sprint. En el grooming, lo primero que se verifica es la presencia de AC. Si falta AC, la tarea se devuelve al Product Manager para refinamiento.

Error 3: olvidar la deuda técnica. El equipo solo hace tareas Feature sprint tras sprint. Seis meses después: la compilación toma 15 minutos, Gradle está 3 versiones principales atrasado, las pruebas fallan en CI debido a deprecaciones. Solución: reservar el 20% del tiempo del equipo para Tech Debt (práctica de Google SRE “SLO-based error budget”). Crea al menos una tarea de Tech Debt por cada sprint de Features. Proporción: por cada 3 tareas Feature — 1 Tech Debt o Bug. Esto evita la acumulación de deuda técnica y mantiene la velocidad de desarrollo.