View
6
Download
1
Category
Preview:
Citation preview
• 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
Recommended