`` El proyecto utiliza Git como sistema de control de versiones y GitHub como plataforma de alojamiento del repositorio.

El equipo utiliza el repositorio para gestionar el código fuente y realizar un seguimiento de los cambios realizados durante el desarrollo. Cada integrante participa mediante commits asociados a las funcionalidades y tareas asignadas.

El desarrollo se organiza mediante ramas para facilitar el trabajo colaborativo y permitir la integración de los cambios realizados por los diferentes integrantes.

main
└── development
    ├── rama-aldo
    ├── rama-juan
    ├── rama-mariano
    ├── rama-mili
    └── rama-nicolas

Para identificar las versiones del sistema Utilizamos el método MAJOR.MINOR.PATCH para versionar el proyecto en sus diferentes etapas y avances

de esta manera utilizamos este método para asignar los diferentes progresos del proyecto:

0.1.0 → primera etapa de desarrollo

0.2.0 → nuevas funcionalidades

0.2.1 → corrección de errores

0.3.0 → más funcionalidades

1.0.0 → primera versión estable

MAJOR: representa cambios significativos que pueden implicar modificaciones importantes en la arquitectura o funcionamiento general del sistema.

MINOR: representa la incorporación de nuevas funcionalidades o módulos manteniendo la compatibilidad general del sistema.

PATCH: representa correcciones, mejoras menores o solución de errores que no modifican significativamente las funcionalidades existentes.

Durante el desarrollo cotidiano, las modificaciones individuales no constituyen necesariamente una nueva versión oficial del producto. Estas modificaciones son registradas mediante commits dentro de las ramas de trabajo correspondientes.

El Sistema de Gestión de Mesas para Bares está compuesto por diferentes elementos Entre los principales componentes se encuentran:

El código fuente de la aplicación

Este código corresponde a los archivos necesarios para implementar funcionalidades al sistema. Dentro de estos componentes se encuentran las vistas, módulos y funcionalidades relacionadas con la operación del establecimiento.

• Código del frontend.

• Componentes de la interfaz de usuario.

• Servicios.

• Modelos.

• Controladores.

• Código correspondiente a la lógica del sistema.

• Archivos relacionados con la comunicación entre frontend y backend.

Todo cambio realizado sobre el código deberá ser registrado mediante el sistema de control de versiones.

La interfaz gráfica es otro elemento importante de configuración del sistema. Incluye los archivos correspondientes a:

Estructura de las páginas y componentes.

Hojas de estilo.

Elementos visuales.

Iconografía.

Diseño responsive para distintos dispositivos.

Estos elementos permiten construir la interfaz utilizada por los mozos y demás usuarios del sistema para interactuar con las mesas, pedidos y servicios del establecimiento.

Los diferentes módulos o secciones funcionales del sistema también forman parte de los elementos de configuración.

Entre ellos se encuentran:

• Autenticación: Gestión del acceso de usuarios al sistema

• Dashboard: Muestra las 4 principales vistas del programa para navegar

• Mesas: Administración del estado y situación de las mesas del establecimiento

• Reservas: Permite reservar una mesa de ser necesario

• Pedidos: es la pestaña de administración de comandas y pedidos

• Cocina: Visualización y gestión de pedidos de cocina

• Bar: Visualización y gestión de pedidos correspondientes al bar

• Productos: Administración de productos disponibles

• Caja: Gestión relacionada con cobros y cierre de operaciones

La documentación generada durante el proyecto también forma parte de los elementos sujetos a gestión de configuración.

Entre ella se encuentran:

• Documentación del proyecto.

• Evidencias académicas.

• Plan de Gestión de la Configuración.

• Documentación relacionada con las funcionalidades desarrolladas.

• Información necesaria para la instalación, ejecución o mantenimiento del sistema.

Se organiza como lo mencionamos en el punto 1 y punto 3 de este mismo documentos

Nuestro grupo utilizó para establecer la línea de base del proyecto los siguientes criterios:

• Las funcionalidades incluidas se encuentren integradas correctamente.

• Los cambios hayan sido incorporados previamente a la rama correspondiente de integración.

• No existan errores críticos conocidos que impidan el funcionamiento del sistema.

• La versión pueda ejecutarse y demostrar las funcionalidades previstas para esa etapa del proyecto.

• El equipo considera que dicha versión representa un estado estable del desarrollo.

Una vez establecida una línea base, ésta se convierte en un punto de referencia controlado del proyecto. De esta manera, nosotros como equipo de desarrollo podemos conservar una referencia clara de los diferentes estados alcanzados por el SGMB durante su desarrollo.

Para el desarrollo del Sistema de Gestión de Mesas para Bares (SGMB), adoptamos una estrategia híbrida basada en Git Flow combinada con Feature Branching (por desarrollador). Esta estructura se compone de la siguiente manera:

• main: Es la rama principal y refleja el estado de producción del sistema. Solo contiene código estable y funcional.

• development: Funciona como la rama de integración principal. Aquí se unifican los cambios y nuevas funcionalidades antes de pasar a producción.

• Ramas individuales (Feature branches): Se crearon ramas específicas para cada integrante del equipo (rama-aldo, rama-juan, rama-mariano, rama-mili, rama-nicolas). En estas ramas se trabaja de forma aislada el contenido de las issues asignadas en el Sprint Backlog.

Justificación: Esta estrategia es altamente adecuada para nuestro equipo de cinco integrantes porque permite que cada desarrollador trabaje en sus tareas asignadas sin generar conflictos directos con el código de sus compañeros. Al centralizar la integración en development, el equipo puede probar la compatibilidad de los cambios antes de exponerlos en la rama main, asegurando la estabilidad del proyecto.

Para mantener el orden y la legibilidad en el repositorio, se establecieron las siguientes pautas:

Nomenclatura de ramas: Se utiliza un formato estandarizado y simple basado en el nombre del desarrollador (ej. rama-mili, rama-aldo). Esto facilita la rápida identificación del responsable de cada flujo de trabajo.

Formato de mensajes de commit: Se adoptó una convención basada en prefijos descriptivos que indican la naturaleza del cambio, seguidos de una breve explicación. Algunos ejemplos utilizados en el proyecto son:

• feat: para nuevas funcionalidades (ej. feat: primer commit del proyecto...).

• add: para la incorporación de nuevos elementos o modelos (ej. add: agregamos el model de DetallePedido).

• docs: para actualizaciones en la documentación (ej. docs: agrego el CHANGELOG.md...).

Proceso de revisión e integración: El flujo de trabajo exige que los desarrolladores suban sus cambios a sus ramas individuales. Luego, se realiza un merge hacia la rama development para integrar el trabajo del sprint. Finalmente, el paso a producción (main) se gestiona mediante Pull Requests (ej. Pull request #10), lo que permite una revisión final del código antes de la entrega definitiva.

La gestión del repositorio es una responsabilidad compartida, fomentando la colaboración activa:

• Desarrollo individual: Cada integrante (Aldo, Juan, Mariano, Mili y Nicolás) es responsable de gestionar su propia rama, asegurar que el código subido cumpla con los requerimientos de la issue asignada en el Sprint Backlog y redactar commits claros según las convenciones.

• Integración y Revisión: Todo el equipo participa en la resolución de posibles conflictos al momento de integrar las ramas individuales hacia development.

• Gestión de Releases: La aprobación de los Pull Requests hacia la rama main y la actualización de archivos clave como el README.md o el CHANGELOG.md se realizan de manera coordinada para asegurar que la versión de producción esté siempre documentada y estable.

Todos los cambios notables en este proyecto serán documentados en este archivo.

El formato está basado en Keep a Changelog, y este proyecto adhiere a Semantic Versioning.

• Added para nuevas características o pantallas.
• Changed para cambios en funcionalidades o estilos existentes.
• Deprecated para características que se eliminarán pronto.
• Removed para características eliminadas.
• Fixed para solución de errores (bugs).
• Security para parches de seguridad.

• Documentación inicial del proyecto (arquitectura, requerimientos y modelo de datos).
• Estructura base del proyecto Angular (v20).
• Configuración inicial del proyecto Django.
• Django, model inicial mesas.
• Django, model inicial pedidos.
• Django, model inicial productos.
• Django, model inicial usuarios.
• Maquetado HTML/CSS de la pantalla de inicio (Home).
• Maquetado HTML/CSS de la pantalla de registro (Registro).
• Maquetado HTML/CSS de la pantalla de recuperar contraseña (Recupero-password).
• Maquetado HTML/CSS de la pantalla de caja (Caja).
• Maquetado HTML/CSS de la pantalla de comandas (Comandas).
• Maquetado HTML/CSS de la pantalla de dashboard (Dashboard).
• Maquetado HTML/CSS de la pantalla de mesas (Mesas).
• Maquetado HTML/CSS de la pantalla de pedidos (Pedidos).
• Maquetado HTML/CSS de la pantalla de productos (Productos).

• Actualización de los estilos CSS globales y variables de diseño (colores, tipografía).

Link Anexo

Para seleccionar el modelo de calidad aplicable a SGMB se aplicaron los cuatro Criterios de Selección de un Modelo de Calidad vistos en clase: Tipo y Contexto del Sistema, Madurez del Equipo y la Organización, Requerimientos del Cliente y Mercado, y Ciclo de Vida y Metodología de Desarrollo.

• Respecto al Criterio 1: SGMB es un sistema no crítico: gestiona mesas, pedidos y consumos en un bar, y una falla no compromete vidas ni pérdidas millonarias como sí ocurriría en sistemas médicos, aeronáuticos o bancarios. Según este criterio, en este tipo de contexto se debe priorizar la velocidad de entrega y la usabilidad por sobre el rigor regulatorio extremo, lo cual orienta la elección hacia un enfoque ágil antes que hacia modelos exhaustivos pensados para sistemas críticos.

• Respecto al Criterio 2: El equipo es un grupo estudiantil sin procesos organizacionales formalizados ni historial de auditorías de madurez (equivalente, en términos de CMMI, a un nivel inicial). Adoptar un modelo como CMMI o ISO 9001 implicaría un salto de madurez no alcanzable en este contexto y generaría burocracia sin valor real; el paso alcanzable y coherente con la madurez actual del equipo es formalizar y reforzar las prácticas ágiles que ya se vienen aplicando (Scrum, Definition of Done, code review obligatorio).

• Respecto al Criterio 3: SGMB es un proyecto académico sin un cliente externo que exija certificación ISO 9001 ni cumplimiento de normativas regulatorias como GDPR, lo que refuerza que un modelo de proceso/madurez orientado a certificación no es pertinente en este caso.

• Respecto al Criterio 4: El ciclo de vida y la metodología de desarrollo de SGMB son explícitamente ágiles: el equipo trabaja con Scrum en sprints de 3 semanas, con ramas individuales que se integran a development únicamente mediante Pull Request y code review obligatorio, y con una Definition of Done formal que condiciona el cierre de cada tarea. Este criterio indica que, para startups y proyectos ágiles, corresponden "enfoques integrados como Built-in Quality y automatización" en lugar de modelos de proceso tradicionales.

Los cuatro criterios convergen en la misma conclusión: se descartan ISO 9001 y CMMI por estar diseñados para certificar o auditar la madurez de organizaciones establecidas, algo desproporcionado para un sistema no crítico desarrollado por un equipo estudiantil sin cliente que lo exija. Se selecciona, en cambio, la combinación del Modelo Ágil de Calidad (Built-in Quality) con el modelo de producto ISO/IEC 25010.

El Modelo Ágil de Calidad define el mecanismo por el cual la calidad se construye sprint a sprint —mediante la Definition of Done ya implementada, el code review obligatorio en cada Pull Request y la validación continua antes de integrar a development— en lugar de verificarse recién al final del desarrollo, algo coherente tanto con el Criterio 1 (priorizar velocidad de entrega) como con el Criterio 2 (un paso de madurez alcanzable para el equipo).

El modelo ISO/IEC 25010 aporta, por su parte, las características de producto concretas y medibles que ese proceso ágil debe garantizar en cada incremento: Seguridad (autenticación OAuth con Google/GitHub), Compatibilidad (integración entre PostgreSQL y MongoDB, y comunicación en tiempo real vía Django Channels/WebSockets), Fiabilidad y Portabilidad (despliegue contenerizado con Docker), entre otras.

Esta combinación resulta la más pertinente para SGMB porque cubre simultáneamente el qué (los atributos de calidad medibles del sistema, definidos por ISO/IEC 25010) y el cómo (el proceso ágil concreto mediante el cual el equipo los garantiza en cada sprint, definido por el Modelo Ágil de Calidad), ajustándose de forma proporcional al tipo de sistema, a la madurez real del equipo y a la metodología de desarrollo efectivamente utilizada.

En el desarrollo de una solución para el sector gastronómico como el SGMB, el entorno de trabajo exige velocidad, precisión y tolerancia cero a la inestabilidad. Estos tres atributos son fundamentales frente a otras características del modelo por las siguientes razones operativas y de negocio:

• Usabilidad como barrera de adopción: La rotación de personal en gastronomía es frecuente. Si la aplicación resulta confusa o requiere múltiples clics para cargar una comanda en un celular, el mozo perderá tiempo frente al cliente. Al ser tu rol específico el de QA/Tester orientado a dispositivos móviles, validar que la navegación y la paleta de colores sean instintivas es prioritario para asegurar la viabilidad del MVP.
• Eficiencia de Desempeño para garantizar el "Tiempo Real": El valor diferencial de esta herramienta es eliminar los viajes manuales del mozo a la cocina. Si los tiempos de respuesta se degradan o los eventos por WebSockets sufren latencia, el cocinero recibirá el pedido tarde y el salón perderá la sincronización, generando cuellos de botella que anulan la promesa tecnológica del producto.
• Fiabilidad operativa crítica: A diferencia de sistemas de uso esporádico, una caída del sistema durante un horario pico de servicio (ej. un sábado a la noche) paraliza por completo el restaurante. La incapacidad temporal de procesar un cobro en la caja o la pérdida de comandas en tránsito por una falla de la base de datos se traduce en un impacto económico directo y una pésima experiencia para el comensal.

La revisión se enfoca específicamente en la implementación de la arquitectura backend en Django / DRF / Django Channels y la arquitectura frontend en Angular.

Se destaca la organización modular del repositorio, el uso de patrones modernos en Angular, el manejo de transacciones atómicas y la comunicación en tiempo real mediante WebSockets. A continuación, se detallan las fortalezas técnicas y los hallazgos puntuales de refactorización en el código base.

• Modelo de Usuario Personalizado: Consiste en crear un sistema de usuarios completamente personalizado en Django, asegurando un control total sobre los datos de autenticación y la estructura de permisos desde las bases del framework. Se utiliza el correo electrónico como identificador único en el campo USERNAME_FIELD y se garantiza la seguridad de las credenciales mediante hashing gestionado por UsuarioManager.
• Separación de Serializadores: Uso estratégico de serializadores diferenciados para operaciones de lectura y escritura. La implementación de componentes como PagoReadSerializer frente a PagoWriteSerializer optimiza la transferencia de datos anidados en peticiones GET sin comprometer el rendimiento de las operaciones POST o PUT.
• Integridad Transaccional: Aplicación del decorador transaction.atomic() en el método perform_create de PagoViewSet. Esto asegura que el registro del cobro, el cambio de estado del pedido a CERRADO y la transición de la mesa a estado LIBRE se ejecuten como una unidad lógica indivisible.
• Arquitectura de Eventos Asíncronos: Gestión eficaz de señales de Django (post_save) para la emisión automática de eventos vía WebSockets. La integración con un broker de Redis y el uso de PedidoConsumer permiten una sincronización fluida con el cliente.

• Estado HTTP Incorrecto en Eliminación de Mesas:

  • Ubicación: backend/mesas/views.py en el método MesaDetailAPIView.delete.
  • Detalle: Al ejecutar mesa.delete(), la vista responde con status.HTTP_400_BAD_REQUEST tras una eliminación correcta.
  • Recomendación: Corregir el código de respuesta a status.HTTP_204_NO_CONTENT.

• Duplicidad de Modelos de Datos:

  • Ubicación: backend/comandas/models.py y backend/pedidos/models.py.
  • Detalle: El modelo Comanda duplica campos de cabecera (numero_mesa, numero_pedido), mientras que Pedido maneja la estructura real de ítems.
  • Recomendación: Derivar las comandas directamente de los eventos de Pedido para evitar descalces de datos entre cocina y salón.

• Uso de Angular Signals y Estado Reactivo: Adopción del esquema de reactividad de Angular (signal(), computed(), effect()) para calcular métricas y filtros sin sobrecargar el ciclo de detección de cambios.
• Actualización Optimista (Optimistic UI): El módulo de Comandas emplea una estrategia de actualización inmediata en la interfaz. Al desplazar tarjetas entre columnas, la UI se actualiza preventivamente; en caso de error en la comunicación con la API, el sistema realiza un rollback automático al estado previo.
• Integración de WebSockets con Signals: El servicio WebsocketService actúa como puente entre los mensajes del canal ws/pedidos/ y la señal ultimoEvento, permitiendo una arquitectura desacoplada donde los componentes reaccionan a datos en tiempo real de forma reactiva.
• Diseño Modular y Estructura CSS: Aplicación de una metodología de diseño consistente basada en prefijos sgmb-* y nomenclatura BEM (Block Element Modifier), asegurando la escalabilidad del estilo visual y la adaptabilidad responsiva.

• Hardcodeo de URLs de Servicios:

  • Ubicación: Servicios de caja, producto, websocket, comandas, mesa y pedido.
  • Detalle: La URL base (http://localhost:8000/api/) está declarada como cadena de texto fija en cada archivo.
  • Recomendación: Extraer los endpoints hacia src/environments/environment.ts para habilitar despliegues dinámicos.

• Definición Incompleta de Interceptores y Guards:

  • Ubicación: Archivos auth-guard.ts y auth-interceptor.ts.
  • Detalle: authGuard permite el acceso incondicional (return true) y authInterceptor no adjunta la cabecera Authorization: Bearer <token>.
  • Recomendación: Implementar la comprobación activa de tokens en el guardián de rutas e implementar la inyección automática de credenciales JWT en el interceptor para todas las solicitudes salientes.

Historia de Usuario incompleta, ambigua:
US09: Como administrador- Quiero poder iniciar sesión en el sistema.

Link:
https://github.com/OpenCodeISPC/Sistema-de-Gestion-de-Mesas/issues/25

Esta US está incompleta, es ambigua y no es testable ya que carece de los siguientes conceptos:

• Incumple el formato completo: Aunque menciona el rol ("administrador"), le falta especificar claramente la acción y el beneficio esperado en una sola oración estructurada.
• Ambigüedad: No define qué credenciales se utilizan (¿correo y contraseña?, ¿nombre de usuario?), ni qué validaciones de seguridad o manejo de errores existen (¿qué sucede si los datos son incorrectos o el usuario está inactivo?).
• Falta de verificabilidad: Al no tener criterios de aceptación, es imposible para el equipo de testing o desarrollo saber exactamente cuándo dar la historia por terminada (no se puede escribir un test automatizado a partir de esta descripción vaga).

Para que NO sea ambigua, sea verificable y completa la US debería estar redactada con los siguientes conceptos:

• Estructura correcta de User Story: Como [rol], quiero [acción], para [beneficio].
• Criterios de aceptación (Gherkin): Definir escenarios de éxito y de error mediante la estructura Dado / Cuando / Entonces para que el requerimiento sea 100% testeable.

Título: Como administrador - Quiero poder iniciar sesion en el sistema

Descripción:
Como administrador del sistema, quiero poder dar de alta a un nuevo usuario completando sus datos personales y asignándole un rol, para garantizar el control de acceso a la plataforma.

Campos requeridos:

• Nombre
• Apellido
• Email (único)
• Contraseña
• Rol (ej: Administrador, Mozo, Cocinero)

Criterios de Aceptación:

• Escenario 1 (Registro exitoso):

  • Dado que el administrador está en la sección de gestión de usuarios,
  • Cuando completa todos los campos obligatorios con datos válidos y presiona "Guardar",
  • Entonces el sistema almacena el usuario de forma segura y muestra un mensaje de éxito.

• Escenario 2 (Error por email duplicado):

  • Dado que se intenta registrar un correo ya existente,
  • Cuando se envía el formulario,
  • Entonces el sistema rechaza la operación y muestra un aviso de error.

• Proyecto: Sistema de Gestión de Mesas Para Bares (SGMB)
• Objeto de auditoría: Repositorio control de versiones, Estructura de trabajo documentada, Changelog, Pull Requests

Se verificó el cumplimiento del formato de nombres definidos en el Plan de Gestión de la Configuración (main/…, development/…, ramas-individuales/…).

Integración de la Línea Base (development → main)

Análisis del cumplimiento de la convención de mensajes de commit por integrante.

Nota aclaratoria sobre la participación:
De común acuerdo en el equipo, la auditoría focalizó el control estricto sobre las integraciones a la rama principal. La diferencia en el volumen de commits entre integrantes no refleja la participación real del equipo, dado que los miembros con menor cantidad de commits realizaron tareas orientadas a maquetación, diseño de UI/UX y documentación, cuyo flujo de trabajo no requiere el registro recurrente de commits individuales de código.

Porcentaje total de inconsistencias en mensajes de commit: 14.4% (13/90).

• Documentación del Proyecto: Se encuentra correctamente estandarizada, actualizada y accesible para todo el equipo.
• Historial de Cambios (CHANGELOG.md): Cumple con la estructura acordada, registrando de forma precisa los avances y correcciones de la versión v0.1.0 sin inconsistencias detectadas.

El proceso de Gestión de la Configuración evidencia un cumplimiento global satisfactorio:

1. Se alcanzó un 100% de alineación en la creación de ramas y en la integración de la Línea Base (main).
2. La documentación general y el Changelog cumplen completamente con los estándares.
3. Se identificó un 14.4% de inconsistencias en los mensajes de commit, motivado por mensajes ambiguos en la etapa de desarrollo rápido sobre development.

Acción de mejora: Para la próxima etapa se propone configurar un linter o hook de pre-commit (commitlint) que impida confirmar mensajes fuera del estándar tipo: descripción.

Link Anexo

En el Nivel 3 de CMMI, los procesos están claramente documentados, estandarizados e integrados a nivel de equipo. A diferencia del Nivel 2 (donde la gestión se hace proyecto a proyecto de forma aislada), en el Nivel 3 existen guías globales, convenciones de código compartidas, herramientas homogéneas y criterios de calidad unificados que todo el grupo sigue de manera consistente. 

• Evidencia: El equipo redactó y aplicó un Plan de Gestión de la Configuración formal. Se definió una estrategia de ramificación híbrida (Git Flow + Feature Branches por desarrollador) con la estructura main, development y ramas individuales nominales (rama-aldo, rama-juan, rama-mariano, rama-mili, rama-nicolas).
• Justificación técnica: Se prohibieron los commits directos sobre ramas principales. Todas las integraciones requirieron obligatoriamente la creación de Pull Requests y Code Reviews. Además, el equipo adoptó convenciones estrictas para mensajes de commit (feat:, add:, docs:, fix:), el estándar de versionado semántico SemVer (MAJOR.MINOR.PATCH) para fijar baselines (líneas base) y el mantenimiento continuo de un archivo CHANGELOG.md estructurado bajo Keep a Changelog.

• Evidencia: El grupo definió formalmente una Definition of Done (DoD) unificada que establece los requisitos mínimos para considerar finalizada cualquier issue (cumplimiento del principio SRP, arquitectura modular en Angular, docstrings en Django, respuesta adaptativa/responsive y documentación en Wiki/README).
• Justificación técnica: Para validar la calidad, el equipo implementó pruebas automatizadas tanto en el backend (PagoApiTests, CierreCajaApiTests y AuditoriaMongoTests utilizando Django TestCase y APIClient) como en el frontend (archivos .spec.ts con Karma/Jasmine). Adicionalmente, crearon y ejecutaron una Planilla de Casos de Prueba (Test Cases) con 16 campos estandarizados (ID, precondiciones, pasos, resultado esperado, etiquetas y capturas de evidencia de ejecución) para asegurar la regresión y sanidad del sistema.

• Evidencia: Creación del script de automatización actualizar-entorno.sh y la configuración de orquestación con docker-compose.yml.
• Justificación técnica: El script actualizar-entorno.sh automatiza la verificación y sincronización de credenciales entre los archivos .env raíz y backend/.env.desarrollo, gestiona la limpieza de volúmenes de PostgreSQL en conflicto y levanta la infraestructura distribuida compuesta por 5 contenedores (sgmb_frontend, sgmb_backend, sgmb_postgres, sgmb_mongo y sgmb_redis). Además, el proceso de negocio incluye una capa de auditoría no relacional automatizada en MongoDB que registra asíncronamente eventos críticos (PAGO_REGISTRADO, CIERRE_CAJA, CAJA_REABIERTA) garantizando la trazabilidad de operaciones sin bloquear el flujo principal.

Problema (Síntoma): El equipo se retrasó una semana en la entrega del módulo de reservas y el dashboard de mesas del sistema SGMB.

1. ¿Por qué nos retrasamos en la entrega del módulo? Porque la integración final entre el frontend (Angular) y el backend (Django REST) tomó mucho más tiempo del estimado.
2. ¿Por qué la integración tomó más tiempo del estimado? Porque al conectar los servicios empezamos a recibir constantes bloqueos de CORS y fallos de autenticación con los tokens Simple JWT.
3. ¿Por qué tuvimos esos problemas de configuración de red y autenticación? Porque durante el desarrollo del sprint, cada programador estuvo levantando el backend y el frontend localmente con configuraciones distintas, en lugar de usar un entorno unificado.
4. ¿Por qué no usamos un entorno unificado desde el día uno del sprint? Porque el archivo docker-compose que debía orquestar PostgreSQL, Redis, Django y Angular no estaba terminado ni estabilizado.
5. ¿Por qué no estaba terminado el entorno de Docker? Porque subestimamos la complejidad de la contenerización múltiple en la reunión de estimación y no asignamos esa tarea de infraestructura como bloqueante antes de empezar a programar las vistas.

Causa Raíz: Falla en la planificación ágil (subestimación) al no considerar la estabilización de la infraestructura (Docker) como un prerrequisito bloqueante para el desarrollo de funcionalidades integradas. Tratar el síntoma sería simplemente arreglar el CORS; tratar la causa raíz, según la teoría, implica cambiar el proceso.

2.1 Lecciones Aprendidas: Integración de Entornos SGMB

Contexto

Este incidente ocurrió durante el Sprint 3 (septiembre de 2026) del desarrollo del Sistema de Gestión de Mesas Para Bares (SGMB) por parte del equipo OpenCode. El equipo se encontraba en la fase de conectar el frontend desarrollado en Angular (v20) con la API REST construida en Django.

Problema

Se produjo un retraso de una semana respecto al cronograma planificado para la entrega funcional del módulo de reservas y el dashboard de mesas. Al intentar probar las funcionalidades de forma conjunta, surgieron múltiples errores de integración, constantes bloqueos por políticas de CORS (Cross-Origin Resource Sharing) y fallos en el manejo y persistencia de la autenticación con tokens Simple JWT.

Causa

Basado en el análisis de causa raíz y el Diagrama de Ishikawa realizado previamente por Aldo, se identificó que la causa profunda no fue un problema de código, sino una falla en la planificación y gestión del entorno de desarrollo. Se subestimó el esfuerzo y la complejidad de la contenerización múltiple. El equipo no estableció la configuración definitiva del entorno unificado (el archivo docker-compose orquestando PostgreSQL, Redis, Django y Angular) como una tarea bloqueante y prioritaria. Como consecuencia, el desarrollo avanzó sobre entornos locales fragmentados, ocultando los problemas de red interna que detonaron al intentar la integración final.

Solución aplicada

Se suspendió temporalmente el desarrollo de nuevas vistas para enfocar el esfuerzo colectivo en la infraestructura. Se estabilizó el entorno de Docker, asegurando que todos los servicios se comunicaran correctamente dentro de la misma red virtual. Se corrigieron los orígenes permitidos en la configuración de Django para habilitar el consumo desde Angular y se automatizó la carga de datos de prueba (seeding) en la base de datos al levantar los contenedores, garantizando que todos los miembros del equipo OpenCode trabajaran exactamente bajo las mismas condiciones.

Recomendaciones para el futuro

Para que esta experiencia se transforme en conocimiento reutilizable, se establecen las siguientes pautas:

   - Definition of Ready (DoR): Ninguna historia de usuario de integración entre cliente y servidor puede iniciar su desarrollo si el entorno unificado mediante Docker no está estabilizado y disponible para todos los programadores.

   - Estimación de Infraestructura: Las tareas de configuración de red, seguridad (CORS) y despliegue local deben ser ingresadas al backlog, recibir estimaciones formales (por ejemplo, mediante Planning Poker) y no ser tratadas como tareas implícitas o secundarias.

   - Medición del Esfuerzo (PSP): Se recomienda a los desarrolladores registrar el tiempo real dedicado a la configuración de entornos frente al tiempo estimado inicialmente, generando estadísticas personales que mejoren la precisión de las estimaciones en proyectos futuros.

   - Base de Conocimiento: Mantener un registro documentado de las configuraciones específicas necesarias para conectar Angular y Django en este entorno, para evitar repetir el ciclo de investigación y prueba y error.

Utilizamos Gemini como apoyo para estructurar y redactar las lecciones aprendidas del equipo OpenCode. Tomamos como base la propuesta de redacción sobre la estandarización del entorno con Docker, y ajustamos el tono y los detalles técnicos con criterio propio para reflejar fielmente la resolución del conflicto de integración entre Angular y Django.