🧭 Cómo Trabajamos (Metodología Ágil)
Este documento está pensado para cualquier persona, sin importar si sabe o no de tecnología. Aquí explicamos, en palabras sencillas, cómo el equipo de zymDev organiza el trabajo, qué significan palabras como sprint, daily o refinement, y cómo viajan los cambios desde que se piden hasta que llegan al software que usas todos los días.
🌱 ¿Qué es "trabajar de forma ágil"?
Imagina que en vez de prometer "en 6 meses te entrego todo el sistema terminado", el equipo dice: "cada 2 semanas te muestro un avance funcionando". Eso es trabajar de forma ágil.
En lugar de intentar adivinar todo desde el principio, el equipo:
- Trabaja en bloques cortos de tiempo (normalmente 2 semanas).
- Muestra avances reales y funcionando, no solo promesas.
- Ajusta el rumbo constantemente según lo que se aprende en el camino.
Esto permite reaccionar rápido a errores, cambios de prioridad o nuevas necesidades, en lugar de esperar meses para descubrir que algo no era lo que se necesitaba.
📅 El Sprint: nuestro "bloque de trabajo"
Un Sprint es simplemente un período fijo de tiempo (en zymDev, 2 semanas) donde el equipo se compromete a avanzar en un conjunto de tareas.
Piensa en el Sprint como un ciclo de cocina en un restaurante: cada cierto tiempo sale un plato nuevo a la mesa. No se espera a tener todo el menú perfecto para servir algo; se sirve lo que ya está listo y bien probado.
- Semana 1: Se construyen y prueban las nuevas funcionalidades.
- Semana 2 (Estabilización): Ya no se agregan cosas nuevas, solo se corrigen errores encontrados, para asegurar que todo quede estable antes de publicar.
- Lunes siguiente: Se libera la nueva versión a todos los usuarios.
📖 Si quieres ver el detalle técnico de fechas y versiones, revisa la sección zymDev Core Framework.
🗣️ Los eventos del equipo, explicados sin tecnicismos
El marco de trabajo ágil (conocido técnicamente como Scrum) se apoya en unas reuniones cortas y puntuales. Aquí te explicamos qué es cada una:
☀️ Daily (Reunión diaria)
Una reunión de máximo 15 minutos, todos los días, donde cada persona del equipo cuenta tres cosas muy simples:
- ¿Qué hice ayer?
- ¿Qué voy a hacer hoy?
- ¿Tengo algún obstáculo que me esté frenando?
Es como el "parte meteorológico" diario del equipo: rápido, breve, y sirve para detectar problemas a tiempo, no para resolverlos ahí mismo.
🧹 Refinement (Refinamiento)
Una reunión donde el equipo revisa y aclara las tareas que aún no se han empezado, antes de que entren a un Sprint. Es como "alistar los ingredientes antes de cocinar": se asegura que todos entienden bien qué hay que hacer, qué tan grande es la tarea y si falta información.
Sin este paso, el equipo podría empezar a trabajar en algo mal explicado y perder tiempo corrigiendo rumbo a mitad de camino.
🔍 Review (Revisión de Sprint)
Al final de cada Sprint, el equipo muestra lo que construyó y funciona, para recibir comentarios. Es como una vitrina o una degustación: se presenta el avance real (no diapositivas ni promesas) y se recoge retroalimentación para seguir ajustando el producto.
🪞 Retrospective (Retrospectiva)
Una reunión interna del equipo, después de la Review, donde se preguntan: ¿qué funcionó bien?, ¿qué no?, y ¿qué vamos a mejorar en el próximo Sprint?. Es el momento de "aprender de lo vivido" para trabajar mejor la próxima vez.
📌 Planning (Planeación de Sprint)
Al iniciar cada Sprint, el equipo decide qué tareas ya refinadas entrarán a trabajarse en las próximas 2 semanas, según la prioridad e importancia para el negocio y los usuarios.
🗂️ ¿Qué es un "Issue" y qué tipos existen?
Un Issue (pronunciado "ísiu") es simplemente una tarjeta o ficha donde se anota cualquier cosa que el equipo debe atender: puede ser un error, una idea nueva, una pregunta o una tarea puntual. Todo el trabajo del equipo pasa por uno de estos "tickets", así siempre queda un registro claro de qué se pidió, quién lo pidió y qué se hizo al respecto.
Existen distintos tipos de Issue, dependiendo de qué tan grande es el trabajo y de qué se trata:
| Tipo | En palabras simples | Ejemplo cotidiano |
|---|---|---|
| 🐞 Bug | Algo que no está funcionando como debería. Un comportamiento inesperado o un error. | "El botón de guardar no responde al hacer clic." |
| ✨ Feature | Una idea, solicitud o funcionalidad nueva que aún no existe en el sistema. | "Quisiera poder exportar el reporte en PDF." |
| ✅ Task (Tarea) | Un trabajo puntual y concreto, que no es ni un error ni una funcionalidad nueva grande (ej. una configuración, un ajuste menor). | "Actualizar el texto de un mensaje en pantalla." |
| 🏔️ Epic (Épica) | Un trabajo tan grande que no cabe en un solo Sprint. Se divide en varias tareas o historias más pequeñas. | "Rediseñar todo el módulo de facturación." |
| 📖 User Story (Historia de Usuario) | Describe algo que un usuario podrá hacer con el producto, contado desde su punto de vista. | "Como usuario, quiero recibir una notificación cuando mi solicitud sea aprobada." |
| 🚧 Impediment (Impedimento) | Un obstáculo que le impide al equipo avanzar (por ejemplo, falta de acceso a un sistema, o una dependencia externa). | "No podemos continuar porque falta la clave de acceso al servidor." |
| 🧪 Test Case (Caso de Prueba) | Los pasos detallados que se siguen para comprobar que algo funciona correctamente antes de publicarlo. | "Verificar que al ingresar un correo inválido, el sistema muestre un mensaje de error." |
| 🔬 Spike (Investigación) | Una investigación o prueba experimental, no para construir el producto final, sino para resolver una duda técnica antes de comprometerse a una solución. | "Investigar si es viable conectar el sistema con una nueva pasarela de pagos." |
| 🗓️ Meeting (Reunión) | Se usa para registrar y llevar seguimiento de reuniones y ceremonias del equipo (Daily, Review, Retrospective, etc.), no representa trabajo de desarrollo. | "Retrospectiva del Sprint 24." |
💡 En resumen: si algo está roto, es un Bug. Si algo no existe todavía y se quiere agregar, es una Feature. Si es un trabajo puntual que no encaja en ninguna de las anteriores, es una Task. Y si el trabajo es demasiado grande para una sola tanda, se organiza como una Epic.
🌳 ¿Cómo viajan los cambios hasta llegar a ti? (Ramas y Versiones)
Aquí es donde muchas personas se pierden con la parte "técnica", así que lo explicaremos como una línea de tiempo.
Imagina el código del sistema como un libro de historia que se sigue escribiendo. Cada "rama" (o branch) es una línea de tiempo paralela, donde se prueban cosas nuevas sin arriesgar la historia principal.
- 🏛️
main(o Producción): Es la historia oficial, la que todos los usuarios ven y usan en el día a día. Solo llegan aquí los cambios que ya pasaron por todo el proceso de estabilización. - 🍲
develop: Es como la cocina del restaurante. Aquí se van "cocinando" y mezclando todos los cambios que serán parte de la próxima versión. - 🌿 Ramas de trabajo (una por cada Issue): Cada vez que alguien va a resolver un
Issue(un Bug, una Feature, una Task, etc.), se crea una línea de tiempo nueva y aislada, dedicada únicamente a resolver ese problema puntual. Así, mientras se trabaja ahí, no se afecta el trabajo de nadie más. - 📦
release/vX.Y.Z: Es la "bandeja de emplatado" antes de sacar el plato al comedor. Cuandodevelopya tiene todo lo que se planeó para la siguiente versión, se crea esta rama para dedicarse exclusivamente a estabilizar y probar (la "semana de estabilización" de la que hablamos arriba). Nunca se pasa directo dedevelopamain: siempre se pasa primero por esta rama de release.
Cuando el trabajo en una rama de Issue se termina y se confirma que todo funciona bien (con pruebas y revisión de otro compañero), esos cambios se integran de vuelta a develop, sumándose a los demás avances que se están cocinando para la siguiente versión.
Cuando llega el momento de publicar, no se toma develop directamente: se crea la rama release/vX.Y.Z a partir de develop, y es ahí donde ocurre la semana de estabilización (solo se aceptan correcciones de errores, nada de funcionalidades nuevas). Una vez esa rama de release queda estable:
- Se abre e integra un Pull Request de la rama de release hacia
main, y ahí se etiqueta oficialmente como la nueva versión (ej.v6.1.0). - Automáticamente, se abre un segundo Pull Request, esta vez desde
mainhaciadevelop, para sincronizar los cambios y correcciones de esa versión de vuelta a la cocina. Este paso es obligatorio: si alguna corrección hecha durante la estabilización no vuelve adevelop, se perdería y el error podría reaparecer en la siguiente versión.
📊 Ejemplo visual de la línea de tiempo
En resumen, el recorrido de un cambio es:
- 🗂️ Alguien reporta o propone un Issue (Bug, Feature, Task, etc.).
- 🌿 Se crea una línea de tiempo (rama) dedicada solo para resolver ese Issue.
- 🧪 Se trabaja, se prueba y se revisa que todo funcione correctamente.
- 🍲 Una vez confirmado, se integra a
develop, donde se junta con los demás cambios del Sprint. - 📦 Cuando ya está todo lo planeado para la versión, se crea la rama
release/vX.Y.Za partir dedevelop. Nunca se salta este paso: dedevelopno se pasa directo amain. - ❄️ Durante la semana de estabilización, solo se corrigen errores sobre la rama de release, nunca se agregan funcionalidades nuevas.
- 🏛️ Cuando la rama de release queda estable, se abre un Pull Request hacia
main; al integrarse, se convierte en la nueva versión oficial que todos los usuarios reciben y se le pone la etiqueta de versión (ej.v6.1.0). - 🔁 De forma automática, se abre un segundo Pull Request desde
mainhaciadevelop, para sincronizar de vuelta todas las correcciones de esa versión y que ninguna se pierda.