eHockey Grupo 3 [75.47] Taller de Desarrollo de Proyectos II

Presentación del tema: "eHockey Grupo 3 [75.47] Taller de Desarrollo de Proyectos II"— Transcripción de la presentación:

1 eHockey Grupo 3 [75.47] Taller de Desarrollo de Proyectos II
Proyecto e-Hockey Grupo 3 [75.47] Taller de Desarrollo de Proyectos II

2 Agenda eHockey Equipo Propuesta inicial vs real
Análisis de la administración del proyecto Lecciones aprendidas Demo

3 Ezequiel Alvarez Iaconis
eHockey Equipo Grupo 3 Nahuel Campo Ariel Scarpinelli Ezequiel Alvarez Iaconis Leandro Ferrigno

4 Propuesta inicial vs real
eHockey Propuesta inicial vs real Metodología Alcance Planificación Herramientas de Planificación Métricas Riesgos Pruebas Aceptación Trazabilidad

5 Propuesta inicial vs real Metodología, alcance y planificación
eHockey Propuesta inicial vs real Metodología, alcance y planificación Scrum poco ceremonioso Alcance definido únicamente por US ¿Qué paso con lo que no era un US? Estimación y asignación de tareas Finger estimate & pool Si bien aplicamos una metodología de trabajo agil, basada en scrum, los tiempos del equipo y el proyecto en si hicieron que no se respeten mucho las ceremonias que plantea la metodología, en particular los daily meetings, que no se hicieron, como tampoco pequeñas reuniones intersemanales con el mismo objetivo; aunque si se hicieron reuniones intersemanales de trabajo. El alcance lo dejamos definido unicamente por los US, no tuvimos en cuenta los requerimientos ya que era repetitivo. De aca se desprende una leccion aprendida: - No todo es un US, sino después hay problemas de tareas que están cruzadas, por haberlas forzado a parecerse a un US. Finalmente, si hablamos de la estimación y la asignacion de tareas, en un comienzo habiamos dicho que ibamos a realizar planning poker, pero en realidad no lo hicimos, empezamos estimando de forma similar a poker, pero luego con el transcurso del proyecto y la necesidad de reducir los tiempos en las reuniones, se empezo a estimar de otra forma, cada uno decia masomenos cuanto pensaba que tardaba y luego se acordaba, sin la vuelta que implica poker planning. Para la asignacion de tareas, cada integrante iba haciendo lo que veia que podia hacer sobre el conjunto total de tareas a realizar. Esto nos funciono, pero hay que tener cuidado, el cartel lo dice todo, hay que tener cuidado si nos tiramos de cabeza, sobre todo en aguas poco profundas, que en nuestro caso podria ser tiempos cortos.

6 Propuesta inicial vs real Herramientas de Planificación
eHockey Propuesta inicial vs real Herramientas de Planificación ¿WBS, para qué? No hubo calendario Solo fechas de cierre y compromisos a cumplir por sprint Diagramas UML Solo diagrama de clases al inicio y la siguiente actualización como entregable final En cuanto a las herramientas, se descarto la WBS ya que la división de trabajo quedo constituida por el backlog del producto, el cual resultó más práctico, teniendo en cuenta la velocidad de cambio y el tamaño del proyecto. Sobre los diagramas UML, los mismos no se mantuvieron actualizados, sin embargo mientras trabajabamos vimos que hubiera sido bueno tenerla. Con lo cual como leccion: - A veces hubiera sido util mantener documentación UML actualizada.

7 Propuesta inicial vs real Métricas y riesgos
eHockey Propuesta inicial vs real Métricas y riesgos Métricas Indicador de bugs cerrados/abiertos Burn-down chart Cobertura de la prueba Análisis de la distribución del trabajo Riesgos Planilla actualizada En lo que refiere a las métricas que dijimos que ibamos a utilizar, a lo largo del proyecto fuimos viendo si iban o no a ser utiles, y cuanto nos iba a costar mantenerlas. Burn down chart lo usamos para analizar distribución temporal dentro del sprint de cada integrante y para saber cuanto faltaba para terminar el sprint (a groso modo). El indicador de bugs cerrados sobre abiertos por sprint nos sirvió para determinar rápidamente en que estado estaba la aplicación respecto a la criticidad de los bugs, y para determinar si se cumplía el criterio de aceptación establecido (cero bugs críticos). El problema con el mismo fue que lo empezamos a implementar a partir del sprint 3, con lo cual de la primera parte no hay mucha información. La cobertura de prueba no se hizo, sin embargo se hizo un seguimiento del tiempo insumido según el tipo de tarea que sirvio para diversasa cosas durante el proyecto Respecto a los riesgos, la planilla se mantuvo actualizada de reunión en reunión. En algunos casos, sobre todo al comienzo, los riesgos representados en la misma eran insignificantes, luego con el paso del tiempo fuimos mejorandola, incluso llegamos a aplicar un plan de contingencia. Igualmente tambien tuvimos falencias con esta planilla, como por ejemplo nunca tuvimos en cuenta que sucedia si cambiaban las priorizaciones del usuario en cuanto a las tareas en realizar

8 Propuesta inicial vs real Pruebas y aceptación
eHockey Propuesta inicial vs real Pruebas y aceptación Pruebas Pruebas de aceptación Pruebas de integración Regresión Aceptación Bugs críticos vs no críticos Corrección inmediata Respecto a las pruebas, hubo ciertos cambios. Con el correr del proyecto, se hizo común el tener las pruebas de aceptación antes de desarrollar la funcionalidad, esto fue positivo y se continuo haciendo, creando test de aceptación y haciendo pruebas cruzadas de los mismos, luego esos test eran utilizados para la aceptación del usuario. Este modelo de trabajo nos lleva a decir que usamos una metodología tipo ATDD. Las pruebas que no realizamos fueron las pruebas de integración, las mismas iban a consumir mucho tiempo del proyecto que necesitábamos para completar la funcionalidad, además con las pruebas de aceptación había cierta integración que implícitamente se estaba probando. Para finalizar, en el periodo de estabilización del proyecto, se realizo una regresión de los UAT verificando que todo este funcionando como corresponda. En cuanto a la aceptación de la funcionalidad del proyecto, se hizo una diferenciación entre bugs críticos y no críticos.   - critico: bugs que comprometan el exito de un UAT   - no critico: bugs de usabilidad o interfaz de usuario que no compromenten a los UAT. La aceptabilidad de la funcionalidad era sin bugs criticos. Se desprende una leecion aprendida: - La metodología tipo ATDD y los mockups ayudan a coordinar la comunicación con el cliente.

9 Propuesta inicial vs real Trazabilidad
eHockey Propuesta inicial vs real Trazabilidad User Stories Módulos de implementación Bugs UAT Respecto a la trazabilidad, se mantuvo durante el proyecto información como para identificar que modulos del programa corresponden a la ejecución de cada US, de forma tal que se puede llegar al código fuente que lo represente. Por otro lado también hay una relación entre los UAT y los Bugs con los US.

10 Análisis de la administración del proyecto
eHockey Análisis de la administración del proyecto Métricas Estimaciones Riesgos

11 eHockey Análisis de la administración del proyecto Métricas I – Análisis de bugs Bugs Críticos Bugs no Críticos Abiertos en sprint 6 Cerrados en el Sprint 6 Pendientes 3 Abiertos en sprint 5 Cerrados en el Sprint 4 2 4 Abiertos en sprint 4 Abiertos en sprint 6 Cerrados en el Sprint 6 Pendientes 10 7 5 Abiertos en sprint 5 Cerrados en el Sprint 5 12 15 2 Abiertos en sprint 4 Cerrados en el Sprint 4 3 4 Primero vamos a mostrar como se ve la relación de los bugs críticos vs los no críticos En el gráfico se puede ver como a medida que pasa el proyecto se van encontrando cada vez mayor cantidad de bugs. También se puede ver que cuando empezamos a tomar está métrica pudimos efectivamente eliminar los errores crtíticos, intentando mantenerlos siempre en 0 al finalizar el sprint

12 eHockey Análisis de la administración del proyecto Métricas II – Análisis de tiempos En el gráfico de análisis de tiempos se puede ver en tiempo que se le dedicó a cada tipo de tarea durante el desarrollo del proyecto. En el mismo se puede ver que la forma que tiene es “normal”, el tiempo en la administración del proyecto es constante, el tiempo en testing va subiendo y el tiempo en desarrollo bajando. Mas allá de la forma, con este gráfico obtuvimos información valiosa - Se mejoró el nivel de estimación. Nos dimos cuenta que estabamos estimando “demasiado bien”, con lo cual decidimos apretar los tiempos de estimación; también el tiempo real mejoró por la experiencia adquirida sin embargo la mayoría de la mejora era por la aplicación de la ley del gas. - Muchas horas de reunión, planificación, armado de documentación, etc. - Poco retrabajo. Se puede ver en la caída prácticamente lineal del tiempo de desarrollo - Trabajo no planificado. Rol no detectado: Documentador, identificado en “otros tiempos”. El otros tiempos en un síntoma de un error en la planificación, si bien se podría haber corregido y decir que esos tiempos fueron para ese rol, queríamos dejar representado que en un principio no lo tuvimos en cuenta

13 Análisis de la administración del proyecto Estimaciones
eHockey Análisis de la administración del proyecto Estimaciones Faltaron estimar tareas que no eran US Distinta velocidad de cada miembro Estimaciones demasiado buenas Con las estimaciones tuvimos varios problemas, por un lado la inexperiencia hizo que nos olvidemos de estimar alguna de las tareas que había que realizar, como ser por ejemplo la documentación del proyecto. Por otro lado, la velocidad de cada uno de los miembros no es siempre la misma, sobre todo si se está utilizando una tecnología que unos conocen más que los otros. A medida que avanzó el proyecto, fue más fácil para cada uno estimar cuanto se tardaría en cada tarea y el framework también terminó colaborando con esto, al permitir extrapolar tiempos fácilmente. Sin embargo en un momento se nos presentó una situación, en la cual en el sprint review vimos que estábamos estimando demasiado bien, sobre un sprint de 80 hs, solamente nos desviamos media hora, lo cual llamó nuestra atención. Ahí fue cuando decidimos empezar a acotar las estimaciones, evaluando el resultado vimos que igualmente se llegaba, confirmando que estábamos sobre-estimando, cumpliendo con la ley del estudiante.

14 Análisis de la administración del proyecto Riesgos
eHockey Análisis de la administración del proyecto Riesgos Presentación de riesgos al cliente No todo es importante para el cliente Cosas para no olvidar El cliente cambia su opinión Mantener los valores actualizados En cada reunión de avance se le presentaba al cliente una lista de los riesgos, con la información más importante para el mismo. En un principio no se supo bien cuales de los riesgos de nuestra planilla se le deberían mostrar al cliente, pero con el avance del proyecto fuimos teniendolo más claro. No se presentaron muchos problemas a la hora del análisis de riesgos. Lo que más nos costo fue mantener la planilla al día, muchas veces olvidabamos revisar la planilla. En lo que respecta a riesgos omitidos, tuvimos uno importante, que el cliente no siempre mantiene las prioridades sobre las distintas partes del proyecto y un cambio de opinion sobre un tema puede hacer que haya que trabajar de mas, como nos paso con la tabla de goleadores.

15 eHockey Lecciones aprendidas

16 Lecciones aprendidas I Algunas ya mencionadas
eHockey Lecciones aprendidas I Algunas ya mencionadas Mantener documentación actualizada No todo es un US Utilización de mockups Todos somos estudiantes. Evaluar disponibilidad del equipo. Tiempos para tareas administrativas A veces hubiera sido util mantener la documentacion UML actualizada para distribuir mejor el trabajo No todo puede ser representado por un US, sino después hay problemas de tareas que están cruzadas, por haberlas forzado a parecerse a un US. La utilización de mockups fue muy útil para mejorar la coordinación y la aceptación del cliente La ley del estudiante no falla; las personas utilizan todo el tiempo disponible para realizar una tarea. Hay que tener mas en cuenta la disponibilidad del equipo a la hora de querer aplicar una metodologia o estimar. Sobre todo cuando la disponibilidad de cada uno no es full time; es muy complicado intentar de realizar reuniones periódicas cuando la gente no tiene disponibilidad completa. No hay que desestimar los tiempos para las tareas administrativas

17 Lecciones aprendidas II Otras que no mencionamos
eHockey Lecciones aprendidas II Otras que no mencionamos Tiempo de start-up Estética y usabilidad Compartir el know-how Es fundamental al principio asignar horas para tener todos los ambientes bien configurados con todas las herramientas, nos paso de que algunos veníamos de programar en distintas versiones de php, con otras herramientas, etc e íbamos resolviendo Hay que darle importancia a la estética y a la usabilidad del sistema. En nuestro caso en un comienzo no le dimos una estética buena, sin embargo el desarrollo fue pensado como para poder aplicarla en un futuro de forma fácil, utilizando hojas de estilos. Es importante que los desarrolladores compartan el conocimiento adquirido para no investigar los mismo 2 veces

18 Lecciones aprendidas III Aún hay más…
eHockey Lecciones aprendidas III Aún hay más… Requerimientos implícitos Tiempo de estabilización Regresión Hay requerimientos que son implícitos, el cliente mismo ni siquiera los especifica, como por ejemplo criterios de seguridad. Hay que tenerlos en cuenta y no olvidarse de agregarlos en la estimación. También puede ser útil discutirlos con el cliente. Otra de las cosas que resultó muy útil también fue dejar tiempo para la estabilización, permitiendo al equipo verificar el correcto funcionamiento del sistema, en el mismo también pudimos hacer una regresión de los UAT, detectanto muchos bugs que se habían pasado por alto o que aparecieron después y corrigiendo los críticos.

19 Demo Demo

20 Preguntas

21 Gracias.