Métricas de gestión

Se utilizaron métricas a lo largo del proyecto con el fin de medir y evaluar el proceso de desarrollo del sistema. El análisis de los valores obtenidos por las métricas nos aportó información precisa que utilizamos como base durante las sprint review y sprint retrospective. Evaluar constantemente la gestión del proyecto, nos permitió mejorar y mantener el rendimiento del equipo.

6.3.1. Story points estimados vs. completados

Utilizamos esta métrica para evaluar que se hayan cumplido las tareas seleccionadas para cada sprint. A continuación, se puede ver una gráfica que ilustra dicha información.

Figura 13: Story points estimados vs. completados

En la gráfica anterior se puede observar cómo evolucionó la capacidad de estimación, así como el trabajo realizado por sprint. En el eje horizontal se puede observar el tiempo de desarrollo dividido en 13 sprints, mientras que el eje vertical representa los puntos tanto estimados como alcanzados en cada uno de ellos.

67 Como podía llegar a esperarse, la estimación en el primer sprint no fue la mejor, ya que no llegamos a completar la cantidad de story points que habíamos estimado. Esto se debió a la falta de experiencia en React Native.

Para el segundo sprint se logró ajustar la estimación ya que pudimos aumentar la velocidad del equipo a medida que se ganó experiencia en las tecnologías.

El tercer y cuarto sprint coincidieron con las fechas de exámenes de la facultad, por lo que la dedicación en horas que se le pudo dedicar al proyecto no fue la esperada en la estimación de story points. En los siguientes dos sprints logramos ponernos a tiro y compensar la desviación que teníamos.

Cuando entramos en los sprints 7 y 8 y nos enfrentamos al desarrollo del panel administrador, subestimamos las diferencias entre React y React Native. Es por esto por lo que la desviación en estos dos sprints es significativa.

Para los siguientes dos sprints hicimos una nueva distribución del equipo en la cual Ionatan se siguió encargando de completar el backoffice, mientras que Gabriel y Martin seguían con el nuevo milestone de tiempo real. Esta estrategia fue exitosa y volvimos a poder compensar la desviación.

En los siguientes tres sprints la estimación y lo realizado coincidió, demostrando que la experiencia no solo en las tecnologías, sino que también en la metodología es vital para lograr esto.

68

6.3.2. Desviación en horas

Figura 14: Desviación en horas

En la Figura 14: Desviación en horas se puede ver la comparación entre las horas que el equipo planeó dedicarle al proyecto y las que realmente pudo dedicarle.

Al comienzo del proyecto el equipo no le dedicó las horas que se había planteado. En los primeros dos sprints el equipo veía muy lejana la entrega del proyecto y, si bien la desviación no es muy grande, se realizaron menos de las horas pactadas. Los siguientes dos sprints son los que coinciden con las fechas de exámenes, por lo que tampoco se pudo llegar.

Fue por eso que para el siguiente sprint el equipo decidió que se iba a tener que dedicar más horas por sprint, y comprometerse a cumplirlas. A partir de ese momento no hubo más desviaciones. Lo que sí hubo fueron saltos en la cantidad de horas dedicadas los sprints 9 y 10, debido al desvío en los story points que se quiso compensar.

69

6.3.3. Velocidad del equipo

Figura 15: Velocidad del equipo

En esta gráfica se ve la velocidad del equipo a lo largo de proyecto. Se decidió no utilizar la velocidad utilizada en Scrum de story points completados por sprint. Esta decisión fue tomada porque en el caso de nuestro proyecto esto no tendría mucho sentido, ya que cada sprint no tenía una carga horaria fija. Por esta razón se decidió calcular la velocidad como story points obtenidos por srpint sobre horas en esfuerzo.

Esta métrica es útil para la gestión de proyecto para poder evaluar continuamente el rendimiento del equipo. Cuando se ve una baja en la velocidad se puede investigar y analizar cuáles fueron los motivos para así poder corregirlos. En caso de que continuamente el rendimiento esté por debajo de lo que el equipo se planteó, se pueden llegar a tomar decisiones más drásticas, como modificar el alcance o aumentar la dedicación en horas del equipo.

Esta gráfica se analizaba en cada sprint review y sprint restrospective. En estas reuniones el equipo analizaba los resultados respecto a la velocidad y discutía acerca de ellos.

Afortunadamente el equipo no tuvo que realizar cambios bruscos en consecuencia de esta

70 métrica. En el único momento que la velocidad le llamó la atención negativamente al equipo fue en los primeros sprints. Sin embargo, el equipo tenía la certeza de que esto se correspondía con la falta de experiencia en las tecnologías, y que a medida que el equipo obtuviera la experiencia la métrica iba a mejorar

Se puede observar claramente en la gráfica, que la misma tiene una tendencia clara a subir. Esto se debe a lo que el equipo sospechaba, a medida que se ganó experiencia en los lenguajes y en las metodologías de Scrum, la velocidad del equipo se vio incrementada.

En los últimos sprints se puede notar una clara baja en la velocidad del equipo. Esto es un fenómeno común en la Ingeniería de Software. Según Tom Cargill en su regla Regla del noventa-noventa:

“El primer 90% del código ocupa el 90% del tiempo de desarrollo. El 10% restante del código ocupa el otro 90% de tiempo de desarrollo.” [17]

Esta regla plantea que el primer 90% de un proyecto se realiza de manera constante y lineal, mientras que en el restante 10% es donde pueden aparecer más desafíos. En el caso de nuestro proyecto, el arreglo de los bugs que habíamos dejado para solucionar en el final terminó siendo más desafiantes de lo que se había estimado.

En promedio la velocidad del equipo fue 0.18 story points por hora.