PROYECTO E-HOCKEY Grupo 3 [75.47] Taller de Desarrollo de Proyectos II

Agenda Equipo Propuesta inicial vs real Análisis de la administración del proyecto Lecciones aprendidas Demo

Equipo Grupo 3 Nahuel Campo Ariel Scarpinelli Ezequiel Alvarez Iaconis Leandro Ferrigno

Propuesta inicial vs real Metodología AlcancePlanificación Herramientas de Planificación MétricasRiesgos Pruebas Aceptación Trazabilidad

Propuesta inicial vs real Metodología, alcance y planificación  Scrum poco ceremonioso  Alcance definido únicamente por US  ¿Qué paso con lo que no era un US?  ATDD  Estimación y asignación de tareas  Finger estimate & pool

Propuesta inicial vs real Herramientas de Planificación  ¿WBS, para qué?  No hubo calendario  Solo fechas de cierre y compromisos a cumplir por sprint  Diagramas UML  Solo diagrama de clases al inicio y la siguiente actualización como entregable final

Propuesta inicial vs real Métricas y riesgos  Métricas Indicador de bugs cerrados/abiertos Burn-down chart Cobertura de la prueba Análisis de la distribución del trabajo  Riesgos  Planilla actualizada

Propuesta inicial vs real Pruebas y aceptación  Pruebas Pruebas de aceptación Pruebas de integración Regresión  Aceptación  Bugs críticos vs no críticos  Corrección inmediata

Propuesta inicial vs real Trazabilidad User Stories Módulos de implementación BugsUAT

Análisis de la administración del proyecto MétricasEstimacionesRiesgos

Análisis de la administración del proyecto Métricas I – Análisis de bugs Bugs Críticos Abiertos en sprint 6Cerrados en el Sprint 6Pendientes 330 Abiertos en sprint 5Cerrados en el Sprint 4Pendientes 220 Abiertos en sprint 4Cerrados en el Sprint 4Pendientes 422 Abiertos en sprint 6Cerrados en el Sprint 6Pendientes 1075 Abiertos en sprint 5Cerrados en el Sprint 5Pendientes Abiertos en sprint 4Cerrados en el Sprint 4Pendientes 304 Bugs no Críticos

Análisis de la administración del proyecto Métricas II – Análisis de tiempos

Análisis de la administración del proyecto Estimaciones  Faltaron estimar tareas que no eran US  Distinta velocidad de cada miembro  Estimaciones demasiado buenas

Análisis de la administración del proyecto Riesgos  Presentación de riesgos al cliente  No todo es importante para el cliente  Cosas para no olvidar  El cliente cambia su opinión  Mantener los valores actualizados

Lecciones aprendidas

Lecciones aprendidas I  A veces hubiera sido util mantener la documentacion UML actualizada  Las personas utilizan todo el tiempo disponible para realizar una tarea  Es muy complicado intentar de realizar reuniones periodicas cuando la gente no tiene disponibilidad completa  No hay que desestimar los tiempos para las tareas administrativas

Lecciones aprendidas II  La velocidad de trabajo de los integrantes es muy distinta  Es importante que los desarrolladores compartan el conocimiento adquirido para no investigar los mismo 2 veces

Lecciones aprendidas III Resumen

Demo

Preguntas

Gracias.