Medir es una labor fundamental para entender y mejorar el flujo de trabajo en proyectos de desarrollo de software con enfoques Agile y DevOps. En este artículo vamos a analizar cuatro métricas que nos darán información de gran utilidad para optimizar nuestras entregas de software y ayudar al equipo de desarrollo a poner el foco en satisfacer a los clientes aportando valor continuamente.
Lo que vas a ver en este post:
¿Por qué medir en desarrollo de software?
Son muchas las razones por las que es conveniente medir y analizar los proyectos de desarrollo de software. Algunas de las principales son:
- Tomar decisiones basadas en datos.
- Identificar mejoras y aplicarlas en el futuro.
- Planificar de forma más precisa los proyectos.
- Mejorar el rendimiento de los equipos.
- Entregar productos de mayor calidad y más rápido.
- Reducir los costes.
¿Cómo medir en Agile y DevOps?
Las metodologías Agile y DevOps nos dan algunas indicaciones que nos ayudan a determinar qué debemos medir en nuestros proyectos de software, de qué manera y con qué objetivo.
Métricas en metodologías ágiles
Por una parte, el Manifiesto ágil recoge 4 valores y 12 principios de las metodologías ágiles. Dentro de él, encontramos dos ideas muy interesantes relativas a la medición:
- Primero, habla de que el software funcionando es la medida principal de progreso. Es decir, no debemos analizar el trabajo de los equipos de desarrollo en base a KPIs tradicionales (centrados en la producción, en la finalización de tareas) sino en software en funcionamiento (focalizado en los resultados).
- Segundo, expone que la prioridad debe ser satisfacer al cliente a través de la entrega temprana y continua de software con valor. En otros términos, los esfuerzos deben destinarse a entregar pronto y continuamente funcionalidades a los usuarios.
Qué medir en DevOps
Por su parte, DevOps nos orienta a la hora de decidir qué medir y cómo a través de dos de sus objetivos:
- Optimizar los procesos de despliegue para llegar antes al usuario. DevOps trata de llegar cuanto antes a los usuarios y cumplir lo más pronto posible los objetivos de negocio. Y lo hace a través de la automatización.
- Reducir el tiempo de entrega. Al igual que Agile, DevOps persigue entregar productos de manera más rápida.
Como vemos, tanto Agile como DevOps se centran en gran medida en los tiempos de entrega. Por lo que, sin duda, será este aspecto uno de los que resultará más clave medir en nuestros proyectos de software.
A continuación, vamos a ver cuatro métricas para proyectos de software con enfoque Agile y DevOps que nos ayudarán a conocer y mejorar todo lo relativo a los tiempos de entrega, para llegar antes a los usuarios y conseguir más software funcionando en sus manos. Concretamente, detallaremos qué miden, cómo se calculan, sus ventajas y desventajas y cómo calcularlas en base a nuestra experiencia.
4 métricas de Agile y DevOps para entregar más software rápidamente
Lead Time for Changes
El Lead Time for Changes o tiempo de ejecución para cambios mide la cantidad de tiempo que tarda un commit en llegar a producción. Es una de las cuatro medidas clave (Four Key Metrics) para analizar el rendimiento del desarrollo de software DevOps.
Es una métrica que refleja la eficiencia del proceso de desarrollo, la complejidad del código y la capacidad del equipo. Resulta de gran utilidad si queremos poner el foco en entregar software más rápidamente. En este artículo te explicamos con todo detalle qué es el Lead Time for Changes, cómo medirlo y cómo reducirlo.
Esta gráfica, obtenida mediante la plataforma de gestión del flujo de valor SENTRIO, nos muestra un caso real de un proyecto de desarrollo de software con el Lead Time for Changes de cada una de las tareas y su correspondiente línea de tendencia.
Los puntos que encontramos por encima de la línea, son anomalías, tareas que el equipo ha tardado más tiempo en llevar a cabo que la mayoría y que han elevado la línea de tendencia. Por ello, parece interesante analizar qué ha sucedido en estas tareas que elevan la tendencia para tomar decisiones al respecto. El objetivo es que la línea de tendencia sea más baja o vaya bajando.
Workflow Efficiency
El Workflow Efficiency o eficiencia del flujo de trabajo es la relación entre el tiempo en el que el equipo aporta valor y el tiempo en el que no lo hace durante todo el tiempo que tarda en entregar un software. Por tanto, la eficiencia de flujo calcula la proporción de Working Time (tiempos activos) y de Waiting Time (tiempos de espera) dentro del tiempo total dedicado a finalizar un proceso. Es una de las métricas más importantes en la gestión Lean y de las medidas más interesantes para conocer el flujo de valor.
Se entiende como Working Time el tiempo en el que el equipo ha trabajado activamente para cumplir el objetivo en cuestión. Mientras que se habla de Waiting Time para referirse a aquellos momentos en los que el equipo no se ha dedicado a trabajar en la tarea por dependencias, cambios de prioridades, exceso de trabajo abierto…
El Workflow Efficiency es una medida muy valiosa. Sin embargo, es difícil de obtener. Algunas herramientas permiten crear tareas con estados, pero en ellas no resulta sencillo decidir qué estados son activos y cuáles son de espera, como tampoco obtener el dato de cuánto tiempo ha pasado la tarea en unos y en otros. En este sentido, plataformas como SENTRIO nos facilitan mucho el trabajo y proporcionan directamente el tiempo que ha pasado cada tarea en cada estado a través de gráficas como ésta:
En este ejemplo podemos ver cómo la eficiencia de flujo va creciendo a lo largo del tiempo. Parece que el equipo de desarrollo fue adoptando medidas que fueron efectivas. Conviene recordar que el objetivo es seguir creciendo, que el equipo cada vez sea más eficiente.
Task Distribution
El Task Distribution o distribución de tareas mide cómo reparte el equipo su tiempo total de trabajo entre los diferentes tipos de tareas que existen. No es una medida en DevOps al uso, pero es muy interesante porque da lugar a muchos debates acerca de cómo el equipo está priorizando su trabajo y si está dirigiendo de forma acertada sus esfuerzos.
Esta distribución se puede calcular sobre el número de items realizados de cada categoría o sobre la cantidad de tiempo dedicado a cada tipo de tarea. Una vez tenemos esta distribución, debemos plantearnos si está alineada con los objetivos de negocio y tomar decisiones al respecto.
En esta gráfica de Task Distribution distinguimos cuatro tipos de tareas: features (funcionalidades), bugs (resolución de errores), tasks (tareas) y spikes (análisis e investigación tecnológica):
Nos encontramos ante un ejemplo en el que el equipo ha priorizado de forma bastante coherente. La cantidad de errores que gestionan cuando se producen está controlada. Así, ocupan de forma proporcional el espacio dedicado a los otros tipos de tareas para mantener la distribución inicial. Y el porcentaje dedicado a errores está entre márgenes controlados (sin superar el 40% en este caso).
Una ventaja de utilizar SENTRIO para conocer esta distribución es que te permite determinar qué tipos de tareas son las que aportan valor y te calcula el porcentaje de tiempo que el equipo está entregando valor. En este ejemplo es de más del 80%.
Burndown chart
Un burndown chart o gráfico de trabajo pendiente es una representación visual del trabajo pendiente a realizar en un periodo de tiempo determinado. No es una métrica en sí, sino una gráfica de gran utilidad para conocer el progreso del equipo durante el desarrollo de un Sprint. Si bien, también se puede ampliar al transcurso de un proyecto, un servicio, una entrega, un hito o el periodo que deseemos.
Como vemos, este gráfico relaciona dos variables: el trabajo a llevar a cabo en el eje vertical (expresado en puntos de historia, días ideales u otra unidad) con un tiempo establecido que durará el Sprint en el eje horizontal. Y representa una línea de entrega ideal (con una entrega proporcional durante todo el periodo) y una línea de cómo se va produciendo realmente la entrega.
Cómo interpretar un burndown chart
Lo ideal es que la línea real se asemeje lo más posible a la línea de referencia. No obstante, en la realidad pueden darse diferentes antipatrones, situaciones no deseadas a las que debemos prestar atención:
- Que el equipo finalice el trabajo más tarde de lo acordado, por asumir más trabajo del que puede gestionar. Es habitual en los primeros Sprints del proyecto hasta que el equipo coge velocidad.
- Que el equipo termine antes de tiempo el Sprint, por haber estimado a la baja y no estar asumiendo todo el trabajo que podría.
- Momentos en los que la línea de evolución es completamente horizontal, porque se están bloqueando tareas, hay dependencias, se abren muchas tareas que no se finalizan… En definitiva, por la existencia de mucho Waiting Time.
- Existen subidas en la línea de evolución, debidas a que se añade trabajo pendiente durante el Sprint. Habrá que plantearse si estas tareas eran tan urgentes y no podían esperar al siguiente.
- Se producen caídas pronunciadas en la línea de evolución, porque los sistemas de despliegue son poco óptimos y el equipo entrega todo al final o porque el trabajo no se ha dividido granularmente.
Como explicamos también en este artículo, el Burndown chart es una de las herramientas más interesantes para medir la productividad en desarrollo de software y optimizar las entregas.
Ejemplo real de burndown chart de un proyecto de software
En este burndown chart real se observa que en los primeros momentos el equipo de desarrollo no entrega apenas, hasta que la pendiente empieza a descender de forma progresiva. Parece conveniente analizar qué estaba pasando al principio:
Si nos centramos en la situación actual, vemos que en los últimos momentos el equipo está entregando más deprisa que lo que marca la línea ideal. Por lo que parece que terminará en tiempo el proyecto.
Asimismo, parece interesante ver qué ocurrió en aquellos puntos que desencadenaron bajadas más pronunciadas de la línea. Podrían ser acciones que supusieron mejoras.
No obstante, en general, la bajada de la línea es progresiva, por lo que el “estancamiento” inicial pudo deberse a que al principio costó al equipo coger velocidad.
Webinar de métricas en entornos ágiles más útiles
Si quieres profundizar más acerca de estas medidas, Guillermo Rocha, especialista en gestión de procesos, hace un repaso por las métricas más útiles en entornos ágiles y DevOps en la actualidad en este webinar:
Conclusión
En este artículo hemos analizado cuatro métricas fundamentales para mejorar las entregas de software en entornos Agile y DevOps. Un conjunto de medidas que nos permiten conocer y mejorar los tiempos de entrega de nuestro equipo, analizando su capacidad para realizar cambios, su eficiencia de trabajo, su distribución de esfuerzos y su progreso durante un Sprint.
Asimismo, hemos visto ejemplos reales de cómo aplicarlas utilizando SENTRIO, la plataforma de Value Stream Management con la que podrás conectar todas las herramientas que intervienen en el proceso de desarrollo y entrega de software y obtener una visión completa y en tiempo real para ayudarte a tomar mejores decisiones.
Visualiza en tiempo real y con información detallada la velocidad y calidad de tus productos software, medidos con métricas reconocidas en la industria tecnológica. ¿Te ayudamos? ¡Solicita una demo gratuita ahora!
