Cómo medir la productividad en desarrollo de software

En este post vamos a ver cómo medir la productividad en desarrollo de software para mejorar el rendimiento de nuestro equipo. Repasaremos por qué medir la productividad de un equipo de desarrollo y qué métricas de productividad nos pueden ser más útiles.

¿Qué es la productividad en desarrollo de software?

La productividad es una relación entre la entrada de una actividad y su salida. Por tanto, la productividad en desarrollo de software es la relación entre el software creado y el esfuerzo requerido para desarrollarlo.

No obstante, la productividad de un equipo de desarrollo de software es muy difícil de medir.  A diferencia de otros sectores, en su análisis intervienen numerosos activos intangibles y resulta muy complicado decidir qué considerar salida.

Tradicionalmente, se optó por la cantidad de código o requerimientos desarrollados. Pero estos enfoques dejaban muchos aspectos fuera y eran problemáticos, ya que anteponían en su análisis la cantidad a la calidad del código y no tenían en cuenta la dificultad de la tarea desarrollada.

Cómo medir la productividad de un programador

No existe un único indicador para medir la productividad en desarrollo de software. En su lugar, podemos utilizar un conjunto de métricas para hacernos una idea más o menos completa de lo que está ocurriendo en nuestro equipo y así poder trabajar en la dirección de la mejora continua.

A la hora de calcularla, se deben considerar un número limitado de factores vinculados con el software desarrollado, el equipo de desarrollo y los usuarios. El objetivo no se limita a que nuestros equipos desarrollen software que funcione de forma rápida y efectiva, sino que además deben entregar valor al usuario final.

De este modo, para la medición de la productividad se deben contemplar dos ámbitos: uno interno, relativo al proceso de producción de código de calidad, y otro externo, que involucra a los usuarios. Igualmente, conviene valorar dos etapas en el desarrollo de software, la creación de código nuevo y su mantenimiento.

Pero más allá de todo lo anterior, la cantidad de indicadores disponibles no debe distraernos de nuestro objetivo final: utilizar estas métricas para aumentar la productividad en el desarrollo de software. 

Por qué medir la productividad en desarrollo de software

Para poder mejorar la productividad de un equipo que desarrolla software, primero debemos conocer su rendimiento y detectar qué aspectos debemos modificar para poder hacerlo. Es decir, debemos medir diferentes áreas del proceso de producción y ver qué está funcionando y qué podemos mejorar y cómo. Y, además, conocer el impacto que estas mejoras pueden tener en nuestro negocio.

Utilizar métricas de productividad en desarrollo de software nos permitirá tener una visión completa del rendimiento de nuestro equipo y de la salud de nuestro producto. Son muchas las razones y las ventajas de medir la productividad:

• Ser más precisos en la planificación de nuestros proyectos. Al estimar de forma más acertada los costes, podemos priorizar mejor las tareas. Al estudiar los procesos, podemos conocer su estado y ver qué prácticas nuevas o cambios han funcionado. Y al analizar la relación tiempo requerido / calidad que aporta una acción podemos escoger mejor aquellas que pueden resultarnos más beneficiosas.

• Mejorar el rendimiento de nuestro equipo. Las métricas de productividad de desarrollo de software aclaran las expectativas. Nuestro equipo estará más comprometido si sabe lo que se espera de él. Además, ayudan a detectar y eliminar los obstáculos que el equipo está encontrando, propiciando que trabaje más feliz y con un mejor rendimiento.

• Entregar productos de mayor calidad. Gracias a simplificar flujos de trabajo y mejorar los ciclos de vida de nuestros productos.

Todas estas cuestiones y muchas otras nos ayudarán a reducir los costes de producir software y nos conducirán a entregar más valor al usuario final.

KPIs para equipos de desarrollo de software

Las metodologías Agile emplean métricas que nos pueden ser de gran utilidad para medir la productividad de nuestro equipo de desarrollo de software. A continuación recogemos algunas de las medidas más interesantes y habituales:

Métricas para optimizar la entrega de software

Burndown chart

Un gráfico de trabajo pendiente (burdown chart) es una representación gráfica del trabajo que queda por hacer en el tiempo que dura un proyecto de desarrollo de software. Habitualmente, relaciona el trabajo pendiente (expresado en puntos de historia, días ideales u otra unidad), en el eje vertical, con el tiempo estimado del proyecto (duración del sprint o número de sprints), plasmado en el eje horizontal.

El burndown chart es muy útil para:

• Monitorizar el avance del equipo en un proyecto (a lo largo de un sprint o de varios)
• Mantener al equipo trabajando según lo previsto
• Comparar el trabajo estimado frente a la progresión real

En esta representación podemos ver cuestiones significativas para nuestro proyecto de software, como cambios repentinos en el trabajo restante por haberse añadido requerimientos adicionales o no haberse distribuido el esfuerzo de forma granular. Así como finales de sprints tempranos o incumplimientos de plazos, por falta o exceso de trabajo programado.

De este modo, un burdown chart es una herramienta valiosa para visualizar el progreso de un proyecto Scrum y un informe habitual en desarrollo ágil de software.

Velocidad del equipo

La velocidad del equipo o Team Velocity mide la cantidad de trabajo o software desarrollado por un equipo durante un Sprint determinado. Así, esta métrica de productividad refleja la velocidad a la que un equipo de desarrollo Scrum entrega valor continuamente. Es decir, la cantidad media de Product Backlog convertida en Incremento de producto durante un Sprint.

La velocidad se calcula sumando los puntos de todas las historias de usuario completadas al final de un Sprint. Es una métrica muy útil para mejorar la estimación y la planificación.

Esta métrica permite:

• Establecer mejores expectativas de entrega. Cuánto alcance podremos entregar en una fecha específica o predecir mejor una fecha en la que podremos entregar un alcance concreto.
• Conocer los límites de nuestro equipo y hacer pronósticos de sprints más realistas. Definir mejor la cantidad de alcance a la que nos comprometemos en un sprint.
• Identificar cuando un equipo está bloqueado y detectar imprevistos

Throughput

El rendimiento o Throughput mide el número de unidades de trabajo completadas por el equipo en un periodo de tiempo. En un sistema Kanban, donde representamos el trabajo en tarjetas, el rendimiento sería el número de tarjetas Kanban terminadas en un tiempo determinado.

De este modo, es una métrica muy valiosa para hacernos una idea de la cantidad de trabajo que un equipo es capaz de completar en un intervalo de tiempo concreto. Junto con el tiempo de ciclo, que explicaremos a continuación, es muy útil para conseguir que nuestros equipos sean más predecibles en sus entregas. 

Utilizar esta métrica es muy útil para identificar bloqueos del equipo o sobrecargas de trabajo, cuando comparamos el rendimiento histórico.

Cycle Time y Lead Time

El tiempo de ciclo o Cycle Time mide el tiempo que un equipo tarda en realizar una tarea, tarjeta o resolución de error desde que comienza a trabajar en ello. Es una métrica de gran valor para gestionar de forma adecuada las expectativas de los usuarios o clientes.

Por su parte, el tiempo de entrega o Lead Time se refiere al tiempo que el equipo tarda en realizar una tarea desde que ésta es planteada. Es decir, desde que una funcionalidad es definida y ésta es entregada al usuario final.

Por tanto, el tiempo de ciclo y el tiempo de entrega son métricas fundamentales para:

• Conocer el flujo de trabajo de nuestro equipo
• Identificar cuellos de botella
• Comprender la capacidad de trabajo de nuestro equipo

Métricas relacionadas con la entrega de valor al usuario (calidad)

Ratio de bugs

El ratio de bugs (bug rates) mide la cantidad de errores que contiene nuestro código cuando implementamos nuevas funcionalidades. En definitiva, esta métrica muestra si nuestro producto aporta valor o no. Se pueden considerar el número de errores, pero también la gravedad de los mismos. Así como establecer valores máximos aceptables para el correcto desarrollo de nuestro proyecto.

Ciclo de vida de los Pull Requests

Cuando un desarrollador crea una nueva funcionalidad o resuelve un bug solicita la integración de estas mejoras al repositorio principal del proyecto. Esta solicitud se conoce como pull request y pide al resto del equipo la revisión del código desarrollado para recibir feedback y conseguir su aceptación.

Realizar frecuentemente un seguimiento del número de pull requests abiertas, mezcladas y desplegadas en nuestro equipo puede darnos datos de gran interés, que nos ayudará a implementar mejoras en el proceso de trabajo. Un tiempo demasiado largo de revisión de estas solicitudes o una incorrecta separación de cada funcionalidad puede afectar a la velocidad de desarrollo o rendimiento de nuestro equipo.

Deuda técnica

La deuda técnica se refiere al esfuerzo adicional que deberemos realizar para implementar una nueva funcionalidad o modificar una existente en nuestro producto de software, por haber acumulado deficiencias en su calidad interna a la hora de desarrollarlo. Suele ser resultado de priorizar la entrega al cliente frente a aspectos técnicos del código.

Es, por tanto, una métrica estrechamente ligada con la productividad de nuestro equipo de software. Una mayor deuda técnica implica más esfuerzo y costes y una menor productividad, por las acciones de mantenimiento posteriores que se deberán realizar.

En este artículo puedes profundizar más acerca de qué es la deuda técnica.

Conclusiones: cómo medir la productividad de forma correcta

Medir la productividad en desarrollo de software es una labor compleja, pero de gran utilidad si queremos mejorar el rendimiento de nuestro equipo. Y utilizar métricas agile como las que hemos visto parece la mejor forma de hacerlo. A la hora de utilizarlas, no debemos olvidar que:

• Debemos emplear estas métricas para identificar problemas y mejorar el desempeño de equipos, pero no para cuantificar el rendimiento de un programador individual.
• Utilizar una métricas u otras dependiendo del equipo, el flujo de trabajo y el tipo de proyecto. El ratio de errores puede ser interesante para medir la productividad de un equipo backend, mientras que para un equipo de desarrollo web puede ser más relevante el tiempo de respuesta.
• Cada equipo debe proporcionar las métricas más útiles para medir su rendimiento. A través de estas métricas debemos desafiarlo y recompensarlo cuando logre una mejora determinada.
• Contraponer unas métricas con otras para evitar que la medida se vuelva en nuestra contra y los esfuerzos del equipo se orienten a engañar a las estadísticas.
• La adopción de estas métricas no es suficiente para mejorar el rendimiento de nuestro equipo. No sirve de nada obtener esta información valiosa si no llevamos a cabo los ajustes necesarios. Estas implementaciones no deben ser unilaterales, sino consensuadas y desarrolladas conjuntamente por el equipo.

En Sentrio somos muy conscientes del valor de las métricas. Por ello, a través de nuestra plataforma te proporcionamos la información que necesitas para tomar decisiones que reduzcan los costes y aceleren el time to market de tus productos de software. ¿Quieres entregar software de más calidad en menos tiempo? ¡Te ayudamos!