Planifica tu primer proyecto de software en Jira
Comienza con un objetivo claro para el proyecto
Antes de crear incidencias en Jira, escribe una breve declaración del resultado que describa al usuario, el problema y el resultado esperado. Por ejemplo, un equipo de dos personas que desarrolla una aplicación de reservas podría proponerse permitir que los clientes elijan un servicio, seleccionen una hora disponible y reciban un correo electrónico de confirmación. Esto es más útil que un objetivo vago como «crear una plataforma de reservas moderna», porque establece un límite para las decisiones posteriores.
Añade una condición de éxito medible para la primera versión. Una opción práctica podría ser que un cliente de prueba pueda completar una reserva en menos de tres minutos utilizando el navegador de un teléfono. La condición no tiene que predecir los ingresos; debe ayudar al equipo a decidir si una funcionalidad pertenece a la primera versión o puede esperar.
Configura el proyecto de Jira adecuado
Para un primer proyecto de software, crea un proyecto de Jira Software y elige una plantilla de Scrum cuando el trabajo se vaya a entregar en ciclos de planificación fijos. Elige Kanban cuando las prioridades puedan cambiar a diario y el equipo quiera tomar el siguiente elemento solo después de terminar el trabajo actual. Un proyecto estudiantil de tres semanas suele beneficiarse de Scrum, porque la fecha de finalización hace que los compromisos breves y visibles sean valiosos.
Mantén sencillo el flujo de trabajo inicial: Para hacer, En curso, Revisión de código y Hecho son suficientes para muchos equipos pequeños. Añadir estados independientes para las pruebas, la revisión de diseño, el despliegue y la aprobación puede tener sentido más adelante, pero solo cuando alguien utilice activamente cada estado. Cada estado adicional crea otra oportunidad para que queden incidencias obsoletas y la responsabilidad no esté clara.
Configura los permisos desde el principio para que cada colaborador pueda crear y actualizar incidencias, mientras que un responsable del proyecto pueda administrar la configuración del tablero y las versiones. Conecta también el proyecto con su repositorio de código fuente si el equipo utiliza GitHub, GitLab o Bitbucket. Vincular ramas y pull requests con claves de incidencia como APP-14 facilita comprobar si una historia planificada tiene un trabajo de implementación real detrás.
Convierte el alcance en épicas e historias
Crea épicas para las capacidades principales orientadas al usuario, no para los departamentos técnicos. En la aplicación de reservas, las épicas adecuadas son Acceso a la cuenta, Catálogo de servicios, Flujo de reservas y Notificaciones. Una épica debe describir una parte significativa del producto que pueda contener varias piezas de trabajo más pequeñas, en lugar de una etiqueta amplia como «frontend».
Divide cada épica en historias de usuario escritas desde la perspectiva del usuario. Una historia útil es: «Como cliente, quiero ver los horarios disponibles para un servicio seleccionado para poder elegir una cita adecuada». Esto indica al diseñador, al desarrollador y al tester qué comportamiento se necesita sin imponer todos los detalles de implementación.
Añade los criterios de aceptación directamente a la historia de Jira. Para la historia sobre los horarios disponibles, los criterios podrían exigir que no se puedan seleccionar horarios no disponibles, que todos los horarios utilicen la zona horaria del negocio y que se muestre un estado vacío cuando no queden horarios. Estos detalles evitan que una tarea llegue a revisión con una interfaz técnicamente funcional, pero incompleta.
Prepara los elementos del backlog para el desarrollo
Un backlog no es solo una larga lista de deseos de funcionalidades. Cada elemento cercano a la parte superior debe tener una descripción concisa, criterios de aceptación, una prioridad y suficiente contexto para que un compañero pueda empezar sin una reunión. Adjunta un boceto aproximado de la pantalla, un ejemplo de API o un enlace a un archivo de diseño cuando responda a una pregunta real; evita adjuntar documentos que nadie vaya a leer.
Divide las historias que sean demasiado grandes para terminarlas en un solo sprint. «Crear la autenticación de usuarios» suele ocultar el registro, el inicio de sesión, el restablecimiento de contraseña, la validación, la gestión de sesiones y los mensajes de error. Para un sprint de una semana, separa el registro y el inicio de sesión en historias distintas, y luego crea subtareas técnicas solo cuando ayuden a una persona a realizar el seguimiento de un paso concreto, como una migración de base de datos o la configuración de una plantilla de correo electrónico.
Usa las etiquetas con moderación para aspectos transversales como accesibilidad, errores, seguridad o dispositivos móviles. No uses etiquetas para sustituir simultáneamente a las épicas, los componentes y las prioridades. Un equipo nuevo debería poder filtrar el backlog y responder rápidamente qué está previsto para la primera versión, quién es responsable y qué lo está bloqueando.
Estima el trabajo sin una falsa precisión
Estima el esfuerzo relativo con puntos de historia en lugar de adivinar horas exactas para cada tarea. Un equipo puede definir 1 punto como un cambio muy pequeño y conocido, 3 puntos como una historia estándar con algunas decisiones y 8 puntos como un trabajo que probablemente necesite dividirse. La escala es útil porque pone de manifiesto la incertidumbre, no porque un punto tenga un valor de tiempo universal.
Realiza una breve conversación de planificación para el primer sprint. Pregunta qué aspectos se desconocen, qué dependencias existen y qué evidencia demuestra que la historia está terminada. Si un desarrollador dice que una historia vale 2 puntos y otro dice que vale 8, el desacuerdo suele revelar un requisito que falta, como el acceso al sandbox de pagos o una ruta de migración necesaria.
Para el primer sprint, comprometeos de forma conservadora. Si hay dos personas disponibles durante cinco días laborables, no llenéis todas las horas con tickets; las reuniones, las revisiones, las correcciones de errores y las tareas de configuración consumen capacidad. Después de uno o dos sprints, utilizad el número de puntos completados como la velocidad del propio equipo, en lugar de copiar un objetivo de otro equipo.
Planifica los sprints en torno a una funcionalidad utilizable
Un buen primer sprint produce un recorrido de producto reducido, pero utilizable. Para la aplicación de reservas, esto podría significar mostrar servicios codificados directamente, elegir uno, seleccionar una franja horaria simulada y ver una pantalla de confirmación. Es más valioso que completar por separado una página de inicio de sesión pulida, un esquema de base de datos y una integración de correo electrónico que todavía no se puedan utilizar conjuntamente.
Durante la planificación del sprint, trasladad al sprint activo únicamente las historias que estén listas y comprobad sus dependencias. Si la pantalla de reservas depende de una API de servicios que no existe, planificad primero el trabajo de la API o utilizad deliberadamente una fuente de datos temporal. Registrad esa solución técnica provisional en Jira para que sea visible, en lugar de que se convierta accidentalmente en una dependencia permanente.
Asignad el trabajo según la responsabilidad y los objetivos de aprendizaje, pero evitad tratar el campo de asignatario como un mecanismo de transferencia. Revisad brevemente el tablero cada día y comentad los problemas bloqueados antes de asignar trabajo nuevo. Una tarjeta que permanece en estado In Progress durante cuatro días merece atención, aunque todavía no haya llegado su fecha límite.
Utiliza los informes de Jira para mejorar el próximo sprint
Al final del sprint, comparad el trabajo completado con el objetivo del sprint, no solo con el número de tickets cerrados. Si el equipo ha terminado nueve tareas pequeñas, pero los clientes todavía no pueden realizar una reserva, es posible que el plan haya favorecido piezas técnicas fáciles en lugar de un resultado utilizable. Mostrad el flujo funcionando y anotad exactamente dónde se detiene.
Utilizad el gráfico de burndown como punto de partida para la conversación. Una línea plana durante varios días puede indicar que las historias son demasiado grandes, que el trabajo está esperando una revisión o que los miembros del equipo solo actualizan Jira al final de la semana. No es una métrica de rendimiento y no debe utilizarse para presionar a las personas a cerrar trabajo incompleto.
Celebrad una retrospectiva breve y convertid una o dos mejoras en elementos reales del backlog. Por ejemplo, si las revisiones de código retrasaron todas las historias, añadid un acuerdo del equipo para solicitar una revisión antes de empezar otro ticket y cread una tarea pequeña para configurar las notificaciones de revisión. La planificación mejora mediante este ciclo de feedback, por lo que el primer plan de Jira debe tratarse como un punto de partida comprobable, no como un contrato permanente.
Lecturas adicionales
Etiquetas :
- Gestión ágil de proyectos
