Presentación Final Equipo 4 Proyecto eHockey Presentación Final Equipo 4

Agenda Contexto Métricas e Indicadores Análisis Demostración Lecciones aprendidas Preguntas

Contexto Ubicarnos en el contexto del proyecto, herramientas, metodologías, etc.

Contexto (I) Objetivo: desarrollar un sistema para la Federación de Hockey Metodología de Desarrollo: Scrum Control de Versiones: GIT Lenguaje y Herramientas: Eclipse, Java, Wicket, Hibernate, Maven Bug Tracker, Wiki, Agile Planner: Assembla

Contexto (II) Se administró: Hincapié en la trazabilidad Riesgos: mediante matriz de riesgos por sprint Comunicación: minutas, informe de avance, retrospectivas Cambios: asentados en minutas de reunión Hincapié en la trazabilidad Trazar el proyecto entre código, documentación, tickets y US Se desarrollaron scripts que trazan el proyecto en pocos segundos

Métricas e Indicadores Qué metricas e indicadores se utilizaron en el proyecto?

Métricas e Indicadores (I) Propuestos por Scrum Sprint Burndown Chart Product Burndown Chart Propuestos por el Equipo Evolución de la Prueba: bugs abiertos, cerrados y totales por día de proyecto Desvíos entre estimaciones de esfuerzo y valores reales Test coverage: que porcentaje del código cubren los tests unitarios?

Métricas e Indicadores (II) Product Burndown Chart

Métricas e Indicadores (III) Evolución de la Prueba

Métricas e Indicadores (IV) Métricas e Indicadores separados por sprint Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Métricas e Indicadores (V) Métricas de Código Fuente

Análisis Análisis de situaciones del proyecto interesantes

Trazabilidad (I) De código a documentación De documentación a código Código vs tickets: script search_tickets Tickets vs User Stories User Stories vs documentación De documentación a código Documentación vs User Stories User Stories vs tickets Tickets vs código: script search_files

Trazabilidad (II) Cuándo se aprobaron las US? Para cuándo fueron comprometidas las US? Qué cambios (defecto, usabilidad, etc.) se introdujeron? Hubo cambios en el alcance del proyecto? Evidencia?

Trazabilidad (III) Qué archivos modificó un ticket? Qué tickets fueron impactados por cambios en un archivo? Qué documentación hay sobre este código? Ejemplo en vivo: Se nos envía un pedido de cambio que afecta sobre la Planilla Final. Se desea analizar el impacto del cambio sobre el proyecto; no sólo en código sino también en documentación. Cómo procedemos?

Demostración Comunicar la hoja de ruta para la demo de la aplicación

Hoja de Ruta (I) Existen en el sistema cargados varios clubes con sus equipos y jugadores Existe usuarios representates para los clubes: Boca Juniors River Plate Racing San Lorenzo Chicago Jugadores en sus respectivas listas de buena fe (ocho jugadores en cada lista)

Hoja de Ruta (II) Crear usuario administrador Mostrar secciones de administración Llenar lista de buena fe de Boca Crear torneo con los cuatro equipos (Boca, River, Racing, San Lorenzo) Mostrar fixture del torneo nuevo Mostrar planilla precargada Marcar primer partido del torneo como jugado Administrador

Hoja de Ruta (III) Ingresar como representante Recorrer las secciones del representante Publicar la planilla del partido terminado Rechazar la planilla: “falta amonestación de Palermo en Boca” Cargar tarjeta roja a Palermo en planilla rechazada Publicar planilla Validar planilla Representante mira la tabla de posiciones River Plate Boca Juniors

Hoja de Ruta (IV) Avanzar fecha al próximo partido de Boca Palermo no aparece en lista de buena fe Administrador

Show Time! Mostrar la aplicación en vivo

Lecciones aprendidas Puntos interesantes sobre el proyecto

Lecciones aprendidas (I) Burndown: Estimar lo antes posible No hay evidencia de trabajo y se distorsionan los indicadores Usar una herramienta automatizada permite ver el avance real día a día Herramientas Carga de tiempo invertido a través de los commits Aprovechar el potencial de la herramienta de versionado distribuido

Lecciones aprendidas (II) Sprint 4 Burndown Chart Sprint 5 Burndown Chart

Lecciones aprendidas (III) Tareas por sprint: No definir las tareas de las US al inicio del proyecto Problemas: Se estiman tareas que pueden quedar fuera del alcance Poco conocimiento del negocio Tareas muy poco específicas Definir tareas insume mucho tiempo que no agrega valor al sprint actual Estimaciones: Google Wave + Planning Poker.com no fue una buena herramienta

Lecciones aprendidas (IV) Métricas e Indicadores Asegurar que los indicadores puedan ser corridos con la información disponible Preparar los indicadores al principio del proyecto Los dos primeros sprints no tienen indicadores de evolución de la prueba ni análisis de desvío de esfuerzo No había información para construirlos Para los sprints siguientes se agregaron campos especiales al issue tracker Construir los indicadores durante el sprint

Muchas Gracias! Hay preguntas en la audiencia? Ciancio Alessio, Mauro Lopez Elías, Lucas Yoan, Norberto