🔄Flujo de Trabajo: Equipo de Desarrollo

🎯 Objetivo del Flujo

Establecer un proceso claro y predecible para el equipo de desarrollo técnico en Jira. Este flujo gestiona tareas relacionadas con la implementación de funcionalidades, corrección de errores, revisiones de código, pruebas QA y preparación para release.

Este flujo aplica principalmente para los siguientes issue types:

• 🧱 Dev Task

• 🪲 Bug

🔸 Las Subtasks tienen un flujo global simplificado que se aplica en todos los tableros del proyecto y será documentado por separado.

---

📊 Estados del Flujo de Desarrollo

Estado	Descripción
Open	Tarea creada y disponible para tomar. Equivalente a "To Do".
In Progress	Tarea en desarrollo activo por parte del equipo técnico.
Code Review	El Pull Request está creado. Se encuentra en revisión por un par o tech lead.
QA Testing	QA validando (manual o automatizado). Puede tener evidencias asociadas.
Reject by QA	El QA detectó errores y se devuelve a desarrollo.
Ready for Release	Validada por QA y aprobada para producción. Esperando deployment.
Done	La tarea fue desplegada a producción y validada final.
Blocked	Tarea detenida por impedimento técnico, de diseño o de negocio.
Canceled	El trabajo fue cancelado por decisión del equipo o stakeholders.

---

🖼️ Diagrama Visual del Flujo

Flujo visual Jira Dev

---

🔁 Transiciones Principales

START → OPEN → IN PROGRESS → CODE REVIEW → QA TESTING → READY FOR RELEASE → DONE
                                     ↘
                                 REJECT BY QA → IN PROGRESS

• Transiciones libres posibles hacia Open, Blocked o Canceled desde cualquier estado.

• QA Testing puede retornar a In Progress si hay errores detectados.

---

📌 Consideraciones

• Todo Dev Task debe estar vinculado a una User Story o Épica que justifique su origen.

• Toda tarea que pase a Code Review debe tener un PR asociado en el repositorio.

• Se recomienda adjuntar en QA Testing las evidencias o pasos para validación.

• Las tareas Blocked deben revisarse en dailys para desbloqueo proactivo.

• Todo Bug debe tener:

  • Comportamiento observado / esperado

  • Evidencia adjunta

  • Contexto del entorno (producción, staging, navegador, etc.)

---

🛠 Uso esperado por el equipo

• El Scrum Master o Líder Técnico valida que las Dev Tasks estén bien formuladas y listas para ser tomadas.

• El Desarrollador mueve los issues por los estados a medida que avanza.

• El equipo de QA toma automáticamente los issues en QA Testing para validar.

• Code Review debe tener mínimo una revisión antes de avanzar a QA.

---

🧭 Siguiente sección

Se documentará el flujo del equipo de Diseño (Design Task), con sus respectivos estados, revisiones y handoffs.