Reglas para el Proceso de Gestión con Board Físico.md

🧭 Reglas para el Proceso de Gestión con Board Físico

1. Estructura del Board

El tablero está compuesto por tres columnas principales que representan el flujo de trabajo:

• TODO: tareas listas para iniciar.

• IN PROGRESS: tareas actualmente en ejecución.

• DONE: tareas completadas, validadas y revisadas.

Cada tarjeta (job request) representa una unidad de trabajo concreta y debe incluir los siguientes campos obligatorios:

• Prioridad: Low, Medium, High o None (define la urgencia).

• Fecha (date): fecha de creación o entrega estimada.

• Área responsable: abreviatura del departamento o equipo involucrado:

  • MAR = Marketing

  • FIN = Finanzas

  • OPS = Operaciones

  • Otros según corresponda.

• Responsable: persona encargada del trabajo, representada por su foto en la tarjeta.

• Descripción breve: alcance, objetivos y criterios de aceptación claros.

• Estimación: duración estimada en días, definida por quien realiza la tarea.

---

2. Organización Temporal (Sprints)

• El trabajo se organiza en bloques de dos semanas, llamados Sprints.

• Cada sprint inicia el lunes y finaliza el viernes de la segunda semana, considerando jornadas laborales de lunes a viernes.

• La carga del sprint puede ajustarse según la capacidad real del equipo.

Revisión de Sprint (quincenal)

El último viernes del sprint se realiza una revisión general:

1. Se validan las tareas completadas.

2. Las tareas no completadas pero relevantes se trasladan al siguiente sprint.

3. Las tareas no relevantes o sin valor actual se descartan, tras una evaluación de su valor, definido como:
   Valor = Esfuerzo + Tiempo restante / Impacto esperado.

---

3. Priorización y Validación de Tickets

• La prioridad (urgencia) la define el jefe o responsable del área, en función del impacto y origen de la solicitud.

• Para que una tarjeta ingrese al board, debe cumplir todos los criterios obligatorios:

  • Prioridad

  • Área

  • Fecha

  • Descripción con criterios de aceptación

  • Responsable asignado

• Si alguno de estos elementos falta, el ticket no se acepta.
  → Se devuelve al solicitante con el mensaje:
  “Se requiere más información antes de ser incorporado al board.”

---

4. Ejecución, Validación y Calidad

• Cada persona puede tener como máximo 2 tareas “In Progress” a la vez.

  • Excepciones requieren aprobación del jefe del área.

• La estimación de días la define quien ejecuta la tarea.

• La descripción debe especificar claramente:

  • Qué se debe entregar.

  • Cuándo se considera terminado (criterio de aceptación).

• La documentación y requerimientos extensos se almacenan fuera del board, vinculados mediante enlaces o documentos externos.

Etapa de Validación / Testing

• Cuando una tarea pasa a “Done”, debe validarse para confirmar que cumple los criterios de aceptación definidos.

• Esta validación la realiza una persona de apoyo, preferentemente con rol de tester o revisor funcional, distinta de quien ejecutó la tarea.

• El objetivo es verificar resultados, detectar desviaciones y asegurar calidad antes de cerrar definitivamente el ticket.

• Solo después de la validación, la tarea se considera completamente entregada.

---

5. Flujo de Trabajo (Resumen)

1. Creación del ticket:

   • Se valida que cumpla con los criterios mínimos.

   • Se asigna prioridad, responsable, área y fecha.

   • Si falta información, se solicita al remitente.

2. Inicio del trabajo:

   • El responsable mueve la tarjeta de TODO → IN PROGRESS.

   • Se muestra su foto para reflejar responsabilidad activa.

3. Finalización del trabajo:

   • Una vez cumplidos los criterios de aceptación, la tarea pasa a DONE (pendiente de validación).

4. Validación / Testing:

   • El tester o revisor confirma cumplimiento y resultados.

   • Si es correcto, la tarea se marca como cerrada.

   • Si no cumple los criterios, vuelve a IN PROGRESS para ajustes.

5. Revisión de Sprint:

   • Se evalúa el avance, se trasladan tareas relevantes y se descartan las de bajo valor.

---

6. Retrospectiva Mensual

• Una vez al mes se realiza una retrospectiva global del proceso.

• Participan los jefes de área y representantes de cada equipo.

• Objetivos de la retrospectiva:

  1. Evaluar la efectividad del proceso: identificar bloqueos, cuellos de botella y oportunidades de mejora.

  2. Revisar la calidad de los requerimientos y la definición de criterios de aceptación.

  3. Detectar mejoras de implementación o coordinación interárea.

  4. Actualizar las reglas si se identifican ajustes necesarios.

La retrospectiva debe generar acciones concretas de mejora, que se integran en el siguiente ciclo mensual.

---

7. Buenas Prácticas

• Mantener el board actualizado diariamente.

• Respetar el límite de tareas simultáneas en progreso.

• Asegurar la visibilidad total del estado y responsables (fotos, fechas, columnas).

• Promover la responsabilidad visual compartida: el board debe reflejar siempre la realidad del trabajo.

• Registrar aprendizajes, incidencias y bloqueos en un Sprint Log o documento complementario.

• Usar las revisiones y retrospectivas como espacios para alinear prioridades, mejorar estimaciones y fortalecer la comunicación del equipo.