Home - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub Wiki
👥 Integrantes del grupo
| Nombre | Correo |
|---|---|
| John Guerrero | [email protected] |
| Mauricio Rodriguez | [email protected] |
| Juan Acevedo | [email protected] |
| Martin Romero | [email protected] |
🤝 Acuerdos del Equipo
Nuestros acuerdos están diseñados para garantizar la calidad del código, la sincronización del equipo y la eficiencia del flujo de trabajo.
-
Gestión de Código y Ramas: Adoptaremos el flujo de ramas GitFlow/Feature Branching para asegurar la estabilidad del código. Todos los nuevos desarrollos deben partir de la rama develop y fusionarse de nuevo en ella.
-
Revisión por Pares (Code Review): Para garantizar la calidad y la revisión por pares, todo cambio requiere una Pull Request (PR) y solo se fusionará una vez que haya sido aprobado por al menos un revisor del equipo.
-
Asistencia y Sincronización: La asistencia a las reuniones programadas es obligatoria para la sincronización. Si no puedes asistir, avisa al equipo con la máxima antelación posible y asegúrate de consultar las notas de la reunión.
-
Gestión de Bloqueantes: Si identificas un bloqueante o un riesgo que impida el progreso de tu tarea, escala la situación inmediatamente (en el canal de comunicación del equipo y en la Daily). No permitiremos que los impedimentos permanezcan ocultos.
-
Higiene del Backlog: Mantendremos el Backlog de trabajo priorizado y saneado de forma continua. El Dueño de Producto, asistido por el equipo, dedicará tiempo regularmente (ej. cada semana) a refinar los elementos del Backlog para asegurar que al menos las próximas tres iteraciones están claras y cumplen con la Definición de Listo (DoR).
🚀 Metodología de Trabajo: DAD-Scrum Híbrido
Adoptaremos un marco de trabajo iterativo con ciclos de Sprints (que definiremos semanal), combinando la estructura de Scrum con la gestión de riesgo y la prueba continua de DAD.
- Frecuencia y Cadencia de las Reuniones Nuestro ciclo semanal estará anclado en la sincronización, el desarrollo y la revisión.
| Reunión Frecuencia | Días y Hora Sugeridos | Duración Máx. | Objetivo / Práctica DAD |
|---|---|---|---|
| Sincronización Semanal (Sync) 1 vez a la semana | Lunes, 7:00 PM (Hora de inicio del ciclo) | 30 min | Establecer el objetivo del ciclo, planificar el trabajo y aplicar la Contabilidad de la Innovación (medir el progreso). |
| Encuentros de Desarrollo 3 veces a la semana | Miércoles, Jueves, Sábado (Hora flexible a definir por el equipo) | 60 min | Revisar el progreso de las tareas, resolver bloqueantes técnicos y realizar Programación en Parejas (Pair Programming) o Revisión de Código. |
| Reunión de Emergencia | Según necesidad Viernes y/o Domingo | 60-90 min | Activada solo si el trabajo está "pesado" o si se identifican bloqueantes críticos que ponen en riesgo el objetivo semanal. |
| Retrospectiva / Demo | Al final de cada ciclo Último día del ciclo (A definir) | 90 min | Mostrar los entregables completados y realizar una revisión de proceso para la mejora continua. |
- Lugar y Formato de las Reuniones
| Parámetro | Definición |
|---|---|
| Lugar | Virtual y Remoto. |
| Forma de Convocatoria | Se enviará una invitación de calendario recurrente a todos los miembros, incluyendo el enlace de acceso. |
| Norma de Asistencia | Comunicación Proactiva: Si no puedes asistir a una reunión, debes avisar al equipo con la máxima antelación (Acuerdo #3) y revisar las notas inmediatamente. |
- Gestión y Cumplimiento de las Tareas Utilizaremos un enfoque basado en el Flujo (Kanban) dentro de nuestra cadencia semanal para asegurar la transparencia, la calidad y el cumplimiento.
A. Herramientas de Gestión
Tablero de Gestión de Elementos de Trabajo: Usaremos una herramienta digital Github Project para configurar nuestro Tablero Kanban, que será el "lugar" de trabajo virtual del equipo.
Elementos de Trabajo: Todo lo que se requiera hacer debe estar capturado como una Historia de Usuario o Tarea en el tablero.
B. Mecanismos de Aseguramiento y Cumplimiento
- Definición de Listo (DoR) y Definición de Hecho (DoD):
DoR (Listo para Empezar): Una tarea solo puede tomarse si está clara, priorizada por el Dueño de Producto, y cuenta con los criterios de aceptación.
DoD (Hecho y Entregable): Una tarea solo se mueve a la columna de "Completado" si cumple todos los estándares de calidad: código revisado (aprobado por otro compañero), pruebas pasadas, y documentación actualizada. El cumplimiento se mide por la DoD.
- Gestión Proactiva de Bloqueantes:
Cualquier impedimento que detenga el progreso debe ser escalado de inmediato a través de la comunicación del equipo y en la Sync de los Lunes (Acuerdo #4).
El equipo tiene la responsabilidad colectiva de ayudar a remover los bloqueantes.
- Flujo de Trabajo (Pull System):
Las tareas se asignan por auto-selección (Pull): los miembros del equipo "jalan" la tarea priorizada del Backlog a la columna "En Curso" solo cuando tienen capacidad, fomentando el enfoque y evitando el exceso de WIP (Trabajo en Curso).
- Revisión por Pares (Code Review):
Para integrar cualquier cambio al repositorio principal, se requiere una Pull Request (PR) que debe ser aprobada por al menos un compañero (Acuerdo #2), manteniendo la calidad del código.
- Validación y Cierre de Ciclo:
La Demo de fin de ciclo no solo muestra el trabajo, sino que formaliza su aceptación por parte del cliente o instructor. Un trabajo no se considera exitoso si no ha sido aceptado.
Esta estructura proporciona la disciplina necesaria para cumplir con los objetivos del curso, al tiempo que nos da la flexibilidad de adaptar el esfuerzo (Viernes/Domingo) a la carga de trabajo real.