Todo equipo de ingeniería de software productivo realiza un seguimiento de sus mejoras a través de un conjunto de indicadores elegidos llamados métricas de ingeniería KPI. Estas son las 5 métricas de desarrollo de Indicadores Clave de Desempeño (KPI) más esenciales que deberías empezar a rastrear hoy mismo.

¿Has trabajado alguna vez con un equipo de ingeniería en el que no se medían métricas KPI? Si lo has hecho, entonces probablemente sabes lo difícil que es saber si el equipo está en el camino de la liberación o no.

La verdad es que si quiere alcanzar sus objetivos de negocio, tiene que asegurarse de que su software cumple con todos los requisitos. Para ello, debe implementar métricas de ingeniería KPI en los procesos de desarrollo.

Al establecer métricas de ingeniería KPI para su equipo de desarrollo de software, evitará la mala calidad y el incumplimiento de los plazos. Lo que conseguirá es un equipo productivo y un producto de alta calidad.

Aquí hay cinco métricas de desarrollo KPI esenciales que debe seguir para alcanzar sus objetivos de negocio.

Sprint Burndown

¿Qué es el Sprint Burndown?

Los equipos ágiles organizan su desarrollo en sprints. Un sprint burndown mide cuánto trabajo completó el equipo durante un sprint.

¿Cuáles son los beneficios?

• Un sprint burndown es genial para mantener al equipo al tanto de cualquier bloqueo que se produzca.
• Al medir el desglose del sprint, puede comprobar si su equipo cumple con su previsión.
• Usando un gráfico de desglose del sprint, el equipo puede gestionar su progreso. Si el equipo se da cuenta de que puede no alcanzar el objetivo del sprint, los miembros del equipo pueden tomar las medidas adecuadas para mantenerse en el camino.

¿Cómo se mide?

Los equipos ágiles utilizan gráficos de desglose del sprint para visualizar su flujo de trabajo. El gráfico tiene un eje x que representa el tiempo y un eje y que representa la cantidad de trabajo que queda por completar. Puedes medir el tiempo en horas o puntos de historia. O bien, puede pensar en sus propias estadísticas. El objetivo principal aquí es tener todo el trabajo previsto completado al final del sprint.

Una herramienta que puedes utilizar es el gráfico de desglose del sprint de Jira. Para usarlo, debes crear una cuenta de Jira Software, y un proyecto Scrum de Jira Software.

Verás un eje vertical que representa los puntos de la historia. El eje horizontal muestra el tiempo. La línea roja en el gráfico representa la cantidad de trabajo que queda en el sprint. La línea gris es la línea de trabajo real. Si la línea roja está por debajo de la línea gris, significa que el equipo va por buen camino. Sin embargo, si la línea roja está por encima de la línea gris, significa que el proyecto está retrasado.

Release Burndown

¿Qué es el Release Burndown?

El Release Burndown ofrece una visión general del progreso del lanzamiento. Es similar al Sprint burn down, pero tiene un mayor alcance. Ayuda a los equipos a comprobar si conseguirán lanzar el producto en una fecha determinada. Si se dan cuenta de que van con retraso, pueden informar a los usuarios y a las partes interesadas sobre la demora. O, si no, pueden reducir el alcance del trabajo para lanzar el producto a tiempo.

¿Cuáles son los beneficios?

• Puede comprobar la rapidez con la que su equipo está trabajando en el backlog.
• Puede obtener información sobre cómo el trabajo añadido y eliminado afecta al progreso de su equipo.
• Puede predecir cuántos sprints necesitará su equipo para completar el trabajo.

¿Cómo se mide?

El burndown de lanzamiento se mide utilizando un gráfico similar al gráfico de desglose de sprints. La diferencia es que ahora, el eje horizontal representa los sprints, y el eje vertical representa el trabajo restante (días, horas o puntos de historia).

Por ejemplo, veamos la imagen de abajo. Es un gráfico de burndown de lanzamiento de Jira. Puedes ver que el equipo ha establecido inicialmente cuatro sprints y 43 puntos de historia. Durante esos cuatro sprints, el equipo ha reducido el número de historias de 43 a 26. El equipo también ha previsto que el lanzamiento del producto llevará siete sprints más, resultando 11 en total.

Tiempo de ciclo

¿Qué es el tiempo de ciclo?

El tiempo de ciclo es una métrica de desarrollo KPI que mide cuánto tiempo pasa el equipo trabajando en una tarea. Los gráficos de tiempo de ciclo son utilizados por los Scrum Masters y Product Owners para controlar la eficiencia del proceso de desarrollo.

¿Cuáles son los beneficios?

• Proporciona información sobre el rendimiento general del equipo.
• Permite estimar la finalización de las tareas futuras.
• Puede notar cualquier cuello de botella y ralentizaciones en el flujo de trabajo.

¿Cómo se mide?

El tiempo de ciclo es igual a la fecha de finalización menos la fecha de inicio. Por ejemplo, si el equipo comienza a trabajar el 1 de diciembre y termina el 10 de diciembre, el tiempo del ciclo es de nueve días.

Si el equipo comienza a trabajar el 1 de diciembre y termina la tarea ese mismo día, entonces su tiempo de ciclo no será cero sino uno. Para los proyectos que comienzan y terminan el mismo día, el tiempo de ciclo es igual a la fecha de finalización menos la fecha de inicio +1.

Puede sustituir los días por semanas, horas o incluso sprints.

Considere el uso de gráficos de tiempo de ciclo para visualizar su flujo de trabajo. Estos gráficos muestran el tiempo que tarda una cuestión en completarse frente al día de finalización.

Por ejemplo, veamos el gráfico siguiente. En el eje de abscisas, puede ver la fecha en que se cerró la tarea, y en el eje de ordenadas, puede ver el tiempo empleado. Los círculos verdes son tareas. Un círculo sólido indica un grupo de problemas, mientras que un círculo abierto indica un solo problema. Si utiliza una herramienta como Jira, puede ver la clave de la tarea, su código y el tiempo de ejecución pasando el ratón por encima del círculo. La línea roja representa el tiempo de ciclo medio, y la línea azul representa el tiempo de ciclo medio rodante.

El objetivo final es que el equipo tenga tiempos de ciclo consistentes para los elementos de trabajo que tienen valores de puntos de historia similares. Los valores más bajos significan que el equipo está trabajando eficientemente, mientras que los valores más altos pueden indicar cuellos de botella en el proceso de trabajo.

Velocidad del equipo

¿Qué es la velocidad del equipo?

La velocidad es otra métrica de ingeniería KPI ágil que mide la cantidad de trabajo que un equipo completa durante un sprint. La cantidad de trabajo se suele medir en puntos de historia u horas.

Los propietarios de los productos utilizan la velocidad para calcular la rapidez con la que un equipo puede trabajar a través del backlog. El índice de velocidad es único para cada equipo, y no se debe comparar la velocidad entre equipos.

Por ejemplo, digamos que se quiere completar 300 puntos de historia en el backlog. Usted sabe que el equipo de desarrollo, en promedio, completa alrededor de 50 puntos de historia por iteración. Con esa información a mano, puedes predecir que el equipo necesitará seis iteraciones para completar el trabajo requerido.

¿Cuáles son los beneficios?

• Es muy útil para la previsión.
• Puede ayudar a planificar futuros sprints.
• Puede ayudarle a entender si el equipo está bloqueado o si sus cambios de proceso están funcionando.

¿Cómo se mide?

Si tienes un equipo estable, conseguirás establecer una velocidad media midiendo al menos 5-7 sprints. Si tu sprint habitual es semanal, y el equipo completa 250 puntos de historia en un periodo de cinco semanas, entonces tu tasa de velocidad media es de 50 puntos de historia por semana.

Miremos el gráfico de velocidad de Jira que aparece a continuación. Las barras azules representan el compromiso, y las verdes el trabajo real completado. En el sprint número 1, el equipo planificó 16 puntos de historia y completó 16 puntos de historia. Esto indica que sus estimaciones eran correctas. Sin embargo, en el segundo sprint, el equipo planificó 19 puntos de historia, pero sólo completó 12. Esto sugiere que la próxima vez, deberían reducir su plan.

Un flujo inconsistente es un indicador de que tienes problemas en el desarrollo y necesitas hacer cambios.

Flujo acumulativo

¿Qué es el flujo acumulativo?

El flujo acumulativo visualiza el estado de sus tickets durante un periodo de tiempo. Muestra el cambio de sus tickets de un estado a otro a medida que su proyecto avanza.

¿Cuáles son los beneficios?

• Es útil para identificar cuellos de botella.
• Ayuda a los equipos a asegurarse de que el flujo de trabajo es consistente.
• Muestra la estabilidad de su flujo de trabajo.
• Le ayuda a entender cómo puede hacer que su proceso sea más predecible.

¿Cómo se mide?

La forma más fácil de medir el flujo de trabajo acumulado es utilizando gráficos. Estos visualizan las tres métricas de ingeniería de software más importantes de su flujo, incluyendo el tiempo de ciclo, el rendimiento y el trabajo en curso.

Veamos el siguiente gráfico. El eje horizontal x indica el tiempo, mientras que el eje vertical y indica los elementos de trabajo. Los diferentes colores representan los distintos estados del flujo de trabajo. Si las bandas progresan en paralelo, significa que su rendimiento es estable. Indica que el número de nuevas tareas que entran en su flujo de trabajo es el mismo que el de las que salen de él.

Si una banda se estrecha rápidamente, significa que tiene más capacidad de la que necesita. Deberías reubicar la capacidad para optimizar el flujo.

Si una banda se está ensanchando rápidamente, significa que hay más tarjetas que entran en la etapa correspondiente que asignaciones que salen de ella.

Sumando

El seguimiento de las métricas de desarrollo de KPIs señaladas anteriormente puede llevar a un resultado exitoso del proceso de desarrollo de productos. Conseguirá dejar de cuestionar el progreso de su proyecto y obtener una visión detallada de cada etapa del ciclo de vida del desarrollo.

Si quiere poner fin al círculo vicioso de los productos de baja calidad, el incumplimiento de los plazos y los fallos de código, empiece a implementar el desarrollo de KPI hoy mismo. Conseguirá lanzar un producto de primera calidad sin los riesgos que lo acompañan.