Repository navigation
Sprint 2: MVP V2
Estado del documento: versión consolidada para la Wiki. Las cifras financieras son estimaciones académicas; los casos de prueba y el protocolo de usabilidad están documentados, pero no se marcan como ejecutados sin evidencia. Las historias indicadas como completadas corresponden a lo reportado por el equipo: US15, US16 y US21.
La preoperación de Paralelo contempla el esfuerzo estimado para revisar, integrar y unificar dos programas existentes, realizar ajustes, ejecutar pruebas y preparar la entrega del MVP.
Para el cálculo se utiliza una tarifa académica de referencia de $15.000 COP por hora, considerando un equipo de cuatro estudiantes de sexto semestre de Ingeniería de Sistemas.
| Actividad de integración | Horas estimadas | Tarifa por hora (COP) | Subtotal (COP) |
|---|---|---|---|
| Revisión de los dos programas existentes | 6 | $15.000 | $90.000 |
| Análisis de compatibilidad y planificación | 8 | $15.000 | $120.000 |
| Unificación del backend y componentes compartidos | 20 | $15.000 | $300.000 |
| Integración del frontend y conexión entre componentes | 16 | $15.000 | $240.000 |
| Configuración y ajustes de integración | 8 | $15.000 | $120.000 |
| Pruebas de funcionamiento y corrección de errores | 12 | $15.000 | $180.000 |
| Documentación y preparación de la entrega | 6 | $15.000 | $90.000 |
| TOTAL DE PREOPERACIÓN ESTIMADO | 76 | $1.140.000 COP |
Supuestos del cálculo: las 76 horas corresponden al esfuerzo total estimado del equipo, no a las horas individuales de cada integrante. La tarifa de $15.000 COP por hora es un supuesto académico utilizado para valorar el trabajo de integración; no corresponde a un salario oficial ni a pagos efectivamente realizados.
Este presupuesto representa únicamente el esfuerzo estimado de integración del proyecto recibido. No incluye el costo histórico del desarrollo previo de los programas.
El repositorio describe una arquitectura con frontend React, backend FastAPI, PostgreSQL mediante Supabase, almacenamiento y proveedores de modelos de inteligencia artificial. No se dispone de información confirmada sobre despliegue productivo, planes contratados o pagos actuales. Por esta razón, se presenta un escenario de operación académica de bajo costo, suponiendo desarrollo y demostración local y uso de planes gratuitos cuando estén disponibles.
| Rubro | Supuesto del escenario | Costo mensual estimado |
|---|---|---|
| Hosting del frontend y backend | Ejecución local para desarrollo/demostración | $0 |
| Base de datos | Plan gratuito de Supabase, dentro de sus límites | $0 |
| Almacenamiento de archivos | Uso dentro de las cuotas gratuitas disponibles | $0 |
| Dominio propio | No se incluye en el escenario | $0 |
| Monitoreo y copias de seguridad pagadas | No se incluyen servicios pagos en este escenario | $0 |
| TOTAL MENSUAL FIJO DEL ESCENARIO | Solo si se cumplen los supuestos | $0 COP |
Este total no confirma que la operación real sea gratuita. Si el equipo contrata alojamiento, dominio, almacenamiento, base de datos u otros servicios pagos, esos costos deben agregarse. El trabajo de mantenimiento puede representar un costo económico de tiempo, aunque no implique un desembolso monetario.
Los costos variables dependen principalmente del proveedor y modelo de IA seleccionado, el número de imágenes procesadas, las solicitudes de planificación y los mensajes enviados al chat. El repositorio contempla distintos proveedores y la posibilidad de utilizar modelos locales; no se cuenta con un volumen de consumo medido ni con un proveedor de pago confirmado.
| Rubro variable | Forma de cálculo |
|---|---|
| Análisis de esquemáticos con IA | Número de solicitudes × tarifa del modelo de visión |
| Planificación de montaje con IA | Número de solicitudes × tarifa del modelo de razonamiento |
| Consultas de chat | Número de mensajes × tarifa del modelo utilizado |
| Almacenamiento adicional | Consumo que exceda la cuota gratuita × tarifa del proveedor |
Fórmula general:
Costo variable mensual = costo de análisis de imágenes + costo de planificación + costo de chat + costo de almacenamiento adicional
No se asigna una cifra mensual definitiva a los costos variables porque faltan el modelo/proveedor seleccionado, las tarifas aplicables y el consumo esperado. Si se usa un modelo local o un nivel gratuito de API, el costo monetario podría ser de $0 dentro de sus límites; eso no debe confundirse con una garantía de gratuidad ni con el costo del equipo y del trabajo realizado.
| Concepto | Valor |
|---|---|
| Preoperación estimada para integración | $1.900.000 COP |
| Costos fijos mensuales del escenario local/gratuito | $0 COP, sujeto a supuestos |
| Costos variables mensuales | Pendientes de proveedor y consumo |
| Costo mensual total | No determinado; depende del escenario real |
Limitación financiera: este presupuesto es una estimación académica de referencia, no una declaración de gastos reales. Antes de establecer un presupuesto definitivo deben verificarse las horas del equipo, los servicios efectivamente contratados, el método de despliegue, las cuotas disponibles y el consumo de modelos de IA.
| Código | Riesgo | Descripción |
|---|---|---|
| R1 | Interpretación incorrecta del esquemático | El procesamiento de imágenes puede identificar componentes o conexiones incorrectos. |
| R2 | Plan de montaje inválido | La distribución propuesta puede incumplir restricciones eléctricas o físicas. |
| R3 | Indisponibilidad de servicios de IA | Una interrupción del proveedor puede impedir el análisis o la generación de instrucciones. |
| R4 | Consumo excesivo de recursos | Consultas, reintentos o imágenes pueden incrementar los costos. |
| R5 | Pérdida o exposición de información | Sesiones, archivos o credenciales pueden verse afectados por problemas de seguridad o disponibilidad. |
| R6 | Fallos de autenticación o autorización | Una configuración incorrecta puede permitir accesos no autorizados. |
| R7 | Modificaciones incorrectas mediante IA | El sistema puede interpretar incorrectamente una solicitud de cambio. |
| R8 | Dificultades de usabilidad | Los usuarios pueden no comprender instrucciones o mensajes de validación. |
| R9 | Cobertura insuficiente de pruebas | Los defectos pueden pasar inadvertidos si las funciones críticas no tienen pruebas adecuadas. |
| R10 | Dependencia de servicios externos | Cambios de tarifas, límites o interfaces pueden afectar el funcionamiento. |
| R11 | Problemas de integración entre los programas | Diferencias de estructura, dependencias o contratos de datos pueden generar incompatibilidades. |
Los valores siguientes son una propuesta preliminar para la entrega académica. La probabilidad y el impacto deben revisarse con el equipo y ajustarse con evidencia del proyecto. Los niveles se interpretan con la matriz institucional del Sprint 2.
| Código | Riesgo | Probabilidad propuesta | Impacto propuesto | Nivel resultante |
|---|---|---|---|---|
| R1 | Interpretación incorrecta del esquemático | Posible | Crítico | Moderado |
| R2 | Plan de montaje inválido | Posible | Crítico | Moderado |
| R3 | Indisponibilidad de servicios de IA | Poco probable | Moderado | Bajo |
| R4 | Consumo excesivo de recursos | Posible | Moderado | Moderado |
| R5 | Pérdida o exposición de información | Poco probable | Catastrófico | Alto |
| R6 | Fallos de autenticación o autorización | Poco probable | Crítico | Moderado |
| R7 | Modificaciones incorrectas mediante IA | Posible | Moderado | Moderado |
| R8 | Dificultades de usabilidad | Muy probable | Moderado | Moderado |
| R9 | Cobertura insuficiente de pruebas | Muy probable | Crítico | Moderado |
| R10 | Dependencia de servicios externos | Posible | Moderado | Moderado |
| R11 | Problemas de integración entre programas | Posible | Crítico | Moderado |
| Probabilidad ↓ / Impacto → | Despreciable | Marginal | Moderado | Crítico | Catastrófico |
|---|---|---|---|---|---|
| Seguro | Bajo | Moderado | Alto | Extremo | Extremo |
| Muy probable | Mínimo | Bajo | Moderado | Moderado | Extremo |
| Posible | Mínimo | Bajo | Moderado | Moderado | Alto |
| Poco probable | Mínimo | Bajo | Bajo | Moderado | Alto |
| Raro | Mínimo | Mínimo | Bajo | Moderado | Alto |
La clasificación de los riesgos es una estimación inicial, no el resultado de mediciones históricas. Se debe revisar periódicamente y después de cambios importantes en la integración.
R = Responsable; A = Aprobador/responsable último; C = Consultado; I = Informado. Los roles son propuestos y deben confirmarse con la organización real del equipo.
| Actividad de gestión de riesgos | Product Owner | Scrum Master | Tech Lead | Equipo de desarrollo |
|---|---|---|---|---|
| Identificar riesgos | A | R | C | C |
| Analizar probabilidad e impacto | A | C | R | C |
| Aprobar mitigaciones | A | C | R | C |
| Implementar controles técnicos | I | I | A | R |
| Revisar resultados de pruebas | C | I | A | R |
| Actualizar el inventario de riesgos | A | R | C | C |
| Código | Estrategia | Responsable sugerido |
|---|---|---|
| R1 | Probar esquemáticos de referencia, entradas ambiguas e imágenes inválidas. | Tech Lead / desarrollo |
| R2 | Validar conexiones, posiciones y restricciones antes de aceptar el plan. | Equipo de desarrollo |
| R3 | Gestionar errores, tiempos de espera y respuestas no disponibles. | Tech Lead |
| R4 | Controlar límites de solicitudes, reintentos y consumo por operación. | Backend |
| R5 | Verificar permisos, copias de seguridad y protección de credenciales. | Responsable técnico |
| R6 | Probar autenticación, autorización y acceso a recursos. | Backend |
| R7 | Verificar que los cambios solicitados se reflejen en circuito e instrucciones. | Equipo de desarrollo |
| R8 | Ejecutar pruebas de usabilidad con usuarios representativos. | Product Owner / UX |
| R9 | Mantener casos de prueba por cada historia entregada y registrar su ejecución. | Equipo de desarrollo |
| R10 | Documentar proveedores, tarifas, límites y alternativas. | Tech Lead |
| R11 | Verificar contratos de datos, dependencias, configuración y flujos de extremo a extremo entre los programas integrados. | Tech Lead / desarrollo |
Las mitigaciones son propuestas hasta que exista evidencia de implementación.
Se reemplaza el conjunto anterior de casos de prueba por las historias que aparecen en las capturas del tablero de Shared-Reasoning:
- US12 — Buscar curso mediante código (Shared-Reasoning #15).
- US13 — Inscribirse a un curso (Shared-Reasoning #16).
- US14 — Crear ejercicio (Shared-Reasoning #18).
- US15 — Consultar ejercicios (Shared-Reasoning #19).
- US17 — Eliminar ejercicio (Shared-Reasoning #21).
Se definen dos escenarios por historia: un camino feliz y un camino alternativo. Los pasos y resultados se deben contrastar con los criterios de aceptación y las validaciones realmente implementadas. Las capturas confirman los nombres de las historias, pero no muestran todos sus criterios de aceptación; por ello, los escenarios siguientes son una base para adaptar antes de automatizar. Todos los casos están pendientes de ejecución y no se consideran aprobados hasta contar con resultados y evidencia.
| Funcionalidad | Tipo de prueba sugerido | Justificación |
|---|---|---|
| US12 — Buscar curso mediante código | Integración y E2E | Verificar que se encuentre el curso correcto con un código válido y que se maneje un código inexistente o inválido. |
| US13 — Inscribirse a un curso | Integración y E2E | Comprobar que una inscripción válida quede registrada y que se controlen códigos o condiciones de inscripción no válidos. |
| US14 — Crear ejercicio | Integración y E2E | Verificar que un ejercicio válido se cree y que se manejen datos incompletos o inválidos. |
| US15 — Consultar ejercicios | Integración y E2E | Verificar la consulta de ejercicios existentes y el manejo de un listado vacío. |
| US17 — Eliminar ejercicio | Integración y E2E | Comprobar que se elimine el ejercicio seleccionado y que se manejen registros inexistentes o acciones no permitidas. |
| ID | Escenario | Precondiciones | Pasos | Resultado esperado | Tipo | Estado |
|---|---|---|---|---|---|---|
| TC-US12-01 | Buscar un curso con código válido | Existe un curso de prueba con código conocido y el usuario puede acceder a la búsqueda. | 1. Abrir la búsqueda de cursos. 2. Ingresar el código válido. 3. Ejecutar la búsqueda. | La aplicación muestra el curso asociado al código ingresado y presenta la información disponible del curso correcto. | Camino feliz | Pendiente de ejecución |
| TC-US12-02 | Buscar un curso con código inexistente o inválido | El usuario puede acceder a la búsqueda y se dispone de un código que no corresponde a un curso. | 1. Abrir la búsqueda. 2. Ingresar el código inexistente o inválido. 3. Ejecutar la búsqueda. | La aplicación informa que no encontró un curso o señala la validación correspondiente, sin fallar ni mostrar un curso incorrecto. | Camino alternativo | Pendiente de ejecución |
| ID | Escenario | Precondiciones | Pasos | Resultado esperado | Tipo | Estado |
|---|---|---|---|---|---|---|
| TC-US13-01 | Inscribirse a un curso disponible | Existe un curso disponible y el usuario cumple las condiciones de inscripción. | 1. Abrir la opción de inscripción. 2. Seleccionar o identificar el curso según el flujo implementado. 3. Confirmar la inscripción. | La aplicación registra la inscripción y muestra una confirmación o el estado de inscripción correspondiente. | Camino feliz | Pendiente de ejecución |
| TC-US13-02 | Intentar inscribirse con un código inválido o en condiciones no permitidas | Se prepara un código de curso inexistente o una condición que, según las reglas implementadas, impide la inscripción. | 1. Iniciar el flujo de inscripción. 2. Ingresar el código inválido o seleccionar la condición de prueba. 3. Intentar confirmar. | La aplicación no registra una inscripción inválida y comunica el motivo o la validación correspondiente. Ajustar el escenario a las reglas reales del sistema. | Camino alternativo | Pendiente de ejecución |
| ID | Escenario | Precondiciones | Pasos | Resultado esperado | Tipo | Estado |
|---|---|---|---|---|---|---|
| TC-US14-01 | Crear un ejercicio con información válida | El usuario tiene acceso a la función y dispone de los campos requeridos. | 1. Abrir la opción para crear un ejercicio. 2. Completar los campos obligatorios con información válida. 3. Guardar. 4. Consultar el registro creado si la interfaz lo permite. | El ejercicio se crea correctamente y aparece disponible con la información ingresada. | Camino feliz | Pendiente de ejecución |
| TC-US14-02 | Intentar crear un ejercicio con información incompleta o inválida | La función está disponible y se conoce una regla de validación real del formulario. | 1. Abrir la opción para crear un ejercicio. 2. Omitir un campo obligatorio o ingresar un valor inválido. 3. Intentar guardar. | La aplicación informa la validación y no crea un registro inválido. Adaptar el caso a las validaciones que realmente existan. | Camino alternativo | Pendiente de ejecución |
| ID | Escenario | Precondiciones | Pasos | Resultado esperado | Tipo | Estado |
|---|---|---|---|---|---|---|
| TC-US15-01 | Consultar ejercicios disponibles | Hay ejercicios de prueba disponibles y el usuario tiene acceso. | 1. Abrir la sección de ejercicios. 2. Solicitar o cargar el listado. | La aplicación muestra los ejercicios disponibles con la información definida por la interfaz y sin errores inesperados. | Camino feliz | Pendiente de ejecución |
| TC-US15-02 | Consultar cuando no hay ejercicios disponibles | El usuario tiene acceso, pero el conjunto de prueba no contiene ejercicios. | 1. Abrir la sección de ejercicios. 2. Cargar el listado vacío. | La aplicación presenta un estado vacío comprensible y no falla ni muestra datos ficticios. | Camino alternativo | Pendiente de ejecución |
| ID | Escenario | Precondiciones | Pasos | Resultado esperado | Tipo | Estado |
|---|---|---|---|---|---|---|
| TC-US17-01 | Eliminar un ejercicio existente | Existe un ejercicio de prueba y el usuario tiene permiso para eliminarlo. | 1. Abrir el listado de ejercicios. 2. Seleccionar el ejercicio. 3. Ejecutar la acción de eliminar y confirmar si la interfaz lo solicita. 4. Actualizar o consultar el listado. | El ejercicio deja de aparecer en el listado o queda marcado como eliminado, conforme al comportamiento definido por la aplicación. | Camino feliz | Pendiente de ejecución |
| TC-US17-02 | Intentar eliminar un ejercicio inexistente o sin permiso | Se prepara un identificador inexistente o un usuario sin permiso, de acuerdo con las reglas implementadas. | 1. Intentar acceder a la acción de eliminación con la condición preparada. 2. Ejecutar la solicitud. | La aplicación informa que el registro no existe o que la acción no está permitida; no elimina otro registro ni genera un error no controlado. | Camino alternativo | Pendiente de ejecución |
| Caso | Estado | Resultado obtenido | Evidencia |
|---|---|---|---|
| TC-US12-01 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US12-02 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US13-01 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US13-02 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US14-01 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US14-02 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US15-01 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US15-02 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US17-01 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
| TC-US17-02 | Pendiente de ejecución | No registrado | Agregar enlace a ejecución/log |
Criterio de cierre: un caso solo se marca como aprobado cuando se ejecuta en el entorno definido, pasa y cuenta con evidencia. No registrar pruebas como aprobadas solo por haberlas documentado.
Planear una evaluación con usuarios para identificar si pueden comprender la interfaz de Paralelo, obtener instrucciones a partir de un esquemático, localizar componentes y conexiones, y utilizar la orientación conversacional. Este protocolo se prepara en el Sprint 2 y se propone ejecutar en el Sprint 3.
| ID | Tarea del participante | Criterio de éxito |
|---|---|---|
| T1 | Analizar un esquemático de referencia para obtener una guía de montaje. | Obtiene la guía e identifica los componentes principales. |
| T2 | Consultar las instrucciones y localizar componentes y conexiones. | Identifica los elementos y explica el siguiente paso sin ayuda del moderador. |
| T3 | Formular una pregunta sobre un componente o conexión en el chat. | Obtiene una respuesta pertinente y explica cómo utilizarla. |
| T4 | Solicitar una modificación de conexión o posición. | Verifica que la respuesta y las instrucciones reflejen el cambio solicitado. Si la función no está disponible en la versión evaluada, se registra como no evaluable. |
| T5 | Interpretar un mensaje de validación en un escenario controlado. | Identifica el problema y una acción correctiva posible. Si no se puede reproducir el escenario, se registra como no evaluable. |
| Código | Hipótesis | Pregunta de investigación | Criterio de evaluación |
|---|---|---|---|
| H1 | Los usuarios podrán obtener una guía a partir de un esquemático. | ¿Puede el usuario completar el análisis del esquemático? | Tasa de éxito y tiempo de tarea. |
| H2 | Las instrucciones facilitarán la comprensión del montaje. | ¿Puede el usuario comprender los pasos y localizar los componentes? | Éxito sin ayuda y errores observados. |
| H3 | Los mensajes de validación ayudarán a reconocer problemas. | ¿Puede el usuario explicar el problema informado? | Interpretación correcta del mensaje. |
| H4 | El chat facilitará resolver dudas sobre el montaje. | ¿Puede el usuario completar una consulta sobre el circuito? | Éxito, errores y solicitudes de ayuda. |
| H5 | La interfaz será comprensible para personas con distintos niveles de experiencia. | ¿Cómo valoran los usuarios la claridad de las instrucciones? | Encuesta de claridad y satisfacción. |
Se propone reclutar entre 5 y 8 participantes con niveles de experiencia variados: principiantes, intermedios y personas con experiencia en electrónica. El tamaño es una propuesta de prueba formativa, no una muestra estadística. Antes de la ejecución se deben confirmar participantes, fechas, consentimiento y disponibilidad del entorno.
- Preparar el entorno, los esquemáticos y los escenarios de prueba.
- Explicar el objetivo de la sesión, indicar que se evalúa la aplicación y solicitar consentimiento.
- Registrar de forma no identificable el nivel de experiencia del participante.
- Presentar las tareas sin revelar la solución; pedir al participante que verbalice lo que intenta hacer.
- Registrar tiempo, finalización, errores, solicitudes de ayuda y observaciones.
- Aplicar la encuesta posterior.
- Consolidar resultados, identificar patrones y priorizar mejoras.
La ejecución corresponde al Sprint 3. En este documento se presenta el protocolo planeado; no se afirma que las sesiones ya se hayan realizado.
| Métrica | Método de cálculo o registro |
|---|---|
| Tasa de éxito | Tareas completadas correctamente / tareas intentadas × 100 |
| Tiempo de tarea | Tiempo desde el inicio hasta la finalización de cada tarea |
| Errores | Cantidad y tipo de errores observados |
| Solicitudes de ayuda | Intervenciones solicitadas al moderador |
| Satisfacción | Valoración del participante en escala de 1 a 5 |
| Comprensión percibida | Valoración de claridad de instrucciones y mensajes |
Como objetivos iniciales de evaluación se propone lograr al menos 80 % de éxito en las tareas evaluables y una satisfacción media de 4/5. Son metas de referencia que deben confirmarse antes de la prueba; no son resultados obtenidos.
Escala de 1 a 5, donde 1 significa “muy difícil/muy baja” y 5 “muy fácil/muy alta”.
- ¿Qué tan fácil fue obtener instrucciones a partir del esquemático?
- ¿Qué tan claras fueron las instrucciones de montaje?
- ¿Qué tan fácil fue localizar los componentes y sus conexiones?
- ¿Qué tan fácil fue utilizar el chat para resolver una duda?
- ¿Qué tan comprensibles fueron los mensajes de validación?
- ¿Qué parte de la aplicación generó mayor confusión?
- ¿Qué cambiaría para facilitar el uso de Paralelo?
- Confirmar los participantes y sus perfiles.
- Definir fechas, duración y entorno de prueba.
- Preparar esquemáticos y escenarios reproducibles.
- Confirmar qué tareas están disponibles en la versión del MVP evaluada.
- Establecer criterios de éxito antes de iniciar las sesiones.
- Preparar el formato de registro y la encuesta.
- Definir cómo se almacenarán y protegerán las respuestas.
Según lo reportado por el equipo, las historias completadas para este sprint son:
| Historia | Nombre | Estado reportado |
|---|---|---|
| US15 | Consultar ejercicios | Completada |
| US16 | Actualizar ejercicio | Completada |
| US21 | Recibir orientación sobre el montaje | Completada |
El estado “completada” corresponde al reporte del equipo y debe respaldarse con la evidencia de la herramienta de gestión, commits, pull requests o demostración. No implica que las pruebas automatizadas estén ejecutadas.
Agregar los enlaces reales disponibles antes de entregar:
- Repositorio: https://github.com/slafontd/Shared-Reasoning
- Commits relevantes: [agregar enlaces a los commits del Sprint 2].
- Pull requests relacionados con US15, US16 y US21: [agregar enlaces si existen].
- Capturas de pantalla o video de demostración: [agregar ubicación de las evidencias].
- Tablero/backlog del Sprint 2: [agregar enlace o captura].
- Evidencia de planificación, revisión y retrospectiva: [agregar actas, capturas o notas de las ceremonias realizadas].
No se deben dejar enlaces de evidencia inventados. Si no existe una evidencia, indicarlo como pendiente o adjuntar una captura real.
La estrategia de pruebas de este documento se centra en las historias mostradas en las capturas: US12, US13, US14, US15 y US17. Se documentan diez casos, dos por historia, todos pendientes de ejecución. Esto no cambia por sí solo el reporte de qué historias fueron completadas en el Sprint 2. Al ejecutarlos, registrar el resultado real, fecha, entorno, responsable y enlace a la evidencia.
- Ejecutar y automatizar los seis casos de prueba definidos para US15, US16 y US21.
- Ajustar los casos de prueba a los criterios de aceptación y comportamiento real de la versión integrada.
- Ejecutar el protocolo de usabilidad en el Sprint 3 y documentar resultados.
- Confirmar costos reales o planes de infraestructura antes de convertir el presupuesto ilustrativo en presupuesto definitivo.
- Revisar la matriz de riesgos con el equipo y registrar responsables reales.
- Completar las evidencias de commits, pull requests, tablero y ceremonias.
- Registrar las funcionalidades no terminadas y tareas trasladadas al siguiente sprint, si aplica.
- Caso de negocio V2: finanzas y riesgos incluidos.
- Presupuesto de preoperación identificado como estimación del esfuerzo de integración.
- Costos operativos descritos como escenario sujeto a supuestos, no como gasto real confirmado.
- Matriz de probabilidad e impacto y matriz RACI revisadas por el equipo.
- Estrategia de pruebas y dos escenarios para cada historia mostrada en el tablero (US12, US13, US14, US15 y US17) documentados.
- Estado de ejecución de pruebas actualizado con resultados reales cuando estén disponibles.
- Protocolo de usabilidad preparado para ejecución en Sprint 3.
- Evidencias reales de desarrollo y ceremonias agregadas.
- Historias completadas y pendientes alineadas con el backlog del sprint.