Proyecto e-Hockey Presentación Final Grupo 2 Speaker: Seba Taller de Desarrollo de Proyectos II - 75.47 -

Agenda El Proyecto Métricas Trazabilidad Lecciones Aprendidas Demos Speaker: Seba

El Proyecto Información General Metodología: Tecnologías: SCRUM (6 Iteraciones) User Stories UAT para el Análisis Speaker: Seba Falta pulir, pero el contenido es mas o menos este Tecnologías: Dynamic Data

El Proyecto Método de Estimación Planning Poker Speaker: Seba Una vez recibido el enunciado nos juntamos a crear las user stories y estimarlas. Nos resulto bastante bien ya que estuvimos bastante cerca con la estimación que las horas gastadas. Planning Poker

Herramientas (Lección Aprendida!) El Proyecto Herramientas (Lección Aprendida!) Sprint Backlog Speaker: Cristian Decir este slide como una primera lección aprendida, aunque después vamos a ver mas. Es como que todos sabiamos en que estaba trabajando el resto, no hacia falta mantener el estado. Nos fue muy util la capacidad de Google code de mandar un mail al grupo cada vez que alguien hace un commit. Fue muy importante los comentarios que cada uno ponia en los commits. + User Stories Comunicaciones

Trazabilidad Bugs Código Bugs con Código de User Stories Commits con Código de User Stories User Stories Speaker: Cristian Agregar icono de bug. UAT por User Story Matriz User Stories- Requerimientos Pruebas (UAT) Requerimientos

Métricas Métricas Utilizadas Pruebas: Code Coverage Speaker: Cristian No decir mucho del burndown chart porque ya lo mostramos antes. Decir que tenemos test unitarios y que usabamos el code coverage para saber cuanto porcentaje del código estaba probado. Avance: Burn Down Chart

Horas Estimadas/Completadas Métricas Métricas Utilizadas Costos: Earn Value Horas Estimadas/Completadas Horas Utilizadas SPI (EV/PV) CPI (EV/AC) 360hs 353hs 1 1,02 Speaker: Cristian Importante decir que manteníamos un Google chart con las horas gastadas. A veces puede ser medio molesto pero nos permite obtener métricas bastante copadas. En el global dio bien la estimación, pero la estimación de tareas por ahí no fue tan precisa. Las tareas que sobre-estimamos se compensaron con las que sub-estimamos. Mas que nada las sub-estimaciones tuvieron que ver con gastar horas en investigación. Las horas finales de ajustes no las tenemos en cuenta. - Horas gastadas trackeadas por tarea en un Google Doc -

- Bug Tracking Utilizando Herramientas del repositorio Google Code - Métricas Métricas Utilizadas Bugs: Bug Tracking - Bug Tracking Utilizando Herramientas del repositorio Google Code - Speaker: Ale

Métricas Análisis de Métricas CPI = EV / AC = 30hs / 18hs = 1,67 Speaker: Ale Mostrar un Burn-down chart que vaya mal con una estimación que va ok y CPI y SPI > 1 Acá va el análisis de Ale CPI = EV / AC = 30hs / 18hs = 1,67 SPI = EV / PV = 30hs / 26hs = 1,15 - El Earn Value muestra que estamos bien, pero el Burn Down chart muestra un desvío -

Lecciones Aprendidas Comunicaciones Utilizar términos cuantificables. Evitar frases confusas. Lo que no está escrito no existe. “sistema intuitivo” “pantalla amigable” Speaker: Renzo Evitar usar palabras que posteriormente sean difíciles de cuantificar al momento de definir el alcance. Por ejemplo: “sistema intuitivo” o “pantalla amigable”. Utilizamos UAT de este estilo para cuantificar una story de aplicación de estilos: UAT #36-1: El Logo de la FAH se debe mostrar en todas las páginas arriba a la derecha. UAT #36-2: El titulo del sistema (e-hockey) debe verse en un encabezado de color azul a través de todo el sistema. 2. Frases como la siguiente no ayudan a mantener acuerdos claros con el cliente: “De momento no se va a realizar el precargado por WAP.” ¿Esto se va a hacer? ¿No se va a hacer? Remplazar esto por frases como: “El precargado por WAP no está dentro del alcance del sistema.” “De momento no se va a realizar el precargado por WAP.” “El precargado por WAP no está dentro del alcance del sistema.”

Lecciones Aprendidas Relación con el Cliente Gold-Plating Speaker: Renzo 2. Gold Plating: se refiere a continuar aplicando esfuerzo a una tarea más allá de lo que el mismo aporta como valor agregado (si es que aporta). Luego de haber cubierto el requerimiento, el desarrollador puede verse tentado a continuar extendiendo el producto, pensando que el cliente va a quedar encantado de ver funcionalidades adicionales, mas allá de lo que se pidió. El cliente puede quedar decepcionado de lo realizado, y el esfuerzo del desarrollador puede ser inútil. Contar el ejemplo concreto del boton para aceptar todas las planillas. 3. A veces es necesario, no solo cumplir con las expectativas del cliente en cuanto a la funcionalidad, sino mostrar que estamos de su lado y queremos solucionarle los problemas. Nunca ir al choque y tratar de hacer lo posible para que todos sus requerimientos sean tenidos en cuenta. Esto último obviamente, manteniendo el balance de alcance y tiempos controlado. Rational Satisfaction vs. Emotional Satisfaction Ser amigo del cliente Gold-Plating Rational Satisfaction vs.Emotional Satisfaction

Demo Speaker: Ale Speaker: Seba Administrador: Ale Delegado Visitante: Cristian Delegado Local: Renzo

Preguntas

Gracias!