Pitch Sprint 1 - Davidcuama/via-coinogas GitHub Wiki
Sprint 1 — Radicación y analítica base
Resultados del Sprint 1 del proyecto VIA Compras para Coinogas. Todas las cifras salen del repositorio y de las issues, y se pueden verificar filtrando por el milestone «Sprint 1 - Radicación y analítica base».
1. El punto de partida
Hoy un requerimiento de compra en Coinogas se diligencia en un Excel, viaja por correo y alguien lo vuelve a digitar en la sábana.
Tres consecuencias que el cliente describió el 24 de julio:
- Se pierde la trazabilidad. Compras no tiene un registro consultable de lo que se pidió originalmente.
- Se arrastran errores. Reutilizar un formato viejo trae especificaciones que ya no aplican — el caso del Fluke 725.
- Se frena la cotización. Un formato incompleto no se puede cotizar, y el Excel no impide enviarlo incompleto.
El cliente resumió el proceso actual en dos palabras: tedioso y desgastante.
2. Objetivo del Sprint 1
Entregar el formulario digital de radicación con validación de campos obligatorios, soporte para múltiples ítems y persistencia en base de datos —sustituyendo el diligenciamiento del Excel para el flujo básico del solicitante— y exponer sobre esa información las vistas de solo lectura y el tablero inicial de indicadores en Power BI.
El objetivo tiene dos mitades: la radicación y la analítica. El resultado del sprint es distinto en cada una.
3. Qué funciona hoy
El formulario reemplaza al Excel
En /requerimientos/nuevo/ está el ADM-F-22 campo por campo: encabezado, justificación, prioridad, fecha requerida y la tabla de ítems.
Se conservó la estructura del formato institucional a propósito: nadie tiene que reaprender el procedimiento. Lo que cambia es que el sistema se hace cargo de lo que antes dependía de la disciplina de cada persona.
El sistema impide radicar incompleto
Al enviar el formulario incompleto se resalta cada campo faltante con un mensaje que indica qué se espera, y lo que ya estaba diligenciado no se pierde.
El formato pide al pie no dejar espacios vacíos; esa era una instrucción escrita que nadie podía hacer cumplir y ahora es una regla que el sistema aplica. La validación no vive solo en el navegador: si la petición llega por fuera del formulario, el servidor la rechaza igual.
Varios ítems en una sola solicitud
Cada requerimiento admite múltiples ítems con cantidad, unidad, descripción y especificaciones técnicas. El total se calcula automáticamente y advierte cuando es parcial porque falta algún precio. Las marcas de requiere calibración y reembolsable viajan con el ítem, porque cambian la forma de comprarlo.
Borrador
El formulario a medio llenar se puede guardar como borrador y recuperar después: vuelven el encabezado y los ítems con sus especificaciones y sus marcas. Si al solicitante lo interrumpen a mitad de un requerimiento, no pierde el trabajo. Es el equivalente a guardar el Excel a medias, pero sin el archivo suelto en el escritorio.
Radicación y consecutivo
Al radicar, el requerimiento recibe un número único e irrepetible con el formato REQ-2026-0001. Ese número es la referencia con la que el solicitante puede consultar su solicitud. Lo genera la base de datos de forma que dos personas radicando al mismo tiempo nunca reciben el mismo, y recargar la pantalla no crea un duplicado.
Confirmación
La pantalla de confirmación muestra el consecutivo destacado, el resumen del requerimiento, cuántos ítems se radicaron, el detalle de cada uno y el total estimado.
Notificación al área de compras
Al radicar se envía un correo al área de compras. El analista se entera sin tener que entrar a revisar el sistema, y el correo ya trae todo lo necesario para salir a cotizar: los ítems, sus especificaciones, cuáles requieren calibración y el total estimado. Aquí desaparece la doble digitación.
4. Los números del sprint
| Historias | Story points | |
|---|---|---|
| Comprometido | 12 | 40 |
| Entregado del compromiso | 10 | 30 |
| No entregado | 2 | 10 |
| Adelantado de Sprint 2 / Backlog | 5 | 18 |
| Total entregado | 15 | 48 |
El equipo entregó el 100% de lo comprometido salvo dos historias de la capa analítica (HU-29 y HU-30, Power BI), que dependían de una decisión pendiente con el cliente sobre licenciamiento y pasaron a Sprint 2. A cambio, se adelantó trabajo que originalmente estaba planeado para Sprint 2 o para el backlog: la marca de calibración y reembolsable (HU-08), las especificaciones técnicas del ítem (HU-09), el cálculo de totales (HU-10), el guardado de borrador (HU-18) y la notificación por correo al área de compras (HU-19).
5. Lo que no se entregó
- HU-29 - Vistas analiticas y acceso de solo lectura y HU-30 - Tablero inicial de indicadores en Power BI: quedaron condicionadas a confirmar con el cliente si Coinogas cuenta con licencias de Power BI. Pasan al Sprint 2.
6. Próximos pasos (Sprint 2)
Sprint 2 se enfoca en lo que pidió el cliente -adjuntar archivos, un aviso de confirmación antes de enviar y un correo de confirmación al solicitante- además de cerrar la capa analítica pendiente (HU-29 y HU-30) y resolver las observaciones del Sprint 1.