Medir la productividad de un equipo de desarrollo es uno de los desafíos más difíciles que enfrentan actualmente los gerentes de software. Muchos gerentes abogan por una gama de métricas complejas para evaluar la productividad, mientras que otros no utilizan ninguna métrica en absoluto.
En nuestra experiencia, hemos encontrado que las siguientes cinco métricas de desarrollo son esenciales para todos los gerentes de software:
- Tiempo de espera
- Agitarse
- Impacto
- Días activos
- Eficiencia
¿Las buenas noticias? Estas métricas de desarrollo pueden derivarse de los datos de control de versiones que están en tu GitHub/BitBucket/GitLab u otro repositorio de código. Los metadatos de estos modernos repositorios de código proporcionan una visión en tiempo real de los patrones de trabajo de ingeniería y la salud de tu equipo.
1. Tiempo de entrega
El plazo de entrega es el período de tiempo entre el comienzo del desarrollo de un proyecto y su entrega al cliente. El historial del tiempo de entrega de su equipo de desarrollo le ayudará a predecir cuándo un artículo estará listo con un alto grado de precisión.
Estos datos son incluso útiles si su equipo de desarrollo no proporciona rutinariamente estimaciones, ya que las predicciones pueden basarse en los plazos de entrega de proyectos similares. Como ejemplo, supongamos que el 50 por ciento de las solicitudes de características similares tienen un plazo de entrega de dos semanas o menos, y el 90 por ciento de estos proyectos tienen un plazo de entrega de un mes o menos. Podrías proporcionar con confianza un plazo de un mes para el proyecto actual.
2. Código Churn
El Code Churn es el porcentaje de código propio de un desarrollador que representa una edición de su propio trabajo reciente. Típicamente se mide como líneas de código (LOC) que fueron modificadas, añadidas y eliminadas en un corto período de tiempo, como unas pocas semanas. El propósito principal de la medición de la rotación es permitir a los administradores de programas informáticos y a otros interesados en el proyecto controlar el proceso de desarrollo de programas informáticos, especialmente su calidad. Cuando la rotación comienza a aumentar, puede ser un indicador de que algo está mal en el proceso de desarrollo.
Por ejemplo, imagínese una situación en la que un desarrollador recibe un conjunto de requisitos muy opaco, como «la aplicación necesita ajustes», algo que no es infrecuente cuando se trabaja con las partes interesadas en el producto. Cuando esta desconexión se convierte en semanas de iteración en la misma característica sin mucho avance, eso se mostrará como una pérdida de código. La tasa de abandono también puede ayudar a identificar problemas con los desarrolladores individuales. Por ejemplo, un aumento repentino de la tasa de abandono puede indicar que un desarrollador tiene dificultades para resolver un problema concreto o que está puliendo repetidamente una característica que está lista para su lanzamiento. Una alta tasa de cancelación de clientes también puede significar que un desarrollador está poco comprometido. Otras causas de una elevada tasa de cancelación de clientes incluyen un equipo de producto indeciso que tiene al desarrollador corriendo en círculos. Para más información, mira las 6 causas de la pérdida de código y qué hacer con ellas.
3. Impacto
El impacto es una medida del efecto que los cambios de código tienen en su proyecto, y una forma de considerar la carga cognitiva que suponen para el desarrollador que los implementó. Por lo tanto, los conjuntos de cambios que son más difíciles de implementar resultarán en una mayor puntuación de impacto. El impacto de un conjunto de cambios depende de diversos factores, como la cantidad de código en los cambios, la gravedad de esos cambios y el número de archivos que los cambios afectaron.
Por ejemplo, la adición de 100 nuevas líneas de código a un archivo, podría tener un impacto mucho menor que un cambio con muchas menos líneas afectadas si incluye múltiples inserciones y supresiones a través de múltiples archivos. También podría comparar los valores de impacto actuales con los valores históricos para determinar el efecto de un conjunto de cambios recientes.
4. Días activos
Un Día Activo es un día en el que un ingeniero contribuyó con código al proyecto, que incluye tareas específicas como escribir y revisar el código. Los ingenieros tienen una habilidad única para construir y resolver difíciles problemas conceptuales, por lo que contribuir con código es una de las cosas más importantes que un ingeniero puede hacer. Las tareas no relacionadas con la ingeniería, como la planificación, las reuniones y la búsqueda de especificaciones son inevitables. De hecho, la mayoría de los equipos pierden al menos un día a la semana en estas actividades.
El cálculo de este tipo de datos permite ver los costos ocultos de las interrupciones, como por ejemplo, cómo una reunión de todos los trabajadores a mitad de la semana afecta la productividad general. Con Días activos, puedes proteger la atención de tu equipo y asegurarte de que el proceso no se convierta en una carga.
5. Eficiencia
La eficiencia es el porcentaje del código aportado por un ingeniero que es productivo, lo que generalmente implica equilibrar la salida del código con la longevidad del mismo. La eficiencia es independiente de la cantidad de código escrito. Cuanto más alta es la tasa de eficiencia, más tiempo ese código está proporcionando valor comercial. Una alta tasa de rescisión lo reduce.
Los diferentes tipos de ingenieros tendrán diferentes tasas de eficiencia. Un ingeniero que esté abriendo camino a una nueva solución puede intentar muchos caminos en la fase de descubrimiento, y se puede esperar una baja tasa de eficiencia. Los ingenieros más prolíficos contribuyen con muchos pequeños compromisos, con una modesta tasa de abandono, lo que resulta en una alta tasa de eficiencia. Comprender la tasa de eficiencia típica de un ingeniero puede ayudar a entender su carácter y dónde encajarán mejor.
Eso concluye nuestra opinión sobre las métricas esenciales de los desarrolladores. Sugerimos que nos centremos en estas métricas en particular porque no se puede rastrear todo, y no todas las medidas son una métrica clave.