• Sainz, Matias• Almendro, Gonzalo• Menasches, Jonathan• Farias, Álvaro

75.47

PRESENTACIÓN FINAL

Taller de Desarrollo de Proyectos II

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 planningSprint 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 PliegosVisualizar 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 SistemaVisualizar 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

Estado/Severidad A B C D Total

Abierto 0 0 0 0 0

Cerrado 20 10 12 15 57

Total 20 10 12 15 57

Evolución de la prueba

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

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.

Descripción Causa Consecuencia Probabilidad Impacto

Mala estimacion por complejidad de user stories

Fata de Experiencia

Atraso en el calendarioCERRADO 2

Problemas con assembla Externa Atraso en el proyecto CERRADO 1Cambios en el proyecto por parte del cliente

Cambios en el negocio

Extencion del calendarioCERRADO 2

Bugs no detectados o detectados tarde

Mala calidad de QC

Mala calidad en el codigo, atraso en el calendario CERRADO 2

Re-trabajo por ausencia del cliente

Ausencia del cliente

Disconformidad del cliente y re-trabajo CERRADO 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

CERRADO 4

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