Presentación Final Equipo 4

Presentación del tema: "Presentación Final Equipo 4"— Transcripción de la presentación:

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

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

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

4 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

5 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

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

7 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?

8 Métricas e Indicadores (II)
Product Burndown Chart

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

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

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

12 Análisis Análisis de situaciones del proyecto interesantes

13 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

14 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?

15 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?

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

17 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)

18 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

19 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

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

21 Show Time! Mostrar la aplicación en vivo

22 Lecciones aprendidas Puntos interesantes sobre el proyecto

23 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

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

25 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

26 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

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