Upload
tono-amezquita
View
15
Download
2
Embed Size (px)
Citation preview
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