75.47 PRESENTACIÓN FINAL Taller de Desarrollo de Proyectos II Sainz, Matias Almendro, Gonzalo Menasches, Jonathan Farias, Álvaro

Agenda Objetivo de la presentación Breve repaso del proyecto Lecciones aprendidas

Objetivo de la Presentación

Repaso del Proyecto

Metodología de desarrollo Product Backlog (requerimientos de alto nivel) Sprint planning Sprint Review (reuniones formales cada 15 días) 5 sprints

Tecnologías utilizadas

Estado final del proyecto Se finalizó el proyecto en el tiempo comprometido Se finalizó el proyecto con los recursos previstos Se entregó el proyecto con un nivel de calidad adecuado Se gestionaron adecuadamente los riesgos del proyecto

Product backlog Dar de Alta (Proveedor) Inscribir en Pliegos Autorizar Alta Proveedor Modificar Oferta Inicial Crear Pliegos Visualizar Proveedores Inscriptos en Pliego Autorizar y Publicar Pliegos Autorizar Inscripción Proveedor Rechazar Pliegos Recibir Notificaciones de un Pliego Visualizar Pliegos (Autorizador Pliegos) Preseleccionar Proveedores Iniciar Sesion en Sistema Visualizar Estado de la Subasta (Proveedor) Administrar Usuarios del Sistema Enviar un Lance Modificar Pliegos Visualizar el Estado de la Subasta

Product backlog Cancelar Pliegos Pausar la Subasta Visualizar Pliegos (Proveedor) Recibir Notificaciones de la Subasta Visualizar Proveedores Generar Reportes

Lecciones Aprendidas

Seguimiento y control Evolución de la prueba Estado/Severidad A B C D Total Abierto Cerrado 20 10 12 15 57 Definir con el cliente dentro de los criterios de aceptación de la entrega (cantidad de bugs y severidad de los bugs abiertos) para evitar problemas futuros y disconformidades al momento de aceptar la entrega.

Seguimiento y control El grafico de evolución de la prueba debe ser general de todo el proyecto para llevar un mejor control y no por sprint. De esta manera se puede llevar un control del estado de bugs a lo largo de todo el proyecto.

Seguimiento y control Burn Down Chart Realizar una estimación de alto nivel de todo el proyecto además de las de cada sprint para mostrarle al cliente el estado del proyecto y detectar problemas de calendario con tiempo.

Gestión de riesgos Descripción Causa Consecuencia Probabilidad Impacto Mala estimacion por complejidad de user stories Fata de Experiencia Atraso en el calendario CERRADO 2 Problemas con assembla Externa Atraso en el proyecto 1 Cambios en el proyecto por parte del cliente Cambios en el negocio Extencion del calendario Bugs no detectados o detectados tarde Mala calidad de QC Mala calidad en el codigo, atraso en el calendario Re-trabajo por ausencia del cliente Ausencia del cliente Disconformidad del cliente y re-trabajo 5 Complejidad de los reportes y no validados Reportes complejos y no validados Extensión de las horas de trabajo, no conformidad por parte del cliente 4 Mostrar en el informe de avance solo los riesgos que son importantes para el cliente y sobre los cuales el cliente puede hacer algo para mejorar su gestión, evitándolos o mitigándolos.

Validaciones con el cliente Siempre validar los mockups de pantallas, estimaciones, uats y alcance definido para el sprint con cliente con tiempo para evitar re-trabajo y la disconformidad del cliente. ¿Qué problemas hubo? Disconformidad con estilo y diseño de pantallas Recorte de alcance Re-trabajo por ausencia del cliente El famoso UAT 17!!!

Mas lecciones aprendidas Los uats deben mostrar como probar una funcionalidad concreta sin usar lenguaje demasiado técnico.   El informe de avance debe ser concreto y corto (2 a 3 paginas) para mostrar un resumen del estado del proyecto y para que el cliente lo lea y lo tenga en cuenta. Realizar un control de cobertura a través de la trazabilidad de requerimientos contra uats y código.

Y ahora… ¿ Como manejar el cambio de representante del cliente?

¿Preguntas?

Muchas gracias