Proyecto eHockeyPresentación Final

Equipo 4

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

Agenda

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

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 (I)

Se administró:◦ 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

Contexto (II)

Métricas e Indicadores

Qué metricas e indicadores se utilizaron en el proyecto?

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 (I)

Product Burndown Chart

Métricas e Indicadores (II)

Evolución de la Prueba

Métricas e Indicadores (III)

Métricas e Indicadores separados por sprint◦ Sprint 1◦ Sprint 2◦ Sprint 3◦ Sprint 4◦ Sprint 5

Métricas e Indicadores (IV)

Métricas de Código Fuente

Métricas e Indicadores (V)

AnálisisAnálisis de situaciones del proyecto interesantes

De código a documentación◦ 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 (I)

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 (II)

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?

Trazabilidad (III)

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

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 (I)

1. Crear usuario administrador2. Mostrar secciones de administración3. Llenar lista de buena fe de Boca4. Crear torneo con los cuatro equipos (Boca,

River, Racing, San Lorenzo)5. Mostrar fixture del torneo nuevo6. Mostrar planilla precargada7. Marcar primer partido del torneo como

jugado

Hoja de Ruta (II)

Administrador

1. Ingresar como representante2. Recorrer las secciones del representante3. Publicar la planilla del partido terminado4. Ingresar como representante5. Rechazar la planilla: “falta amonestación de

Palermo en Boca”6. Cargar tarjeta roja a Palermo en planilla

rechazada7. Publicar planilla8. Validar planilla9. Representante mira la tabla de posiciones

Hoja de Ruta (III)

River PlateBoca Juniors

1. Avanzar fecha al próximo partido de Boca2. Palermo no aparece en lista de buena fe

Hoja de Ruta (IV)

Administrador

Show Time!Mostrar la aplicación en vivo

Lecciones aprendidasPuntos interesantes sobre el proyecto

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 (I)

Sprint 5 Burndown Chart Sprint 4 Burndown Chart

Lecciones aprendidas (II)

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 (III)

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

Lecciones aprendidas (IV)

Muchas Gracias!Hay preguntas en la audiencia?

Ciancio Alessio, MauroLopez Elías, Lucas

Yoan, Norberto